Re: always @(implicit_net)

Comments below.

Martin O'Leary wrote:

> Comments below.
>
>     ------------------------------------------------------------------------
>     *From:* owner-verilog-ams@eda.org
>     [mailto:owner-verilog-ams@eda.org] *On Behalf Of *Jonathan David
>     *Sent:* Friday, August 26, 2005 12:46 AM
>     *To:* Tamhankar Prasanna-A14507; verilog-ams@eda.org
>     *Subject:* RE: always @(implicit_net)
>
>     You can also assign the value of a wire to another wire..
>     assign output2 = !output1||input ; 
>     oleary>as all of these nets (output2, output1, input) are used as
>     discrete nets, they are considered discrete nets and cannot
>     resolve to continuous. 
>
For those of you new to the group: Verilog-AMS as it currently stands 
uses semantics derived from simulation environments that split analog 
and digital behavior at module boundaries (for use with old 
two-simulators-in-a-box implementations), so modules generally view a 
net as being either analog or digital (not both simultaneously). 
Obviously hardware makes no such distinction and a net can be viewed as 
digital (1/0) or analog (high/low voltage)  simultaneously. From 
previous discussions (and proposals) the current discipline 
resolution/binding scheme is referred to as "port bound", the 
alternative scheme which allows both views of a net within a module is 
"process bound".

With "process bound" semantics the discipline resolution is performed 
according to the usage of the net by analog and digital processes and 
declarartion at the module level is just somewhere to hang the type 
information.

---

The assign statement above has an equivalent process e.g.:

    always @(.*)
       output2 = !output1||input ;

- and it should behave the same as that process.

The tricky case is a straight assignment:

    assign a = b;

Is it supposed to be a short-circuit or a digital assign? - if the 
latter you might need to insert an A2D and D2A. To make matters worse 
the implementation in Verilog-D varies: Verilog-XL treats it as a short 
(using blocking assign semantics) while NC-Verilog (and others) insert a 
delta-cycle (implying it isn't a short).

To avoid the problem I added the "alias" statement to SystemVerilog so 
that you can explicitly declare a short-circuit (bidirectional) 
connection e.g.:

    alias a = b;

Going forward I'd suggest adopting "alias"  into Verilog-AMS and treat 
"assign" as always digital and issue warnings for the  degenerate cases 
that  are likely to be  intended as short-circuits.

Kev.
 

>     if either of those are wires, and get resolved to a continuous
>     discipline, there could be a difficulty, but I would assume that a
>     simple 
>     declaration added with the desired discrete discipline should
>     resolve this, which means that if its NOT resolved, and the wire
>     is used in an assign, it should be assumed to be of the
>     default discrete discipline and the appropriate connect_module
>     should be inserted at elaboration. 
>      
>     If this is NOT currently in the spec, is there ANY reason
>     we couldn't add it? 
>      
>      
>
>     Jonathan David   Mixed-Signal IC
>     jbdavid@cadence.com Ph (408)894-2646
>
>      
>
>         ------------------------------------------------------------------------
>         *From:* owner-verilog-ams@eda.org
>         [mailto:owner-verilog-ams@eda.org] *On Behalf Of *Tamhankar
>         Prasanna-A14507
>         *Sent:* Thursday, August 25, 2005 11:32 PM
>         *To:* 'verilog-ams@eda.org'
>         *Subject:* always @(implicit_net)
>
>         All,
>
>         Have a question about usage of implicit nets in Verilog-AMS,
>         can implicit nets be used in behavioral blocks ?
>
>         AMS LRM section 3.4.5 says they can be used in structural
>         descriptions, there are no restrictions on implicit net usage
>         withing behavior block.
>
>         Looks like in a pure digital module (no mixed signal), usage
>         of always @(implicit_net) is actually allowed.  However, this
>         gets complicated in a mixed-signal module because the implicit
>         net may either get resolved to be analog or digital, and doing
>         always @(analog_implicit_net) is wrong even within a digital
>         block. I have attached a simple module illustrating the issues
>         below
>
>         `include "disciplines.vams"
>
>         `timescale 1ns/1ns
>         //`default_nettype wire
>
>         module testImplicitNets;
>
>           reg d;
>           wire dout;
>
>           not #1 (implicitNet1, d);
>           not #1 (implicitNet2 , implicitNet1);
>           not #1 (dout , implicitNet2);
>
>           initial begin
>             #100 d  = 0;
>             #100 d  = 1;
>             #100 d  = 0;
>             #1 $finish;
>           end
>
>           always @( d )              $display( $time, "[DIGITAL]d
>         toggled to \t",     d );
>           always @( implicitNet1 or implicitNet2 ) $display( $time,
>         "[DIGITAL]\t\t", implicitNet1, implicitNet2);
>
>           analog begin
>             // @( implicitNet1 or implicitNet2 )
>         $strobe("[ANALOG]\t\t", implicitNet1, implicitNet2);
>                 @(implicitNet1) $strobe("[ANALOG]implicitNet1 toggled
>         at time = %g!\n",  $abstime);
>           end
>         endmodule
>
>         Cheers,
>         Prasanna
>         ------------------------------------------------------
>         Prasanna Tamhankar
>         Freescale Semiconductors, Adelaide
>         +61 8 81683585
>         ------------------------------------------------------
>