OVI soliciting Verilog enhancements and ideas
Elliot H. Mednick
seeking ideas for ways Verilog might be extended, if at all, to support
any and all aspects of Verilog usage.
In recent articles in this group, several people have mentioned certain
aspects of the language they would like to see enhanced. We will
consider any request. Already suggested are such items as multi-
dimensioned arrays and local variables.
It should be noted that the LS is very aware of the benefits of the Verilog
language, one being its ease of use. We want to keep it that way, so
any enhancements would ultimately have to stay within the spirit of the
Verilog language. We do not want to turn Verilog into another VHDL,
although some aspects of VHDL not currently in Verilog may have some
appeal.
One weakness of Verilog is its perceived value as an architectural-level
simulator. Perhaps this is an avenue for exploration.
Please send requests, ideas, comments, etc. to me or to Maq Mannan,
<man...@berlioz.nsc.com>.
Thanks for your attention.
--
Elliot H. Mednick P.O. Box 150
Wellspring Solutions, Inc. Sutton, MA. 01590
ell...@Wellspring.com +1 508 865 7271
Interpretive Systems
>The Language Subcommittee of Open Verilog International is actively
>seeking ideas for ways Verilog might be extended, if at all, to support
>any and all aspects of Verilog usage.
>
In my opinion, the one feature that is missing most is the external
declaration a-la ANSI C. Example:
extern module m(input[7:0] i, output[2:0] o);
This will ease separate compilation/analysis of modules (while we are
at it, let's abolish all forward references).
Eli Sterheim
interHDL inc.
(408) 749-8775
e...@interhdl.com
Hai Vo-Ba
: In recent articles in this group, several people have mentioned certain
: aspects of the language they would like to see enhanced. We will
: consider any request. Already suggested are such items as multi-
^^^^^^^^^^^^^^^^^^
I could really use bit selections with an element of a register array
Oren Rubinstein
: <man...@berlioz.nsc.com>.
One of the common problems is the inability to have indices in instance
names.
I would like to be able to write something like:
______________________________________________
input [31:0] a,b;
output [31:0] q;
integer i;
for (i = 0; i < 32; i = i + 1) begin
my_cell cell_name[i] (q[i],a[i],b[i]);
end
______________________________________________
and have Verilog understand that I want to instantiate 32 cells.
And while we are at it, I'd like to have "for(i=0;i<32;i++)"
_______________
Oren Rubinstein
Hewlett-Packard (Canada) Ltd.
Panacom Automation Division or...@waterloo.hp.com
20 Lexington Rd. TEL (519) 883-3067
Waterloo, Ontario N2J-3Z3 FAX (519) 886-8620
CANADA
Disclaimer: the above opinions are my own; I do not speak for HP.
Kartik Subbarao
>seeking ideas for ways Verilog might be extended, if at all, to support
>any and all aspects of Verilog usage.
Make it more like C. Get rid of endmodule, endtask, etc -- unify everything on
{..}. (Some people currently even have //{ and //} after every begin and end
so they can match braces). Make semicolon usage more logical and to your
advantage. Add ++ and -- operators. Pascal is a language of the 70's. People
don't develop serious code on it anymore. Making verilog more C-like will
work wonders for ease of use, familiarity, and extendibility.
While you're at it, improve the VCD file format too -- get a real
compression scheme going so that time-consuming wading through 100 MB dump
files isn't necessary.
-Kartik
Dave Rich; x6337
|> One of the common problems is the inability to have indices in instance
|> names.
|>
|> I would like to be able to write something like:
|> ______________________________________________
|> input [31:0] a,b;
|> output [31:0] q;
|>
|> integer i;
|>
|> for (i = 0; i < 32; i = i + 1) begin
|> my_cell cell_name[i] (q[i],a[i],b[i]);
|> end
|> ______________________________________________
|> and have Verilog understand that I want to instantiate 32 cells.
|>
This ability was already added in OVI LRM 2.0. The syntax is simpler,
but it covers 95% of what people want to do with iterated instances.
(This syntax comes from HILO, Verilog's predecessor)
input [31:0] a,b;
output [31:0] q;
my_cell cell_name[31:0] (q,a,b);
--
___________________________________________________________
Dave Rich tel 1-508-446-6337 email dav...@cadence.com
Cadence Design, 270 Billerica Rd., Chelmsford MA 01824-4140
"I used to have Time. Now I have Twins"
___________________________________________________________
Cindy Eisner
--
Cindy Eisner, Tel: 972-4-551551
CAD group, Fax: 972-4-551550
Zoran Microelectronics LTD, E-mail: ci...@Zoran.HellNet.Org
Advanced Technology Center
POB 2495, Haifa 31204, Israel Could be my employer doesn't agree.
Michael Lodman
>seeking ideas for ways Verilog might be extended, if at all, to support
>any and all aspects of Verilog usage.
How about a decent preprocessor, better command line arguments for
code, braces instead of begin/end, abbreviated operators (a++), an
arithmetic shift operation, the ability to default powerup register
values to something besides unknown, the ability to use true macros.
--
Michael Lodman Department of Electrical and Computer Engineering
University of California, San Diego
jlo...@cs.ucsd.edu (619) 455-1500 x2627
"If you don't care where you are, you ain't lost"
John Williams
1) Virtual processes.
Allow true local variables in tasks and functions with the ability
to call them multiple times and / or recursively.
2) Transport delay.
Allow a selection of delay mode, either inertial or transport.
3) Dynamic memories.
Allow memories to be dynamically allocated.
These could be implemented by using keywords before declarations such as:
virtual reg [31:0] argument;
.. or ..
dynamic reg [31:0] memory [0:1023];
.. or ..
@(transport #10);
John.
Venkatesh Elayavalli
primary products are memories and PLDs based on BiCMOS process. The problem
we encounter with Verilog is ther is no bipolar primitive and we are using
behavioral models for bipolar device configurations.
Question: Are there any plans to provide support for bipolar/bicmos premitives.
if so what would be the approximate time frame when this would happen.
Thanks
Venkatesh K. Elayavalli
Aspen Semiconductor Corp.
4001 N. First St.
San Jose CA 95134
phone: 408 456 1858
email: v...@cypress.com
John Williams
design op amps with them, these should work OK.
John.
Gary York
>I'll only repeat what I said earlier:
>
>1) Virtual processes.
>
> Allow true local variables in tasks and functions with the ability
> to call them multiple times and / or recursively.
>
>3) Dynamic memories.
>
> Allow memories to be dynamically allocated.
>
The problem with dynamic allocation and recursion is that they they don't
correspond to hardware. In general, they imply a system with MUCH greater
state (effectively infinite state) which makes synthesis and formal
verification inpossible (with current techniques).
Remember that Verilog is an HDL (Hardware description language).
---
Gary York
Cadence Labs
Cadence Design Systems e-mail: yo...@cadence.com
555 River Oaks Parkway, 3B1 phone: (408) 944-7839
San Jose, CA 95134 fax: (408) 954-9517
--- standard disclaimer ---
Paul Israel
> In article <742068...@Wellspring.COM> ell...@Wellspring.COM writes:
>>The Language Subcommittee of Open Verilog International is actively
>>seeking ideas for ways Verilog might be extended, if at all, to support
>>any and all aspects of Verilog usage.
>
> How about a decent preprocessor, better command line arguments for
> code, braces instead of begin/end, abbreviated operators (a++), an
Hey, what are ya, some kind of darned C junkie? :-)
Yeah, yeah, yeah, I agree with all of this.
> arithmetic shift operation, the ability to default powerup register
^^^^^^^^^^^^^^^^^^^^^^^^^^
reg [31:0] x,y,z;
// Arithmetic Shift Left by z
x[31:0] = {y[31], (y[30:0] << z)}
// Arithmetic Shift Right by z
x[31:0] = {{32{y[31]}}, y[30:0]} >> (z > 31) ? 31 : z;
I don't know what the synthesizer will produce, but the verilog code
seems to work.
> values to something besides unknown, the ability to use true macros.
Yeah, it would certainly be nice to use macros that can take an
argument.
--
Paul Israel, Senior Smartypants, Unisys Corporation, San Jose, California
isr...@risky.convergent.com Disclaimer: "Who, me? I wasn't even there!"
Quote: "Don't think of it as a gun - think of it as a remote control for
turning people off." - Roger Guts, PI
Elliot H. Mednick
> In article p...@largo.key.amdahl.com, jw...@key.amdahl.com (John Williams) > writes:
> >
> > Allow memories to be dynamically allocated.
> >
>
> The problem with dynamic allocation and recursion is that they they don't
> correspond to hardware. In general, they imply a system with MUCH greater
> state (effectively infinite state) which makes synthesis and formal
> verification inpossible (with current techniques).
>
> Remember that Verilog is an HDL (Hardware description language).
The fact that a construct is or is not synthesizable is not a precondition
for adding it to the language specification. There are plenty of
higher level syntax that are useful for methodologies that don't
include synthesis or formal verification. In fact, most, if not all
commercial synthesis tools require RTL-like coding conventions. Behavioral-
and architectural-level modelling does not require the exclusive use
of synthesizable constructs.
VH*L advocates claims that amongst its strengths are the abstraction
constructs that one would use at the high levels of modeling.
These are certainly not synthesizable.
The term "HDL" is a label, not a denotation. There is a difference between
hardware "description" and hardware "mapping".
I will comment on some of the other suggestions when I am ready to
present to the Language Subcommittee the postings made here.
Thanks to those who have made these suggestions thus far.
-Elliot
Interpretive Systems
Remember that an HDL needs to describe not only hardware but also general
environment. In fact modeling the environment around the hardware can be
as big or bigger task than describing the hardware. I agree that we should
make Verilog as close to C (actually C++) as possible.
John Cooley
>
>Remember that an HDL needs to describe not only hardware but also general
>environment. In fact modeling the environment around the hardware can be
>as big or bigger task than describing the hardware. I agree that we should
>make Verilog as close to C (actually C++) as possible.
>
>Eli Sterheim
I'd like to second Eli's motion. Verilog is not only a hardware description
language, a lot of simulations people have to work in whatever HDL of choice
the ASIC designers are designing in; having C or C++ like constructs
available in Verilog helps the language to be accepted throughout the
design world.
- John Cooley
EDA & ASIC Design Consultant
(and ESNUG Moderator, too!)
===========================================================================
Trapped trying to figure out a Synopsys bug? Want to hear how others dealt
with it ? Join the E-Mail Synopsys Users Group! To join, E-mail me today!
John Cooley
!!! "It's not a BUG, jco...@world.std.com
/o o\ / it's a FEATURE!" EDA & ASIC Design Consultant
( > ) (508) 429-4357
\ - / Snail Mail: P.O. Box 6222, Holliston, MA 01746-6222
_] [_ "There's nothing here but opinions in these letters."
Gary York
...
>
>The fact that a construct is or is not synthesizable is not a precondition
>for adding it to the language specification. There are plenty of
>higher level syntax that are useful for methodologies that don't
>include synthesis or formal verification. In fact, most, if not all
>commercial synthesis tools require RTL-like coding conventions. Behavioral-
>and architectural-level modelling does not require the exclusive use
>of synthesizable constructs.
I agree that there are some constructs that are useful that "current"
synthesis tools don't handle. However, that is not the point.
If an HDL supports constructs that can not be supported in any
reasonable way in hardware, then I claim it should not be an HDL construct.
It may be useful in a SDL (System Design Language).
Future synthesis tools can handle everything in VHDL with a few exceptions. Two
of those are recursion and dynamic allocation.
I think adding concepts to Verilog which are completely foreign to hardware
would be a step in the wrong direction.
George Lippincott
>Elliot H. Mednick (ell...@Wellspring.COM) wrote:
>: Please send requests, ideas, comments, etc. to me or to Maq Mannan,
>: <man...@berlioz.nsc.com>.
>One of the common problems is the inability to have indices in instance
>names.
>I would like to be able to write something like:
>______________________________________________
>input [31:0] a,b;
>output [31:0] q;
>integer i;
>for (i = 0; i < 32; i = i + 1) begin
> my_cell cell_name[i] (q[i],a[i],b[i]);
>end
>______________________________________________
>and have Verilog understand that I want to instantiate 32 cells.
And also
if(i > 3) begin
my_cell cell_name[i] (...)
end
Or
if(i > 3) begin
for (j = 0; j < i; j = j + 1) begin
my_cell cell_name[j] (...)
end
my_cell2 cell_name2[i] (...)
end
This "generate" capability exists in VHDL and also in many schematic
editors. Some students at the University of Michigan put together a
verilog-based system that had this capability added to it (See "Synthesis
and Verification of a GaAs Microprocessor From a Verilog Hardware Description
in the 1992 OVI Conference proceedings). It should not be difficult to
come up with an acceptable syntax to do this and it would be useful.
I was surprised that this feature was not included in the 2.0 spec.
---------------------------------------------------------------------------
George Lippincott | UUCP: uunet!ole!george
Cascade Design Automation Corp. | Internet: geo...@ole.cdac.com
3650 131st Ave SE, #650 | TEL: (206)-649-7661
Bellevue, WA 98006 | FAX: (206)-649-7600
Michael T.Y. McNamara
|e...@netcom.com (Interpretive Systems) writes:
|>
|>Remember that an HDL needs to describe not only hardware but also general
|>environment. In fact modeling the environment around the hardware can be
|>as big or bigger task than describing the hardware. I agree that we should
|>make Verilog as close to C (actually C++) as possible.
|>
|>Eli Sterheim
|
|I'd like to second Eli's motion. Verilog is not only a hardware description
|language, a lot of simulations people have to work in whatever HDL of choice
|the ASIC designers are designing in; having C or C++ like constructs
|available in Verilog helps the language to be accepted throughout the
|design world.
|
as a Hardware Description Language, but as a Hardware Design and Verification
Language. (HDVL, how's that for a shuffle)
I.E., one gets no points for describing hardware with an HDL.
One gets lots of points for describing the hardware that does what
one wants it to do!!
Hence features that allow the later are of as much value as those
facilitating the former.
--
__ ______
Michael T.Y. McNamara -o| \_____| |------ 1+(415) 965-3312
C H R O N O L O G I C --|__/ | | 1+(415) 965-2705 FAX
--------. Simulation -----------|> |------ m...@chronologic.com
Gavin Brebner
to become more "C" like - well here is an appeal against any such
step.
Verilog as a language should have as some of it's goals (IMHO) clarity, simplicity,
and "obviousness". It is important that anything that hides the meaning
of code should not be part of the language. "C" has many strengths as a sequential
language for hacking OS code and other similar applications. It is also well
known, however, as a language which takes pride in being concise to the point of
being unreadable to any but the "gurus", and in which the unwary can easily encode
bugs which are extremely difficult to identify. In designing a language that
expects to be widely used in the verification of chips (where the cost of errors
can be extremely high), I think that "C", no matter how familiar to some, is an
extremely inappropriate role model. The wide use of a language in one area should
not be taken as meaning that it is in any way suitable for tasks far removed from
the original intention of the creators.
In a similar vein, I would also argue that the ability to default the initial
values of a reg to something other than x is dangerous. Although typing in an
"initial" block may take a little more time, explicit assignment of values within
an easily identifiable block reduces the chance of errors (IMHO).
---
Gavin Brebner,
Advanced Computer Research Institute,
1 Bd. Marius Vivier-Merle,
69443 Lyon Cedex 03, France
email: bre...@acri.fr
Tel : (33) 72 35 84 45
Fax : (33) 72 35 84 77
Bob Wood
> The problem with dynamic allocation and recursion is that they they don't
> correspond to hardware. In general, they imply a system with MUCH greater
> state (effectively infinite state) which makes synthesis and formal
> verification inpossible (with current techniques).
> Remember that Verilog is an HDL (Hardware description language).
---
> Gary York
> Cadence Labs
While it's true that Verilog is an HDL, many of us use the existing Verilog
simulators (particular Verilog-XL) to do full system simulation, which often
entails more than just feeding vectors through the HDL model. We typically
have tasks for doing things like:
* loading a program image (or a partial image) into the cache.
* randomly pulling a retry line on the system bus.
* displaying the contents and state of a cache block by displaying the
contents of several rams in a meaningful format.
* simulating other bus traffic (noise).
None of these represent any real hardware, but we find these types of tasks
quite useful for modeling how our design will respond when it's put into
a large system, without incurring the memory overhead of simulating the
whole system. We're forced to implement these tasks in Verilog, along with
all of the inherent restrictions (or we could go thru the PLI, with just
enough Verilog to connect to the simulation). I could see a lot of benefit
to having more software-friendly features that would help us implement
this code that doesn't represent real hardware in the first place.
-- bob wood
data general corp
Don Lewis
>In article <742068...@Wellspring.COM> ell...@Wellspring.COM writes:
>>The Language Subcommittee of Open Verilog International is actively
>>seeking ideas for ways Verilog might be extended, if at all, to support
>>any and all aspects of Verilog usage.
>
> braces instead of begin/end ...
I've wished for this too, but what do propose doing about fork/join?
--
Don "Truck" Lewis Phone: +1 916 478-8284 Silicon Systems
Internet: gd...@ssi1.com FAX: +1 916 478-8251 138 New Mohawk Road
UUCP: {uunet,tektronix!gvgpsa.gvg.tek.com}!ssigv!gdonl Nevada City, CA 95959
Kartik Subbarao
>In article <51...@sdcc12.ucsd.edu> jlo...@cs.ucsd.edu (Michael Lodman) writes:
>>In article <742068...@Wellspring.COM> ell...@Wellspring.COM writes:
>>>The Language Subcommittee of Open Verilog International is actively
>>>seeking ideas for ways Verilog might be extended, if at all, to support
>>>any and all aspects of Verilog usage.
>>
>>How about ...
>> braces instead of begin/end ...
>
>I've wished for this too, but what do propose doing about fork/join?
Simple -- ditch the join.
fork {
...
}
-Kartik
John Williams
> The problem with dynamic allocation and recursion is that they they don't
> correspond to hardware. In general, they imply a system with MUCH greater
> state (effectively infinite state) which makes synthesis and formal
> verification inpossible (with current techniques).
>
> Remember that Verilog is an HDL (Hardware description language).
Remember that synthesis language is ALREADY a subset of "HDL".
Remember that "HDL" is useless without a way to model the environment.
Remember that the success of verilog depends on your end user's time to market.
Remember that the purpose of OVI is to prevent Cadence from refusing to make
verilog marketable in the long term.
Remember that without OVI many users would already be flocking to VHDL.
As strange as this may sound, I do not write any models that are implemented
in hardware.
John.
Michael Lodman
>>How about ...
>> braces instead of begin/end ...
>
>I've wished for this too, but what do propose doing about fork/join?
Nobody doing synthesis uses fork/join, and there are better constructs for
hardware modeling, namely the non-blocking assignment.
Adam Krolnik
I like using a more powerful language suited for programming. Having an interface
to the hardware language then allows me to develop my environment and then connect it
to the hardware. This way I get much greater performance both in developing the
environment and in the execution speed.
Adam Krolnik (214) 497-4578
Design Verification Engineer
Convex Computer Corp, Richardson Tx, 75083
John Williams
---
> We're forced to implement these tasks in Verilog, along with
> all of the inherent restrictions (or we could go thru the PLI, with just
> enough Verilog to connect to the simulation). I could see a lot of benefit
> to having more software-friendly features that would help us implement
> this code that doesn't represent real hardware in the first place.
I've written a fairly large amount of PLI in order to support our current
verification methodology. The problem with implementing things in C is that
C has no conception of blocking in the middle of a routine, that is, you have
to exit the routine and block in verilog. I've written some PLI that implements
a virtual queue ( the queue identifier is the virtual process name and the queue
contents are the (true) local variables), however, I have to split a virtual
process into distinct single threaded units. It would be far more convenient and
readable if these virtual processes could remain whole and multi threaded.
I'll briefly mention the obvious or not so obvious: Virtual processes can not be
traced. This means you can't enable or disable them. You can't access them using
hierarchical names. You have to debug using display functions and breakpoints
( which you have to do with PLI ). I don't expect virtual processes to have
magical qualities, I fully expect all the limitations of any virtual language
( like C ).
While we're at it, non blocking tasks would be extremely valuable. The construct
for this might be a block keyword pair such as detach and attach, used
in a manner similar to fork and join, except that the process is not blocked at
the attach like it is at the join.
A brief coding example:
task pulse;
virtual input [31:0] ticks;
virtual input [31:0] data;
begin
while (ticks > 32'h00000000)
begin
@(posedge clock);
ticks = ticks - 32'h00000001;
end
line_out = data;
end
endtask
always
begin
@(posedge clock);
if (condition === 1'b1)
detach
pulse(32'h00000010,line_in);
attach
end
This would create a process that performs a sort of transport delay. Granted,
this example is trivial, but I think it encapsulates the concept.
John.
Steve Miller
My suggestions for Verilog enhancements come from the viewpoint
of a design verification engineer. My primary concerns are with
building simulation environments and verifying the designs.
1) Better support for strings.
The current support that Verilog has for strings is only
slightly better than assigning ASCII codes to registers.
I spend way too much time dealing with the short-comings
of Verilog strings.
What we need is a new character data type that works like
characters in other programming languages. This would mean
null-terminated strings, among other things.
2) Reference bit ranges using expressions.
I would like to be able to do something like this:
reg [63:0] big_reg
reg [7:0] good_byte;
integer i;
good_byte = 8'hAB;
for (i = 63; i > 0; i = i - 8) begin
if (big_reg[i:i-8] == good_byte)
$display("Found good byte");
end
Currently, I would have to explicitly check each byte like
this:
if (big_reg[63:56] == good_byte)
$display("Found good byte");
if (big_reg[55:48] == good_byte)
$display("Found good byte");
.
.
.
if (big_reg[7:0] == good_byte)
$display("Found good byte");
3) True local variables in tasks and functions.
Someone else already suggested this one, but I feel that it
is important enough to re-state it. I need this so that I
can call the same task multiple times. I probably wouldn't
use it for recursion, though.
+-------------------------------------------------------+
| Steve Miller PictureTel Corporation |
| email: mil...@pictel.com One Corporation Way |
| phone: (508) 977-8235 Peabody, MA 01960 |
+-------------------------------------------------------+
John Williams
> Rather than use the HDL language to describe the environment the hardware lives in,
> I like using a more powerful language suited for programming. Having an interface
> to the hardware language then allows me to develop my environment and then connect it
> to the hardware. This way I get much greater performance both in developing the
> environment and in the execution speed.
This works OK if the interface is single threaded. Multi threaded interfaces
will require that you split the processes into single thread units.
Multi threaded:
>--process 1---------------------->
>--process 2---------------------->
Single threaded:
>--process 1a---->
>--process 1b---->
>--process 2a---->
>--process 2b---->
As I said earlier, I use the PLI extensively, but C is absolutely useless when
it comes to blocking.
I personally feel as though verilog is not that far away from virtual processes,
I believe I enumerated 5 new keywords; virtual, dynamic, transport, detach, and
attach. With compiled verilog, the difference in performance should be within
an order of magnitude, and the time needed to develop a verification suite is
shortened significantly.
John.
Venkatesh Elayavalli
>The bipolar "primitive" is either tran or rtran. As long as you aren't trying to
>design op amps with them, these should work OK.
>
> John.
There are many situations in digital ICs where bipolars are more analogish than digital.
Example memories. In many cases, just using tran/rtran may not correctly simulate the
logic that is required to be simulated, examples: selfreseting logic. The solution is to
use behavioral representations. Also, having them as primitives makes life easier when
using switchxl, since you are delaing with only one strength model, instead of two
differnt models which is the case now (numeric for switchxl and regular highz-to-supply
model for behavioral blocks).
-venkatesh.
Frank Bennett
In UDP definitions I would like to use z in addition to 0,1,x
_/_/_/_/ _/ _/ _/_/_/ | Frank Bennett, MTS
_/ _/ _/ _/ _/ | Hewlett Packard
_/_/_/ _/ _/ _/ _/_/_/ | Fort Collins, CO
_/ _/_/ _/_/ _/ _/ | (303) 229-2679
_/ _/ _/ _/_/_/ | f...@fc.hp.com
Gary McGoff
>
>In UDP definitions I would like to use z in addition to 0,1,x
>
How about extending the "x" state so that one can tell "x" from the complement of "x".
An example: (pardon the line drawn schematic - the fluffy triangles are supposed
to be inverters).
|\ |\ |\
in ----| *------| *---+--| *-------out2 = "x" (i.e. unknown)
|/ |/ | |/
|
|____________out1 = "x_" (i.e. unknown but the complement of x)In article
now, suppose out1 and out2 are the inputs to a two-input exclusive OR gate.
Should not the output of the exclusive OR be 1 regardless of whether ((out1=1 and out2=0) OR
(out1=0 and out2=1))? If only the states could be represented as "x" and "x_" or some such
nomenclature, AND the udp capability were extended to allow one to distinquish between "x"
and "x_".
The UDP capabilities would also be greatly enhanced by adding the z state capability.
While we are on this, why not allow udps to have two outputs, Q and Qbar, rather than having
to add logic to generate this which modeling simple flip flops, etc.
Gary McGoff
Senior EE
Motorola Inc., SPS, ASIC Division
1300 North Alma School Road
Chandler, AZ 85224
(602)814-4251
email: mcg...@chdasic.sps.mot.com
Gary McGoff
I totally agree with Gavin. As a hardware engineer, the only thing I can think of that
scares me more than hardware engineers writing software is software engineers
designing hardware.
Gary McGoff
Senior EE
Motorola ASIC
Dave Rich; x6337
|> This "generate" capability exists in VHDL and also in many schematic
|> editors. Some students at the University of Michigan put together a
|> verilog-based system that had this capability added to it (See "Synthesis
|> and Verification of a GaAs Microprocessor From a Verilog Hardware Description
|> in the 1992 OVI Conference proceedings). It should not be difficult to
|> come up with an acceptable syntax to do this and it would be useful.
|> I was surprised that this feature was not included in the 2.0 spec.
|>
The ability to instanciate arrays of instances was added in the 2.0 spec.
It is not as flexible as the "GENERATE" statement in VHDL, but it does
cover all of the "for" loop type in structures
--
___________________________________________________________
Dave Rich tel 1-508-446-6337 email dav...@cadence.com
Cadence Design, 270 Billerica Rd., Chelmsford MA 01824-4140
"I used to have Time. Now I have Twins"
___________________________________________________________
Cindy Eisner
> Nobody doing synthesis uses fork/join, and there are better constructs for
> hardware modeling, namely the non-blocking assignment.
>
wrong! synopsys v3.0 supports it, and we have coded and successfully
synthesized one module of our current block using fork/join. assuming
we have no unforseen problems, we plan to start using fork/join throughout
our modules.
fork/join solves the problem of delays accumulating under being/end (yes,
even with non-blocking assignments), which can cause ugly simulation-time
bugs.
cindy.
--
Cindy Eisner, Tel: 972-4-551551
CAD group, Fax: 972-4-551550
Zoran Microelectronics LTD, E-mail: ci...@Zoran.HellNet.Org
Advanced Technology Center
POB 2495, Haifa 31204, Israel Could be my employer doesn't agree.
Jurgen Schulz
Our version of Synopsys V3.0 has fork/join down as an unsupported statement.
Delays do not accumulate in non-blocking assignemnts.
Regards, Jurgen.
j...@dsbc.icl.co.uk
John Williams
> How about extending the "x" state so that one can tell "x" from the
> complement of "x".
I do not know if you realize the can of worms you are opening up with this one. Not only
do you need a complement of "x", but an identifier to mark each "x" with an origin.
Believe it or not, I wrote a simulator that solved exactly this type of problem. I
solved the general case, which involved any combination of "x" in a gate level network.
One benchmark I ran was something I called a stall counter, that is, a counter that
counts up to a certain number then stops. Theoretically, if it starts in the unknown
state, it should transition to the final state after a certain number of ticks.
In order to do this, I had to run a different ( concurrent ) simulation for every
permutation of initialization values. Very expensive and combinatorially explosive.
I was researching algorithms for simulating self timed circuits years ago. As you know,
self timed circuits more or less died out when the cost of analysis was figured into
the cost of production.
I do not recommend any analysis of "x" states.
John.
John Williams
> fork/join solves the problem of delays accumulating under being/end (yes,
> even with non-blocking assignments), which can cause ugly simulation-time
> bugs.
Since I was the original poster - I would be very interested in hearing about how
non-blocking assignments accumulate delay in begin - end blocks. If you are willing
to put your assignments in reverse order, you don't even need non-blocking assignments
and you speed up your simulation significantly ( you are not thrashing the event list
with every assignment ).
Sure, maybe an extra bug or two might slip through - but I consider these relatively
easy to identify and correct, and the increased simulation performance makes up for it.
Personally, I never even use non blocking assignments. I just do it in reverse order.
However, I will admit that the blanket statement "No one uses fork - join" is a little
over zealous.
John
Cindy Eisner
> Our version of Synopsys V3.0 has fork/join down as an unsupported statement.
yes, you are correct. as michael lodman has already pointed out to me,
i was the one who was wrong here. fork/join is not supported by synopsys.
sorry for any confusion this has caused.
what i was thinking of was non-blocking assignment, which, when used correctly,
give you the effect of fork/join in synthesizable code.
> Delays do not accumulate in non-blocking assignemnts.
yes, again, you are correct. again, i was thinking of the old problems with
begin
a = #1 b;
c = #1 d;
end
which are blocking assignments.
again, i apologize for the confusion. glad to see you are all awake out there.
Cindy Eisner
> If you are willing
> to put your assignments in reverse order, you don't even need non-blocking assignments
> and you speed up your simulation significantly ( you are not thrashing the event list
> with every assignment ).
>
> Sure, maybe an extra bug or two might slip through - but I consider these relatively
> easy to identify and correct, and the increased simulation performance makes up for it.
as i've already said - i was mistaken about accumulating delays under non-
blocking.
now, about this above - i am interested in hearing why you consider these bugs
"easy to identify and correct". if you are talking about synthesized code, as
i assume you are, then if you mess up the order and your simulations
work anyway because of some other bug - the only place you will identify
these is at gate level simulation, correct? i.e., simulation will not agree
with synthesis. we go to great lengths to make sure that our coding style
ensures that simulation will agree with synthesis - so i am interested in
hearing from people that do it another way. do people find it easier to allow
simulation to disagree with synthesis and then go back and debug these
problems one by one?
John Williams
> "easy to identify and correct". if you are talking about synthesized code, as
> i assume you are, then if you mess up the order and your simulations
> work anyway because of some other bug - the only place you will identify
> these is at gate level simulation, correct?
I'm talking about having the assignments execute out of order. I'm not a big
synopsis user ( rather, I'm a design verification engineer ), so I can't tell you
the full ramnifications of how synopsis will react to a mangled file. My experience
is that blocking statements work faster and if properly understood only generate a
small number of bugs which are easy to find. If you are talking about double munged
bugs ( a bug fixed with a bug ) that works in verilog but not in synopsis, I would
say, "get trained".
For synchronous devices, I might model then like:
reg [7:0] d;
always // pipeline shift register
begin
@(posedge clock);
d_out = d[7];
d[7:1] = d[6:0];
d[0] = d_in;
end
You can see the order dependency. Maybe it's just because I'm comfortable with
software, but the order dependency stuff comes naturally to me. I minimize the
events on the event list so it runs faster.
As far as I can determine, non-blocking assignments are yet another verilog bandaid
for the lack of detached tasks. They are also the first thing a rookie grabs on to
to apply universally as the cure to all order dependency ills.
Maybe the idea of programming for side effects bothers you. All I can say is that
performance is always a side effect of programming style. I haven't actually run
any benchmarks, but it would not surprise me if the difference was as much as a factor
of 3 or 5.
John.
Rafael Diaz
>>In article 4...@ca41.zoran.hellnet.org, ci...@Zoran.Hellnet.Org (Cindy Eisner) writes:
>> now, about this above - i am interested in hearing why you consider these bugs
>> "easy to identify and correct". if you are talking about synthesized code, as
>> i assume you are, then if you mess up the order and your simulations
>> work anyway because of some other bug - the only place you will identify
>> these is at gate level simulation, correct?
Regarding HOW to identify these "out-of-order" cases is by using two different
version of Verilog-XL. The different versions usually come to 'enhance' the
XL algorithm, and thus use different random-que-ordering. Different random-queue-
ordering will hopefully "flag" them.
Our group approached Cadence to include a 'random-seed' select variable set
at initialization. This way, one could change the random-queue on the fly.
The question is - When Cadence delivers?
As for now, you are correct in approaching the identification at Gate-Level.
I'm not sure about performance, but Modifying the pipeline to Master-Slave, takes out
ALL order dependency. e.g.:
reg [7:0] d_m, d_s;
always // Master-Slave pipeline shift register
begin
@(posedge clock);
d_out = d_s[7];
d_m = d_in;
end
always // Slave-Part
begin
@(negedge clock)
d_s[7:1] = d_m[6:0];
d_s[0] = d_m[0];
end
--cheers
_________________________________________________________________________
__ _
=_ __ ___ = / ) / ) ============ ra...@sol-tx.sps.mot.com
= ) /_ ) ) = /--< _ -/- == oakhill!sol-tx!ra...@cs.utexas.edu
= ___/ / = / / (_( / (_/ =========== Ph: (512) 891 2977
=== Rafy Diaz ===== Motorola Inc. / AMCU Operations, Austin TX ===========
/
p.s. Say hi to Sergio.
--
_________________________________________________________________________
__ _
=_ __ ___ = / ) / ) ============ ra...@sol-tx.sps.mot.com
= ) /_ ) ) = /--< _ -/- == oakhill!sol-tx!ra...@cs.utexas.edu
Cindy Eisner
> I'm not sure about performance, but Modifying the pipeline to Master-Slave, takes out
> ALL order dependency. e.g.:
>
> reg [7:0] d_m, d_s;
> always // Master-Slave pipeline shift register
> begin
> @(posedge clock);
> d_out = d_s[7];
> d_m = d_in;
> end
>
> always // Slave-Part
> begin
> @(negedge clock)
> d_s[7:1] = d_m[6:0];
> d_s[0] = d_m[0];
> end
yes, this is the way we do it, in order to ensure that simulation agrees with
synthesis. but of course we have simulation performance problems just like
anyone else. i wonder if someone can tell us if a compiled-code simulator
would show a performance difference between these two coding styles?
Paul Tobin
signal value in Verilog, making it easy to distinguish between drive
fights and as yet undriven signals. In silicon, internal nodes not
directly reset at powerup settle to some value. In Verilog, that
value is X. When that X is encountered during simulation, say by the
tool you're using to check results, there's no way to tell if it was a
drive fight or simply an internal storage node that hadn't been driven
yet. Often, you wouldn't care about the "unitialized" value, but you
would definitely want to track down a drive fight.
Paul Tobin
Hewlett-Packard
p...@fc.hp.com
John Williams
> In addition to 0,1,X, and Z, we'd like to see a new "uninitialized"
> signal value in Verilog, making it easy to distinguish between drive
> fights and as yet undriven signals.
I disagree with this request. Adding more symbols to the logic would have an
adverse effect on the performance of the simulator. I know that for the work
we do, X's are undesirable, period. We never ignore X's. When I write a transactor
I drive X's during the time a design model should be ignoring a signal. I really
can't see the use of additional X permutations.
John.
Paul Tobin
: In article 4...@fc.hp.com, p...@fc.hp.com (Paul Tobin) writes:
: > In addition to 0,1,X, and Z, we'd like to see a new "uninitialized"
: > signal value in Verilog, making it easy to distinguish between drive
: > fights and as yet undriven signals.
: I disagree with this request. Adding more symbols to the logic would
: have an adverse effect on the performance of the simulator. I know
How can you be so sure? Even if it have a detrimental impact on
performance, this new capability would be a net win (for us, at
least). Knowing very little about Verilog implementations, I can't
even comment on whether a new signal type would slow simulations.
: that for the work we do, X's are undesirable, period. We never ignore
: X's. When I write a transactor I drive X's during the time a design
: model should be ignoring a signal. I really can't see the use of
: additional X permutations.
Thank you for your blunt discussion of my suggestion. Undoubtedly,
our designs are quite different than yours, and X's are not always bad
in ours. It also sounds like you're referring to a more behavioral
model than I am. Consider the example of a large synthesized block,
containing registers that are not cleared with a RESET signal, and are
only updated when a system error occurs. If your test should read
that register before such a system error, X's will be presented. And
they're not "bad" X's.
This is a very large model, in which there are many, many signals that
are not immediately initialized at time 0, or when RESET occurs. I
could change the test, but it's dangerous to change tests simply to
suit your model. There are other situations in which I cannot change
the test to avoid X's.
Paul Tobin
p...@fc.hp.com
Michael Lodman
I like this idea as well. In our designs of communication
circuits nodes may be unitialized until a particular data set is seen
on some input. Apparently new tools from Cadence will give
better diagnostics of drive fights indicating where the conflicting
driving nodes are, but I don't know if this will extend to differentiating
between uninitialized and unknown (for whatever reason) nodes.
It seems to me that other simulators I've used had a "U" signal value -
either Daisy, Valid, or N., but I can't remember which or maybe all
or none of them.
John Williams
symbol. I'm still not sure I like it, but at least I understand why
you want it. If this register should only be read after it is written
to, then X's mean you have a bug. It's not a case of ignoring X's.
Your test scripts should never attempt reading from that register
unless they have been written to.
Can you think of a case where you truly want to ignore X's?
John.
John Williams
a bus, rather than have a managerie of X look alikes. X means
1 or 0. The amount of time saved is minimal, if you get "U"'s instead
of X's, you still need to track down the guilty party. Get a good
waveform tool like undertow.
John.
Paul Tobin
John Williams (jw...@key.amdahl.com) wrote:
: OK, I think I see what you're getting at with this alternative X
: symbol. I'm still not sure I like it, but at least I understand why
: you want it. If this register should only be read after it is written
: to, then X's mean you have a bug. It's not a case of ignoring X's.
You're right, good distinction.
: Your test scripts should never attempt reading from that register
: unless they have been written to.
That works, but often we want to write tests which read that register
at semi-random intervals, just to make sure it wasn't inadvertently
updated, indicating a bug in the chip. If I change my test script to
never read it until after the first time it's supposed to have been
written, I leave a window at the beginning of the test in which I
could miss a bug. If I had U values coming out, I could confidently
ignore them until the register was supposed to be updated.
: Can you think of a case where you truly want to ignore X's?
In addition to the last paragraph, pipelined logic is trouble at
startup. For example, logic that drives an address onto a bus might
have 3 stages of logic between the address source and the bus. If
that logic was trying to save a state of setup time by presenting onto
the bus addresses it "snooped" from the source during idle bus cycles,
only pulling the address valid line when a real transaction was to
occur, I could get a couple states of X's at startup while the first
address rippled through the pipeline. In real silicon, these X's are
just the random powerup values in the last 2 logic stages, and I'd
love to see them as U's in the model.
Most often, these pipelined problems occur at startup, but sometimes
they lie latent in the model until the associated logic is accessed,
causing a state of X's on the pins far into the simulation (sending
everyone into a panic). It would be especially reassuring in these
cases to see U's instead of X's!
Paul
Venkatesh Elayavalli
>Thank you for your blunt discussion of my suggestion. Undoubtedly,
>our designs are quite different than yours, and X's are not always bad
>in ours. It also sounds like you're referring to a more behavioral
>model than I am. Consider the example of a large synthesized block,
>containing registers that are not cleared with a RESET signal, and are
>only updated when a system error occurs. If your test should read
>that register before such a system error, X's will be presented. And
>they're not "bad" X's.
exactly, In out designs too some times X's are not bad. the disadvantage
with verilog is it appears to have no strength specification for UNKNOWN
(please correct me if i am wrong).
This was not a problem in Lsim.
Venkatesh
v...@cypress.com
Paul Tobin
: I think the better course of action is to determine what is driving
John, I think of U as a completely different type of value, rather
than as an X variant. Using simulators with U values, in the past we
were able to build models where U's actually didn't matter, making it
easier to detect "real" drive fights or problems that showed up as X.
Nobody here was very enthused about Undertow. To pack as much
information as possible onto the screen, we tend to favor columns of
binary or hex values, where time is on the vertical axis. Other
people I know are very happy with Undertow, though. I recently got an
evaluation of SignalScan, which looked like a better Undertow.
Paul
Clifford E Cummings
>John Williams (jw...@key.amdahl.com) wrote:
>: In article 4...@fc.hp.com, p...@fc.hp.com (Paul Tobin) writes:
>: > In addition to 0,1,X, and Z, we'd like to see a new "uninitialized"
>: > signal value in Verilog, making it easy to distinguish between drive
>: > fights and as yet undriven signals.
>
>: I disagree with this request. Adding more symbols to the logic would
>: have an adverse effect on the performance of the simulator. I know
>
>How can you be so sure? Even if it have a detrimental impact on
>performance, this new capability would be a net win (for us, at
>least). Knowing very little about Verilog implementations, I can't
>even comment on whether a new signal type would slow simulations.
I would not want a "U" state to degrade the current performance
of Verilog.
For most simulations I do not need a "U" state, but perhaps a
Verilog command-line option "-uninit" would be acceptable when a
"U" state is more important than performance?
====================================================================
While we are making suggestions, how about
-mindelays -typdelays -maxdelays
Verilog command-line options in addition to the
+mindelays +typdelays +maxdelays
variety. The "+" versions are not syntax checked, and more than
once I have given Verilog applications support to engineers who
swore that Verilog did not work because they did not get minimum
timing delays when they typed "verilog +mindelay"
Regards - Cliff Cummings
John Williams
would take about the same. Verilog, at least at the PLI interface,
stores 4 state values as a pair of unsigned arrays. An additional
state would require three of these unsigned arrays. I believe the XL
algorithm is all table lookup, which makes sense for structural
models. I don't know if they're packed, probably not. This means
that in all probability, the XL performance would stay the same,
but behavioral code would take longer and consume more memory.
John.