C5XX EMULATOR 1.00,1.20,1.70,7.40

XREF UTILITY 1.10,1.20,3.10

QUICKSIM MODEL 4.4

SYNOPSIS MODEL 4.00

VANTAGE MODEL 4.40

EMULATION PORTING KIT (EPK) 1.70

COMPILER 1.10,1.20,3.10

BUG DESCRIPTION
===============
 
The code generator may generate internal error messages:
"...COMPILER ERROR: no match for VREG" when generating
code for interrupt service routines.
 

BUG DESCRIPTION
===============
 
If the command line (includding both options given on command line
plus any specified by C_OPTION)  exceeds 99 chars the compiler may
fail generating the error message: COMPILER ERROR : PACKET ERROR : 8
Note: This problem occurs on PC only.

BUG DESCRIPTION
===============
 
The compiler may err when generating code for an assignment
from read of a PORT variable, when the target of the assignment
is a local var whose storage space is allocated on the stack,
and whose value is subsequently used in a call to a function.
e.g.
 
port unsigned int port100;
 
  func()
  { int tmp;
 
    tmp = port100; /* incorrect address may be calculated for
                      store to tmp */
 
   call(0,tmp);
  }

BUG DESCRIPTION
===============
 
The compiler may err in pushing the shift value for a
long shift as a long operand, when calling the run-time
support routine L$$SL to perform a long shift. The L$$SL
routine expects the shift value to be only 16 bits long,
leading to incorrect results. Note that this error may
also occur for umtiplication of longs in which the compiler
optimizes by substituting a shift operation.
 
e.g.
long a,b,c1;
.
.
   a = 32;
   b = 0xffff0001;
   c = a * b;      <== compiler errs here when generating code for this
                       expression
 

Change the file to include a prototype for the setjmp function.
 
ANSI shows that the prototype should be
 
int setjmp(jmp_buf env);
 

Linker fails with error when relocating addresses from "far"
memory:
Most of the time, addresses are 16 bits.  When using c548 "far"
addressing, you get an extra 8 bits, so that addresses are 24
bits.  The assembler and linker are not properly relocating
addresses that are 24 bits -- It chops off the
upper 8 (extra) bits.
 
Check to see if the executable works anyway.  It's POSSIBLE that
it might (if you don't really need the upper 8 bits in that spot
anyway).  If not, then the only workaround is not to have
relocatable things accessed from different memory banks.
 
This bug will be fixed in the V1.21 tool set.
 
 
 

The compiler may issue certain instructions (MVDK, MVMD, MVDK, MVDM)
as repeat-singles.  This has the unintentional side effect of
incrementing the DAB address register (DAR) after each repetition,
which could cause incorrect values to be moved by the instruction.
Workarounds include pairing a dummy instruction with the move
instruction (so that the move instruction cannot be transformed into
a repeat-single), and compiling at low optimization.

SXM must always be set for MPYA instructions, as 17 upper bits of A,
which includes one of the guard bits, is used.  This means that
sign extension must always be performed upon accumulator A.
 

Problem:  the repeat-block registers cannot distinguish 24-bit addresses.
If a repeat-block (RPTB) is exited prematurely, and program control
switches to an address whose lower 16-bits overlap with the lower 16
bits of the repeat-block, the hardware will loop when it should not.
 
RPTB's are only generated at optimization level 2 or higher.
Compile at -o0 or -o1 to avoid the problem.  This problem can occur
only when extended addressing is used; when a repeat block is exited
prematurely (as with a "break" statement); and when the lower 16 bits
of the repeat block and another program address overlap.
 
 
Description: Consider the following 2 programs:
testc.c:
int j;
extern int increment(int i);
void main()
{
  int i;
  for(i=1;i<=100;i++)
  {
    j  = i;
    if (i == 30) break;
  }
  j = increment(j);
  asm(" nop");
  asm(" nop");
  for(;;);
}
 
testp.asm:
  .text
         .mmregs
         .global _increment
_increment:
            NOP
            NOP
            NOP
            NOP
            NOP
            NOP
            NOP
            NOP
            ADD #2,0,A,A
            NOP
            NOP
            FRET
    .end
 
The value of J at the end of executing the above program is going to be 32
(correct value)
This is true only if the .text sections of both test.c and test.asm are on the
same page.
If you specify in your linker command file that the 2 .text sctions are to be
on 2 different pages then link them,
then the value of J is no longer 32. It is going to be a # greater than 32
(wrong value).
The reason for this behaviour is as follows:
The problem comes from the fact that the compiler does NOT clear BRAF flag
prior to jumping out of the RPTB block when implementing conditional break
as shown in testc.c.
 
When testc.obj and testp.obj are linked in different pages so that the lower
16-bit addresses overlap , we will see phantom loop being executed
within the increment() function just because BRAF was not reset when breaking
out of the loop.

Request to add, as part of the save/restore prologue and
epligoue of an interrupt service routine, instructions that
restore the proper C environment when the interrupt is declared
with the "interrupt" keyword in C.  This will ensure the C
environment will be preserved if any assembly functions are
interrupted.
 
This will be implemented in the next release of the compiler.
Interrupt routines will reset the C enviroment by saving and
restoring PMST; saving and restoring ST1; and, for the duration
of the C interrupt routine, setting CPL in ST1 and clearing SMUL
and SST in PMST.
 

Compiler sometimes generates assembly code with pipeline conflicts.
For Example:
Instruction which reads memory mapped register immediately follows an
instruction which modifies accumulator A or B in a repeat-instruction
or a repeat-block loop.
 

When an unsigned immediate value is used in a signed instruction,
and the immediate is > 0x7fff, the compiler may neglect to reset
the SXM bit before the operation.  A workaround is to store to, and use
the immediate value from, memory.

If a file compiled/assembled with -v548 is linked with the default
rts.lib (or other non-v548 files), and the -v548 file is not the
first file given to the linker on the command line, the linker will
not flag the output file as a c548 file.  This means that the hex
converter will not recognize the output file as a c548 file, which
could affect processing of the boot table.
 
The workaround is to place the -v548 file first on the command line
to the linker, or to compile with -mf -v548 and link with the
extended runtime library (rts_ext.lib).
 
 
 

When I compiled K&R source with "-pk" option the results were incorrect.
So, without "-pk" option, the results were correct.
 
------------------
This is a duplicate of 3938, which has already been fixed
in a supplemental compiler release.

The argument to the ABS instruction may not always be properly
sign-extended, producing an incorrect result.

The division of a negative int by a value that is a power of 2
(2,4,8,16...) could generate an incorrect result in some
cases.

SXM bit is being set before the ST1 register is saved to the
stack.
 
In certain cases, the 'SSBX SXM' instruction in an interrupt
routine may be relocated across settings, savings, or restorings
of ST0, ST1, and PMST.

The runtime function strftime could display the year incorrectly
for a date past the year 1999. The year field will contain
3 digits such as 101, instead of 01 for the year 2001. This
could occur in calls to strftime().

The compiler may modify ARx before a fuction call and as a
result, store the returned value from the call in an incorrect
memory location.

The compiler may incorrectly perform a peephole optimization to change
 
   DLD  Smem, B
   ADD  B,A
 
to
 
   ADD  Smem,A,A
 
This transformation would be illegal in this example if B is
subsequently used, because the load to B would have been removed.
 

When a register is shifted right by a constant from 1-8,
inefficient code may be generated; the compiler may sign-extend
the register before the shift, when the value is already properly
sign-extended.
 
 

The FRET[D](E) instructions implement a return from a FCALL[D] (Far Call)
/FCALA[D] (Far call Subroutine at Location Specified by Accumulator)
instruction or an interrupt using the extended addressing feature on the
54x.  On certain devices, the instruction works correctly if returning
from only one FCALL[D]/FCALA[D] or interrupt.  The bug occurs when more
than one FCALL[D]/FCALA[D] or interrupt is used (nested), and the wrong
XPC value is returned.  If extended addressing or the FRET[D](E)
instructions are not being used, there is no impact of this bug.
 
