gnupic: Thread: Re: [gnupic] Remarks to gpsim of 05/12/2006

On Sat, 20 May 2006, Peter ####@####.#### wrote :
>
>Note that I just made this up. I hope I did not forget anything 
>important.

It looked quite extensive, but I think you're re-inventing the wheel 
somewhat. GPSim already has an established mechanism for connecting 
stimuli via nodes, so it's not appropriate to specify destination pins 
in the stimulus file. Indeed that would be a bad idea, because it ties 
you to one project. Suppose I have two projects which process the same 
or very similar data streams. One of these uses a 12CE519, the other a 
16F628. These two processors share no pin names at all so by embedding 
the pin names in the stimulus you would force me to create two stimulus 
files. GPSim's current asynchronous stimulus system lets me use the same 
file for both projects. Oh, and you can stop "supposing", because the 
preceding situation is not hypothetical.

I don't think it needs the header with identifier in it. GPSim has no 
use for that information that I can see. Providing a comment character 
is defined (as is currently the case) then you are free to populate any 
information you may want for other tools.

I'm not convinced by the time stamp format. You appear to have defined a 
way to specify lots of conflicting combinations of output at the same 
time. GPSim will want the file to specify a list of time-stamped events 
with only one output pattern being given at any one time. For this, it 
seems to me, the sensible approach is to specify that the first column 
is always a time stamp. Whether you need three forms of time is also 
debatable - the delta from last is possibly a convenient extension, but 
the distinction between absolute and start-time relative is redundant. 
If you want the times to be absolute, start the stimulus at reset. Mind 
you, your description of the examples seems to contradict your 
description of the syntax, so I'm not sure whether you meant that.

As for the flexibility to mix analogue and digital, that's probably 
useful but not essential. If all the data were defined to be voltages 
then digital states can still be represented. Of course, you could 
define "H" and "L" as aliases for 5.0 and 0.0 respectively.

I don't think there's really that much need to worry about compressing 
the files. From GPSim's viewpoint, compression is an unnecessary 
complication, and anyone with enough disk and memory to run GPSim will 
be unlikely to run out because of a stimulus file, even with 1000000 
samples. But a format that would zip up nicely in case you have to put 
it on a floppy or send it by email would be good (and I suspect will 
just happen in any case).

For output, GPSim does not need to give names to columns if the format 
doesn't need names. The "stimulus file recorder module" would have a 
specified number of input pins called "pin1" through "pinx", which you 
would connect to the points of interest by the usual mechanism. The file 
it creates could then be played back through a "stimulus file input" and 
the pins of that module would produce the wave forms recorded by the 
corresponding pins on the recorder.

Just my few pence worth.
-- 
Rob Pearce                       http://www.bdt-home.demon.co.uk

The contents of this | A new chef from India was fired a week after starting
message are purely   | the job.  He kept favoring curry.
my opinion. Don't    |
believe a word.      |

On Sat, 20 May 2006, Robert Pearce wrote:

> On Sat, 20 May 2006, Peter ####@####.#### wrote :
>> 
>> Note that I just made this up. I hope I did not forget anything important.
>
> It looked quite extensive, but I think you're re-inventing the wheel 
> somewhat. GPSim already has an established mechanism for connecting stimuli 
> via nodes, so it's not appropriate to specify destination pins in the 
> stimulus file. Indeed that would be a bad idea, because it ties you to one 
> project. Suppose I have two projects which process the same or very similar 
> data streams. One of these uses a 12CE519, the other a 16F628. These two 
> processors share no pin names at all so by embedding the pin names in the 
> stimulus you would force me to create two stimulus files. GPSim's current 
> asynchronous stimulus system lets me use the same file for both projects. Oh, 
> and you can stop "supposing", because the preceding situation is not 
> hypothetical.

I said that the names are 'node names' not 'pin names'. As in, symbols 
defined elsewhere in a simulation setup file.

> I don't think it needs the header with identifier in it. GPSim has no use for 
> that information that I can see. Providing a comment character is defined (as 
> is currently the case) then you are free to populate any information you may 
> want for other tools.

The header is needed because then the sim file can be partial or the 
columns can be re-ordered to suit the developer. It also allows 
versioning and comments, which are *essential*.

