gnupic: Re: [gnupic] Remarks to gpsim of 05/12/2006
Subject:
Re: [gnupic] Remarks to gpsim of 05/12/2006
From:
Peter ####@####.####
Date:
21 May 2006 00:15:32 +0100
Message-Id: <lenh.yacq@hpxxs.vvpi.up>
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
