Initialisation problem with 8 bit counter …

[mikels]

Hi


I come from « normal » programming world and I am very pertubated by INITIALISATION procedures in VHDL code.

I have difficulty with of course the most basics : 8 bit counter…

But if we generalise, the problem goes like this ….

[this is the « correct » VHDL code. Well « correct » according to your norms which still puzzle me …]



architecture
signal var1 : std_logic_vector ( n-1 )
signal var2 : std_logic_vector ( n-1 )
signal var3 : std_logic_vector ( n-1 )

process (clock, reset)

if reset = 0 then
var1 = 0
var2 = 0
var3 = 0
else if rising edge (clock) and clock event then

…

end process

exit1_Q = var1
exit2_Q = var2
exit3_Q = var3
end architecture



[this is what we would be tempted to do in « normal » programming world ». We would initialise in the declaration section. Don’t you think ? So the code would go like this …]



architecture
signal var1 : std_logic_vector ( n-1 ) = 0
signal var2 : std_logic_vector ( n-1 ) = 0
signal var3 : std_logic_vector ( n-1 ) = 0

process (clock, reset)

if reset = 0 then
var1 = 0
var2 = 0
var3 = 0
else if rising edge (clock) and clock event then

…

end process

exit1_Q = var1
exit2_Q = var2
exit3_Q = var3
end architecture



I would like to have the point of view of a PROFICIENT VHDL programmer to give me his view. I’ve never seen this thing :

architecture
signal var1 : std_logic_vector ( n-1 ) = 0

so I guess it is wrong. Wrong or inutile/useless ?
I don’t have a simulator at home (…). Could SO simulate the code and let me know what happens ?




architecture
signal count : std_logic_vector ( n-1 ) = 0
process (clock, reset)
if reset = 0 then
count = 0
else if rising edge (clock) and clock event then
count = count + 1
end process
exit_Q = count
end architecture



what does the simulator tell ? Does it accept Initialisation at the Signal Declaration level ? ? ? ? It is true that the body of the architecture is concurrent world. So I can imagine the initialisation should not be in the Declaration Section and just stay in the reset section (I don’t have any problem with initialisation after the reset. All the components are initialised after RESET). This gives a static and « FLAT » vision of the code.

If I initiliase with zeros , am I committing a breach ? Is it Erroneous VHDL code ? That’s why I would like the opinion of a PROFICIENT VHDL. I feel very uncomfortable with this issue so I hope someone will take the time to reply to me .

 

[permute]

there are certainly a lot of syntax errors above.

initial values generally shouldn't be done when the signal will be reset. this is because the synthesizer may not perform as many optimizations.

constants and variables in functions will often be initialized.

Simulators should accept initializations correctly. Synthesizers might ignore them (on signals), or give a warning/error.

initial values have similar issues as async resets -- the values can be corrupted if the reset is not synchronously de-asserted.

 

[mikels]

yes extremely useful. thanks for the reply permute.

the lines I 'm interested are :

Simulators should accept initializations correctly. Synthesizers might ignore them (on signals), or give a warning/error.


Simulators. Accept. I'm OK with this (though I don't have a simulator to check myself. I believe you thanks).
Synthetiser. Ignore or give Error signal. Can you be more categoric? Percentage for Ignore? How does your synthetiser behave?


I'm interested in your personnal experience.

when you build an 8 bit counter yourself ..... will you simply write:

architecture blabla
Signal var1: std_logic_vector="0000"

or just

architecture blabla
Signal var1: std_logic_vector
(this is 99% per cent of the codes I saw)

Can you make a categoric recommandation here?