This is a bug in the C54x core and the only production devices
affected are the TMS320LC/VC549-80/100-GGU/PGE, all of which use
'549-PG 2.1 material.
 
Work-Around:
------------
 
For FRET[D] -
 
The FRET instruction can be replaced with the code fragment below at the
exit of each subroutine.
 
  FRET[D]                -->  
                 POPM    AH (or BH)
                              POPM    AL (or BL)
                              FBACC   A
 
For FRETE -
 
The FRETE instruction can be replaced with the code fragment below at the
exit of each ISR.
 
  FRET[D]                -->  
                 POPM    AH (or BH)
                              POPM    AL (or BL)
                              FBACCD  A  (or B)
                              RSBX    INTM
                              NOP

The compiler sometimes generates pipeline conflicts.
 
For example, the compiler may generate the following assembly code:
 
 
    STLM    A,BK
 
    MVDK    *SP(2),*(AR2)
 
    LD      *AR2(242),A
 
 
The first two instructions shows an example of the conflict of
updating an ARx register and BK register. The STLM A,BK instruction
stores the BK contents at the Execute stage of the pipeline.
The MVDK *SP(2),*(AR2) tries to store in the Read stage of
the pipeline BUT this is delayed automatically by the processor
to avoid updating the BK and AR2 registers at the same time.
Unfortunately, because of this one cycle delay, AR2 is incorrect
for the LD *AR2(242),A instruction.

C SOURCE INTERLIST 1.10,1.20,3.10

ARCHIVER 1.10,1.20,3.10

LINKER 1.10,1.20,3.10

BUG DESCRIPTION
===============
 
When a two word instruction with a long constant as the second
word of the encoded instruction occurs on a 2048 word boundary
the assembler may assign incorrect relocation information for
this constant. The incorrect relocation information will cause
the linker to fail to properly relocate the constant. The constant
will have the value assigned to it by the section program counter
(SPC) within the assembler.
 

ASSEMBLER 1.10,1.20,3.10

BUG DESCRIPTION
===============
 
   The assembler does not treat signed floating point constant operations
correctly in all instances.
 
i.e.
 
t2      .set -5.0
       ...
       ...
t15     .set    t2*-1.0      ; incorrectly yields a negative value
 

BUG DESCRIPTION
===============
 
The assembler .pstring directive does not work correctly, for
strings with less than two chars or that have an odd number of
chars. The correct code is generated but the SPC is not properly
updated. A side-effect of this is that the assembler may generate
an error message and stop assembly when it encouters a label on
the line following the .pstring directive. This is do to bad SPC
value.
 
e.g.
        .pstring 2,3
label   .word 1          <===== Assmebler will generate error here

BUG DESCRIPTION
===============
 
There is a bug in the parser of the assembler for STH instruction
in which it fails to catch incorrect operand combination such
as appears below:
 
    STH A, *AR4+,1
 
The side effect of this is that the assembler will generate
errors when processing addresses of labels that subsequently
appear in the file.

The PC-hosted assemblermay fail with the message
DOS 4GW Professional Error.  The problem occurs during
processing of a .if directive.  This will be fixed in the
next release of the assembler.
 
Workaround:
-----------
Use version 1.16c of the assembler.
 
Download PC patch
Download Readme file
 
 

When compiling a switch statement which has a control expression
of unsigned int, the compiler may represent the expression in the
assembly code as a large negative offset.  This could in turn cause
the assembler to emit a warning about the offset being out of range.
However, the code emitted will run correctly, and the warning may
be ignored.
 
 

In algebraic mode, given the following type of instruction
 
  ar2 += 1  (MAR)
 