> I'm not convinced by the time stamp format. You appear to have defined a way 
> to specify lots of conflicting combinations of output at the same time. GPSim 
> will want the file to specify a list of time-stamped events with only one 
> output pattern being given at any one time. For this, it seems to me, the 
> sensible approach is to specify that the first column is always a time stamp. 
> Whether you need three forms of time is also debatable - the delta from last 
> is possibly a convenient extension, but the distinction between absolute and 
> start-time relative is redundant. If you want the times to be absolute, start 
> the stimulus at reset. Mind you, your description of the examples seems to 
> contradict your description of the syntax, so I'm not sure whether you meant 
> that.

I think that the format I made up helps to keep the file terse. It also 
allows a human to edit it by hand (good luck writing tick times for each 
line by hand). It is possible to have a conflict where relative timings 
specify an event in the future where two events overlap partially or 
entirely. I assume that the user/generator will take care of that. You 
have to trust somebody eventually. The idea is that users/programs 
usually specify the file using mostly one of the time specs, mixing them 
rarely. A script that can lint suspected faulty files is trivial to 
write.

> As for the flexibility to mix analogue and digital, that's probably useful 
> but not essential. If all the data were defined to be voltages then digital 
> states can still be represented. Of course, you could define "H" and "L" as 
> aliases for 5.0 and 0.0 respectively.

The idea is to make it convenient for humans to understand and edit 
stimulus files. The way this is done until now is not so easy imho.

> I don't think there's really that much need to worry about compressing the 
> files. From GPSim's viewpoint, compression is an unnecessary complication, 
> and anyone with enough disk and memory to run GPSim will be unlikely to run 
> out because of a stimulus file, even with 1000000 samples. But a format that 
> would zip up nicely in case you have to put it on a floppy or send it by 
> email would be good (and I suspect will just happen in any case).

gpsim is not to compress or decompress but users may want to have 
significant amounts of data to feed as stimulus to, f.ex., a DSP 
algorythm. F.ex. 16 kHz sampled audio, 5 minutes, using the format I 
showed, is about 50 megs uncompressed (5*60*16000*(5+11 chars)), using 
relative time marks.

> For output, GPSim does not need to give names to columns if the format 
> doesn't need names. The "stimulus file recorder module" would have a 
> specified number of input pins called "pin1" through "pinx", which you would 
> connect to the points of interest by the usual mechanism. The file it creates 
> could then be played back through a "stimulus file input" and the pins of 
> that module would produce the wave forms recorded by the corresponding pins 
> on the recorder.

Assume a PIC with lots of pins is used, and one would want to select a 
few (see above for size).

Peter

On Sat, 2006-05-20 at 22:15 +0300, Peter wrote:

<snip>

> sorry for the long post, I hope something will come of it.

Hi Peter,

That was a long post! I don't want to discourage discussions such as
these, however your suggestion is not exactly what we're looking for. I
think Rob points out how there's some duplication in what you're proposing
and what exists. I think we want to keep the interface fairly simple, even
if it sacrifices some simulation efficiencies.

(BTW, gpsim has a SWIG interface if you're interested in creating a very
direct Perl <-> gpsim link.)

Instead, I was thinking of something more along the lines of a stimulus
file interface that could supply a (potentially large) stream of data. Rob
suggests making this interface a named pipe, therefore providing a
mechanism whereby data can be generated somewhat automagically by an
external program. For example, in one terminal you could type:

 $ mkfifo stim_pipe
 $ cat MyBigDataFile > stim_pipe

And in another, invoke gpsim:

 gpsim> module load filestim FS1         # Instantiate the module
 gpsim> FS1.file = stim_pipe             # The data file
 gpsim> attach nodeRA0 FS1.pin porta0    # connect the pin to a node


My initial thoughts for the data file structure were to keep it extremely
simple; for example, each line would consist of a simulation time and the
data for that time.

 0000  0
 0010  5
 0020  0
 0030  5

In other words, there are just two columns for the time and data and no
other information.

gpsim also already has the reciprocal interface. For example, it's
possible to log data written to a register or attribute. I haven't used
this interface in quite some time, but it's purpose was to collect
simulation data verify with some external tool that it was correct. It'd
be nice if this reciprocal interface created data that could subsequently
be fed back into the simulation.

