- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sidenote: don't use casex. Very bad design technique. You can google it.
And put default clauses at the end of your cases.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page