Subject: Incomplete Sensitivity Lists
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Oct 08 2001 - 13:04:45 PDT
At 08:45 AM 10/8/01 -0700, Paul wrote:
> >
> > I was very surprised to learn that Synplicity ignored initial blocks. I
> > consider this to be a serious flaw in the Synplicity tools.
>
>As someone pointed out, Synplicity ignores initial blocks with a warning.
>Ambit also ignore initial blocks with a warning. This could result in
>simulation mismatches, but not necessarily. There are other situations that
>could result in simulation mismatches for which Ambit also issues a warning,
>not an error. For instance, an incomplete sensitivity list is flagged as a
>warning. What do other tools do?
>
>Paul
Again, I consider it a serious flaw for a synthesis tool to ignore initial
blocks unless a user has taken specific action to tell the synthesis tool
to accept the initial block in one form or another. If I were Ambit, I
would not be bragging about this "feature."
To Paul's, second question, Synopsys issues warnings for incomplete
sensitivity lists. I thought somebody told me that Exemplar Leonardo issued
errors. Can anyone confirm this?
It should probably be an error to code an incomplete sensitivity list. As
far as I can tell, if there are no posedge or negedge keywords in the
sensitivity list, the synthesis tool ignores the sensitivity list, builds
the logic within the procedural block (combinational or latches, depending
on coding style) and then reviews the sensitivity list to warn the user if
there is going to be a simulation and synthesis mismatch. The problem is
really a simulation problem, not a synthesis problem. The synthesis tool
builds the "correct" logic, while the simulator simulates something that
can't even be built in logic.
We addressed this issue in Verilog 2001 with the always @* combinational
sensitivity list (thanks to Mike MacNamara for proposing this enhancement!)
It always seemed silly to list all of the signals that changed in a
sensitivity list and then list them again when used. Add another assignment
and forget to add the identifier to the sensitivity list and, at best, you
found a warning and fixed your code, or at worst, you missed the warning,
built bad logic and found the problem during gate-level simulation,
equivalence checking, or missed it and had to turn the chip again.
The @* fixes this problem and is also a nice short-hand for combinational
sensitivity lists. This is much nicer than listing 3-5 lines of signals
that make up sensitivity lists for larger combinational blocks.
Summary: IMO incomplete sensitivity lists, if undetected, will cause
problems, should be flagged as errors, but if not flagged as errors, the
always @* Verilog-2001 sensitivity list will eliminate the problem when it
is fully implemented. Unfortunately, VHDL does not have an equivalent @* (I
understand the VHDL Standards group considered process * but the proposal
was voted down (probably not verbose enough! ;-) ) so asking vendors to
consistently flag incomplete sensitivity lists as an error in both Verilog
and VHDL might help our VHDL comrades.
Regards - Cliff
//*****************************************************************//
// Cliff Cummings Phone: 503-641-8446 //
// Sunburst Design, Inc. FAX: 503-641-8486 //
// 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
// PMB 501 Web: www.sunburst-design.com //
// Beaverton, OR 97005 //
// //
// Expert Verilog, Synthesis and Verification Training //
//*****************************************************************//
This archive was generated by hypermail 2b28 : Mon Oct 08 2001 - 13:08:46 PDT