If the brain-dead simple interface is too simple, then the next step up
could be something along the lines of what Peter proposes. I'd be more
inclined however to use a more standard encoding like LXT or VCD. This
would be more work for gpsim, however it would allow users to graphically
view and synthesize data streams with tools like GTKWave.

Scott

On Sun, 21 May 2006, Scott Dattalo wrote:

<snip>

> Instead, I was thinking of something more along the lines of a stimulus
> file interface that could supply a (potentially large) stream of data. Rob
> suggests making this interface a named pipe, therefore providing a
> mechanism whereby data can be generated somewhat automagically by an
> external program. For example, in one terminal you could type:
>
> $ mkfifo stim_pipe
> $ cat MyBigDataFile > stim_pipe
>
> And in another, invoke gpsim:
>
> gpsim> module load filestim FS1         # Instantiate the module
> gpsim> FS1.file = stim_pipe             # The data file
> gpsim> attach nodeRA0 FS1.pin porta0    # connect the pin to a node
>
> My initial thoughts for the data file structure were to keep it extremely
> simple; for example, each line would consist of a simulation time and the
> data for that time.
>
> 0000  0
> 0010  5
> 0020  0
> 0030  5
>
> In other words, there are just two columns for the time and data and no
> other information.

Okay with me. I agree. Besides 'my' format can be split into this 
easily (and vice versa).

> gpsim also already has the reciprocal interface. For example, it's
> possible to log data written to a register or attribute. I haven't used
> this interface in quite some time, but it's purpose was to collect
> simulation data verify with some external tool that it was correct. It'd
> be nice if this reciprocal interface created data that could subsequently
> be fed back into the simulation.
>
> If the brain-dead simple interface is too simple, then the next step up
> could be something along the lines of what Peter proposes. I'd be more
> inclined however to use a more standard encoding like LXT or VCD. This
> would be more work for gpsim, however it would allow users to graphically
> view and synthesize data streams with tools like GTKWave.

I think that any encoding should be left to an external script (supplied 
with gpsim). As is now with a module as you said you can have input and 
output in the same format easily (the one you show).

thanks,
Peter

Scott Dattalo wrote:

> Let me design a file stimulus. I have another application I can use this 
> for too.

I have an application where I'd like to configure the processor/system 
state in some manner and validate the system state at a subsequent time:

    set up input state
    simulate the code
    validate output state

For example, take something like a square root routine. You might want 
to specify a number whose root you wish to compute and then at the end 
of the routine verify that the correct value is returned. You could 
imagine a file containing 2^16 inputs and their corresponding 2^16 outputs.

The simplest file format I can imagine is one where each line contains a 
list of commands. For example, let's assume that N_hi and N_lo are the 
16-bit input to the square root routine and that 'root' is the 8-bit 
result. Here's how a stimulus file might look:

-------------------------
N_hi = 0; N_lo = 0    # input condition
(root == 0)           # expected result
N_hi = 0; N_lo = 1
(root == 1)
N_hi = 0; N_lo = 2
(root == 1)
N_hi = 0; N_lo = 3
(root == 1)
N_hi = 0; N_lo = 4
(root == 2)
# and so on
------------------------

The stimulus could then be used like so:

   gpsim> module load file_stimulus FS1
   gpsim> FS1.file = "SquareRootData"

And in the PIC program under test:

   ; Get the next input from the file stimulus

   .command "FS1.stepcommand=true"
    nop

    call SqrtRoutine

   ; now validate the results

   .command "FS1.stepcommand=true"
    nop

The File Stimulus attribute '.stepcommand' reads the next line in the 
file and passes it through the gpsim parser. Conditional commands must 
evaluate to true for the simulation to continue.

Timed commands
--------------

Now, I realize that Tobias requires something different. Instead, he 
wants to supply data to a stimulus at a specific point in time. I think 
the best way to do this is to instantiate a pullup resistor and modulate 
it's pullup voltage.

   gpsim> module load file_stimulus FS2
   gpsim> FS2.file = "PinStimulusData"
   gpsim> module load pullup V1  # we'll use a pullup as a voltage source
   gpsim> node nRA0
   gpsim> attach nRA0 porta0 V1.pin

Now suppose he wishes to create a voltage ramp and make sure that it 
causes the variable 'hasTripped' only to be set at some particular voltage:

