Subject: RE: Related Question [Re: your question about digital variableaccess]
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Mar 20 2001 - 17:00:40 PST
> From jons@cadence.com Tue Mar 20 14:27:23 2001
>
> Ian,
>
> Glad to hear this clarification as if we force users to add "connect modules"
> in their text it would as Martin stated be cumbersome and would likely be a
> point of contention from a user perspective. It certainly would not be
> intuitive and it would be a bear to teach this requirement.
>
> Since conversion models can convert digital to analog in a number of ways (with
> delays, rise and fall times, deal with X and Z, ....) what are you proposing this
> conversion be. I see that what Martin and Kevin proposed as essentially defining
> this semantic, or are you just taking a step back and in the end may end up
> with something like they have propopsed?
>
> Jon
I think Ian and I agreed that for any given time - reached by all processes in the
simulation - all signal and variable names are well defined. If a process asks directly
for a value from another process using the same view of the data then there is no
problem - the value is that of the time of asking. Signals held as different views in
disparate processes will normally be converted through connect modules as they are
connected through ports defined in structural Verilog. Variables and proceduaral access
is where the problem lies (along with working out when an analog process is actually
evaluated).
I would rewrite the example as -
real np; // variable - can't attach connect module or be sensitive
...
always @(posedge clk) begin
np = np + 1.0;
V(a) <+ np; // force analog update (currently illegal?)
end
- as it appears to be signal flow. Or -
wire clk2; initial clk2 = 0;
always @(posedge clk) begin
np = np + 1.0;
clk2 = !clk2;
end
analog @(clk2) V(a) <+ np; // clk2 => np changed
[ My view is that you can easily write Verilog that doesn't do anything sensible, so
the same will probably apply to Verilog-AMS :-) ]
The case of accessing a voltage or current from Verilog-D as a real is a "same view"
access and should just work -
@(clock) if ((V(glob.vdd) - V(glob.vss)) > 3.3) begin $meltdown(); end
accessing them as logic values requires a light-weight conversion mechanism we
havn't defined yet e.g.:
@(negedge reset) if (top.irq1) $printf("IRQ 1 Jammed"); // top.irq is an analog signal
// with no structural reference
// (if in M/S simulation)
[ this was mentioned in http://www.eda.org/verilog-ams/hm/0071.html ]
- but I think extending the syntax to allow "connect functions" as well as "connect modules"
fixes that, which then handles the flip-side of behavioral analog access to digital:
real smp = 0.0;
analog begin
@(posedge sample) smp = V(top.irq2); // top.irq2 is a digital signal
V(out) <+ smp; // with no structural (port) reference
end
- which would just call a function to get a Voltage for "top.irq2" if it has not been converted
to analog somewhere already. (For completeness) accessing it as digital is "same view":
real smp = 0.0;
analog begin
@(posedge sample) smp = top.irq2 ? `VDD : `VSS;
V(out) <+ smp;
end
Note: although you can do "@(*)" in Verilog 2000 to catch all signals a block uses, it
still misses variables.
Anyway, we would probably make more headway on this stuff in a face-to-face meeting - do
we have any meetings scheduled?
Kev.
This archive was generated by hypermail 2b28 : Tue Mar 20 2001 - 17:07:06 PST