Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

To work around the clock cycle delay by fsm

Status
Not open for further replies.

rahdirs

Advanced Member level 1
Joined
May 22, 2013
Messages
424
Helped
93
Reputation
192
Reaction score
91
Trophy points
1,308
Location
Mordor
Activity points
4,496
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.

fsm_timing_issue.PNG
 
Last edited:

std_match

Advanced Member level 4
Joined
Jul 9, 2010
Messages
1,187
Helped
444
Reputation
888
Reaction score
409
Trophy points
1,363
Location
Sweden
Activity points
9,162
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

Advanced Member level 1
Joined
May 22, 2013
Messages
424
Helped
93
Reputation
192
Reaction score
91
Trophy points
1,308
Location
Mordor
Activity points
4,496
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

Advanced Member level 1
Joined
May 22, 2013
Messages
424
Helped
93
Reputation
192
Reaction score
91
Trophy points
1,308
Location
Mordor
Activity points
4,496
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.
 

Attachments

  • Timing_issue.PNG
    Timing_issue.PNG
    10.1 KB · Views: 4

ads-ee

Super Moderator
Staff member
Joined
Sep 10, 2013
Messages
7,805
Helped
1,809
Reputation
3,628
Reaction score
1,768
Trophy points
1,393
Location
USA
Activity points
58,912
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

Advanced Member level 1
Joined
May 22, 2013
Messages
424
Helped
93
Reputation
192
Reaction score
91
Trophy points
1,308
Location
Mordor
Activity points
4,496
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.
 

Attachments

  • Timing_issue_1.png
    Timing_issue_1.png
    21.7 KB · Views: 3

vGoodtimes

Advanced Member level 4
Joined
Feb 16, 2015
Messages
1,089
Helped
307
Reputation
614
Reaction score
302
Trophy points
83
Activity points
8,730
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.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top