Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Signal ignoring initializer and initializing to random state

Status
Not open for further replies.

alexandicity

Newbie level 6
Joined
Oct 18, 2017
Messages
11
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
166
Signal ignoring initializers and initializing to random state

Hi all!

I have a VHDL program that, despite all my effort to stop it, keeps initializing its signals in a random state. Sort of: it apparently initializes in the same state on each powerup, but the pattern that comes up I don't recognize. This initialization state appears to change on each reprogramming event to a new random pattern that will be consistent across all restarts.

Take, for example, a signal vector I have, reg_control. My problem appears to affect all my signals, but I use this one as an illustration due to its relative simplicity. I declare it as follows:

Code:
architecture Top_Level_Arch of Top is
...
    signal [B]reg_control[/B]:     std_logic_vector(1 to 16) := X"0000";
...

I understand that that initialiser is used in simulation only, and that it is disregarded in hardware. I have no combinational logic that drives this vector, but instead it is manipulated in a PROCESS:

Code:
PROCESS(clk)
    VARIABLE reset_count 		: INTEGER :=0;	

    BEGIN
        IF (clk'EVENT AND clk = '1') THEN
	        IF (reset_count < 10000000) THEN
                    -- Reset hold-off for 200ms at 50MHz
		    reset_count := reset_count + 1;
		    [B]reg_control [/B]<= X"0000";

                ELSE	
...
                    IF (some_condition) THEN
                        [B]reg_control[/B](to_integer(unsigned(bit_to_set))) <= '1';
                    END IF;
                    IF (some_other_condition) THEN
		        [B]reg_control [/B]<= X"FFFF";
                    END IF;
                    IF (Yet_another_condition) THEN
		        [B]reg_control [/B]<= X"0000";
                    END IF;
...

In the above, the first part before the ELSE is trying to force assignment to all zeros, which is what I want it to start at, by repeatedly setting it to zero for a short while after startup - which I expect would be implemented in the hardware. The second part, after the ELSE, contains the only two situations in my VHDL where the vector is assigned a non-zero value, although neither of the conditions are ever true in this test case (when the conditions are true, I do see these assignments working properly). The assignment to X"0000" works fine. There are no other deliberate assignments to a non-zero value, so I am uncertain how these signals keep getting set to anything other than zero.

The value in this vector is assigned into other signals and ports in many places in combinational and sequential areas of the code, but such read operations, I would hope, would not cause assignment of this vector! One of these combinational assignments is to output pins; it is here that I can see that the signal vector is not all-zero.

The target device is a ProASIC3, and I am using Libero SoC. I'm fairly new to FPGA development, so it's entirely possible there's some setting or configuration outside of the VHDL that I've not seen. But more likely, I suspect I've not implemented in VHDL a correct method of assigning this vector to all zeros until otherwise assigned - can anyone see why this might be? Is there a best-practice way to assign a signal a value "at startup" until it is given a new value by an assignment in a PROCESS block?

Thank you!
 

Re: Signal ignoring initializers and initializing to random state

The reset condition is a Synchronous reset, and hence cannot be used for power on values.
It is not true for all devices that initial values are unsupported - in Xilinx and Altera compilers initial values are used for the power-on state, but this has not always been the case. Before this you had to assign their initial value via project assignments. I have no knowledge of Libero, but I would be surprised if it didnt have some mechanism to set it. Otherwise the compiler is free to set the initial values to whatever it wants, and this may be technology dependent.

The VHDL is fine. Have you considered an asynchrous reset? does ProASIC support async resets?

These are questions you will likely have to read the documentation for, as not many people have experience with MicroSemi.
 

Re: Signal ignoring initializers and initializing to random state

I deleted my previous post.

It seems that the ProASIC3 family doesn't support power-on initialization of registers.
The register values are unknown after power-on:

http://www.actel.com/kb/article.aspx?id=SL1163
 
Last edited:

Re: Signal ignoring initializers and initializing to random state

This means that the value of reset_count is unknown/random after power on.
It is common to have very similar values after every power-on, so it isn't a good random generator.

If the "random" initial value of reset_count is 10000000 or greater there will not be a reset of reg_control.

You need to define a reset function that depends on the value of some pin/pins. The standard solution is to dedicate a pin as a reset signal.
 

Re: Signal ignoring initializers and initializing to random state

Proasic3s have asynchronous resets, so use that on all logic where the initial value matters.
 

Re: Signal ignoring initializers and initializing to random state

Thanks all. I didn't even realise that my startup counter might also be starting up in a state that prevented that init block execution, but I can see that's completely the case.

I've not got any external circuitry to do an external power-on reset, but I am going to try implementing an internal POR, feeding the resulting signal into an async reset...
 

Re: Signal ignoring initializers and initializing to random state

Thanks all. I didn't even realise that my startup counter might also be starting up in a state that prevented that init block execution, but I can see that's completely the case.

I've not got any external circuitry to do an external power-on reset, but I am going to try implementing an internal POR, feeding the resulting signal into an async reset...

overkill? just add a primary input reset signal and your code stops relying on any ridiculous power-up state.
 

Re: Signal ignoring initializers and initializing to random state

Can you elaborate slightly on what this "primary input" is? I've not encountered this term. What would drive this signal? I'm certainly keen to simplify this reset logic if I can!
 

Re: Signal ignoring initializers and initializing to random state

Use a pin on the part and make it a reset. Even your POR circuit uses a pin on the part (that has a weak pullup).
 

Re: Signal ignoring initializers and initializing to random state

OK, that's easy enough - but what drives the pin, in this approach? An external hold-off circuit?
 

Re: Signal ignoring initializers and initializing to random state

OK, that's easy enough - but what drives the pin, in this approach? An external hold-off circuit?

You linked to that document about a POR circuit did you even read it?

Don't know if it will even work with your design as it is a method for generating a reset when exiting flash freeze mode.
 

Re: Signal ignoring initializers and initializing to random state

OK, I think we are confusing each other a little here. As I see it, there are two approaches we are discussing:

1. The method described in the application note to implement a mostly-internal POR circuit. This uses one external pull-up. It is not for Flash-Freeze; in fact, the AN specifically cautions against this method for FF-dependent designs. This is working well in my implementation, but I am not necessarily confident it is the simplest or surest way to get a reset. I like that it does not require much external circuitry, though.

2. The method hinted at by ThisIsNotSam, which has not been described other than that it uses a "primary input" - which I do not fully understand. It seems that this is just suggesting an external hold-off circuit, is that right? That's always an option, but I am looking for internal - or mostly internal - solutions here. An external circuit would be more complex, in my mind, than setting up the internal POR circuit described in the application note.

For context, I'm working here with a demo board that doesn't have an easy way to access the I/O.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top