It adds 3 and subtracts 1 instead of adding just 1

[Altera_Forum]

Hi! 

I'm pretty new with vhdl and Quartus II and maybe this question is too obvious, but I spent three days on it and I cannot understand yet why is not working... I made a silly program, just adding one to a number, and just send one bit to the output. I tried to simulate it. There are no errors on Analysis & Synthesis, and no errors on EDA Netlist Writer. But the simulation is wrong (I don't obtain what I should) 1. I make a reset and "nombre" should be "0101010101", instead it is "0000000". 2. It should add 1 to this variable at each rising edge clock. Instead sometimes it adds 3 and then subtracts 1. I cannot understand what's happening. I know it should be a really silly mistake from me, because this program is too simple, but I cannot find it. Moreover I've done a more complicated program and I had no problems. Can anybody help me, please?  Hier there is the code:  ------------------------------------------------------------------------  library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_arith.all; use ieee.std_logic_unsigned.all; library altera;  use altera.altera_primitives_components.all;   entity prova1 is    port  (  -- Input ports  clk : in std_logic;  reset : in std_logic;   -- Output ports  sortida : out std_logic  );   end prova1; -- Library Clause(s) (optional) -- Use Clause(s) (optional)  architecture arch_prova1 of prova1 is   signal nombre : std_logic_vector(9 downto 0):="0101010101";  begin   pr1: process(clk,reset,nombre)  begin  if reset='1' then  nombre<="0101010101";  else  if(rising_edge(clk)) then  nombre<=nombre+1;  else  nombre<=nombre;  end if;  end if;  end process pr1;    -- Add the library and use clauses before the design unit declaration  ff_sortida : DFF  port map (  d => nombre(4),   clk => clk,   clrn => not(reset),  prn => '1',  q => sortida  );  end arch_prova1;

[Altera_Forum]

In Quartus, you have "not-gate push back" (something like that) option which can answer to that presets. I don't try this because it introduces a risk of error design. 

 And thanks for thanks, rmc, it is a pleasure that authors notice other that their help are useful ;-)

[Altera_Forum]

I totally disagree with Darkwave. For one thing, integer subtypes aren't in the same category as variables, and variables are totally fine in synthesizable VHDL. In fact, they are used all over the place to great success, e.g. for scratch pad calculations in a process and, of course, in a subprogram. You just need to understand the semantics of initialization and assignment. Some people don't realize that local process variables are static. Yes, no one should write VHDL code like it's a C program , but let's not toss the baby out with the bath water.  

 Not-gate push back is poor name for a simple and totally safe technique for FPGAs to implement preset when the device registers only power up to zero. The tool inverts the input and output of the register, which doesn't alter the synchronous functionality one bit but makes the register's fanout see a power-up state of VCC. Now, Quartus II doesn't alter the register name in order not to lose assignments (or need to migrate them to the new name). The inversion is essentially free in a LUT-based architecture (just push the inversion into the LUT masks of all the fanouts) in almost all cases, although you will see an occasional wire lcell implementing an inversion. The technique gets a bad rap because people see an inverted polarity when the observe the register in SignalTap II or Modelsim.

[Altera_Forum]

I found "Not-gate push back" on the Quartus Handbook Volum I section II 6.40, if someone want to take a look. Basically is what you have said on the forum. 

Reading your posts I get some more questions :-))    1. The using of variables, I understand the definition made before: use them when you need the result within the same clock time. Ok, this is a good rule of thumb, but: when I try to read signals that are not on the sensitivity list, compilator gives me a warning.   I tried what mmTsuchi proposed: the use of a variable:  Comptador: process (clk,reset) is  variable c : std_logic_vector(9 downto 0);  begin  if reset='1' then  count<="0000000000";  else  if(rising_edge(clk)) then  c:=count;  count<=c+1;  else  count<=count;  end if;   end if;   end process Comptador;  Inside the if (clock_rising_edge) there is no more warnings. Now the warning is only for the else statement: count<=count. In this case the warning persists even when I use the variable here. My question: If there is a warning, it means that something is not properly done, so how can I fix it? If I read several signals, and I have to create a variable for each one is not a mess? so I have to ignore the warnings?  2. I don't know where I read it, but as I know it's good (it helps the compiler) to write the else statement always, even when it is an assigment count<=count. This stands always? also for the if (clock_rising_edge)? if there are no more signals on the sensitivity list the else statement should not happen, shouldn't, maybe if reset is made synchronous putting it inside the if (clock_rising_edge)?   When someone starts on a new topic, as me with vhdl, all these tips are very useful, because one looses a lot of time in silly things. So I always thanks to who spent time on helping others. And really I'm learning a lot with these posts! thanks again :-)))

[Altera_Forum]

--- Quote Start ---  The warnings I have now are:  Analysis & Synthesis: Warning (10492): VHDL Process Statement warning at prova1.vhd(39): signal "nombre" is read inside the Process Statement but isn't in the Process Statement's sensitivity list Fitter: Warning: Feature LogicLock incremental compilation is not available with your current license Warning: Some pins have incomplete I/O assignments. Refer to the I/O Assignment Warnings report for details  In EDA and in Simulations there are no errors nor warnings. I set reset 1 from the begining of simulation, during a clock period. then it remains 0 until the end. I generated the clock using the menu clock, as you've said.  --- Quote End ---    Hi Guy's  when I remove the default value of the signal "nombre" all works fine.   signal nombre : std_logic_vector(4 downto 0);