@0x100 V1.voltage = 0.0
@0x200 V1.voltage = 0.5
@0x210 (hasTripped = 0)   # make sure some internal state is correct
@0x300 V1.voltage = 1.5
@0x310 (hasTripped = 1)   # should've tripped at ~ 1.2 volts

etc.

The @NNNN prefix tells gpsim to execute the list of commands at a 
particular cycle.

Periodic sequences.
-------------------

The File Stimulus could support a "jump to line command". For example,

FS1.starttime = cycles   # specify base cycle to be the current cycle
FS1.line = 5             # start executing at line 5

The '.starttime' attribute represents the offset cycle to which the 
'@NNNN' prefix is added. The '.line' attribute specifies the next line 
from which the File Stimulus should read (I'm thinking of files and not 
named pipes). Here's an example of a periodic stimulus:

@0x100 V1.voltage = 0.0
@0x200 V1.voltage = 0.5
@0x210 (hasTripped = 0)   # make sure some internal state is correct
@0x300 V1.voltage = 1.5
@0x310 (hasTripped = 1)   # should've tripped at ~ 1.2 volts
@0x400 FS1.starttime = cycles; FS1.line = 0;

The last line turns the ramp into a 0x400 cycle repeating sequence.

---

I think that was longer than Peter's post! And speaking of Peter's post, 
  you probably notice that they're similar. I borrowed Peter's ideas and 
recast them into a gpsim form. The major difference is that the file 
stimulus as I've proposed it is nothing more than a list of gpsim 
commands that can be executed at the rate the user (or the simulation) 
requires.


Comments?

Scott

On Mon, 22 May 2006, Scott Dattalo wrote:

> The simplest file format I can imagine is one where each line contains a list 
> of commands. For example, let's assume that N_hi and N_lo are the 16-bit 
> input to the square root routine and that 'root' is the 8-bit result. Here's 
> how a stimulus file might look:
>
> -------------------------
> N_hi = 0; N_lo = 0    # input condition
> (root == 0)           # expected result
> N_hi = 0; N_lo = 1
> (root == 1)
> N_hi = 0; N_lo = 2
> (root == 1)
> N_hi = 0; N_lo = 3
> (root == 1)
> N_hi = 0; N_lo = 4
> (root == 2)
> # and so on
> ------------------------

I think that this is not quite a stimulus file, it is more like a 
script. E.g. you are effectively promoting (demoting) gpsim with the 
loaded program to a function, and you wish to have it perform 
calculations and check them. So a more complete syntax would be to 
consider gpsim a function that takes a set of initializers as arguments, 
and can return a list of arguments (borrowing from Perl a little):

use Gpsim;
my prog = perlgpsim( 'program_to simulate' );
my rr,f,nhi,nlo;

prog->reset;
prog->breakpoint('somelocation');

foreach ($nhi,$nlo,$rr) $testlist {
 	prog->set('N_hi', $nhi, 'N_lo', $nlo);
 	prog->run;
 	($r, $f) = prog->get('root', 'flags');
 	($r != $rr) and die "Aargh: nhi=".$nhi." root=".$r." f=".$f."\n";
}

So gpsim would have a Perl object wrapper.

Another way to look at it is as a set of clauses (e.g. Horn c. - see 
Prolog), and write something like:

testroot79 :- set N_hi=0, set N_lo=2, call rootfunc, root==1.
testroot79 !- write 'Aargh root=' root '\n';

All of these can be substituted with the simple stimulus format (input 
and output) if gpsim can be driven by a script (for example expect(tk)) 
that can handle all the comparisons and so on.

> I think that was longer than Peter's post! And speaking of Peter's post,  you 
> probably notice that they're similar. I borrowed Peter's ideas and recast 
> them into a gpsim form. The major difference is that the file stimulus as 
> I've proposed it is nothing more than a list of gpsim commands that can be 
> executed at the rate the user (or the simulation) requires.

I think that there must be a distinction between a stimulus or trace 
file and a script. A stimulus is just a set of values for nodes (input 
and output).

A script is something entirely different, and it may or may not want to 
use stimuli (input or output).

For example, I believe that spawning gpsim from an expect shell should 
open a number of interesting possibilities, but this is unrelated to 
stimuli.

Peter