From: DSP Hotline

Subject: 320C30 Simulator Bug List

-------------------------------------------------------------------------------
* RELEASE 2.10 BUGLIST                                                        *
* Update - 11/18/94                                                           *
*                                                                             *
* This file contains a list of bugs in the release 2.10 of the 320C30         *
* Simulator                                                                   *
*                                                                             *
* All bugs will be fixed in the next production release unless othwerwise     *
* indicated. There will sometimes be references to internal versions in       *
* this list. For that reason you must always refer to the release status      *
* information (published every two weeks) to verify the availability of a     *
* specific revision.                                                          *
*                                                                             *
-------------------------------------------------------------------------------


				Part 1

4380     V2.00  will fix in V2.01
  Consider the following group of instructions:

     LDI     10h, RC         ;

     RPTB     LOOP

     .
     .
     .
LOOP     NOP     *ar0++
     .
     .

All the instructions in the repeat block are executed 10h number of
times.  the last instruction " LOOP NOP *ar0++" is not executed.
The pointer ar0 does not increment by one for each repitition of
the loop.


4797     V2.10  will fix next release
  In some rare cases the simulator may reexecute a sequence of instructions
following an LDI instruction that is the target of a branch instruction.
This may occur under the following circumstances.

     1.  The code is located in internal memory
     2.  An address referenced by the LDI instruction is in
         external memory and the number of wait states set
         on that memory is > 2.


begin:     ldi     @op0_ptr,ar0     ; 1
     ldi     @op1_ptr,ar1     ; 2
     ldi     @store_ptr,ar1     ; 3 
     ldi     10,r1          ; 4 
     ldi     10,r2          ;
     mpyi3     r1,r2,r0     ; 
     sti     r0,*ar2          ;   
     br     begin          ;  


In the example above after the  "br begin" instruction is executed
and you begin single-stepping with instruction 1, the simulator
will execute 1, 2, 3 and then refetch instruction 1 and continue
execution.


Workaround:  Place a NOP at the branch label

i.e.          begin: NOP
              LDI @op0_ptr,ar0
              ..
              ..


4914     V2.10  will fix next release
  Note: This problem is present when operating with -mv31 and -mm1 !

The simulator does not correctly simulate the operation of the interrupt
vectors for the C31 in microcomputer/boot loader mode (-mm1 option). 
The simulator behaves as if C31 is operating in micrprocessor mode.
(i.e. The simulator still expects the vectors to be located starting at
0x0 and expects addresses of interrupt service routines rather than
branches to those locations at the vector address.)


5065     V2.10  will fix next release
  The simulator will perform a transfer from the serial port even though
the XRESET/RRESET bits in the serial port global control register have
not been set.  In addition, the first transfer will occur as soon as
both serial port control registers have been initialized. There should
actually be a few cycles of delay before the transfer.


5481     V2.10  will fix in V2.11
     According to page 13-4 of the C Source Debugger, the "?" command is
supposed to be available in profile mode.    However, the command "?"
is NOT recognized in profile mode.


5501     V2.10  will fix in V2.11
  The serial prot read bit gets set in the IF register, even when interrupt
has not been enabled.

Serial port control regs:

   spgcr = 0x0c3c0046 
   fsx/dx(clkx): 0x111
   fsr/dr(clkr): 0x111
   tim ctrl    : 0xf
   tim prd     : 0x4


5515     V4.50  will fix in V4.51
  The SAMPLE.OUT file with the C31 simulator is inconsistent with the C source
debugger.   The meminit() is not even in the SAMPLE.C program.

On page 4-14 of the TMS320C3x C Source Debugger User's Guide, users are 
told if they issue the command "go meminit" then the simulator will run
to the meminit label in the DISASSEMBLY window.   This is not the case,
because the meminit function is not included in the SAMPLE.C source code.


5666     V2.20  will fix in V2.21
       C30  simulator doesnot handle register conflicts in the pipeline after
     a parallel store instruction properly .The  simulator  takes  the  old
     value of the conflicting register.

     An example section of asm and C code is given below:
-------------------------------------------------------------------------
       :
       :
    STI      R1,*+FP(2)                    ;
    ANDN     R1,R0,R2                      ;  u &= ~m;
    STI1     R2,*+FP(1) ||  STI2R2,*AR0    ;

    LDI      @CONST+2,AR1      <---+       ;
    tms_poke(TMS_A_S0_GLOBAL_CONTROL,u);
    LDI      *AR1,R0           <---+       ;  u = tms_peek(TMS_A_S0_DR_CONTROL);
                       |
                                 |
                 REGISTER CONFLICT
                 SIMULATOR USES OLD VALUE OF AR1 FOR INDIRECT ADDRESSING
                 AFTER THE PARALLEL STORES FROM ABOVE LINE

--------------------------------------------------------------------------

