To work around the clock cycle delay by fsm

[rahdirs]

To work around the clock cycle delay by fsm to prevent timing issue

Hi,

I have an input to my module,'ready' signal(app_rdy_1) which goes low at random time for some short duration & then goes back high.
When the ready signal goes low,i need to maintain the values of some of my signals.

I will explain for 1 signal.
1 of i/p to my module = count1(26 downto 0)
1 of o/p of my module = ui_c0_app_addr(26 downto 0)

The i/p to my module,count1 is coming from a counter.I stop the counter from incrementing when ready goes low.So obviously,the i/p to my module also stops incrementing when ready goes low.This can be seen in attached waveform.

In my module,through a fsm,i assign the count1 i/p to my o/p ui_c0_app_addr.So this gets delayed by 1 clock cycle.So when ready is low,my o/p changes once.How can i resolve this ?

Attached is a snapshot to understand it better.

 

[std_match]

First, you should not use an asynchronous input signal directly. Race conditions and metastability can cause malfunction of your circuit. The standard way to eliminate that is to clock all asynchronous signals through at least two registers before using them. This will cause your delay to be even longer. You should fix this in the other end, the counter value. Delay the counter output (clock through registers) or subtract a constant to compensate for the delay in the input signal.

 

[rahdirs]

Hi,

Yeah,i totally forgot about synchronizers.I used to use them in my design when i was in college.
About this delay getting even longer,i think it won't affect me.Not sure but i will work on it & post the results tomorrow.

 

[rahdirs]

This will cause your delay to be even longer. You should fix this in the other end, the counter value. Delay the counter output (clock through registers) or subtract a constant to compensate for the delay in the input signal.

I've attached the waveform with the asynchronous signal now passed through a synchronizer.As i guessed yesterday,the delay would still be the same.

In waveform:
i/p - count1(26:0);o/p - c0_app_addr(26:0);
asynch. signal - c0_app_rdy; synch signal - app_rdy_1

We can clearly see a 1 clk cycle delay between i/p & o/p.
I'm thinking the only way of solving this problem might be using 1 D Flip Flop Synchronizer app_rdy signal for Counter &
2 D Flip Flop app_rdy signal for my FSM module.

Is this even a good way of doing things ? But it would most likely solve problem posed by c0_app_addr signal,but other signals i'm not sure.

 

[ads-ee]

Based on your original description and to make it easier to write code to control it. I would remove ui_c0_app_addr from the FSM and use the synchronized app_rdy signal to enable the loading of the count value. I'm not sure that 10288 is the value you want on the bus at the end, but using app_rdy as the enable will stop it on that value and count will hold the next value to be clocked into the ui_c0_app_addr.

What you aren't seeing (if my assumption is correct) is the count and ui_c0_app_addr are a pair of pipeline registers that must stay in lock step, therefore if you clock enable one of them (count) you better clock enable the other one too.

This to me is a classic example of why I stopped implementing any output signals inside my FSM. I only implement the FSM in a single clocked process. All my outputs (or most of them at least) are in separate processes/always blocks, where I use the state variable to determine where I am in the FSM. It also avoids all the gotchas with default output values missing asisgnments, etc.

Typically the only non-state signal in my FSMs will be counters that mark off time delays that the FSM uses to stay in a state.

 

[rahdirs]

Hi,

Thinking back on some of the answers provided:

@std_logic :- yes,using synchronizers in your design is a good practice.But,that asynchronous ready signal is provided by memory controller(MIG ip) indicating when the DDR is busy/idle.

If we synchronize it,we will be timing our signals with a synchronous ready signal,but the controller expects you to maintain/time your signal values with the asynchronous ready signal.
So,your signals would still suffer if you synchronize it.

 

[vGoodtimes]

My guess is that there is something in the simulation model that adds the small delay, or you've connected a slightly wrong clock to a module. It would be insane to have a truly async signal for this application.