
+--------------------------------------------------------------------+
| Question 1: When I use the DSP56000 Simulator to access "external" |
|             memory, my clock cycle counts are too high.            |
|             What's going on?                                       |
| Question 2: My instruction cycle count doesn't seem to give the    |
|             the correct result.  There are 2 extra instruction     |
|             cycles (4 clock cycles) added into my cycle count      |
|             when I RESET the simulator and run my test program.    |
| Question 3: How do I calculate timing for the DSP56000 when my     |
|             program uses external memory?  How does the external   |
|             bus arbitrator decide how many cycles to add to an     |
|             instruction's execution time?                          |
+--------------------------------------------------------------------+

Answer:
   In each case, the simulator exactly emulates the cycle-by-cycle
   operation of the actual DSP56000 and DSP56001 devices.  

1) On RESET, the Bus Control Register (BCR) is set to $FFFF (all ones).
   This places the maximum number of wait states into each external
   bus cycle, accommodating slow memories for bootstrapping.  
   Clearing the BCR will remove all wait states from external bus
   cycles (see the DSP56000 User's Manual, sections 2.4, 2.4.1 & 7.2).
   A user's program might typically include the instruction:
   MOVEP   #0,$FFFE   ; This clears the BCR, removing all wait states. 

2) Following RESET, the DSP56000 will begin execution of user instruc-
   tions after 4 clock cycles (2 instruction cycles) occur.  This delay 
   is used to fetch, then decode, the first instruction.  The simulator 
   begins counting instruction cycles starting with the first instruc-
   tion fetch.  Note that for each of the following instructions the 
   fetch and decode operations occur while preceding instructions are 
   being executed.

3) There are 3 situations where external bus operation can affect cycle
   timing:
    a) When two or three of the DSP56000's address controllers request an 
       external memory access (X, Y, or P) during the same instruction 
       cycle.  (Section 6.4.2, DSP56000 User's Manual)
    b) When the Bus Control Register (BCR) is programmed to insert
       wait states during an external memory access.
       (Sections 2.4, 2.4.2, and 7.2, DSP56000 User's Manual)
    c) Another device has requested control of the external bus at the
       same time that a user's program requires an external memory
       access.  (BR & BG, Section 2.2.2, DSP56000 User's Manual)

   It is important to note that the bus arbitrator never wastes clock 
   cycles or bus bandwidth when resolving a conflict.  When the bus 
   arbitrator is resolving contention between address controllers, 
   the external bus remains continuously busy without added dead cycles. 
  
   If several external bus accesses are requested simultaneously, the
   bus arbitrator will queue those requests.  If the processor must wait
   for external data access, the amount of added execution time can be
   calculated by using the following simple rule: 
          If 3 external accesses are needed, add 2 instruction cycles;
          If 2 external accesses are needed, add 1 instruction cycle;
          Otherwise, the arbitrator will not delay execution.
   If BCR wait states are inserted during the external accesses, then 
   instruction processing will be delayed accordingly.

   Memory access timing is summarized in Figure A.13 of the User's
   Manual.  This table is accurate, but it only describes the execution
   phase of a single instruction.  Users must remember that when any  
   instruction is being executed, another instruction is being decoded 
   and a third instruction may be fetched.  This "pipelining" (discussed
   in the User's Manual, section 6.4) can insert an external program 
   memory fetch into the bus arbitrator at the same time that another
   instruction might be moving two data words in external data memory 
   space.
   
   The bottom line is that while one instruction is being executed, 
   (Figure A.13) some following instruction might also be fetched.  
   If this new instruction is being fetched from internal program 
   memory, external bus operation is completely unaffected.  
   If it is being fetched from external program memory, then this 
   instruction fetch could contend with data movements from an 
   instruction that is currently executing.

