+ Post New Thread
Results 1 to 13 of 13
  1. #1
    Newbie level 6
    Points: 71, Level: 1

    Join Date
    Oct 2017
    Posts
    11
    Helped
    0 / 0
    Points
    71
    Level
    1

    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 reg_control:     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;
    		    reg_control <= X"0000";
    
                    ELSE	
    ...
                        IF (some_condition) THEN
                            reg_control(to_integer(unsigned(bit_to_set))) <= '1';
                        END IF;
                        IF (some_other_condition) THEN
    		        reg_control <= X"FFFF";
                        END IF;
                        IF (Yet_another_condition) THEN
    		        reg_control <= 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!

  2. #2
    Advanced Member level 5
    Points: 35,071, Level: 45
    Achievements:
    7 years registered

    Join Date
    Jun 2010
    Posts
    6,424
    Helped
    1871 / 1871
    Points
    35,071
    Level
    45

    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.



  3. #3
    Advanced Member level 3
    Points: 5,928, Level: 18
    Achievements:
    7 years registered

    Join Date
    Jul 2010
    Location
    Sweden
    Posts
    772
    Helped
    315 / 315
    Points
    5,928
    Level
    18

    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 by std_match; 8th November 2017 at 11:45.



    •   Alt8th November 2017, 11:39

      advertising

        
       

  4. #4
    Advanced Member level 3
    Points: 5,928, Level: 18
    Achievements:
    7 years registered

    Join Date
    Jul 2010
    Location
    Sweden
    Posts
    772
    Helped
    315 / 315
    Points
    5,928
    Level
    18

    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.



  5. #5
    Super Moderator
    Points: 27,821, Level: 40
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    6,355
    Helped
    1540 / 1540
    Points
    27,821
    Level
    40

    Re: Signal ignoring initializers and initializing to random state

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



    •   Alt8th November 2017, 15:28

      advertising

        
       

  6. #6
    Newbie level 6
    Points: 71, Level: 1

    Join Date
    Oct 2017
    Posts
    11
    Helped
    0 / 0
    Points
    71
    Level
    1

    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...



    •   Alt8th November 2017, 17:22

      advertising

        
       

  7. #7
    Advanced Member level 4
    Points: 5,034, Level: 16

    Join Date
    Apr 2016
    Posts
    1,061
    Helped
    189 / 189
    Points
    5,034
    Level
    16

    Re: Signal ignoring initializers and initializing to random state

    Quote Originally Posted by alexandicity View Post
    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.
    Really, I am not Sam.



  8. #8
    Newbie level 6
    Points: 71, Level: 1

    Join Date
    Oct 2017
    Posts
    11
    Helped
    0 / 0
    Points
    71
    Level
    1

    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!



  9. #9
    Super Moderator
    Points: 27,821, Level: 40
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    6,355
    Helped
    1540 / 1540
    Points
    27,821
    Level
    40

    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).



  10. #10
    Newbie level 6
    Points: 71, Level: 1

    Join Date
    Oct 2017
    Posts
    11
    Helped
    0 / 0
    Points
    71
    Level
    1

    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?



    •   Alt9th November 2017, 04:04

      advertising

        
       

  11. #11
    Super Moderator
    Points: 27,821, Level: 40
    ads-ee's Avatar
    Join Date
    Sep 2013
    Location
    USA
    Posts
    6,355
    Helped
    1540 / 1540
    Points
    27,821
    Level
    40

    Re: Signal ignoring initializers and initializing to random state

    Quote Originally Posted by alexandicity View Post
    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.



  12. #12
    Advanced Member level 4
    Points: 5,034, Level: 16

    Join Date
    Apr 2016
    Posts
    1,061
    Helped
    189 / 189
    Points
    5,034
    Level
    16

    Re: Signal ignoring initializers and initializing to random state

    Quote Originally Posted by alexandicity View Post
    OK, that's easy enough - but what drives the pin, in this approach? An external hold-off circuit?
    how about a button?
    Really, I am not Sam.



  13. #13
    Newbie level 6
    Points: 71, Level: 1

    Join Date
    Oct 2017
    Posts
    11
    Helped
    0 / 0
    Points
    71
    Level
    1

    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.



--[[ ]]--