[I had a look at camcorder codes. they don't inititalise in the Signal Declaration Section at all. so I suppose your recommendation would be. don't initialise there. just after the reset button

I'm just hoping for a very down to earth practical and true and out of experience good procedure advice.

(you previous reply was very good. I just need some more chat for me to understand it 100%

 

[permute]

I'm not familiar with ALL synthesis tools. But pretty much every EDA tool will implement only a subset of VHDL. Simulators tend to understand nearly everything, while synthesis tools are very hit-or-miss. Worse, the choice for error vs warning is often arbitrary. Further, very few things give "strong warnings" -- things that require the user set a "I know I've been warned" environment variable. There are a handful "warning" (and non-warning) conditions that will always cause a design to fail and really should have been errors.

In 2008, I had inherited some code that made use of initialization. It would only work when built with XST. Using synplifypro resulted in warnings that initial values are unsupported. Eventually this feature was added. Synplifiy does give a warning claiming that optimizations might have been foregone due to the initializations. For reasons like this, it likely most VHDL will only use initialization to make simulations look a little bit cleaner.

For XST though, I suggest reading Xilinx's XST docs, as well as the other documentation on the website. These are invaluable tools, as they provide excellent reference as well provide HDL guidelines for inferring FPGA-specific features (RAMs, Multipliers, ect...). It makes little sense to try look first to the VHDL samples on the internet -- they often were written by students who only needed to get something to "work" in a very limited sense.

(a final issue with inits is that the current partial reconfiguration flow doesn't re-assert the global reset. This probably isn't a concern for you.)

 

[lucbra]

To add to Permute's comments:
to synthesize is the process (not to confuse with the VHDL process keyword) of translating your description of the logic to logic gates, memory cells etc.

And as a lot of processes (VHDL) are infering FFs, these should have a reset line (called a signal in VHDL). The reset line is the only way to give a FF an initial value. Whether this reset line is coming from an external (reset) port or an internal PUR (Power Up Reset) or GSR (Global set Reset), this is another thing.
Some compilers/synthesizers (like XST) can add this Reset by themselves.

To conclude:
VHDL (like Verilog) is a harware description language, not a programming language. Therefore I wouldn't tell you come from 'normal' programming world; no, you have dealt with microcontrollers and microprocessors (eventually DSPs). These devices are programmed.

 

[mikels]

Thank you very much for your replies Permute and Lucbra.

so what should I do now? I get rid of all my initialisations now (even though most symulators/synthetisers will take them. I liked your story Permute [I'm a bit familiar]. You have a code with initialisation. works with XST. doesn't work with sinplify pro then the feature is added. then works fine also with synplify pro. so OK. synthetisers now take initialisation)

But like Mr Lucbra say the synthetiser will do nothing of it. The initlisation (of FFs) takes place in the reset part (whether external reset or PUR or GSR. I didn't know all of them so thanks for them).

So what do I do? synthetiser/simulator accept and will do nothing of it. Initialisations serve to make the simulation cleaner like Permute says (I share this point of view. It is cleaner. somehow ...)

I just want someone to say to me "OK Mike. Forget all these initialisations. Nobody write these. It corresponds to no physical reality. stop embarrassing. I'll show you a piece of my code or someone's else. you see. not a drop of initialisations. No vhdl programmer will make initialisations. You stop it. You get it?" (don't hesitate to be sharp with me. The sharpest, the easier i'll put things correctly in my mind. because right now I'm puzzled)

 

[lucbra]

Mike,

I can't generalize because I'm not using XST every day. What I do know is that I'm trying to re-use my code. That's why I tend to write independent from any architecture. If it comes to timing issues, then I'm looking for the black magic (black boxes, architectural features, ...) Obviously you won't get rid of PLL's ...

Therefore I'm not using initializations in the definition. However, I'm using initializations in testbench files.

Here is some code as an example of how I'm organizing my code work.

entity cdr_rx is
generic (
			DIn_Width	: integer := 8;
			DOut_Width	: integer := 10						-- Width of dout
			);
port (
		Rst				: in	std_logic;
		RefClk			: in	std_logic;
		Sin				: in	std_logic;
		Data_Out			: out	std_logic_vector (DOut_Width-1 downto 0);
		DOut_Valid		: out	std_logic;
		Sample_Error	: out	std_logic;
		PLL_Lock			: out	std_logic;
		SClk				: out	std_logic;
		SClk90			: out	std_logic;
		LowClk			: out	std_logic
		);

attribute dout	: string;
attribute din	: string;
attribute dout of SClk		: signal is "";
attribute din of RefClk		: signal is "";
attribute dout of SClk90	: signal is "";		

end cdr_rx;
		
architecture arch_cdr_rx of cdr_rx is
-- -------------------------------------------------------------------------------------
-- Constant definitions
--
-- -------------------------------------------------------------------------------------
-- Component definitions
--
component Ser2Par
	generic	(
			DOut_Width	: integer
			);
	port (
			PLL_Lock	: in	std_logic;
			Rst		: in	std_logic;
			SIn		: in	std_logic;
			SClk		: in	std_logic;
			SClk90	: in	std_logic;
			RefClk	: in	std_logic;
			DOut		: out std_logic_vector (DOut_Width-1 downto 0)
			);
end component;

component Data_Extract
	generic	(
			DIn_Width				: integer := 8;
			DOut_Width				: integer := 10;
			Lock_Number				: integer := 4;
			Max_Samples_per_Word	: integer := 4
			);
	port (
			Rst				: in	std_logic;
			Clk				: in	std_logic;
			DIn				: in	std_logic_vector (DIn_Width-1 downto 0);
			DOut				: out	std_logic_vector (DOut_Width-1 downto 0);
			DOut_Valid		: out	std_logic;
			Sample_Error	: out	std_logic
			);
end component;

component Rx_Dyn_PLL
	port (
			CLK		: in	std_logic;
			RESET		: in	std_logic;
			CLKOP		: out	std_logic;
			CLKOS		: out	std_logic;
			CLKOK		: out	std_logic;
			LOCK		: out	std_logic
			);
end component;
-- -------------------------------------------------------------------------------------
-- FSM state variable assignments
--
-- -------------------------------------------------------------------------------------
-- Signal definitions
--
signal data_4x			: std_logic_vector (DIn_Width-1 downto 0);
signal data_sampled	: std_logic_vector (DOut_Width-1 downto 0);
signal Lock				: std_logic;
signal DOut_Valid_Int: std_logic;
signal RxClk			: std_logic;
signal SClk_Int		: std_logic;
signal SClk90_Int		: std_logic;
signal LowClk_Int		: std_logic;
signal Data_D4			: std_logic_vector (DOut_Width-1 downto 0);
signal Cnt				: natural range 0 to 4;
-- -------------------------------------------------------------------------------------
-- Attributes settings
--
-- -------------------------------------------------------------------------------------
-- Begin of Architecture description
--
begin

U1 : Ser2Par
	generic map (DOut_Width => 8)
	port map(
			PLL_Lock	=> Lock,
			Rst		=> Rst,
			SIn		=> SIn,
			SClk		=> SClk_Int,
			SClk90	=> SClk90_Int,
			RefClk	=> RxClk,
			DOut		=> Data_4x);
			
U2 : Data_Extract
	generic map (			
			DIn_Width				=> 8,
			DOut_Width				=> 10,
			Lock_Number				=> 4,
			Max_Samples_per_Word	=> 4)
	port map(
				Rst				=> Rst,
				Clk				=> RxClk,
				DIn				=> Data_4x,
				DOut				=> Data_Sampled,
				DOut_Valid		=> DOut_Valid_Int,
				Sample_Error	=> Sample_Error);
				
U3 : Rx_Dyn_PLL
	port map(
				CLK		=> RefClk,
				RESET		=> Rst,
				CLKOP		=> SClk_Int,
				CLKOS		=> SClk90_Int,
				CLKOK		=> LowClk_Int,
				LOCK		=> Lock);


process (SClk_Int, Rst)
begin
	if Rst = '1' then
		RxClk <= '0';
	elsif rising_edge(SClk_Int) then
		RxClk <= not RxClk;
	end if;
end process;

...

Good luck,
Luc

 

[FvM]

If you are talking about VHDL for synthesis, you should consider, that initilization of signals (registers) is basically a hardware feature of most (all?) FPGA and CPLD families, representing a power-on reset of registers to a defined state. The question whether it's supported by a particular synthesis tool is about if the tool is able to support existing hardware features correctly. Vendor tools (e.g. Altera Quartus, Xilinx XST) are typically supporting it, 3rd party tools probably don't.

In addition to the POR function, many FPGA and CPLD families have also an optional global reset input, that is able to set the default register initialization state at runtime. In a VHDL design, it's often required to include an explicite asynchronous or synchronous reset to particular design entities. In this case, the default POR may be unnecessary.

In a design for synthesis, some objects, e.g. the registers forming a binary counter are possibly don't care in initialization. Their initial state doesn't affect the design operation, because the counter cycles through all possible states anyway. It's completely different in simulation, when the respective objects are caught in an "UUU" state. This is another motivation to apply initial values to VHDL signals that are not provided with an explicite reset condition.

 

[mikels]

[addressed to Mr Fvm]

Your comment is very rich. So thanks for that. You focus essentially on the hardware aspect (Init for you will be the POR aspect and the optional GSR aspect. And like “Lucbra” also mentioned it is added by the simulator/synthetiser by itself [be it XST / or Altera quartus which had not been mentioned so far. So an important question for me. How do you implement it in the softwares? Is it a panel with options and you click “yes I want a POR” or the software will really do it all alone).

But me I would like to refocus on the coding aspect: the initialisation in the definition section. Lucbra showed a code with no initialisation in the definition section. Fine . Perfect. But still I’m still there: I have nothing that tells me: stop putting those initialisations in the definition section. This is a very short message I received. It goes like this: “with fpga/cpld, you can write those initialisations. There’s no problem. It works. On the other hand, in the heavy industry, we use ASIC. And there no. It is not physically supported. So not a line of initialisation in the definition section”. That’s all I got.

Could someone confirm in that direction? Experience in fpga/cpld versus Experience with Asic (the industry). And apparently it is out of question to put initialisations in the definition area for Asic (and I guess all camcorders, computer parts are made on Asic and not fpga)

(other source trying to understand it: fpga4fun.com :: View topic - Initialisation problem with 8 bit counter …)

 

[permute]

for FPGA's i'd say its mixed. Most designs will have a soft-reset feature. initialization can be used as above -- for logic that would work from any starting state but only when such state is known. Another use is to initialize the contents of a block ram.

Outside of simulations, I tend to avoid initializing signals/variables. This aids in simulation -- if the cadence of the inputs is incorrect, it can spread X's or U's all over the sim.

 

[FvM]

In usual FPGA hardware, signals specified without an initializer are reset to zero at power-on by default. In so far "avoiding initializsation" doesn't necessarily mean there is none. But I agree to avoiding initialization code without a functional purpose.

I should be also noted, that power-on reset doesn't guarantee a correct initialization of state machines or counters. They typically need an explicite reset, released synchronously to the design clock. Otherwise, state machines can get caught in an illegal state at worst case.

 

[Electro_Nic]

Hey Mikels,
This is a good thread... A good quesiton indeed.
Personnal, I don't care what the synth tool does. I don't initialise anything outside of the process itself. Xilinx XST does initialise registers to all "0"s, but i'm not sure of all the other fabs... So for portable code, don't think about the tool...
I use resets on all of my processes (or most anyhow), except actual state machine. (in the "case" part..; however, you can initialise the Present_State to a specific state in the reset of the process).
This is where i define my initial values.
Also, most resets are not synchronous. That's why it's outside the clock region.

Not sure if this helps... FvM, Permute and Lucbra really have a way with words...

 

[lucbra]

I use resets on all of my processes (or most anyhow), except actual state machine. (in the "case" part..; however, you can initialise the Present_State to a specific state in the reset of the process).
This is where i define my initial values.
Also, most resets are not synchronous. That's why it's outside the clock region.

this brings us to the following point: I learned to write state machine the old way (with 2 processes):

process (clk, rst)
begin
   if rst = '1' then
      CurrentState = S0;
   elsif rising_edge (clk) then
      CurrentState <= NextState;
   end if;
end process;

process (CurrentState)
   case CurrentState is
      when S0 =>
...

this will always get you to a correct FSM initialisation. I'm not sure if you trust the POR and initializer that you will start the FSM with a desired behavior.

Unfortunately we can't add a poll on this threat. It would have been useful to list how many of the FPGA guru's are using initializer, POR or explicit initializer (with reset).

Regards,
Luc

 

[FvM]

The problem of the state machine reset isn't if you write the FSM with one or two processes. It's the requirement to release the reset synchronous to clk. If reset (or any other input signal of the state machine) violates a timing requirement, the next state is unpredictable.

In so far, a POR isn't reliable here.