problem with Global Clock pin and normal IO pin as Clock input

hi i am trying to detect falling edge of a 200ns pulse(WriteStrobe) synchronously with this code. GlobalClk is 100MHz(10ns) oscillator clk attached to global clk pin of Xilinx Spartan 3 XC3s400-5I. the problem i am facing is that about 1000 falling edges 100 of them are missed. i used IBUFG at the input clk but the output is the same. but if I connect the oscillator to a normal io pin with the constraint CLOCK_DEDICATED_ROUTE = FALSE; i can detect all the falling edges without error. i don't know what's the problem. any help would be appreciated :)

always @(posedge GlobalClk) begin pre_WriteStrobe

Reply to
nba83
Loading thread data ...

You can't use the asynchronous input in your "if" clause. To properly sense the falling edge of an asynchronous input you need two flops and then compare the outputs of those flops. If instead you compare the output of the first flop to the input signal (yes I know this would have less latency) you have the possibility of a vanishingly small time when the two signals are different. Then you don't meet the setup time to the registers inside your if statement.

Try this:

reg [1:0] pre_WriteStrobe;

always @(posedge GlobalClk) begin pre_WriteStrobe

Reply to
Gabor

am

=

hay, it seemed that's the problem, because it was solved with this solution:). but i have some question, this solution is equal to lowering GlobalClk frequency, i decreased the globalclk frequency to 10MHz but the previous code still have error detecting edges, but with the code you suggest the code is working ok at globalclk 50Mhz, so what may be the issue? tnx in advanced for help

--------------------------------------- Posted through

formatting link

Reply to
nba83

No it is not.

As Gabor explained, the problem is that the input WriteStrobe is asynchronous to your clock. This means that it can change states likely anywhere within the clock cycle. Now ask yourself the question, if the flip flop has a requirement that the input be stable for some period of time prior to the clock in order to work correctly, how are you going to meet that requirement for the flip flop that is the receiver of logic derived from WriteStrobe?

Resynchronizing WriteStrobe to the clock before using it to control any real logic means that the 'real logic' will have a delayed WriteStrobe that only changes immediately after the clock and therefore should meet the timing requirements.

Kevin Jennings

Reply to
KJ

To belabor the point, in your original post you said you missed about

10% of the incoming edges at 100 MHz. Now imagine that your flip-flops need 1ns setup time, and you use the original equation "pre_WriteStrobe & ~WriteStrobe" where WriteStrobe can change state anywhere within the clock cycle. If it changes about 1ns before the clock edge, then the pulse created by "pre_WriteStrobe & ~WriteStrobe" will only be about 1ns long. This would happen about 10% of the time when the clock is 100 MHz. It would still happen, but only about 1% of the time at 10 MHz. Regardless of the clock frequency you would never get down to 0% missed edges.

When you use two flip-flops, the real trick is that the first flop is the only one that receives an asynchronous input. Thus all flops down the road rely on it to make the decision as to which clock cycle the input changed. So when WriteStrobe changes 1 ns from a clock edge, either the first flop will change state at that edge or it will change state only at the following clock edge, but in all cases its output will change just after a clock edge and every flop that uses its output will agree on which clock edge the change occurred. Any design where more than one flop is involved in deciding the edge where an asynchronous change happens will be subject to errors like you have observed.

-- Gabor

Reply to
Gabor

In theory this will never work, but statistically you will get an acceptable result by reclocking you signal. Make sure you read and understand meta stability. The thing is that if your first FF tries to grab a signal that may change at an invalid phase (setup and hold are bad for the FF), the output of this FF can get to a state where the output voltage level is somewhere between 0 and 1. So even the next FF may get problems seeing if this is a 0 or 1. In worst case it can oscillate. The chance of this happening is rediuced for every FF you pass, so after a

2-3 FF's you should most likely have an acceptable error rate.
Reply to
Morten Leikvoll

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.