the assembler will calculate a different size for the instruction
on each of its two passes.  If a label follows the instruction,
the assembler will calculate two different addresses for the label,
and will emit an error message.

BUG DESCRIPTION
===============
 
"Assembler erroneously rejects a macro parameter as a "bad
 expression" when the parameter is an argument to a .loop
 directive inside of a .if conditional."
 

The assembler will report pipeline conflicts regarding the T
register where none exist.  The spurious warnings may be given
when MPY*, MAC*, or MAS* instructions are involved.  These
instruction do not really pose problems for the T register in
the pipeline.
 

Invoking the assembler in algebraic mode results in a seg fault.
 

The assembler crashes when using the -pw
option, which detects pipeline conflicts,
on parallel instructions.

In some instances, assembler crashes with a invalid page fault
error.  The problem is caused by the assembler expression evaluator
when two subtract or additions are performed upon a symbol and two
constants when the symbol is not defined.
 
Example:
 
    .eval  foo-70-1, loopcnt
 
creates an infinite recursion in the assembler.
 

There is a general problem with expressions contained in
assembler directives that causes spurious error messages to
be issued by the 3.10 Beta assembler.  This problem is fixed
in the v3.10 release.
 

The assembler crashes with invalid page fault if you try to
redefine mnemonic functionality by creating macros. So if you
use a mnemonic as a macro name, then the assembler fails.

In some instances when code is assembled with -pw switch, the
assembler generates "Internal error:unrecognized node opcode!"

The assembler will not truncate the value when the argument to a .byte
directive cannot be contained in 8 bits -- the value will be represented
as 16 bits.  Similarly, negative values will be represented as 8 bits;
i.e., .byte -1 will be represented as FFFF instead of as 00FF.
 
 
 
 

The assembler will not issue an error given a .set or .equ directive
and a constant argument, which is larger than can be represented.
 

If a local label appears within a conditional block that evaluates to
false (.if 0), the assembler may not correctly locate the end of the
block (.endif), and so may report an error.
 
 

An illegally formed RSBX or SSBX instruction could result in a seg fault
in the assembler.
 
Example:
 
         RSBX  1,DP       ; illegally formed instruction
 
will seg fault.
 
 
 

When used in algebraic mode, the assembler will not encode the
following instruction correctly:
 
   acc = acc + smem << shift
 
Example:
 
   A = A + @label1 << -16
 
is not encoded correctly.
 
 

The assembler may sometimes generate errors for .elseif
directives within a macro. The workaround is to replace the
".elseif" directive with ".else" and ".if" directives.

It is possible that the .eval directive
may incorrectly evaluate an expression on
the PC hosted assembler.  The problem does not
appear on the Unix-hosted products.

The A_DIR environment variable only recognizes the last
directory assigned to it.
 
For example, if you set:
 
set A_DIR=c:\dir1;c:\dir2
  or
setenv A_DIR "/dir1 /dir2"
 
the assembler will only find the files in dir2 when searching
for .include files and will not find the files in dir1.
 
A workaround is to use the -i assembler switch to name the
directories containing the .include files.

An algebraic assembly command which adds a shifted value to
a variable may erroneously generate an error message.
 
The tokens for ">>" and ">>>" have been reversed in the
algebraic parser.  If ">>" is rejected by the assembler,
try using ">>>."
 

In algebraic mode, the operands of the second instruction
of a parallel instruction pair may not be correctly recognized,
and may generate an error message.

TAP5000 3.10

ABSOLUTE LISTER 1.10,1.20,3.10

HEX CONVERTER 1.10,1.20,3.10

There is a bug in the V1.20 hex utility. When using -byte option
the hex utility should give addresses in byte count rather than
word count.

The hex converter sometimes emits the error message :
"Error reading COFF file" when trying to convert specific
sections of the COFF file.  This problem has not been observed
in the 3.10 release.

LIBRARY BUILDER 1.10,1.20,3.10

RTS 1.10,1.20,3.10

