Subject: Re: LRM Issue, bad example in need of lots of corrections
From: Kevin.Cameron@nsc.com
Date: Wed May 15 2002 - 01:45:16 PDT
Jonathan Sanders wrote:
> Committee,
>
> One of our AE's hit this a couple of weeks ago. I went through the example and made the corrections needed to get it to simulate in our simulator. The net_resolution is something we are talking about removing so whatever we do we will need to address that one.
I proposed an extension to force/release to add user-programmable strengths as a solution to the net-resolution problem (and deprecating assign/deassign for SytemVerilog) -
http://www.eda.org/vlog-pp/hm/0560.html
- it's a general purpose extension i.e. not intended to be confined to A/D converter modules.
It has an advantage in that if it is available through PLI in a digital simulator you can just netlist the digital portion of a circuit and attachA2D drivers transparentlly at runtime (if you use process bound semantics, port-bound requires a different netlist).
The algorithm for Verilog-D resolution is to consider the only the highest strength driver(s), so a strength between "normal" and "force" or "supply" would be used by an A2D to override the regular Verilog-D drivers on the net. If the A2D driver is released the net would revert to regular digital behavior (with process-bound semantics).
It would also be usable for more general purpose resolution schemes which are likely to be required to handle real/wreal wires and user defined types in SystemVerilog.
Kev.
> Also, I did a search in the LRM (pdf version) and found two other examples that don't declare ground but use the ground statement (ex 3.4.3 (motorckt), 7.1.2 (comparator)) that need to be fixed by adding "electrical gnd; " to the examples.
>
> A few of these are already part of our cleanup effort but this whole example needs to be cleaned up as shown below as part of the cleanup effort as well as the two ground declaration examples listed above.
>
> Jon
>
> > Subject: Re: AMS Driver Update functions?
> >
> > Ron,
> >
> > Unfortunately most of the issues you hit in example 8.10.6 are known and being cleaned up by the committee but we don't have a new rev yet.
> >
> > You are correct on the following (plus a few others):
> >
> > ground not declared, neither is rail (needs to be: electrical rail, a, gnd; several other cases in LRM
> > )
> >
> > 1`b instead of 1'b (typo)
> >
> > branch statements are backwards (should be branch (nodeA,nodeB) branchname; only misuse in LRM)
> >
> > analog port defined as inout (should be output)
> >
> > i++ (should be i=i+1 although this will be supported in the future, only misuse in LRM)
> >
> > variable i is not defined (should be integer i, num_ones, num_zeros; )
> >
> > $driver_state(sig,index) is missing sig (should be $driver_state(d,i), only misuse in LRM )
> >
> > endconnectmodule is wrong (should be endmodule, only misuse in LRM)
> >
> > net_resolution is not supported by Cadence (we need to use assign d=out; instead, LRM will be changing this also to remove net_resolution)
> >
> > need to initialize num_ones and num_zeros (could go away as we extend support for X/Z, add: initial begin num_ones=0; num_zeros=0; end)
> >
> >
> > Anyway I made all of the above changes (and a few cosmetic ones) and have validated that the module works although it may not be optimized. I ran it on a simple ring oscillator and it seemed to oscillate.
> >
> > Jon
> >
> > Here is the modified module:
> >
> > `include "disciplines.vams"
> > `timescale 1ns/1ps
> >
> > connectmodule c2e(d,a);
> > input d;
> > output a;
> > logic d;
> > electrical rail, a, gnd;
> > reg out;
> > ground gnd;
> > branch (rail,a) pull_up;
> > branch (a,gnd) pull_down;
> > branch (rail,gnd) power;
> > parameter real impedence0 = 120.0;
> > parameter real impedence1 = 100.0;
> > parameter real impedenceOff = 1e6;
> > parameter real vt_hi = 3.5;
> > parameter real vt_lo = 1.5;
> > parameter real supply = 5.0;
> > integer i, num_ones, num_zeros;
> >
> > //net_resolution(d, out);
> > assign d=out; // Cadence method since we don't support net_resolution
> >
> > initial begin
> > num_ones=0;
> > num_zeros=0;
> > end
> >
> > always @(driver_update(d)) begin
> > num_ones = 0;
> > num_zeros = 0;
> > for ( i = 0; i < $driver_count(d); i=i+1 )
> > if ( $driver_state(d,i) == 1 )
> > num_ones = num_ones + 1;
> > else
> > num_zeros = num_zeros + 1;
> > end
> >
> > always @(cross(V(a) - vt_hi, -1) or cross(V(a) - vt_lo, +1))
> > out = 1'bx;
> > always @(cross(V(a) - vt_hi, +1))
> > out = 1'b1;
> > always @(cross(V(a) - vt_lo, -1))
> > out = 1'b0;
> >
> > analog begin
> > // Approximately one impedence1 resistor to rail per high output
> > // connected to the digital net
> > V(pull_up) <+ 1/((1/impedence1)*num_ones+(1/impedenceOff)) * I(pull_up);
> >
> > // Approximately one impedence0 resistor to ground per low output
> > // connected to the digital net
> > V(pull_down) <+ 1/((1/impedence0)*num_zeros+(1/impedenceOff)) * I(pull_down);
> >
> > V(power) <+ supply;
> > end
> >
> > endmodule
>
> ***********************************************************
> Jonathan L. Sanders
> Product Engineering Director
> Custom IC Solutions
> Cadence Design Systems, Inc.
> 555 River Oaks Pkwy
> San Jose, CA. 95134
> INTERNET:jons@cadence.com Tel: (408) 428-5654 Fax : (408) 944-7265
> ***********************************************************
This archive was generated by hypermail 2b28 : Wed May 15 2002 - 01:48:04 PDT