Xilinx register inits

Rob schrieb:

Hi Rob, aren't there any hints (warnings or infos) in your synthesis report. It should be noted somewhere if a piece of code is ignored by the synthesis tool.

How is your array synthesized? As a bunch of FFs or as RAM? There are different coding rules for initialisation. But what should be working for both is using some attribute (see the ISE Templates)

Using a function for array/RAM/ROM initialisation is similar to using a file. Since this is not covered by the synthesis standard for VHDL 87 or

93 there's no general guideline of how to do it. But some tools are able to do this anyway, so you have to read the tool specific instructions very carefully. (or search this newsgroup, it's a common topic)

Have a nice synthesis Eilert

HI Eilert,

The array is being implemented as registers. I've had a look through the syth report and there are two warnings related to the init function and they are produced because a 5 bit vector is being assigned to an 8 bit vector (i'm not sure why simulation didn't warn about this). Maybe this one bad line is causing the init function to fail? I'll reimplement and see what I get.

Rob

Hi Rob, Besides the bus widths issue, here's what you can do for initialisation without need for a function.

e.g. (kept simple with 8 bit only)

constant init_vector : std_logic_vector(7 downto 0) := "10011001";

reg1:process(Reset,clock) begin if Reset='1' then four bit register The array is being implemented as registers. I've had a look through

This is in no way equivalent to assigning an initial value. While it is generally better from a design perspective to reset things with a reset signal rather than counting on intial value assignments, what you've described with tying reset to a 'constant value' will end up either not initializing anything on reset since the code inside the "if Reset = '1' then" will never be executed (assuming Reset is tied to a constant '0') or the code inside the "elsif rising_edge(clock) then" will never be executed (assuming that Reset is tied to a constant '1'). In either case, you won't get what you want.

Kevin Jennings

Slight correction to previous, I missed the word 'inactive' in your sentence "And if Reset is tied to a constant inactive value..". This means then the latter part of my post was not correct, but the first part still is.

In any case, the code inside the "if Reset = '1' then" portion will be synthesized away, and no assignments having to do with 'init_vector' will occur, ever...not a very good replacement for an initial value assignment.

Kevin Jennings

KJ schrieb:

Hi Kevin, Generally I agree to what you say, but to my excuse I also said that I'm not 100% sure about it. That's because as far as I remember there was some other posting about this topic some time ago. There it was said, that XST "recognizes" these values and puts them in the bitstream regardless of the later optimization of the reset net.

But I may remember wrong. (Did anyone try it on some hardware?)

Still, with a reset signal it will work. And if Rob is using the internal reset net (GSR) of the startup block he hasn't even to waste an I/O pin and the initialisation will occur only once at power up. (And as far as I understood power up initialisation is Robs problem, not at any other time)

Do you confirm with this alternative solution?

Best regards Eilert

Haven't tried this in VHDL, but it certainly works in Verilog for XST.

i.e. XST looks at the reset terms, whether or not they get optimized away, and uses this value as the INIT (configuration bit download) value. My most common approach is to have an asynchronous reset term to every module, and tie it to zero (inactive) if not needed.

XST is also smart enough to take initial values from "initial" blocks in Verilog, including initialization of memory using $readmemh or $readmemb. Again I'm not sure what the VHDL equivalent would be, but it suggests that XST at least tries to match the simulation result when possible.

Cheers, Gabor

entence

n the

be

will

ment.

m n t

If the async reset is tied inactive and there are no initial values specified, the synthesis tool is free to apply whatever initial values that it so chooses. If XST happens to be doing something in a way you like, then you're free to take advantage of that, but keep in mind that by doing so you're tying your design to a quirk with a particular tool (perhaps with particular versions of that tool) and you're not specifying the behaviour of your design using the design language.

Reliance on tool quirks is usually not good design practice...'specially if used in situations other than where such reliance may be absolutely needed for some reason. If for some reason it is absolutely needed then you should comment this reason up in the code for later on when you find that the tool no longer does what you'd like it to be doing.

The VHDL equivalent is specifying the initial value in the signal declaration like this signal xyz: std_ulogic :=3D '1';

Well, the original poster was having a problem because the tool was ignoring the initial value specification so sim didn't match reality.

Specifying an initial value that is different from what is inside the always inactive async reset portion would lead to a sim mismatch...not a plus in my book. Simple example below.

signal xyz: std_ulogic :=3D '1'; -- Specify an initial powerup value of

1 =2E.. process(clk, reset) if rising_edge(clk) then xyz