Why "rtl_full_case" instead of "full_case", etc? I know about behavioral
syntesis but I don't see the need to include "rtl_". I saw this with the
VHDL synthesis spec too (and did not like it there either!)
Why "pragma"? - even the VHDL synthesis spec uses "-- rtl_synthesis off", etc.
At 04:04 PM 7/6/98 -0700, you wrote:
>
> I am also on the Verilog Synthesizability group (1364.1), and
>one issue they have is trying to standardize the
>
>// synopsys parallel_case
>
>directives.
>
> They are proposing a bunch of stuff, in the context that they
>can not change the language.
>
> But of course, what would be much better, is if we would
>introduce a pragma to the language, and go further and define some
>pragmas, while leaving others for vendors extentsions.
>
> I propose we introduce a new tick define, `pragma
>
> Further, we introduce a set of pragmas as follows:
>
>`pragma rtl_full_case
> Tells the system that every value is decoded.
>
>`pragma rtl_parallel_case
> Tells the system that each case_item is mutually exclusive,
> and hence a full priority decoder (if then [else if then]* )
> is not needed.
Mac -
Interesting thoughts but I'm not sure I fully agree with the direction this
is going.
First: full_case parallel_case
I consider these directives to be quite dangerous and they are perhaps the
most overused and abused synthesis directives in use. For the past two
years I have been teaching as many Synopsys, Galileo, Leonardo, Synplicity
and FPGA Express users as possible to avoid these switches.
I have only found one place where I recommend using these switches; one-hot
state machines using the case-if-true (case (1'b1)) construct. This is the
only place where these switches consistently improve the timing and area of
a synthesized design.
Most of the FSMs that my students synthesize end up being larger, slower or
both after adding full_case parallel_case directives. I have yet to find a
non-case-if-true FSM that I could not synthesize to a smaller and faster
design simply by using good Verilog coding practices (that was meant to be
a challenge ;-)
Since there are relatively few occasions when full_case parallel_case
directives should be used, I do not think it is wise to introduce a
compiler directive that is active across all files from the point it is
enabled. Galileo used to enable full/parallel for all case statements in a
module, which caused problems unless the user was willing to break out all
case statements that required full/parallel_case into a separate module.
If we introduced a `pragma rtl_full_case, etc., we would also need to
introduce a `pragma rtl_full_case_off, etc.
I prefer "// synthesis full_case" added to the end of the same line with
the "case" keyword and case expression, which I believe is currently
supported by Galileo, Leonardo, Synplicity and FPGA Express. Of course,
exchange the word "synthesis" with "synopsys" for Synopsys. The directive
should only be active for the case statement that it augments.
I don't like the idea of having Verilog mimic the full/parallel_case
behavior based on a pragma. At best, I believe this would add confusion to
the functionality and desired use of case statements.
Adding full_case to a case statement informs a synthesis tool that all
variables (FSM example: next state and output assignments) that are not
explicitly assigned for all case items, or for missing case items, can be
treated as "don't cares" by the synthesis tool. I believe it would be
impossible for a Verilog simulator to predict how the don't cares will be
assigned by a synthesis tool; therefore, still very difficult to match
pre-synthesis to post-synthesis simulations.
I continue to see respected colleagues recommend putting parallel_case on
every case statement to make sure priority encoder is not inferred. Most of
the synthesis tools that I use will not infer a priority encoder unless
there are overlapping case items that would match the case expression. An
engineer either wants a priority encoder and should code overlapping
conditions with the correct priority, or they don't want a priority encoder
and should code their case statements correctly to begin with (as opposed
to relying on an additional instruction to the synthesis tool that is not
given to the simulator).
If Verilog compilers do not recognize full/parallel_case pragmas (currently
this is the case), then these directives can change the functionality of a
design (I use a couple of examples in my labs to show this point) or make
designs larger and slower (more lab examples).
Although I believe we need to include and describe the full_case
parallel_case directives, I believe the synthesis spec should include stern
warnings about there proper use and the hazards of improperly using these
switches (including both good and bad examples).
(Cliff now descends from his soap box!)
>`pragma rtl_translate_on
>`pragma rtl_translate_off
> Turns on and off synthesis translation. Can be used to wrap
> design verification code.
I don't see any significant advantage using these `pragmas over "//
synthesis translate_off" "// synthesis translate_on". Am I missing something?
The directives below look pretty good (although I'm still wondering about
the word "pragma")
>I asked the list what other pragmas they wanted, and one of the
>gentlemen (Ken Coffman <kcoffman@atvideo.com>) said:
>
>other pragmas I'd like to see:
>
>// Define pin assignment.
>// Hierarchal assignment should be possible.
>// Pin assignment example 1
>// pragma signal_name pin_number nnn
>
>// Pin assignment example 2
>// pragma top_module_name1.lower_module_name2.signal_name pin_number nnn
>
>I know we can sometimes infer the following, but I'd rather command the
>hardware to synthesize a certain way.
>
>// Assign signal to clock enable if supported by hardware.
>// pragma signal_name clock_enable
>
>// Assign signal to global clock resource if supported by hardware.
>// pragma signal_name global_clock
>
>// Assign signal to global reset resource if supported by hardware.
>// pragma signal_name global_reset
>
>// Assign signal to global preset resource if supported by hardware.
>// pragma signal_name global_preset
>
>// Don't collapse signal and use this signal name in place of any other
>naming option.
>// pragma signal_name preserve_signal
//********************************************************************//
// Cliff Cummings E-mail: cliffc@sunburst-design.com //
// Sunburst Design Phone: 503-579-6362 / FAX: 503-579-7631 //
// 15870 SW Breccia Dr., Beaverton, OR 97007 //
// //
// Verilog & Synthesis Training / On-Site Training //
// Verilog, VHDL, Synopsys, LMG, FPGA, Consulting and Contracting //
//********************************************************************//