WORKAROUND:
===========
    The problem does not occur if the order of the C statements has been
    changed; thereby eliminating the pipeline conflict after the parallel
    store.

    We will fix this problem in the next release of the C3X simulator.


5669     V2.20  will fix next release
     The simulator (ver 2.1) should observe hardware wait states
   even when the software wait states are set to zero; it does
   not.  All writes take two cycles and most reads take one 
   (the exceptions for the reads are when a data page boundary
   is crossed and when the the read takes place immediately
   following a write).  The simulator calculates the wait
   states properly for the external memory wirtes; it fails
   to take care of the multicycle writes in the pipeline.

   WORKAROUND/SOLUTION:
   ====================
   A software wait state can be set up on external memory;
   this will affect all external memory access.  Thus, reads
   will have an extra cycle as well. 

   ***This will be fixed in the next release.


5694     V2.20  will fix next release
  What happens is that the simulator blows up on the last access - the one that
implements the circular buffer - if the BK register contains 0.

***This was checked on the C4x emulator and found that on the silicon
   when BK=0, the circular addresses are calculated just like
   a normal linear address.  So this will more than likely   
   be a bug.


5725     V2.20  will fix next release
  When there are too many memory blocks defined it causes an out
of memory error (there are about 40 blocks).  The customer can
combine blocks but this does not provide error cecking for areas
between non-contiguous blocks.

***Currently only 40 memory blocks are allowed to be defined
   at any given time in the simulator (this applies to all 
   simulators).  This should be increased to 200 by the next
   release.


5871     V2.20  will fix next release
  The code below has been run with the C30 simulator PC-version 2.10(2.20 also) and 
with the Emulator PC-version 4.60 Revision 3. Different results came out in the data
area for saved results. It differs on the last instruction in the loop when the
contents in RC is 1.
 
With the simulator, RM is set and with the emulator RM is reset when the result
is stored in the data area.
I guess it's a problem with enloop label ...?
 
;
; TEST ROLC
;
   
   LDI     *+AR0(11),R0
   LDI     34,RC
   RPTB    Save_status2
   ROLC    R0
   STI     R0,*AR1++
;
   Save_status2:
;
   STI     ST,*AR1++
;
   SUBI    1,AR1
   LDI     @Arith1_CRC1_add,AR2
   ADDI    Cache_Switch,AR2
   PUSH    AR0
   CALLU   Calc_CRC


   Which is correct behaviour?


5880     V2.20  will fix in V2.21
  When the DMA completes a transfer, the START bits remain in 11 (base 2).
  The DMA "starts" when the START bits are set to 11 and one of the following
  conditions apply:
  1. the transfer counter is set to a value different than 0x0
      OR
  2. the TC bit is set to 0.
 

Workaround/Solution:
     Though the manual doesn't say anything about reseting the start
bits of DMA CTRL register, the simulator resets the start bits
of DMA control register when TC bit is set to 1 and when the
transfer counter becomes zero.
 
We will fix this bug in the next release of the C30 simulator.
 


-------------------------------------------------------------------------------
* EXAMPLE 1: Array initialization with DMA
 
*
* TITLE ARRAY INITIALIZATION WITH DMA
*
* THIS EXAMPLE INITIALIZES A 128 ELEMENTS ARRAY TO ZERO. THE DMA SENT AN
* INTERRUPT TO THE CPU AFTER THE TRANSFER IS COMPLETED
*
* THIS PROGRAM ASSUMES PREVIOUS INITIALIZATION OF THE CPU INTERRUPT VECTOR TABL
E
* (DMA INTERRUPT). THE PROGRAM INITIALIZE THE ST AND IE REGISTER FOR INTERRUPT
* PROCESSING.
*
*
*  SECTION ADDRESSES SHOULD BE ALLOCATED CAREFULLY TO AVOID
*  CPU-DMA CONFLICT. REMEMBER CPU ALWAYS WINS. IN THE EVENT OF A .TEXT
*  CONFLICT, THE ENABLING OF THE CACHE WILL HELP IF THE .TEXT SECTION IS IN
*  EXTERNAL  MEMORY.  FOR EXAMPLE, WHEN LINKING THIS EXAMPLE,
*  WE HAVE USED: .TEXT-->RAM0 ; .DATA-->RAM1; .BSS -->RAM1 , WHERE RAM0 AND RAM
1
*  CORRESPOND TO ON-CHIP RAM BLOCK 0 AND BLOCK 1 RESPECTIVELY.
*
        .GLOBAL ST


-------------------------------------------------------------------------------

4930     V(current)  will fix next release
  Note:  The maximum number of files that can be connected to an I/O
port in the simulator via "mc" commands is 14.  This is a simulator
feature resulting from a limitation on the number of files that
are allocated to any one program under DOS.


-------------------------------------------------------------------------------
