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


Previous by date: 21 May 2006 19:23:42 +0100 Re: [gnupic] Remarks to gpsim of 05/12/2006, Scott Dattalo
Next by date: 21 May 2006 19:23:42 +0100 [gnupic] gpsim, documentation, Nestor A. Marchesini
Previous in thread: 21 May 2006 19:23:42 +0100 Re: [gnupic] Remarks to gpsim of 05/12/2006, Scott Dattalo
Next in thread: 21 May 2006 19:23:42 +0100 Re: [gnupic] Remarks to gpsim of 05/12/2006, Scott Dattalo

Subject: Re: [gnupic] Remarks to gpsim of 05/12/2006
From: Peter ####@####.####
Date: 21 May 2006 19:23:42 +0100
Message-Id: <eafxjf.dtjrdn.jjkavp@up.iu>

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

Previous by date: 21 May 2006 19:23:42 +0100 Re: [gnupic] Remarks to gpsim of 05/12/2006, Scott Dattalo
Next by date: 21 May 2006 19:23:42 +0100 [gnupic] gpsim, documentation, Nestor A. Marchesini
Previous in thread: 21 May 2006 19:23:42 +0100 Re: [gnupic] Remarks to gpsim of 05/12/2006, Scott Dattalo
Next in thread: 21 May 2006 19:23:42 +0100 Re: [gnupic] Remarks to gpsim of 05/12/2006, Scott Dattalo


Powered by ezmlm-browse 0.20.