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]

Hi, 

 In your process,  just type process(reset,clk) : your process must be synchronous and then no other signal in sensibility list of process. if you type "process(reset,clk,nombre)" the process will be activated on any changes of nombre. you may use variable in this process. Because "nombre<=nombre+1;" is not obvious. and then typenombre <= var +1 ;.  Sorry for my english, I'm french.

[Altera_Forum]

--- Quote Start ---  1. I make a reset and "nombre" should be "0101010101", instead it is "0000000".  --- Quote End ---  I think this is because your reset is connected to the "clrn()" of your DFF... What you can do is connect is to ground or Vcc depending on whether its active_low or active_high.... I guess its active_low by the looks of the way you have connected it... Also, your initialization is run only once, at the start of the program, so when you reset, the value of "nombre" gets cleared...  ff_sortida : DFF port map ( d => nombre(4), clk => clk, clrn => not(reset), prn => '1', q => sortida );and i'm just guessing here but    --- Quote Start ---  2. It should add 1 to this variable at each rising edge clock. Instead sometimes it adds 3 and then subtracts 1.  --- Quote End ---  again has something to do with the way you are storing the value in your DFF...   Hope it sheds some light on your query...  Regards, YashD...

[Altera_Forum]

In my opinion there is a mistake somewhere in your reason. 

Most of all the code seems ok, but: 1- as mmTsuchi told you, in a synchronous process's sensitivity list you need to put only reset and clock signal.  2- your signal is too long and will be synthetized away because you use it only through bit 0 and bit 4. so define it as: signal nombre : std_logic_vector(4 downto 0):=b"10101";  3- told that how are you looking at the signal output? You've the out on a pin and you see it with an external digital scope? Or it is only something in the simulator? I ask because simulator can change the polarity of the signal. Moreover you could have some timing problem. If it's the case and you're looking at it in the simulator try to simulate it only in functional and not in timing (if the result change, your timing problem are true).  4- How fast is your clock?  you think to read: signal your output 10101 0 (because you reset the DFF at the beginning) 10110 1 10111 1 11000 1 11001 1 11010 1 11011 1 11100 1 11101 1 11110 1 11111 1 00000 0 00001 0 00010 0 00011 0 00100 0 00101 0 00110 0 00111 0 01000 0 01001 0 01010 0 01011 0 01100 0 01101 0 01110 0 01111 0 10000 1 10001 1 10010 1 10011 1 10100 1 10101 1   and cyclically the same, right?   you see a sort of square wave that has an initial phase shift compared to the started reset signal.

[Altera_Forum]

Thank you both mmTsuchi and yashd for your answers. I tried all you said but I obtained the same result. Moreover, the logic that RTL viewer shows it is right, so it seems that my code is understood by the compiler but the simulator give me another result. Also, in the simulator the five most significant bits of 'nombre' are ignored... I don't really understand what's happening... 

 Thank you again!!  rmc

[Altera_Forum]

Thank you Darkwave for your answer:  

 1. I removed 'nombre' from sensitivity process list.  2. You're right the most 5 significant bits where removed by simulator because never used. Of course, I'm using only until the bit 4. Now I've understood. 3. now with functional simulation it works!! Now the output polarity is also right. I'm testing only in the simulator. I'm using a clock period of 20ns. But I cannot understand why it is not working with timing simulation. Do you think I have to change any settings? 20ns should be enough... shouldn't?  Thank you a lot for your help!

[Altera_Forum]

No problem (click on my reputation if you think my help is good), 

for your problem now it seems that it's a timing problem. You can check it on the report after your compilation ended (see under the compilation report the timing section).  If you've timing problem they could depend from a lot of thing: is your clock coming from a pin? Have you given the assignement to it in order to tell the compiler that it's a clock and that its period is 20ns?  This will really help quartus and drive its compilation.

[Altera_Forum]

The clock comes from a pin: I assigned to the corresponding input pin. This clock it is working at 50MHz, so the period it is 20ns. 

Indeed there where a lot of warnings on Timing Analysis due to pulse width violations. I set Classical timing Analyzer on timing settings. I added clk as a system clock and I fixed 50MHz as the maximum frequency. Now there are no warnings on Timing, but the simulation is still wrong. The other time I used Quartus, I had also timing warnings, but the simulations were ok... I realize that I don't know a lot about timing settings...  Now I have three warnings on all compilation, 1. On Analysis and Synthesis: 'nombre' is not on sensitivity list and is read indise the process. But I understood the reasons. 2. On Fitter: Logiclock incremental not available: my license is from web edition, ok 3. On Fitter: some pins have incomplete I/O assignments. I assigned my three pins to the clock, a button and a LED.   Any idea why the simulation it's still wrong?  Thanks!!

[Altera_Forum]