BUG DESCRIPTION
===============
 
The RTS C boot routine c_int0, does not contain code for copy
of .const section from program to data space as is stated
in the C compiler Users Guide (SPRU103A, Sec 4.1.3, pg 4-4).

BUG DESCRIPTION
===============
 
A shift instruction within the l&&MPY instruction does not fully
sign extend the result. This may cause incorrect values for the
result when a subsequent operation occurs before the result is stored
to memory.

The trig and exponential math functions have been failing the
functionality test:
  Let 'a' be a floating point variable, initialized to a value.
Let 'b' be another variable that gets the value of sin(a).
Let 'c' be another variable that gets the value of inverse of sin(b).
Then value of 'c' must be equal to value of 'a'.
  If you write a program incorporating the above steps, then after
compiling and linking and running the code, you will not get
correct results.
   All the trig and other math functions are in the rts.lib file.
It looks like there are some bugs in this library file.
 

BUG DESCRIPTION
===============
 
Floating point divide operations are sometimes not very accurate.
 
Download Readme file
Download PC patch
Download Solaris patch

Due to the 16-bit integer implementation, attempts to use the
time and date functions will sometimes give erroneous results.
Affected functions include but are not necessarily limited to:
 
                gmtime()
                localtime()
                ctime()
 

DOCUMENTATION 1.10,1.20,3.10

The description of the .tag directive in the
TMS320C54x Assembly Language Tools User's Guide needs to be
updated to include a comma between the stag and expression
parameters:  .tag    [,]
 

Section 5.4.1, "DP-Referenced Addressing", of the
TMS320C54x DSP Reference Kit CPU and Peripherals (SPRU131D),
should be updated to include a description of the @dma
syntax used for DP-referenced direct addressing.

Table A-5 of the TMS320C54x Assembly Language Tools User's
Guide (SPRU102B), "Section Header Contents for COFF2 Files",
contains an incorrect type for bytes 46-47 (memory page number).
Bytes 46-47 should be listed as type Short instead of
type Character.
 

The TMS320C54x Mnemonic Instruction Set User's Guide (SPRU172A)
is not very clear in the description of RPTB[D] instruction.
The documentation says :
 
"This instruction repeats a block of instructions the number of
times specified by the memory-mapped block-repeat counter (BRC).
BRC must be loaded before the execution of this instruction."
 
However, when code is run in processor and n is loaded to BRC
before RPTB[D] command, the block is repeated n+1 times.
 
This bug has been forwarded to Technical Documentation Services
so that the appropriate writer can be assigned to fix it.
 

The predefined macro names:
 
_TMS320C5xx
C_MODE
.FAR_MODE
 
as shown on page 2-30 of the TMS320C54x Optimizing C Compiler
User's Guide SPRU103B are incorrect.  The macro names actually
are:
 
_TMS320C5XX
_C_MODE
_FAR_MODE

The example for the C54x hex conversion utility in the
TMS320C54x Assembly Language Tools User's Guide (SPRU102C),
pages C17-C23, does not state what options are used to compile
the example. This is the example for generating a boot table
for LP Core Devices.
 
If the example is compiled without the -v548 option, the
hex file produced does not look like the one on page C-23.
However, if it is compiled with -v548, the hex file produced
looks a lot more like what is documented.
 
The manual should to more specify on what options are
used to compile the example.

HLL 1.00,1.20,1.70,3.10

DEBUGGER 1.00,1.20,1.70,3.10

Download PC patch
 
 

The v1.70 debugger needs to be owned by root for it to run
successfully under SOLARIS.
 
Download Solaris patch
 

 
This is a problem filed against the beta version of 3.1
emulator debugger.   This record should not appear on
the external web.
 

The RUNB (run benchmark) command automatically enables analysis. The problem with this is that any analysis break points that have been set become active and the CPU will halt if a hardware breakpoint
 
 