[Altera_Forum]

--- Quote Start ---  The warnings I have now are:  Analysis & Synthesis: Warning (10492): VHDL Process Statement warning at prova1.vhd(39): signal "nombre" is read inside the Process Statement but isn't in the Process Statement's sensitivity list Fitter: Warning: Feature LogicLock incremental compilation is not available with your current license Warning: Some pins have incomplete I/O assignments. Refer to the I/O Assignment Warnings report for details  In EDA and in Simulations there are no errors nor warnings. I set reset 1 from the begining of simulation, during a clock period. then it remains 0 until the end. I generated the clock using the menu clock, as you've said.  --- Quote End ---    Hi rmc,  it looks like that my reply is not received.   In order to solve your problem, you have to remove the default value of your signal "nombre". After that it works fine with Quartus 8.0.

[Altera_Forum]

Hi rmc 

 Some thoughts for you:  1) I wouldn't use the variable that mmTsuchi suggested. Variables can be really useful but as various people have suggested they can catch you out if you're not careful. It will make no difference to your simulation or synthesis here - the synthesis process will strip it out anyway, so why bother!  2) Looking at your original code:   pr1: process(clk,reset,nombre) begin if reset='1' then nombre<="0101010101"; else if(rising_edge(clk)) then nombre<=nombre+1; else nombre<=nombre; end if; end if; end process pr1; I would remove the last else - this is why you're getting the messages about the sensitivity list. Altera have some guidelines on coding for synthesis (which are pretty much the same as other FPGA manufacturers) - check out page 6-42:  http://www.altera.com/literature/hb/qts/qts_qii51007.pdf?gsa_pos=1&wt.oss_r=1&wt.oss=coding%20style  If I were you I would strip out the last else - it's not doing anything anyway:   pr1: process(clk,reset) begin if reset='1' then nombre<="0101010101"; elsif(rising_edge(clk)) then nombre<=nombre+1; end if; end process pr1; This is then exactly in line with Altera's coding guidance (and the other silicon manufacturers); there is no gratuitous code; it is simple and clear.  Hope this helps  Cheers  batfink

[Altera_Forum]

So, if I remove the default value on definition, I can use the reset circuit, in order to force an initial reset and so set al the values then, maybe it is more accurate...  

Do you know why it happens so? the warning only refers to the starting point? so default values are not good to use?

[Altera_Forum]

--- Quote Start ---  So, if I remove the default value on definition, I can use the reset circuit, in order to force an initial reset and so set al the values then, maybe it is more accurate...  Do you know why it happens so? the warning only refers to the starting point? so default values are not good to use?  --- Quote End ---    To be hoenst I don't know, because I'm not an VHDL expert. I always use Verilog for my designs. At least I assume your design is running now.

[Altera_Forum]

First of all I completely agree with batfink, I've never heard anyone suggesting to use useless code in order to "help the compiler". 

Then, DEFINITELY YES, the reset logic is always the best way to initialize registers at some starting values. And try also to be sure that, form a hardware point of view, the logic is reset during the board power-up (using a simple RC circuit or some safer reset ICs which you can find in the market).

[Altera_Forum]

Yes!! thanks batfink, I removed the else statements from if(rising_edge), and there are no more warnings even when the signals have a default value and are not in the sensitivity list. I will take a look to this document! 

 Thaks again!

[Altera_Forum]

--- Quote Start ---  And try also to be sure that, form a hardware point of view, the logic is reset during the board power-up (using a simple RC circuit or some safer reset ICs which you can find in the market).  --- Quote End ---    A reliable power-up reset can also be achieved by using the FPGA internal reset, possibly supplemented by a delay. As long as no other reset sources are intended in the design, the external reset isn't actually necessary. Of course it does no harm to provide it anyway and keep it for possible design extensions.  The signal nombre is initialized to the same state in FPGA internal power-up reset as by the external reset input. This also happens implicitely, if the initialisation expression is removed from the signal declaration.

[Altera_Forum]

Quartus will issue the sensitivity list warning whenever you read the value of an externally declared signal within a process UNLESS the read occurs under a clock-edge. In your case, you're reading "count" when you say count <= count. This read occurs in the else branch, so it's outside the clock edge. Prior posts indicated the correct recommendation - just avoid the unnecessary else branch.

[Altera_Forum]

If you dig through the Quartus synthesis documents then you will find that, as previously mentioned by some of the eminent VHDL chaps in this thread, the default value in the signal declaration is used by Quartus as a reset value. 

 But I have learnt from various VHDL courses that I have been on, that some synthesis tools ignore the default signal value and therefore for these tools you have to use a reset signal.  Whether you stick with default signal values or incorporate a reset signal (which you could generate internally), is up to you but just bear in mind that default signal values may not result in portable code.

[Altera_Forum]

I am agree, I may add  

If you use an external reset, you'd better resynchronize reset (and often with delay block) and incorporate it.  To resume, it is better writing "if reset" statement in synchronous process to initialize values.