Simple VHDL startup issue driving me nuts!

[mikeselectricstuff]

(Using Lattice Diamond with XO2, but should be a generic VHDL issue)

All I want is this : A signal that starts off at 0 on powerup, and gets set to 1 under a specific condition, and then stays there forever.

AIUI, VHDL signals  all get set to zero at startup, so it should be simple as doing
if <condition> then startsig<='1'; end if;
within the relevant process.
However what happens is the signal starts off high and stays there.

What I think is happenning is the the synthesiser is only ever seeing an assigment to '1' and never an explicit assignment to '0', and assuming the line needs to be high all the time.   
I do get a "Register is stuck at one" warning in the compile report
I've tried using :='0'; at the signal definition but no effect.

Surely there must be some way to force it to know that I want to use the power-up '0' state?
Or another way to do it - preferably without the need for any device-specific features.

[Psi]

ok, ive never done any FPGA stuff, so this is probably a stupid comment

But what about starting the i/o pin as an input with pulldown active.
Then changing it to output and high when you need.
.

[AwArD_RzD]

Hi Mike

I tried this code in Quartus and i simulated the behavior in Modelsim Altera and tested on a Cyclone iv and it work, try it you will see if its a compiler fault or just an error in your code. I just started to use VHDL 6 month ago i dont know if there any other option who can stuck your pin at 1 when the FPGA start maybe a pull up or something like that.


-- EEVblog forum
-- VHDL test
-- Jason Beliveau
-- 06-10-2013
-- Quartus II 64 bit 13.0.1 build 232 SP1
-- A std_logic bit power up at 0 and latch to 1 when a condition
-- is met

--library
library IEEE;
use IEEE.std_logic_1164.all;

--entity
entity startup_0_cond_1 is

   port ( a : in std_logic;
          y : out std_logic);
         
end startup_0_cond_1;

--architecture
architecture behv of startup_0_cond_1 is

signal temp : std_logic := '0'; -- set the signal to 0

begin

   trigg_process : process(a)
         begin
            if (a = '1') then -- latch the signal when input a is 1
               temp <= '1';
            end if;
         end process;
         
      y <= temp;  --output the bit
      
end behv;

[mikeselectricstuff]

That's pretty much what I have, but it is ignoring the :=0 and reducing it to holding high all the time.

[AndyC_772]

I've a feeling I've seen this before; you're quite right that the optimisation & synthesis sees the fact that the signal is only ever assigned the value 1, and simply ties it high.

Is there a reset signal you could use, ie:

PROCESS (reset_n, condition)
BEGIN
  IF reset_n = '0' THEN
    signal <= '0';
  ELSE
    IF condition = '1' THEN
      signal <= '1';
    END IF;
  END IF;
END PROCESS;

For 'reset', substitute anything else that happens at start up - a counter equal to zero, a processor fetching data from address 0 etc.

[mikeselectricstuff]

OK I've managed to do it by a slightly roundabout, and more annoyingly, wasteful method.

  signal startcnt:std_logic_vector(1 downto 0);

process (clk)
 if rising_edge(clk)

  if <my event>
   if startcnt(1)='0' then startcnt<=startcnt+1;


startcnt(1) does what I want ( after 2 events - I don't care about this - I'm just trying to detect lack of an incoming clock).

Seems like invoking the counter prevents it optimising away the startup state. I did try with a 1 bit counter but no joy.

This is what I hate about high-level stuff like VHDL that is so abstracted from the hardware that you have to jump through unnecessary hoops to get the hardware you know is there to just do what you know it can do...

Suggestions welcome about a better way to do this - how hard can it be..?

[mikeselectricstuff]

I've a feeling I've seen this before; you're quite right that the optimisation & synthesis sees the fact that the signal is only ever assigned the value 1, and simply ties it high.

Is there a reset signal you could use, ie:

PROCESS (reset_n, condition)
BEGIN
  IF reset_n = '0' THEN
    signal <= '0';
  ELSE
    IF condition = '1' THEN
      signal <= '1';
    END IF;
  END IF;
END PROCESS;

For 'reset', substitute anything else that happens at start up - a counter equal to zero, a processor fetching data from address 0 etc.

Problem is I don't have anything that isn't just cycling round continuously, and if you do something like this to latch it
If <condition> and startup='0' then startup<='0'; 
It will optimises it out because it has no effect

Unfortunately the only count I could potentially use is one I want to control with the startup signal...

[TerminalJack505]

My VHDL is getting rusty but I wonder if it would help if you declared it as a variable instead of a signal.  And if that still doesn't work maybe see if declaring it as a shared variable will prevent the unwanted optimization.

[marshallh]

Yes, even if you decalre an initial value, if the synth sees it sticking at value 1 for the entirety of the operation, it just hard wires it.
For internal fpga reset I have a counter like that, counts to 255 then waits for PLLs to lock, etc.

[free_electron]

try this :