When a program accesses extended addressing (i.e. the writa or
reada instructions), the XPC value is changed temporarily to
execute the instruction.  However, the debugger automatically
changes the disassembly and memory windows to display the
contents corresponding to the extened addressing address based
on the XPC register.
 
Currently, the debugger cannot distinguish between when the
user is stepping into extended addressing space (and needs to
update the displays accordingly) or just make a reference to it.
 

Memory reads from external data space on devices with the cLEAD
core fails every eighth value read stating at 0x0c000.
 
Download PC patch
Download SPARC patch
 

The disassembly window needs to be able to differentiate between
stepping into extended addressing program space and just accessing
extended addressing program space (with the READA or WRITA instruction).
When executing a READA or WRITA instruction, the debugger changes
the XPC value to the extended address page. This causes the disassembly
window to display the contents of program space corresponding to the
XPC value referenced in the READA or WRITA instruction.
However, the program gets executed correctly even though it looks
like you are stepping through different code.
 
NOTE: This bug will not be fixed until Code Composer is used as
the 54x debugger.
 

The memory window does not always get updated when the
memory contents change, for example, when the XPC is changed
in the CPU window.

PDM 1.10,1.20

EMULATOR 1.00,1.20,1.70,3.10

The cycle count is incorrect when running benchmarks using the
RUNB instruction. Depending on what instuction the breakpoint is
set on, the cycle count can be off by as much as several cycles.
 
 

If you set the display window to I/O memory and scroll the memory
window up and down to update the memory display, two access reads for each of the memory locations is performed.

Proper Windows NT support on the cLEAD 549B device.
 
Download PC patch
Download SPARC patch
 
 

Branches aren't being performed correctly when stepping
thru code when extended memory window is displayed.
 
Download PC patch
Download SPARC patch
 

Fractional mode does not consistently give the same results in
the emulator. It is sometimes ignored even when the fractional
mode bit in ST1 is set. The problem occurs when the PC is
manually changed or when any modification of ST1 is done
( rsbx, ssbx, stm).

BUG DESCRIPTION
===============
 
When a memory window is opened, and then you open another
memory window, if you change the displayed location in the first
window, the second window is updated.
 
 
SOLUTION
========
 
This is a GUI bug.  No more GUI bugs will be fixed in the TI debugger.
The customer must wait for Code Composer to be released.

When multiple memory windows are opened, there are no labels identify
ing the sucessive memory windows.
 
This is a GUI bug that will be fixed in the Code Composer Studio
release.

Changing the value of ARP causes all memory windows and memory
mapped registers to be displayed incorrectly.

If the user changes the values of the ST0 or ST1 registers the
values are changed in the GUI but the registers in the CPU are
not changed.  Then, when a user does something that causes the
debugger to update the GUI (load a program, step, etc..) the
original values of ST0 and ST1 are read from the CPU and
displayed in the GUI.  This action causes the ST0 and ST1
registers to appear to change.
 
This only happens if the user changes the ST0 or ST1 registers
before doing anything else in the debugger after start up.

C548 sometimes hangs when using some versions of Windows 95
Japan.
 
Workaround is to use the Win 95 (U.S. version).

C5XX SIMULATOR 1.20,1.30,1.70,2.00,2.20

BUG DESCRIPTION
===============
 
The simulator does not recognize the first parameter in a
function definition. It is not possible to set a "wa", "?",
or "e" on this parameter.
 
i.e.
 
     int func(first, second, third) {
        ...
        ...
     }
 
The simulator will not recognize the symbol "first" when within
the function.

When the -l option is used, sim54x version 2.25 is complains about some
pipeline latency problems that don't appear to exist, according the
TMS320C54x DSP Mnemonic Instruction Set documentation (SPRU172) and the
TMS320C54x DSP Mnemonic CPU and Peripherals documentation (SPRU131C) .
 
 
bug_1
Page 4-73 of TMS320C54x DSP Mnemonic Instruction Set (SPRU172)
...
"This instruction is not affected by the value of SXM."
 
