2
\$\begingroup\$

I have recently completed a design that had run into timing issues (negative slack). The modules that were found to be troublesome, from the timing reports generated in Vivado 2017.4, are these modules that are used to calculate some synchronous outputs. A clock, reset, and enable (en) signal are provided as inputs. The modules that had these issues were previously implemented as shown below:

always @ (clk, rst) begin
     if (rst) begin
          ...
          ...
     end
     else if (clk & en) begin
          ...
          ...
     end
end

A coworker suggested that the "code is creating latches for the pipeline segments, instead of clocked flip flops". Following his suggestions I changed the modules to what is shown below.

always @ (posedge clk, posedge rst) begin
     if (rst) begin
          ...
          ...
     end
     else if (en) begin
          ...
          ...
     end
end

This seems to have resolved the negative slack coming from these modules, but I am curious to know why this is the case.

\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

A coworker suggested that the "code is creating latches for the pipeline segments, instead of clocked flip flops".

The two code segments are totally different. The first is combinatorial logic, the second is a register.

The behavior of the two is also total different.
In the first what you call a 'clk' is not giving you the behavior of a real clock at all, it is just a signal*. From the first code you can get gates or latches, but not registers. In the code section you should use blocking = assignments.

The second format should produce registers with an asynchronous positive reset.
In the code section you should use non-blocking <= assignments.

*(That was so unusual that it caused my first, wrong, answer)


I'm just having a hard time seeing why this would be the root of a timing issue.

As you are saying you get negative slack, I assume some other parts of the circuit does have registers in them.
The logic from the first parts of the code has NO registers. It is just one huge combinatorial 'blob'.

my original thinking was that the if-statements would help implement the sequential behavior

No, an if statement produces only multiplexers which are combinatorial again.

\$\endgroup\$
9
  • \$\begingroup\$ The project still ran through the Synthesis, Implementation, and Generate Bitstream. I am assuming that some inference was made by Vivado while going through this process then? \$\endgroup\$
    – dby
    Sep 11, 2019 at 16:25
  • \$\begingroup\$ I can see how the first is interpreted as combinatorial, but my original thinking was that the if-statements would help implement the sequential behavior that I intended to have. The second code segment seems to be better defined, I guess I'm just having a hard time seeing why this would be the root of a timing issue. \$\endgroup\$
    – dby
    Sep 11, 2019 at 16:40
  • \$\begingroup\$ Great, that makes a lot of sense now. Especially the 'blob' part of the explanation, thank you for the help. I guess I have a pretty simple work around to implement and a habit to start when coding. \$\endgroup\$
    – dby
    Sep 11, 2019 at 16:53
  • \$\begingroup\$ @Oldfart, I don't see how it's purely combinatorial. If you have an x = y inside there, then you have a case where x changes, but only when an event happens on clk or rst. I don't think there's combinatorial logic that can do that. (But I also don't think there are latches that can do it either, so it's hard to say what will really happen) \$\endgroup\$
    – The Photon
    Sep 11, 2019 at 16:54
  • 1
    \$\begingroup\$ If I actually want a latch, I should write always @(clk or y) begin if(clk) x = y; end, right? If I use always @(*) do I still get a latch, or do I get combinatorial logic? \$\endgroup\$
    – The Photon
    Sep 11, 2019 at 17:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.