Subject: RE: Related Question [Re: your question about digital variable access]
From: Jonathan Sanders (jons@cadence.com)
Date: Tue Mar 20 2001 - 13:37:31 PST
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 semantics, or are you just taking a step back and in the end may end up
with something like they have propopsed?
Jon
At 07:24 PM 3/19/01, Ian Wilson wrote:
>My intention was *not* to require that conversion elements be
>inserted into the text. I meant the rewritten example as an
>illustration of how I should the semantics should make it
>operate.
>
>--ian
>
> > -----Original Message-----
> > From: Martin O'Leary [mailto:oleary@cadence.com]
> > Sent: Monday, March 19, 2001 6:46 PM
> > To: Ian Wilson; kevin cameron; Graham Helwig; Martin O'Leary
> > Cc: verilog-ams@eda.org
> > Subject: Re: Related Question [Re: your question about digital variable
> > access]
> >
> >
> > Ian,
> >
> > my concern with requiring an explicit conversion element for every
> > cross-domain variable access is that it is somewhat cumbersome.
> > It will make mixed-signal modules more verbose and difficult
> > to read than they would otherwise be.
> >
> > --Martin
> >
> > On Mar 19, 4:15pm, Ian Wilson wrote:
> > > Subject: RE: Related Question [Re: your question about digital
> variable ac
> > > I'm reassured that everyone sees the problems inherent in the
> > > example (repeated below) - especially since this is by no
> > > means a pathological case, but was taken from a 'simple'
> > > tutorial example in a connect module.
> > >
> > > The correct solution, in my view, is to take the position that
> > > if you replace each occurrence of a 'wrong domain' entity with
> > > an explicit conversion element, then the two representations of
> > > the problem should return the same result. There are several
> > > alternative ways to think about this - the simplest is to recognize
> > > that when you need to access a variable of one domain from another,
> > > that both domains must agree about what time it is. As Kevin says,
> > > there are several ways to implement this, but we are not concerned
> > > with that here.
> > >
> > > Applying this to the original example:
> > >
> > > module mixed1(clk,vout);
> > > wire clk;
> > > electrical vout;
> > >
> > > integer np; initial np =0;
> > >
> > > always @(posedge clk)
> > > np = np + 1;
> > >
> > > analog V(a) <+ np;
> > >
> > > endmodule
> > >
> > > this can be formally rewritten as:
> > >
> > > module mixed1(clk,vout);
> > > wire clk;
> > > electrical vout;
> > >
> > > integer np; initial np =0;
> > >
> > > always @(posedge clk)
> > > np = np + 1;
> > >
> > > integer anp; // analog representation of np
> > > digital_to_analog(anp, np);
> > >
> > > analog V(a) <+ anp;
> > >
> > > endmodule
> > >
> > > The digital_to_analog operation provides the mixed-signal
> > > synchronization that ensures that changes to np result in a
> > > synchronization event between the analog and digital world,
> > > and for a transfer of data between np and anp.
> > >
> > > The synchronization necessary in all the cross-domain cases
> > > can be deciphered by rewriting similarly. The problem is to
> > > find words that express the required semantics accurately.
> > >
> > > --ian
> > >
> > >-- End of excerpt from Ian Wilson
> >
> >
This archive was generated by hypermail 2b28 : Tue Mar 20 2001 - 14:18:18 PST