Subject: Re: Initial Blocks fail with Synopsys Tools
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Oct 08 2001 - 13:04:20 PDT
Hi, All -
Some of this is a repeat of a discussion we had in July on initial blocks.
I might not have been very clear in my previous e-mail message. The
question was asked if Synopsys permits initial blocks in RTL code. The
answer is no. Unless surrounded by // synopsys translate_off and //
synopsys translate_on, the initial block is flagged as a syntax error.
GENERAL CASE
Initial blocks should NOT be synthesizable. Some synthesis tools, like
Synplicity, ignore initial blocks. This is almost criminal! An ignored
initial block means that the initial block is providing information to the
simulator that is ignored by the synthesis tool. This can cause a mismatch
between pre- and post-synthesis simulations.
All initial blocks should be flagged as errors by synthesis tools
(possible alternatives discussed below). Users of any synthesis tool that
routinely ignores all initial blocks should bitterly complain to their tool
vendor.
CONSTANT ASSIGNMENTS
There is a proposal to allow initial blocks that make constant assignments
to variables that are not assigned in the module by any other procedural
assignment. This might be reasonable for making a fixed (constant) device
identification assignment to an ID output port.
EXCEPTIONS
There are times when an engineer does want to include an initial block to
display diagnostic code or to indeed have the simulator do something
different for the synthesis tool.
If an engineer has a good reason (completely subjective) for adding an
initial block to the RTL source code, the engineer can certainly tell the
synthesis tool to ignore the block by proactively adding the synthesis_off,
synthesis_on pragmas:
(The following pragma is offered as an example - the actual naming and
format of the pragma is still subject to debate and ratification by the
Verilog Synthesis Interoperability Working Group)
(* rtl_synthesis, synthesis_off *)
initial begin
... // initial register assignments
... // Display commands
... // Whatever!
end
(* rtl_synthesis, synthesis_on*)
FPGAS AND OTHER POWER-ON-TO-KNOWN-STATE DEVICES
An example has been given of FPGAs that power up their registers to known
states (or they are programmed to a known state). I could envision using
Verilog-2001 attributes to identify an initial block as something like:
(The following pragma is offered as an example - the actual naming and
format of the pragma is still subject to debate and ratification by the
Verilog Synthesis Interoperability Working Group)
(* rtl_synthesis, power_on_initialize = true *)
initial begin
... // initial register assignments
end
I imagine that this pragma would identify this initial block as power-on
initialization only and any timing controls in the initial block would
cause a synthesis tool to flag the initial block as illegal (syntax error).
Without the pragma, IMO, the synthesis tool should flag this block as a
syntax error, for the reasons stated above.
POWER-UP RANDOM-STATE DEVICES
As has been pointed out in other e-mail messages, a real design does not
power up with X-state register outputs. Registers might power-up to random
sets of 1's and 0's. The ability to assign random values to register
outputs in a design has some value for both RTL and gate-level simulation.
I think the above (* rtl_synthesis, power_on_initialze *) pragma could also
be used for this type of testing.
POTENTIAL PROBLEMS
There are a few difficulties with some of these mechanisms:
1) A tool like Synopsys might ignore the pragmas and flag a syntax error.
This is reasonable behavior.
2) A tool like Synplicity might ignore the pragmas and also ignore the
initial block. This is the same problem that Synplicity currently has, as
explained in the GENERAL CASE above.
3) In general, synthesis tools do not consider the target library when the
HDL code is read. If the target device family does not support power-up
register initialization, the synthesis tool would have to flag a syntax
error at the compile stage, not when the code is read.
4) Libraries might require some type of property that synthesis tools could
read to indicate if the library supports power-on register initialization.
5) The synthesis compiler will need to be capable of identifying if the
initializations are valid, and flag a syntax error if the settings are invalid.
6) Should this feature require all registers to be initialized, or can a
subset be initialized? If only a subset is initialized, this becomes a
testbench coverage issue (have you tested all of the important scenarios
where un-initialized registers are given some default value?). I have
always found it a bit scary to power-on a device and not reset all
registers before commencing functional operation.
7) Is there a better way to model, simulate and synthesize the behavior of
initialized registers other than brute-force setting each register to a
known value? How tedious is it to initialize all of the registers of larger
FPGA devices from within an initial block?
Until something like the above pragmas are implemented, keep initial blocks
out of all RTL code!
Regards - Cliff Cummings
At 04:38 PM 7/3/01 EDT, you wrote:
>>>>
An interesting topic (and responses) came up on comp.lang.Verilog newsgroup:
Question: Would it make sense - or are there arguments against - using the
Verilog 'initial' block (or VHDL signal initialization statements) to inform
a synthesizer what the power-up state of the registers and memory should be?
Arguments FOR (from Jonathan.Bromley@doulos.com):
1. Many FPGAs power up with defined states without the use of an external
reset signal. Xilinx has "config-up" reset. The config bit stream gives an
initial value to just about every FF on the device. And several CPLD
families have real physical power-on reset to a known value; and it's always
been essentially impossible to exploit that in VHDL or Verilog designs, which
is sad because it's potentially a useful feature. The "initialise in an
initial block" (Verilog) or "initialised signals" (VHDL) approach would open
this window wide.
2. If there is a solid reset mechanism associated with power-up, and if that
can be coded so that simulation and synthesis give the same results, then you
have met the key requirements that normally force us into using explicit
resets. And in any case there is no reason why power-up and explicit reset
(possibly to different values!) shouldn't coexist in the same design.
Arguments Against:
1. Currently initialization is only defined with explicit resets. Would
synthesis vendors really want to change their tools?
2. Not all targets allow for configurations of registers. Synthesis tools
would have a hard time synthesizing code for targets that do not provide
those configuration features.
3. Portability issues.
--------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
//*****************************************************************//
// 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:40 PDT