Subject: RE: ...digital variable access
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Wed Mar 21 2001 - 17:22:19 PST
> From imw@antrim.com Wed Mar 21 16:50:51 2001
>
> >
> > module ms_2v_dac(ctrl,d0,d1,d2,out)
> > wire ctrl,d0,d1,d2;
> > electrical out;
> > real v;
> > analog begin
> > @(posedge ctrl) begin
> > v = 0.0;
> > v = v + 0.25 * d0;
> > v = v + 0.50 * d1;
> > v = v + 1.00 * d2;
> > end
> > V(out) <+ v;
> > end
> > end
> >
> > If the d* signals are noisy the process will be re-evaluated needlessly, which
> > will slow down the entire simulation.
> >
>
> Signals in the digital domain are defined by their edges, so I'm not sure how
> you could sample them; and I don't understand what noisy means in this context.
>
> There would be a synchronization event between the analog and digital solvers
> in your example each time d0, d1, d2 change state and at no other time. When
> d0 changes, d1 and d2 aren't sampled: they retain their values (unless they
> happen to change at the same instant).
For the circuit above you could assume that the d0-d2 are part of a data bus
whose value changes at (say) 100MHz, 'ctrl' would come from some address decoder
and might run at 1MHz, so you would see (potentially) over a hundred times as
many events on d0-2 than on 'ctrl', but the analog process only looks at d0-2
on the ctrl event.
> I don't see how it's possible to do better than this without introducing the
> potential for missing changes on the digital signals being read - surely not
> a tolerable situation.
I think Verilog designers understand the potential for missing changes, that's
why '@*' got introduced in Verilog 2000, and the performance hit for
re-evaluating on all digital signal changes will be equally intolerable for
many users. So I'm voting for incorporating '@*' in Verilog-AMS for the
"sensitive to everything" behavior in analog blocks.
If you don't like using '@*' and want that as default behavior, then I think
we need an option to turn it off e.g. '!@*' or !@(d0,d1,d2), but I think that
would be more inconsistent with Verilog-D.
Kev.
This archive was generated by hypermail 2b28 : Wed Mar 21 2001 - 17:34:43 PST