bug_2
Page 7-85 of TMS320C54x DSP CPU and Peripherals
...
"No latency is required since the next instruction uses a long offset modifier.\"
 
bug_3
Page 4-158 of TMS320C54x DSP Mnemonic Instruction Set (SPRU172)
"Status Bits  Affects C"
as opposed to SFTA which states on 4-155 "Affected by SXM and OVM"

Values loaded into the IMR register (address 0) are not displayed
by the simulator in the CPU register window. However,
the value is loaded and can be viewed via a memory window
at address 0)

The simulator analysis breakpoint is not functioning properly.

to use the Saturation on Store(SST:PMST bit0) which allows
only LP devices('545LP,'546LP and '548). The simulator ver2.15
suports LP devices, I believe, but it seems not to operate
correctly. Below is codes which let him think so.
 
      ORM   #0003h, PMST
      SSBX  SXM
      SSBX  OVM
      NOP
      LD    #08000h, 16, a
      STH   A, 1, *( 2000h )
 
If SST bit was set, the contents of 2000h must be 8000h according
to UG, but it was 7FFFh. And when I also tried ver2.20, the same
result was got. When I tried to operate the same program using a
XDS510, it worked correctly(the contents of 2000h was 8000h).
This means the device is OK. I guess this would be simulator bug.

In version 2.15 of the Sun c54x simulator, the MVMD instruction
incorrectly clears a data memory location. This bug is not
encountered in the PC version of the simulator.

The occurrences of the simulator not writting to the output file
depend upon the number of execution cycles.
 
For example, an output file was connected to I/O port like this
     ma 0x0,2,1,oport
     mc 0x0,2,1,out.dat,w
When executing "step 10000" + "quit", data is saved in theoutput file.
But when executing "step 5000" + "quit", the data is not saved.
 
The workaround for this is to try disconnecting the I/O port by
using the "mi" command before quiting the simulator.
 
 

Simulator does not allow writing to program memory location
0x0. If the program is linked to 0x0, and you try to set
a breakpoint at the first instruction, it returns a target error.
The simulator's disassembly window also shows the first instruction
linked at address 0x0 to always be "ADD 0h,A".
 

The cycle count is incorrect on the simulator when using the MAC instruction.
 
For Example:
The instruction MAC [R]  Xmem, Ymem, src[, dst] should only take 1 cycle.
When the instruction is executed on the simulator, it takes 2 cycles.

When counting cycles in a benchmark, the number of cycles displayed
by '? clk' may be incorrect when using the 'runb' command.

In the simulator, sometimes when structures are displayed, data
are displayed in big endian rather than little endian.
 

The simulator displays the memory mapped registers:
 
   PDWSR and IOWSR
 
in the disassembly window, when the correct registers are:
 
   SWWSR and BSCR
 
Note that the opcodes are correct, it is only the contents of
the disassembled instruction that is incorrect.

The pin name used/accepted by the pinc and pinl simulator
commands are different from the physical names for the pins.
For example:
 
physical name    simulator name
-------------    --------------
FSX0             FSX
TFSR/TADD        TFSR
TFSX/TFRM        TFSX
HPIENA           HPI
FSR0             FSR

When using the algebraic mode, the simulator will display
 
   IF (TC) CALL label
 
instead of
 
   IF (TC) CALLD label
 
Note that the instruction is executed correctly and the
only error is in the display.

The load command does not perform a load at the HPI buffer
physical address, rather it performs a load at the BSPO physical
address.

The HPIC Register should be read as a xxxxxx0x0 value
(2 bits are always read as "0" by the C54x).
 
Sometimes what the "Host" has written can be displayed as
well.

C5XX EMULATOR 1.00,1.20,1.70,7.40

XREF UTILITY 1.10,1.20,3.10

QUICKSIM MODEL 4.4

SYNOPSIS MODEL 4.00

VANTAGE MODEL 4.40

EMULATION PORTING KIT (EPK) 1.70