If you can please write one of the message of error you've. 

 "Indeed there where a lot of warnings on Timing Analysis due to pulse width violations."  I've not understood where you've this error (if it's in the compilation or when you run the simulator). If I remember well that's a problem in the simulation that mean that you've designed bad waveform. If that's the case in your simulation you should only move Reset and CLK, all other shall be "U" (that mean undefined - so not set). To design the clock you shall use the "clock" button on the simulation weaveform vector file. Moreover in your simulation are you trying to move the reset in strange way? Or you move it only at the beginning (machine that start in reset and then it'll never been in reset).  If your purpouse is to move the reset with the button while you run the machine, it's better that you use a synchronous reset and not an asyncronous one. So you put 2 register (2 because of metastability) after your input pin that will be clocked by your clock and modify your code as:  pr1: process(clk) begin  if(rising_edge(clk)) then  if reset='1' then  nombre<="0101010101";  else  nombre<=nombre+1;  end if; else  nombre<=nombre; end if; end if; end process pr1;

[Altera_Forum]

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.

[Altera_Forum]

Ehm so you've no timing error? 

I mean not what it tell you while you compile (also if you can see it in the end because it tell you that all time requiring are met), but if you see some path in red in the compilation report (the window that open to you when you end to compile: on the left side you should see something like Timing Analisies: open it and see if something is red).  What about the: "warnings on Timing Analysis Timing Analysis due to pulse width violations"?  have they vanished?  Now I'll have to go home, good week end.

[Altera_Forum]

After setting the maximum clock frequency on Classic timing Analyzer all errors and warnings on timing have vanished. now there are only these three I posted. But the simulation is still wrong... 

 good weekend and thank you again!

[Altera_Forum]

All above speculations are basically missing the problem.  

the design is working fully correct!  Ít only looks like an error. The problem is that internal nodes are not guaranteed to be shown correct (e. g. without inverting bits) by the Quartus simulator (in timing simulation). They are shown as the design uses them after optimisation. If you add an output port, that simply copies the state of the nombre signal,you'll see immediately that the design is counting correct, but showing some inverted bits. The reason is very simple, the reset state of "0101010101" is mapped to "00000000", all registers are reset to zero, in other word an XOR with "0101010101" gets the correct result. You have to consult the Technology Map instead of RTL Viewer to see this behaviour.

[Altera_Forum]

--- Quote Start ---  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  --- Quote End ---   because you have nombre <= nombre + 1; I think it is better use variable which receive [b]nombre [/b] at clock edge. var_nombre := nombre; nombre <= var_nombre + 1;

[Altera_Forum]

It's VHDL not C! 

Variable command should never exist..  When you write VHDL you need to know exactly how it's been implemented.  Moreover the design works well and that's what is important. If simulation is wrong it should be something about simulation signal or the reset condition not at 0. Moreover simulation not guarantee that internal node that you see are what you expect (it depend on the implementation), but the output signal MUST be ok.  If you wanna see also the internal node right, the only solution is to route them as output too, but it's not important if you see the output signal right. But please stop use "variable" or "integer".. it's not C.

[Altera_Forum]

--- Quote Start ---  It's VHDL not C! Variable command should never exist..  --- Quote End ---    You're right in so far, that there isn't a reason to use a variable here. But apart from that, variables are existing as objects in VHDL specification, and they have a purpose. Some VHDL constructs must use variables, others may use it to achieve specific behaviour (Variable assignments behave similar to blocking assignments in Verilog). And in many places, a confused VHDL programmer could use it without causing a different behaviour than when using signals. But it's bad programming style.

[Altera_Forum]

if you write nombre <= nombre + 1; it is like C affectation. 

The synthesizer want to 'wire' nombre with "nombre + 1". I think Quartus Synthesizer will introduce a DFF by itself on signal "nombre" if the process is synchronous and alert designer that nombre <= nombre + 1 were modified.  I use variable in process for edge detections for exemple.

[Altera_Forum]

A variable must be used, if the assignment result has to take effect immediately, within the same clock cycle, e. g. if the variable is used as an interim result in other expressions and no pipelining is intended. Only in this case, there is a different behaviour of signal versus variable. If the variable value is used across clock cycles, a register is automaticly inferred by the compiler and it's behaving similar to a signal. This would be the case in the present code. 

 Using a variable, where no variable is required, can be regarded as bad programming style, but of course it's a matter of taste.

[Altera_Forum]

First of all thanks you for all your answers. I've understood a lot of things with your posts. 

I consulted The Technology Map and this behaviour can be seen, all clr are connected to the reset, so the reset is done by "00000" instead of "10101". So the values (of internal signal) I obtained in the simulation are correct if I make a XOR with "10101". Moreover I create another output as you suggested me and I can see the correct values of the counting. Now I know that my design is correct, but I don't understand why it does that. If my design is more complicated how can I see the correct values of internal signals? Only routing them as an output? How mapping is made? Can I set anything to "force" the mapping? I searched on the Quartus Handbook but i couldn't found any information about maping. Could anyone recommend me anything to read? I searched also in Internet but i couldn't found anything.  thanks again

[Altera_Forum]

An obvious reason to map the register polarity as found here, is in the fact, that many device families, e. g. Cyclone II and Cyclone III have no preset signal with DFF. The compiler has no other means to implement the logic at all. Thus the behaviour can't be changed by a setting or synthesis attribute.

[Altera_Forum]

Then, I understand!!! indeed I'm using Cyclone III! Ok, now it is clear, thanks again FvM and everybody for all the posts, it was so frustating to expend so many days without understanding what was going on...