Re: [Iverilog-devel] Potential rework of nets/wires support in VVP

[Cary R. <cy...@ya...>]

--- Stephen Williams <st...@ic...> wrote:

> Cary R. wrote:
> > --- Stephen Williams <st...@ic...> wrote:
> > 
> >> Add to that switch level modeling such as tranif* and rtran*. These
> >> are odd devices in that they are bidirectional. The resistive
> >> devices in particular escape me. (I was kinda holding off on
> resistive
> >> transistors to see if the problem goes away when AMS support gets
> >> figured out.)
> > 
> > Once we have multi output gates, or maybe that should be multi inout
> > gates, implementing these should not be too hard to code. If you were
> to
> > do multi output gates I would think implementing a multi output buffer
> and
> > one of the rtran gates would be enough to allow someone else to build
> the
> > rest. Is it the need or the implementation that is escaping you?
> 
> It is the implementation that is escaping me. I'm not even clear
> how a rtran resolves its inputs and generates it outputs.

I'm not sure if this is feasible or not, but would tagging the propagating
signal with the source help (a pointer to the driver object)? Only the
tran/rtran gates would retag a signal and would only propagate signals
they did not send. There is still the possibility of multiple gates
creating a loop, but that problem already exists. As a bonus, having a
usable tag would also allow us to print error messages that could point to
the driver when something goes wrong.

So something like this: the tran receives a signal on inout1 it retags the
signal making it the driver and sends the modified signal to the net
connected to inout2. It will receive a signal back on inout2, but since it
is the driver of this signal it will be ignored.
 
> > Unless you are hoping that a future version of Verilog-D removes these
> > gates we still have missing functionality. 
> 
> We have missing functionality. Even if Verilog-D does drop them,
> I have delusions of Verilog-AMS in the future and I suspect similar
> problems will turn up there.

Yes, at the digital-analog interface you could have the same problem. 
 
> That kind of complexity is already handled by the existing delay
> objects. Multiple specify path objects feed into a given delay
> node, and they are in turn used to calculate the given delay for
> logic that flows through the delay.

I didn't realize the existing delay objects were that powerful.

Cary


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs