VHDL Strange Behavior

[Altera_Forum]

Hello, 

 I need to calculate the average between 4 std_logic_vectors: "A, B, C and D".   When I simulate my code in modelsim everything seems to be OK:cool:.   But, When I test it in the FPGA :confused: the output is corrupted.   The strange thing is that if I calculate the average between A and B the output is ok.  The same If I calculate the average between C and D the output is ok.  The same If I calculate the average between A and C the output is ok.  The same If I calculate the average between B and D the output is ok.   I suspect is something relationated with the FAN OUT. I verified each signal, and she is ok, but if I use the 4 at the same time :mad: it fails.    In my code I have 2 process: one combinational and one sequential.    --------------------------COMBINATORIE-----------------------  PROCESS(A30022, B30022, C30022, D30022) IS    BEGIN  aux_pij <= (B"00" & A30022)+(B"00" & B30022)+  (B"00" & C30022)+(B"00" & D30022);    END PROCESS;     --------------------------SEQUENTIAL-------------------------  PROCESS(reset_n,clk) IS   BEGIN  if reset_n = '0' then    pij <= (others =>'0');    elsif clk'EVENT AND clk = '1' THEN     pij <= aux_pij(9 downto 2);     end if;   END PROCESS;  -------------------------------------------------------------      Here I will attach the complete VHDL file.  Thank you in advance.  Cordially,  DABG

[Altera_Forum]

I forgot the Attachment.

[Altera_Forum]

I suspect that you're trying to add together 4 inputs in a single clock cycle is causing the problem. Normally, it would be better to pipeline it, doing A+b and C+D in parrallel, then the next clock cycle add the two results and bitshift.

[Altera_Forum]

--- Quote Start ---  I suspect that you're trying to add together 4 inputs in a single clock cycle is causing the problem.  --- Quote End ---  Depends on... (the FPGA family, the clock frequency).  In any case, the timing analyzer would tell.

[Altera_Forum]

So what's the answer?

[Altera_Forum]

As long as the input terms are unregistered and no timing constraints are defined for it, the timing analyzer can't check a required timing. But it reports a required setup and hold time related to clock, that allows to determine the achievable speed even without timing constraints. With Cyclone III slowest speed grade, the worst case setup time is around 6 ns, which is acceptable in my opinion. But you are of course always able to define unsuitable simulation waveforms, thast cause a timing violation.

[Altera_Forum]

As Tricky pointed, it is safer to pipeline. It is no good to register output yet add up 4 inputs in combinatorial circuit. 

  PROCESS(reset_n,clk) BEGIN if reset_n = '0' then ... ... ... elsif clk'EVENT AND clk = '1' THEN aux_AB <= (B"00" & A30022)+(B"00" & B30022); aux_CD <= (B"00" & C30022)+(B"00" & D30022); aux_pij <= aux_AB + aux_CD; end if; END PROCESS; pij <= aux_pij(9 downto 2); -- save 8 registers

[Altera_Forum]

--- Quote Start ---  It is no good to register output yet add up 4 inputs in combinatorial circuit.  --- Quote End ---  It works with 8 bit numbers up to 100 or 200 MHz clock, depending on the device family. Adding two numbers of more common 16 to 32 bit word width results in a higher computational delay. You're free to pipeline everything, of course, but in my opinion, pipelining should be applied where actually required.

[Altera_Forum]

Yes it might work with modern devices but remember that RTL is based on pipelining to reduce critical paths. A practical project design will not just contain few adders. It is likely to grow till almost of the chip is occupied as managers push in more and more of tasks every morning...

[Altera_Forum]

Yes, of course. I was speaking of the particular example with a 4 input adder. As I previously mentioned, the example is incomplete, because the input is unregistered, effectively unrelated to the system clock. This fact was most likely causing confusion in simulating the design. The output is however registered, so it doesn't suggest an endless chain of combinational logic.  

 In a real world problem, the input signals would be either registered or have a specified timing relation to the clock. Then you are able to place pipeline stages, where necessary.