Subject: Re: Using initialization statements for defining initial setup of registers
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Tue Jul 03 2001 - 16:13:19 PDT
Ben -
Would you post my comments to comp.lang.verilog and keep me posted on this
thread? I don't have good access to usenet groups.
Thanks - Cliff
The arguments for and against permitting initializing with initial blocks
in synthesizable code are nicely laid out in Ben's e-mail message.
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 alternative discussed below). Users of any synthesis tool that
ignores initial blocks should bitterly complain to their tool vendor.
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:
(* 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.
There are a few difficulties with this mechanism:
1) A tool like Synopsys might ignore the pragma and flag a syntax error.
This is reasonable behavior.
2) A tool like Synplicity might ignore the pragma 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 would probably 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 pragma is 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 http://www.vhdlcohen.com/ vhdlcohen@aol.com Author of following textbooks: * Component Design by Example ... a Step-by-Step Process Using VHDL with UART as Vehicle", 2001 isbn 0-9705394-0-1 * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1 * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115 ---------------------------------------------------------------------------- --
-------------------------------------- <<<< //*****************************************************************// // 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 : Tue Jul 03 2001 - 16:32:22 PDT