gnupic: Re: [gnupic] Remarks to gpsim of 05/12/2006
Subject:
Re: [gnupic] Remarks to gpsim of 05/12/2006
From:
Scott Dattalo ####@####.####
Date:
19 May 2006 23:49:53 +0100
Message-Id: <446E4B8D.2040502@dattalo.com>
Tobias Schlottke wrote:
> On Fri, 19 May 2006, Scott Dattalo wrote:
>
>> I think the asynchronous stimuli are too confusing. This past week
>> I've begun working on a new stimulus mechanism. This new stimulus will
>> actually be a collection of dynamically loadable modules. Think of
>> them as function generators!
>
>
> Mmmh, may be confusing but they work. I'm now observing a new problem. I
> have big stimulus files with kind of serial bit patterns. One file has
> 100,000 entries of transistions. Size about 3 MB. This file is of course
> generated by a script. In version 0.21.2 I had no problems with this
> file. Load time was ok and the simulation was fine.
100,000! That's a lot. When I'm confronted with a situation such as this
I'll write a special module to cope with it. However, I think that's too
complicated for gpsim users. It sounds like what may be more appropriate
is to have something like a "file stimulus". The stimulus takes a file
name as it's input and will fetch data only when it's needed.
The reason that the existing stimuli take longer now than they use to is
that they're more generic. In the past, you could only have 0's and 1's
for data stream. Now you can have any kind of type. This requires more
memory storage.
> Do you have a hint for me how to
> improve the reading of big stimulus files?
> or how to couple stimuli with kind of a multiplexer?
Let me design a file stimulus. I have another application I can use this
for too.
>> In addition to the pulse generator, I'm going to create something like
>> SPICE's PWL (piece-wise linear) voltage source. Essentially, this will
>> ramp between the data points instead of stepping. This will allow
>> triangle waves and saw tooth waves.
>
>
> On one hand side this is nice. On the other hand I prefer a stupid ascii
> format what I can use for machine generated files. And there is always a
> case that's too complex for the internal generators and then we move
> again to precomputed or measured data. I.E. you want to simulate a
> simple speech recognition system. You have recorded voice samples and
> want to simulate the behaviour of your program with these samples. There
> is no other way than just reading the files.
There's nothing preventing you from putting the pulsegen configuration
into a configuration script!
Scott
