UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor nfranch
Visitor
8,275 Views
Registered: ‎04-08-2015

Improving FSM timings

Jump to solution

Greetings, I've written a FSM to control my system, which I'm trying to really push in terms of clock frequency (300 MHz). This means, of course, I'm getting hit by setup times, and given my lack of experience I've decided to ask for ways to improve my design.

The FSM has to wait in some of it's states for a number of programmable cycles. To do so, I inferred counters in such states, and compare that to the given input. This is where the design fails, and where I have the first doubts.

I infer the counters rather innocently (by issuing counter <= counter+1 in the state). One of the first things I tried is to change that into instantiated counters, but then I realized the critical path isn't about the counter, but with what seems to be the comparison and the logic to get the next state, with most of the data path delay being due to routing, I suppose due to the tools trying to accomodate FSM logic between the different states. I tried that change anyway, and it didn't seem to help at all.

 

I'm using the PerfOptimized High synth strategy, and the Performance Explore Post Route implementation strategy. I've even tried issuing phys_opt_design -directive AggressiveExplore manually after the implementation, without any improvement.

Am I doing something fundamentally wrong, or missing on something? Can I help the design to pass timing? The 9 failing paths have the same start (the 8th register where that input data is stored after being synchronized), and the endpoints are against the different state registers.


Included is the worst path report and the schematic shot, together with the verilog file for reference.

 

Thank you very much for your help and time, and any tip will be very welcome!

0 Kudos
1 Solution

Accepted Solutions
Instructor
Instructor
15,522 Views
Registered: ‎08-14-2007

Re: Improving FSM timings

Jump to solution

Typically what you want to do is reduce the number of levels of logic in order to run quickly.  Your state logic will have a lot if inputs if the counters are long and you need the output of the comparison on the same clock cycle.  Using an intermediate signal to do the comparison on the previous clock cycle can improve timing, i.e. instead of (pseudo-code)

 

  if (counter = 0) go to next state

  else stay here and decrement counter

 

you would have a signal like "counter will be zero"

 

  cwbz  <= (counter equals 1 and being decremented)

 

  if (cwbz) go to next state

  else stay here and decrement counter

 

In the second case, the FSM only needs the state of the single-bit signal cwbz.

 

You can also have the tools make the same sort of timing optimizations for you by enabling register balancing in the synthesis settings.

 

Another point is that having a different counter for use in different states may increase the overall number of inputs to the FSM logic.  It may seem counterintuitive, but sharing the same counter for different states could improve timing even if you don't do other optimizations.

 

Finally you might consider having a separately coded wait state that operates like a subroutine.  This only works if the timing is fixed for any particular state, i.e. there is no way to exit the state before the full time elapses.  Then in your various states you would load a signal with the delay time in clocks, load another signal with the state you want to proceed to after the delay elapses (the "return address") and "call" the wait state.  In the wait state you decrement the counter until it becomes 0 (or 1 or some other value) and then set the state to the value in the "return address" signal.

-- Gabor
2 Replies
Instructor
Instructor
15,523 Views
Registered: ‎08-14-2007

Re: Improving FSM timings

Jump to solution

Typically what you want to do is reduce the number of levels of logic in order to run quickly.  Your state logic will have a lot if inputs if the counters are long and you need the output of the comparison on the same clock cycle.  Using an intermediate signal to do the comparison on the previous clock cycle can improve timing, i.e. instead of (pseudo-code)

 

  if (counter = 0) go to next state

  else stay here and decrement counter

 

you would have a signal like "counter will be zero"

 

  cwbz  <= (counter equals 1 and being decremented)

 

  if (cwbz) go to next state

  else stay here and decrement counter

 

In the second case, the FSM only needs the state of the single-bit signal cwbz.

 

You can also have the tools make the same sort of timing optimizations for you by enabling register balancing in the synthesis settings.

 

Another point is that having a different counter for use in different states may increase the overall number of inputs to the FSM logic.  It may seem counterintuitive, but sharing the same counter for different states could improve timing even if you don't do other optimizations.

 

Finally you might consider having a separately coded wait state that operates like a subroutine.  This only works if the timing is fixed for any particular state, i.e. there is no way to exit the state before the full time elapses.  Then in your various states you would load a signal with the delay time in clocks, load another signal with the state you want to proceed to after the delay elapses (the "return address") and "call" the wait state.  In the wait state you decrement the counter until it becomes 0 (or 1 or some other value) and then set the state to the value in the "return address" signal.

-- Gabor
Visitor nfranch
Visitor
8,098 Views
Registered: ‎04-08-2015

Re: Improving FSM timings

Jump to solution

Hello!

 

Sorry for the delay on any kind of answer: I went to directly toy with my design, using the ideas you gave on your post. Thank you very much for them... I realize now how basic it was (I was really using the whole 8 bits of the counters for the comparison), but beyond that you also gave me some nice and not so evident ideas.

 

In the end, it's been a success, with my design finally working at the desired frequency. Thank you very much!

0 Kudos