Guidelines to avoid Negative Slack with State Machines

Hi,

I m working on a hardware which uses a hardware block (Lets call it x), which does communication with a host machine, does processing based on the request given by the host machine, and gives a response back once the processing is done.

X hardware is written as a state machine, with a total of 54 usable states. The coding is done as follows(Just a sample demonstration, exactly the way state machine is defined in my hardware)

always@(posedge clk)

begin

if(rst)

presentstate <= IDLE;

else

begin

presentstate <= nextstate;

case(nextstate)

IDLE:

STATE1:

STATE2:

STATEX:

default:

endcase

end

end

always@(*)

begin

nextstate = presentstate;

case(presentstate)

IDLE:

begin

if(condition1)

nextstate = STATE1;

end

STATE1:

begin

if(condition2)

nextstate = STATE2;

else if(condition3)

nextstate = STATEX;

else

nextstate = IDLE;

end

STATE2:

nextstate = STATEX;

STATEX:

nextstate = IDLE;

endcase

end

The states are defined using localparam, and are defined in a binary encoded fashion(But QuartusMap report says, the encoding was done as onehotcode)

localparam IDLE = 0;

localparam STATE1 = 1;

This hardware is consistently showing negative slacks after routing, with launch clock and latch clock being the same, and the from node and the to node, both within the hardware x.

Some of the incoming signals and some of the outgoing signals are not latched(To save a clock cycle). But with the To Node and From Node within the same hardware, Will latching the signals make a difference in the timing? Is there anything wrong with the way, the coding is done? Any suggestions on how to get rid of the negative slack?.

When you get a negative slack in the route report, how do you systematically debug it?. The route report shows long combinational path in terms of the net names generated in the synthesis, and how would you relate it to your code?.

Regards

Jeebu