RE: [sv-bc] RE: functional if statement

Brad -

I will make this my last post on the subject and let you and others 
have the last word after this. I have probably outstayed my welcome 
on the topic, but I have strong opinions on this subject. I would be 
happy to take this topic offline with those who would still like to 
continue the debate.

There are places where it makes sense to let something slide. One 
example from the 1800-2005 Standard was the issue of adding modports 
to interfaces. Most of us thought it would be a good idea to make it 
a requirement until Matt Maidment pointed out that interfaces without 
modports were valuable for early exploration of a design and that 
adding them later would be desirable. That opinion made sense and we 
backed off on making the requirement.

Look at your own synthesis tool and the coding restrictions on 
Verilog flip-flops. The sensitivity list must have posedge or negedge 
on all signals in the list, including resets (which is a good 
requirement). The edge polarity on the reset must match the tested 
reset polarity in the always block and the reset signal must be 
tested first in the always block and then followed by the clocked 
assignment. I am okay with this but simulation would do equally well with:

always @(posedge clk or negedge rst_n)
   if (rst_n) q <= d;  // clocked d-input assignment
   else       q <= 0;  // reset assignment

I am okay with the synthesis tool restriction even though the other 
coding style would be fine.

The new always_style procedures prohibit assignment to the same 
variable from more that one always block. That is a good restriction. 
Synopsys synthesis tools used to only warn under these circumstances 
and then would build multiple flip-flops tied together through an and 
gate, which was not even close to the simulation behavior. In recent 
years, DesignComiler made this an absolute error, as well it should be.

The new always style procedures prohibit LHS delays in assignments, 
which is a good thing! The delays are just ignored by synthesis tools 
and simulations could give very flawed simulation results if the LHS 
delays are added.

I can think of no good reason to allow a designer to use always_comb 
and always_latch interchangeably in synthesis, differentiated by only 
a warning or two. Once a designer starts to synthesize the RTL, they 
should know whether the intended logic is combinational or 
latch-based, and as a project lead I would like the tool to weed out 
my weaker designers so that they either have to fix the problem or 
come to me for advice. To me, a tool that allows always_comb to 
legally (albeit with warning) infer latches has a serious hole.

Prior to always_style blocks, a recommended coding style was to name 
all latched outputs with an "_lat" suffix and then to scan the latch 
reports for signals that did not end with "_lat." It was assumed that 
those signals were either improperly named or that unintended latches 
had been inferred. It would be so much easier to have a tool that 
aborted whenever an un-requested latch was inferred.

At 11:40 AM 12/12/2008, Brad Pierce wrote:
>Cliff
>
> > I still claim that synthesis tools should report errors and not
> > warnings when the specified always_style block does not infer the
> > requested logic.
>
>For every request we see for being able to be more restrictive on 
>certain things, we probably see 2 requests to "just let it go 
>through, so I can see some interim results".

I would love to know who these 2-to-1 guys are because in my classes, 
I get nearly unanimous nodding when I suggest that violations of 
always_style block intent should be errors and nobody has ever said 
that they believe the warnings are a better idea.

I have a hard time believing that a designer only wants to be warned 
when the always_comb block infers a latch. A very hard time believing that!

I give permission to any vendor who desires to send the following 
short message to their customer base:

Cliff Cummings of Sunburst Design has strongly urged that our 
synthesis tools report errors under the following conditions:
(1)     when an always_comb block infers a latch.
(2)     when an always_latch block does not infer a latch. The always 
latch is allowed to infer other combinational logic.
(3)     when an always_ff block has an invalid sensitivity list.
(4)     when an always_ff block also infers a latch. The always_ff is 
allowed to infer other combinational logic. Latches must be inferred 
separately using always_latch or else a Verilog-style always block 
must be used to infer both latches and flip-flops in the same 
procedure. (I could be persuaded to change this requirement if there 
is much dissent on this point).

You are encouraged to email your comments regarding approval or 
disapproval to both us (the synthesis tool vendor) and to Cliff 
Cummings. Cliff has agreed to answer all email objections to these proposals.

>Designers need to be free to choose their own priorities.  They'll 
>make a list of problems and put it in order.  Why I should force 
>them to put "always_comb" violations at the top of their list?

It is not a top-of-list issue. It is a correct or wrong design issue. 
A good designer who took time to identify combinational logic with 
always_comb will want to be notified and forced to fix the design if 
a latch is inferred (and yes, I am saying any engineer who wants to 
let this slide is a crap designer! - Feel free to share this fully 
attributed opinion with whomever you want)

>-- Brad

Thanks to all who have contributed to this discussion. We are all 
working to make the language better for the end user. We sometimes 
disagree on what "better" is :-)

Regards - Cliff


----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.