(this is verilog. i don't do "very hard design language")

Code: [Select]

input trigger
output reg flag

if (!flag and trigger) flag <=1;

now the synthesizer will not optimize since the assignemt is conditional ( the flag has to be clear before it can be set. )

[Rufus]

All I want is this : A signal that starts off at 0 on powerup, and gets set to 1 under a specific condition, and then stays there forever.

Search "VHDL SR-latch"

[mikeselectricstuff]

try this :

(this is verilog. i don't do "very hard design language")

Code: [Select]

input trigger
output reg flag

if (!flag and trigger) flag <=1;

now the synthesizer will not optimize since the assignemt is conditional ( the flag has to be clear before it can be set. )

I think this is one of the things I tried, but has the same issue - it's not the conditionality, it's that the only explicit assignment it ever sees is to '1' so it just optimises it away. 

Another issue I didn't mention is that it's a very small device (XO2-256) and I'm not yet sure what else I may want to put in there, so don't want to take up unnecessary space. 

[flynnjs]

It's a long shot but have you tried ORing it with 1 instead of a static assignment to 1?

[mikeselectricstuff]

It's a long shot but have you tried ORing it with 1 instead of a static assignment to 1?

no, but as anything OR 1 = 1, I would expect this to be optimised out - even a 25yr old CUPL GAL compiler could do stuff like that!
I did try a startup<=startup assigment as well (i.e. hold the present value), which also didn't work.

[Rufus]

I think this is one of the things I tried, but has the same issue - it's not the conditionality, it's that the only explicit assignment it ever sees is to '1' so it just optimises it away.

I don't do VHDL but

if (flag = 1 or trigger = 1 )
  flag = 1;
else
  flag = 0;

seems explicit enough to me.

[hughes_k]

I think this PDF describes what you want - using the Global Set Reset (GSR) or Power-up Reset (PUR) components.
http://www.latticesemi.com/~/media/Documents/UserManuals/HowtouseGSRPURandTSALL.ashx?document_id=31408

[Neilm]

When designing VHDL, I always try to ensure I have either a reset input to handle this sort of issue, or a state machine that detects a startup condition. The latter can be done with a simple array that if it is all the same as happens on start up, it triggers a reset signal and then changes the array so it is different.

[mikeselectricstuff]

I think this is one of the things I tried, but has the same issue - it's not the conditionality, it's that the only explicit assignment it ever sees is to '1' so it just optimises it away.

I don't do VHDL but

if (flag = 1 or trigger = 1 )
  flag = 1;
else
  flag = 0;

seems explicit enough to me.

I think that may also optimise itself away, as it can only ever assign to 1 or its previous state.

[mikeselectricstuff]

I think this PDF describes what you want - using the Global Set Reset (GSR) or Power-up Reset (PUR) components.
http://www.latticesemi.com/~/media/Documents/UserManuals/HowtouseGSRPURandTSALL.ashx?document_id=31408

No - this doc is about generating resets, and providing known startup states for simulation.
This whole  thing boils down to how to tell the synthesiser to not optimise away things - the ":=0" at symbol declaration ought to  be the logical way to do it, but it seems that the Lattice synthesiser doesn't use it properly. I read that this is most commonly used to specify default for simulation and it's not always used for synthesis.

[jahonen]

This works at least with Altera Quartus (tested it with EP3C120 dev kit actually):

Code: [Select]

library ieee;
use ieee.std_logic_1164.all;

entity single_set is
  port
  (
    sin : in std_logic;
    sout : out std_logic := '1'
  );
end entity;

architecture rtl of single_set is

begin

  test: process(sin)
  begin
    if falling_edge(sin) then
      sout <= '0';
    end if;
  end process;

end;

sout is permanently set to '0' when sin goes from '1' to '0'.

Regards,
Janne

[AwArD_RzD]

In Quartus you have a menu Assigment editor, you can with that tell what you want to be optimised or not and a bunch of other option to tell the compiler what to do with pin, register, clock and other thing. I dont know the Lattice software but im sure you have something like this assigment menu to play with.

I just remembered when i started to play with FPGA sometime Quartus removed the code i wrote in the fitter because there no interaction between the input and the output, my code was valid but because it had no function with the other part it was removed, i played with the option and this never happened again but i dont remember where i did the change, maybe its not only an optimisation but a total removal and the pin just stuck high. If you can see how your compiler implement the LUT this will help you to understand what the compiler fitter do with your code.

[Rufus]

I don't do VHDL but

if (flag = 1 or trigger = 1 )
  flag = 1;
else
  flag = 0;

seems explicit enough to me.

I think that may also optimise itself away, as it can only ever assign to 1 or its previous state.

Assignment of previous state is what infers the latch that you need.

[RPKH]

http://www.doulos.com/knowhow/vhdl_designers_guide/synthesising_latches/

Is this of any help?

[nctnico]

This is a common VHDL problem. What is needed is a reset condition:

if reset=1 then
  signal<=0;
else if rising_edge(clk) then
  if condition=1 then
   signal<='1';
  endif
endif

This way the synthesizer is forced to infer a flipflop.

[Kohanbash]

I've tried using :='0'; at the signal definition but no effect.

Initial values for signals are mostly ignored by synthesis tools.

It is always frustrating when things work in simulation but then do not get synthesized.