
To-Do List for WEDS 1.0.6

11/09/97

We need to add/fix the following for future versions of WEDS.

Java applets:

1. the Simulator applet should communicate with the server to find
   out the information about what simulators it supports:  right
   now, it's hardcoded in the Simulator applet.

2. the applets should allow access to more tools, e.g. assemblers.

The C30 and HC11 instruction set architecture simulators:

1. extend the simulators to accept a
   script of simulator commands to evaluate.

2. add simulator commands to trigger interrupts.

3. speed up the simulators by speeding up the disassembler that 
   underlies them and disabling the creation of assembly instructions
   in the disassembly loop when they are not needed.

4. add the ability for the simulators to assemble code to produce
   intermediate files (.hex for the C30 and .s19 for the HC11).

Improvements for the C30 simulator:

1. implement C30 floating point arithmetic ("+", "-", "*") in bit
   operations rather than converting to IEEE, performing the operation,
   and converting back from IEEE operation.

2. allow the allow the user to specify from the command line whether
   the simulator should simulate a C30 EVM (which uses a C30 processor)
   or the C30 DSK (which uses a C31 processor) and set the correct
   memory map, etc.

3. redo the way that interlock is detected and handled to match
   the C30 user manual.  From Chi Duong:

   a. Register conflicts (DP, ARn, SP which are currently handled
      in 1.0.5 and IR0, IR1, BK which are not): accesses to the registers
      are incremented in the DECODE stage, and decremented in READ
      and the EXECUTE/WRITE-BACK (WB) stage. 

   b. Memory conflicts: the number of accesses to different parts
      of memory are incremented during READ, and WB and decremented
      at the beginning of each cycle, which is currently done in 1.0.5.

   Interlock can be set at 2 places: every time memory (RAM0, RAM1, ROM)
   is accessed (either during READ, WB or FETCH stage), or in DECODE stage. 
   Interlock will be reset at beginning of each cycle only if the number
   of accesses is less than the limit (1 access for register conflict and
   2 accesses for memory conflict).   Version 1.0.5 does not handle
   the FETCH stage and unconditional resets the interlock flag.

   Re-implement interlock scheme will not be complicated but a few changes
   will need to be made in memmap.cc, cycle.cc and dasmc40.cc. 
