Subject: Re: [vhdl-200x-mp] Re: Bi-directional signals and resistors
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon May 05 2003 - 10:51:50 PDT
> From rob@reawebtech.com Mon May 5 10:32:38 2003
>
> It seems like you should be able to model this with resolved types
> using normal VHDL. For example,
>
> > > Basic bidirectional assignment:
> > > A <=> B ;
>
> Clearly you must have some concept of drive strength in mind when
> connecting two drivers/signals. This functionality could be written:
>
> process (a,b,en) begin
> if (en = '1') then
> a<=b;
> b<=a;
> end if;
> end process;
>
> There might be lots of drivers on a and b. The capacitor would
> be a time varying driver.
>
> The values should resolve to something, then the process will
> settle down.
The problem is that "a <= b; b <= a;" forms a cycle that isn't
guaranteed to settle out to anything useful. What the process
needs to drive onto 'a' is not the value of 'b' but a function
of the drivers of 'b' from other processes - that evaluation
isn't cyclic.
Kev.
... Perhaps instead of introducing a non-procedural
> operator "<=>" one could use a component with the process
> inside. E.G.
>
> u1:my_pass_gate(a,b,en);
>
> People [e.g. Navabi] have used VHDL to model FETs because
> of the ability to override and change waveforms in the event
> queue.
>
> --Rob
>
> Kevin Cameron wrote:
>
> >
> > Another interesting device to model is a capacitor - can you do a simple
> > model that will hold the value on a net for a while after other drivers
> > have
> > gone to Z/null? (it's a single ported component).
> >
> > Kev.
> >
> > Jim Lewis wrote:
> >
> > > The resistor seems to be the interesting part.
> > > If the bidirectional assignment operator were
> > > like a "port mapping" then perhaps resistors
> > > could be handled similar to handling type
> > > conversions in a port map.
> > >
> > > Basic bidirectional assignment:
> > > A <=> B ;
> > >
> > > Extended to allow resistors:
> > > to_WLH(A) <=> to_WLH(B) ;
> > >
> > > where the to_WLH function is similar to to_X01 except
> > > it maps 0 and L to L, 1 and H to H, and all others
> > > to W.
> > >
> > > Cheers,
> > > Jim
> > >
> > >
> > > Jim Lewis wrote:
> > >
> > >> Hi Rick,
> > >> You sound a little frustrated. We have an issue
> > >> list based on the DVCon documents (posted on
> > >> vhdl-200x home page). This issue is already
> > >> on the list.
> > >>
> > >> > What else should I do to promote my cause?
> > >> Perhaps flush out some detail of what you envision
> > >> for the implementation.
> > >>
> > >> For example, when I first started thinking of this
> > >> I thought of a bidirectional operator that
> > >> attaches two bidirectional ports:
> > >>
> > >> A <=> B ;
> > >>
> > >> However, David Bishop showed me some interesting
> > >> things he would like to be able to do for pass-gate
> > >> multiplexers:
> > >>
> > >> bidir_mux : process (Sel, A, B, C)
> > >> begin
> > >> case sel is
> > >> when "00" => A <=> B ;
> > >> when "01" => A <=> C ;
> > >> when "10" => B <=> C ;
> > >> when others =>
> > >> end case ;
> > >> end process ;
> > >>
> > >>
> > >> If we do this, do we need to be able to do
> > >> concurrent assignments:
> > >> A <=> B when S = '1' else C ;
> > >>
> > >>
> > >> Do we allow the following or do the expressions
> > >> have to resolve to signals?
> > >> A <=> B and C ;
> > >>
> > >>
> > >> Your request includes, switches, resistors, and
> > >> transmission gates. I think the above may address
> > >> switches and transmission gates, how do we do resistors?
> > >>
> > >> At minimum the above needs to be made some sense
> > >> of an integrated into the MP-001 proposal.
> > >>
> > >> Cheers,
> > >> Jim
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Munden Rick wrote:
> > >>
> > >>> Jim,
> > >>>
> > >>> OK, I have submitted the proposal (for the third time). What else
> > >>> should I do to promote my cause?
> > >>>
> > >>> Rick
> > >>>
> > >>> Jim Lewis wrote:
> > >>>
> > >>>> Bidirectional assignment is on the list.
> > >>>> It is a matter of formalizing the request, submitting
> > >>>> an analysis, voting, and resolving the issue.
> > >>>>
> > >>>> We need a volunteer or two to address this issue.
> > >>>> Anyone interested in volunteering? (hint)
> > >>>>
> > >>>> This is issue MP-001. The proposal template is at:
> > >>>>
> > >>>> http://www.eda-twiki.org/vhdl-200x/proposals/proposal_template.txt
> > >>>>
> > >>>> Cheers,
> > >>>> Jim
> > >>>>
> > >>>>
> > >>>>
> > >>>> Steve Casselman wrote:
> > >>>>
> > >>>>> Verilog has many constructs like this. It allows Verilog to model
> > >>>>> almost
> > >>>>> anything you need to model and design an ASIC. I believe that
> > >>>>> Verilog is the
> > >>>>> language most ASIC designers use because of this (and performance
> > >>>>> issues).
> > >>>>> What would it take to have VHDL cover the same turff as Verilog in
> > >>>>> this
> > >>>>> respect?
> > >>>>>
> > >>>>> Steve
> > >>>>> ----- Original Message ----- From: "Kevin Cameron x3251"
> > >>>>> <Kevin.Cameron@nsc.com>
> > >>>>> To: <vhdl-200x-mp@server.eda.org>
> > >>>>> Sent: Wednesday, April 30, 2003 9:56 AM
> > >>>>> Subject: [vhdl-200x-mp] Re: Bi-directional signal flow
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>> From owner-vhdl-200x-dta@eda.org Wed Apr 30 06:50:10 2003
> > >>>>>>>
> > >>>>>>> Kevin,
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>> Is this the right group for tackling bi-directional signal flow
> > >>>>>>>> (for
> > >>>>>>>> modeling transmission gates etc.)?
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> No, I'd say that the right group is Modeling and Productivity
> > >>>>>>> (vhdl-200x-mp).
> > >>>>>>>
> > >>>>>>> Paul
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> A friend of mine has been bugging me for a while to fix this
> > >>>>>> aspect of
> > >>>>>> VHDL for him, is anyone else interested?
> > >>>>>>
> > >>>>>> The extensions would allow users to create digital models for
> > >>>>>> transmission
> > >>>>>> gates and other bi-directional devices.
> > >>>>>>
> > >>>>>> Kev.
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
This archive was generated by hypermail 2b28 : Mon May 05 2003 - 10:53:02 PDT