Re: [Simulavr-devel] RFC: a few feature ideas

[Colin Coombs]

Hi Joel,

your ideas are bordering on an area I am *very* interested in, so I
would like to outline a few ideas of my own, and bounce them off you in
return. 

Disclaimer: I will not be able to begin detailed design of my proposals
for a few weeks yet, so some of these ideas may turn out to be a bit
half-baked.

I will describe the low-level facilities I need from simulavr, and then
some high-level facilities built over them which I think would be
generally useful. Then I will comment on the relationship to your ideas.


Low-Level facilities:

(1) every event from the simulator process to the ui process must be
accompanied by the current (simulated) timestamp

(2) the ui must be able to request an event from the simulator at a
given time in the future, and to have an arbitrary number of such
requests pending at any time.

(3) on receipt of any event (or maybe just some special types of event)
from the simulator, the ui must be able to assume that the simulation is
suspended until the ui allows it to continue. [Note: I have not yet
understood the current arrangements for synchronisation between ui and
simulator, maybe this facility exists already]

(4) the ui must be able to send an event to the simulator at any time.
Events sent whilst processing a simulator->ui event should be picked up
immediately the simulator resumes, events sent at other times would be
picked up "eventually" (perhaps at the occurrence of your "pulse"
event).


High-level facilities:

(Since I am an enthusiastic Tcl user, I shall describe these facilities
in terms of event-driven Tcl. Transliteration into Python or other
scripting languages is a separate exercise...)

(a) Just as Tcl has the "fileevent" command which can register a script
to be executed when a file becomes readable, I want a "pinevent" command
to register a script to execute when a pin changes value (either a
positive edge, a negative edge, or both). There could be an arbitrary
number of such scripts registered for a given pin.

(b) Just as Tcl has the "after" command which registers a script to be
executed when a given (real) time has elapsed, I want a "sim_after"
command to specify the delay using simulated time not real time.

(c) The scripts which are invoked at these events could perform actions
such as changing the values of pins or terminating the simulation,
as well as any ordinary Tcl code such as updating the GUI, logging
messages in files, or communicating with arbitrary external processes.
All these actions would also be available in scripts invoked from GUI
and other events.


Comparison with your idea:

Where you seem to be proposing a single fixed repetitive 'pulse-rate', I
would propose a facility for an arbitrary number of user-defined one-off
'pulses'. A fixed pulse rate could be implemented simply by requesting
the next pulse in the handler script for the current pulse.


An example use of my proposed facilities, inspired by verilog's "specify
blocks": 

assume that your AVR has to send a data value to an external hardware
device, which has a hold-time requirement: after the data strobe goes
high, the data lines must remain stable for 5 ns.

In your ui script, you could include something like the following Tcl
code:

----------------------------------------------------------------------------
#
# This procedure is to be called at every data strobe
#
proc check_hold_time {} {
        global data_bus
        global bus_watch
        set bus_watch [pinevent any $data_bus naughty_data_change]
        sim_after 5 hold_time_over
}

#
# This procedure is to be called when the hold-time expires,
# and we are no longer interested in changes to the data bus
#
proc hold_time_over {} {
        global bus_watch
        pinevent cancel $bus_watch
}

#
# This procedure is to be called if the hold-time is violated
#
proc naughty_data_change {} {
        puts stderr "data bus changed within hold-time"
}

#
# set up the monitoring for the data hold-time
#
pinevent posedge $data_strobe check_hold_time
----------------------------------------------------------------------------

then this code will check that the hold-time requirement is fulfilled
throughout the simulation run.