Subject:
Re: [gnupic] Remarks to gpsim of 05/12/2006
From:
Scott Dattalo ####@####.####
Date:
19 May 2006 20:04:42 +0100
Message-Id: <446E16C5.2060408@dattalo.com>
Tobias Schlottke wrote:
>> BTW, gpsim can even model an unknown bit state. However this is not fully
>> supported for the PIC processors.
>
>
> ?? I dont understand this. If a bit state is unknown and the program
> tests the bit, what should be the result? Ok, it could break with a
> warning or with an error.
That's one behavior (and is what I do). However, this behavior is
extended beyond what I think you may be expecting.
For example, consider something like this:
; interrupt routine
MOVF PORTA,W
MOVWF SampledPORTA
;------------
; non-interrupt code:
; Test the I/O state capture in the interrupt routine:
BTFSS SampledPORTA,0
CALL RA0_went_low
This code copies the state of the I/O port to a register and tests it at
a later time. With the unknown/3-state propagation, the unknown state is
stored in the variable SampledPORTA. If you attempt to execute condition
code based on the state of an unknown bit then the simulation halts. You
can examine the trace log to determine when the register obtained it's
unknown state.
But, as I said, the PIC port of gpsim does not fully support this feature.
>
> I have two further questions:
> It still regards to gpsim of 05/12/2006 so I dont open a new thread.
>
> First:
> In file src/stimuli.cc method
> ValueStimulus::start() (around line 1650):
>
> current = initial.v;
> next_sample = *sample_iterator;
> future_cycle = next_sample.time + start_cycle;
>
> get_cycles().set_break(future_cycle, this);
>
> }
>
> I appended (uncommented) the "+ start_cycle" for the future_cycle
> computation. IMHO all times are relative to the start_cycle.
>
> Do you agree?
I believe so. I made some changes here recently and may've broken this.
> Second:
> In the same file, same method at the beginning of the method you add an
> initial data set to the array if the period != 0. With this special
> handling I am not able to create an exact stimulus with an exact
> repetition. I get glitches if the period is reached and the stimulus
> rolls over. May be because the pointer into the data set is always moved
> forward one step. If we have multiple values (even equal ones) for the
> same time, the mechanism gets confused. I dont understand this extra
> value. If the last point of the array is different from the initial
> state who cares?
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!
I'm working on one called 'pulsegen' that will be used for generating
pulses. It has the same functionality of the asynchronous stimulus,
however it's behavior is controlled via editable attributes. The
asynchronous stimulus requires all of it's data in one giant gpsim
command and is uneditable.
There are attributes to control it's electrical behavior, e.g. output
resistance, output capacitance, drive voltage, etc. And there attributes
to control its personality. For example there are .set, .clear, and
.delete that have the units of simulation cycles. Here's how you use them:
module load pulsegen V1
V1.set = 100 # drive high at cycle 100
V1.clear = 200 # drive low at cycle 100
If you need to insert a pulse, then you can do this:
V1.set =50
V1.clear = 52
If you decide that you need to make a pulse wider:
V1.delete = 52
V1.clear = 55
The set and clear attributes remember the last time written to them. So
you can do this:
symbol PulseStart=100 # create a symbol with a value
symbol PulseWidth=50
V1.set = PulseStart
V1.clear = V1.set + PulseWidth
The point I'm trying to make is that attributes give you quite bit of
flexibility.
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.
>
> Ah!
>
> After thinking again I found the following:
> If you specify the stimulus as:
>
> {
> 10, 0,
> 10, 1,
> 10, 0,
> 10, 1,
> 10, 0,
> 10, 1,
> 10, 0,
> 20, 1
> }
That won't work because you're repeatedly specifying cycle 10.
Scott
