Forum Discussion

Baller's avatar
Baller
Icon for New Contributor rankNew Contributor
1 year ago
Solved

Quartus Lite 'No paths found'

I am currently working on a KISS2 to verilog translator and this is one of the designs that it generated cannot measure FMax.

My verilog module consists of 3 blocks:
- state transitions (choosing nextstate, combinational)
- outputs (combinational)
- memory (changing state with nextstate, clocked)

This is the troublesome module block:

always@(*) //2nd process (outputs)
begin
out = 1'b1;
case(states)
st0: casex(in)
2'b00: out = 1'b0;
endcase
endcase
end

Because of it, 2 of the Operators are directly connected to output.

Would there be any way I could calculate the FMax without drastically changing the code?

  • O.k., you didn't show the registered part of your design.

    Problem is however, that your state logic is creating latches by incompletely decoding states, which breaks timing analysis of states register. To remove latches, preset nextstate to current state:

    always @(*) //1st process (transitions)
      begin
        nextstate = states;
        case(states)

7 Replies

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor

    Hi,

    Fmax calculation works only for registered (edge sensitive) logic with a dedicated clock. It's assessing the longest combinational path between two register. To determine overall design speed, you might add in- and output registers and specify the clock input with create_clock in .sdc file.

    • Baller's avatar
      Baller
      Icon for New Contributor rankNew Contributor

      Hi

      Thanks for replying, I was going to update the post with more information about the design but I'll include it here:

      The module is an FSM automatically generated from the KISS2 file and I do not wish to change it drastically. The entire file consists of 3 modules:
      1 - determining next state
      2- determining the current output
      3- memory handling (assigning nextstate to state)

      This is how it looks like:

      module train11_DOut (
      input reset, clk,
      input [1:0] in,
      output reg [0:0] out);

      reg [3:0] states, nextstate;

      parameter [3:0]
      st0 = 0,
      st1 = 1,
      st2 = 2,
      st3 = 3,
      st4 = 4,
      st5 = 5,
      st6 = 6,
      st7 = 7,
      st8 = 8,
      st9 = 9,
      st10 = 10;

      always @(*) //1st process (transitions)
      begin
      case(states)
      st0: casex(in)
      2'b00: nextstate = st0;
      2'b10: nextstate = st1;
      2'b01: nextstate = st2;
      endcase
      st1: casex(in)
      2'b10: nextstate = st1;
      2'b00: nextstate = st3;
      2'b11: nextstate = st5;
      endcase
      st2: casex(in)
      2'b01: nextstate = st2;
      ... (other state transitions) ...
      end

      always@(*) //2nd process (outputs)
      begin
      out = 1'b1;
      case(states)
      st0: casex(in)
      2'b00: out = 1'b0;
      endcase
      endcase
      end

      always @(posedge clk) //3rd process (clock)
      begin
      if (reset)
      states <= st0;
      else
      states <= nextstate;
      end
      endmodule

      My SDC file consists only of 1GHz clock creation for clk
      I am completely new to the subject and I am not sure how I could force a timing calculation without changing the module code, but my research so far leads me to believe I will have to. Any and all feedback is appriciated because I am starting to get desperate

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor

    O.k., you didn't show the registered part of your design.

    Problem is however, that your state logic is creating latches by incompletely decoding states, which breaks timing analysis of states register. To remove latches, preset nextstate to current state:

    always @(*) //1st process (transitions)
      begin
        nextstate = states;
        case(states)
    • Baller's avatar
      Baller
      Icon for New Contributor rankNew Contributor

      Yes! It worked. This also explains why other files I generated (with default states or default case statements) work without issue.

      If you don't mind me asking, would setting initial starting values for each and every module (for example state = st0, nextstate=state and out=1'b0) similiarly solve the latch issue for any future generated files?

      I am extremely thankful for your assitance

      Edit: I got too excited and didn't see the logic implication. My design generates different possible file descriptions (safe, with default state/out and 3,2 and 1 process ones) and adding this specific lines of code defeats the purpose of having different implementations as I believe it automatically turns them into safe FSM. I will explore the subject further. Again, I am very thankful for your assistance

  • FvM's avatar
    FvM
    Icon for Super Contributor rankSuper Contributor

    I can only give a general answer. Latches must be avoided in synchronous logic design, the most simple way is to make default assignments in combinational always blocks for all variables that are not obviously assigned under all conditions. They don't hurt (and don't consume any logic resources) if they are redundant. They'll of course break intentional latches which should never happen in a reasonable design.

    • Baller's avatar
      Baller
      Icon for New Contributor rankNew Contributor

      Thank you

      Some of the files I generate implement this rule, giving extra reliability to the design (those safe designs I mentioned) and those never encountered this latch problem. I suppose my main goal of testing and comparing all the possible designs was still reached and now I can see that for some FSM 3 process description style without default assignments is just fundamentally flawed

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor

    Sidenote: don't use casex. Very bad design technique. You can google it.

    And put default clauses at the end of your cases.