Compare and update in same clock cycle synthesis problem

Something simular to the following code fragments works in pre-synthesis simulation, but not in real hardware and post P&R timing simulation.

entity controller is port ( ... datain in : std_logic_vector(7 downto 0); clock in : std_logic; ... lastval out : std_logic_vector(7 downto 0); ); end entity controller;

architecture rtl of controller is begin process(clock) ... variable lastval_v : std_logic_vector(7 downto 0); begin if rising_edge(clock) then case control_state_v is

...

when STATE_CHECK =>

if datain /= lastval_v then lastval_v := datain; control_state_v := STATE_CHANGED else control_state_v := STATE_OTHER; end if;

when STATE_CHANGED =>

...

when STATE_OTHER =>

...

end case; end if;

lastval if datain /= lastval_v then control_state_v := STATE_UPDATE else control_state_v := STATE_OTHER; end if;

when STATE_UPDATE =>

lastval_v := datain; control_state_v := STATE_CHANGED;

This works in both pre- and post-synthesis simulation and also in real hardware. There is now an 8-bit comparator found for the compare line and no more warning about constant values.

So my question is: Is there a problem with comparing and updating a value in the same state (clock)?

And does the problem als exist for single bit values when used like this:

if my_bit_v = '1' then my_bit_v := '0'; -- do stuff end if;

All inputs to the entity come from other parts in the fpga and are all updated on the same clock. The synthesis report claims the design can run at 58 MHz, actual clock is 50 MHz, no other constraints defined.

The hardware is Xilinx spartan-3e and synthesis is done with ISE9.2.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)
Reply to
Stef
Loading thread data ...

No as a general problem. The code shown is IMHO synthesisable. Only strange thing I see is lastval beeing updatet again at the falling edge of clock, but the code shown here should work right.

However I would change this code in case of trouble, as this code might easily mask problems resulting from other parts of the design (eg. if you have a module where clk and data change their order in timing).

It might be also possible, that Xst struggles with this code even if it the overall design is correct. Try if other tools behave well with this code.

bye Thomas

Reply to
Thomas Stanka

OK, thanks. This is what I believed as well but started doubting after this experience. I use the single bit compare and update in a number of places and have not had problems with those. There should not be a fundamental problem between single-bit and multi- bit compare operations.

Sorry about that, that was a mistake in the example, the update should have been inside the "if rising_edge(clock) then".

At the moment I only have access to Xst for synthesis, so I can't try that. I have now split up the compare and update in several states and this has solved the problem. As the performance of this statemachine is not critical, I will leave it like that.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)
Reply to
Stef

control_state_v is being assigned to as a variable. It should be a signal.

Reply to
RCIngham

Why should that be a signal? control_state_v is my state variable and is declared (not visible in the fragments) and used only in the clocked process.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)
Reply to
Stef

...snip...

This can be significant. Do you have the tools to "see" the logic produced by this code? It will be a *lot* easier to understand the logic produced if you can reduce the problem code to a minimum set. Look at exactly what is being produced in the way of logic. You talk about an 8 bit comparator, but I only see an equivalence check. If the variables are 8 bits, this only takes 5 LUTs in two levels. I supposed it might use 4 LUTs with the carry chain, but I don't think that is essential.

No, certainly the language does not know what you are doing in terms of updating or comparing. It only knows what you tell it. If you said to compare values and update the register that is used in the compare, it is happy doing that... as long as that is what you are telling it.

Reply to
rickman

Xst actually reports "Found 8-bit comparator not equal for signal..." So I presume it will implement something like you describe.

Somehow I must have failed telling that in the one-state approach. ;-) Why, I still don't know. If there's a real error in my logic, I would expect the pre-synth simulation to fail as well.

To my relief, there is no problem with that type of coding, as I have used this in more places in the design (but mostly with 1-bit flags).

The 2-state approach solved the curent problem, but it would indeed be interesting to see if I can reproduce the problem in a minimal design, but that will have to wait.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)
Reply to
Stef

Take this example:

sigA

Reply to
Andy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.