Signal 2 clocks long but only one clock possible

So you receive data at 125 MHz, and you transfer it then at 100 MHz (if I understand you right) How do you control the FIFO to prevent it from overflowing? What do you do with the flags? Peter Alfke, Xilinx (from home)

You might try changing your timing constraints to be a bit more pesimistic to see if that helps. Try 130MHz and 105Mhz. I've had cases (using 6.1) where things would be erratic. I then tightened the constraint and poof! the problem went away.

Good luck.

John Providenza

Hello, my input data rate from the phy gigabit into the fifo is 162 Byte / 5 us. The output data rate out of the fifo is approximately 162 Byte / 3 us. The data is packet into 32 Bit and transfered over an external bus which is clocked by 100MHz/8 = 12.5MHz. I do not check the fifo status, because I know, that I'm fast enough to empty it. The only thing I need is a

1-clock-pulse from the receiving component to tell that a new frame (162 Byte) has been received. After this pulse is seen ( I name it frame_ready) a statemashine does the rest without beeing controlled by any signal from the receiving component ( I name it phy_rx). In this way I send the data with a corresponding chipselect to 1 of 3 external devices. Every external device has to get 128*512*162 Byte = ca. 10MB. After that, the chipselects are switched to the next device. Because of this, every chipselect for the external devices are approximatly 0.3s long. I see this in my testbench and on the oszilloscope. Sometimes one of this chipselect is shorter than 0.3s which causes data to be send to the wrong device. This happens randomly after 1000s or 12345s or something else, A friend at work originally wrote the component for empting the fifo and sending data. After long studies I decided to rewrite this component. Absolutely new and absolutly different. But with this version the same effect happens. Chipselects sometimes are to short. If we generate the testdata in the FPGA and replace the phy_rx component the mashine works ok. It looks like the receiving clock from the phy_rx is making us problems in a way we do not understand. This receiving clock is generated out of the received datastream at the gigabit phy device and is connected through a DLL to the fifos write-clock. To produce the short chipselects one of my counters in the statemashine has to be reset. But a reset does not occur, because the short chipselect sometimes occured at device 1, which is the default device after reset. A reset would enlarge the chipselect. A wrong working fifo has no effect on the chipselect-signals. For the sending and receiving of data over gigabit phy we use 2 xilinx boards ML401.

???

thanks for your email

Dennis

Dennis - Can you post some of the code you use to generate the frame_ready signal? I suspect you've got a problem in how you pass the signal from one clock domain to the other, but without seeing some code it's hard to guess what's going on.

John Providenza

johnp schrieb:

Hello,

sorry for my late response, but I was not in the office for 2 days. Here the synchronization follows:

--Frame rdy counter to enlarge frame_rdy_125 (@125MHz RX-CLK) process(rxclk_in,rst_in) begin if (rst_in='1') then frame_rdy_count

Dennis -

Note that you create frame_rdy_125_ext 0 else '0'; as an combinatorial signal. Thus it may have decode glitches on it as the counter outputs change. These glitches could be caught by the 100MHz clock.

Try making frame_rdy_125_ext synchronous.

A simpler approach that does not require a counter is to simply toggle frame_rdy_125_ext each time a new frame is ready. In the

100MHz domain, synchronize the signal, then look for an edge to indicate a new frame: frame_rdy_out

Thank you for your advice. I'm running a new long time test with a glitch-free frame_rdy_out.

Dennis