The Future of ScriptSim

ScriptSim is a new product. Many powerful features are under investigation and will be implemented in the near future if there sufficient interest. Such as:

Script Restart: If a script terminates due to a programming error, the verilog simulation pauses and the user can choose to terminate the simulation, fix the script, or continue the verilog simulation without that script. If the user chooses to fix the script, he edits the script and clicks on the 'restart process' button. That failing process is restarted with the new script. Provided that the new script provides the same stimulus to the simulation up to the time of the error as the old script, it is not necessary to restart the simulation. For very large simulations which take a substantial amount of time to reload, this can be a major time saver. With the initial release of ScriptSim, if a script process fails, the simulation pauses and the user can abort or continue without the script process - no restart of a script process is possible.

Parallel Execution: In the initial release of ScriptSim, script processes and the simulator process execute sequentially, not concurrently. For multi-processor workstations, better performance could be achieved if the processes could execute in parallel. To achieve this, the scripts can be viewed as either monitors, drivers, or both. A monitor script drives no signals, so the simulation never needs to wait for the monitor. A driver application never reads signals, so a driver application never has to wait for the simulator. For scripts that read and write signals, parallel operation is still possible. Consider a standard clocked model with all activity occurring on the rising clock edge. If the script receives the signal values immediately before the clock, and drives the signals soon after the clock, the script and the simulator can process the clock event in parallel.
Note: In the initial release the Tk display process already executes in parallel with the simulator.

Threads Capability: Most operating systems, plus these scripting languages support threads. Although the verilog simulation can generate script processes dynamically, currently the script processes cannot create internal threads. Threads in the scripts could make it easier to write advanced models.

ScriptSim Console:
Things which could be implemented in the console:
Writes to 'stderr' should appear in a 'error' color.
A 'Filter' menu should be present to 'Hide' or 'Unhide' messages from specific python agents.
Clicking on a message should highlight it and all other messages from the same agent.
Should reading from the console be supported?

Transaction Display:
This display is designed to hold time ordered transaction entries which can be individually updated. Transaction entries have a time, global transaction number, and a bus number. Various filters can be used to display the transactions in various modes. The concept of 'tracing' a transaction through an asic to another bus is supported.

User Defined Memory Display:
This display shows memory contents. The term memory is used loosely here, since the format routine can be provided by the user and memory contents can be formatted in any complex way.

Design Scanning Through PLI
It would be possible to use Python or Perl to scan the verilog design through the PLI interface, gaining access to any or all registers, variables, and other verilog objects. This would allow many advanced capabilities such as computing test coverage.