3

so I’ve come across some old code that I have to replicate, but it won’t compile with the new Xilinx compiler, so I need to figure out exactly what it does. I have something like this:

if rising_edge(clk) then
   —do some things
   if rising_edge(clk) then
      —do some other things
   end if
end if

Does it take 2 clock cycles to get to the inner if statement, or is the second if statement simply redundant?

Also, Xilinx gives the error: “Logic for signal is controlled by a clock but does not appear to be a valid sequential description”

Thanks, and any help is appreciated.

Jamal
  • 33
  • 1
  • 3

4 Answers4

6

Given that rising_edge(clk) is true for the first if, surely it's still true at the second nested if. This assumes no time has passed within the -- do some stuff section, which is presumably the case.

Therefore, that second if could be replaced by if true then... or indeed left out!

Martin Thompson
  • 16,395
  • 1
  • 38
  • 56
1

That just plain won't synthesize in any tool I have seen. Don't do it, even for simulation.

The second statement rising_edge isn't a sequential statement, e.g. an assignment. It is a statement that involves time so that's how you can be sure.

Brian Carlton
  • 7,545
  • 5
  • 38
  • 47
  • I can't get it to synthesize either, and honestly it's not anything I would ever think of writing. I'm just trying to determine the intent of the original author so I can re-wirte the code. Apparently with an old synthesizer this used to work, or so I'm told. – Jamal Jun 16 '11 at 17:49
  • The second if does not involve time passing, it's the same test as the first one (if clk = '1' and clk'event) – Martin Thompson Jun 17 '11 at 11:00
1

If it synthesized before it was a synthesizer failure/bug. How sure are you that the code matches what was tested and determined to be working? (It sounds like you only have someone's word for this being the correct code that was synthesized before.)

Is the existing system available for comparison and testing? What are the tool versions involved? Can you use the old tools and verify it synthesizes and what warnings it provides? Depending on what version you are using you might be able to use the synthesis report, fpgaeditor (or similar) to look at what actually synthesized.
Or you can analyze the code to see what the designer intended and duplicate that with valid HDL.

Failing that all you have left is trial and error. Try assuming:

  1. The statements inside the nested rising edge are always active. (Remove the nested rising edge if statement leaving the code block it surrounded).
  2. The statements inside the nested rising edge are never active. Remove the entire nested rising edge block.
  3. You could try it but I really can't imagine how a synthesizer would create a 2 cycle delay out of this. You might be reduced to trying this or other even more unlikely situations. It gets really hard to predict what this failure mode would be.
davidd
  • 783
  • 4
  • 9
  • Thanks for such a great reply! I'm pretty sure that I'm able to determine what the original authors intent was from the rest of the code (no comments, mind you) and I'm going to try and implement that and see what happens. Thanks for the help! – Jamal Jun 17 '11 at 15:37
  • 1
    I'm not so sure that it would be a bug if a synthesizer would accept this. The second if-statement would always pass in a simulation (the same condition is tested). While it makes sense for a synthesis tool to refuse two nested edge conditions, it would also make sense to just ignore the second condition. That said, the code should really be changed so that it would only have a single edge detection. – Philippe Jun 19 '11 at 06:24
0

actually what you want to infer is nested clocked processes.

This shouldn't synthesize since it doesn't represent meaningful hardware.

You should rewrite your code, accordingly to xst.pdf (e.g. if you use Xilinx ISE).

Kind regards, Nikolaos Kavvadias

Nikolaos Kavvadias
  • 31
  • 2