gnupic: Re: [gnupic] Remarks to gpsim of 05/12/2006
Subject:
Re: [gnupic] Remarks to gpsim of 05/12/2006
From:
"Scott Dattalo" ####@####.####
Date:
21 May 2006 14:56:04 +0100
Message-Id: <60051.71.139.32.36.1148219337.squirrel@ruckus.brouhaha.com>
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
