Quartus Lite 'No paths found'

[Baller]

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?

[FvM]

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]

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 · Accepted solution]

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]

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]

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]

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]

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

And put default clauses at the end of your cases.