No, not FIFOs again...

Hi Peter,

thanks for your answer. The only thing wrong with core-generator is that it's not included in the web pack ;-)

In the meantime I have bitten the bullet and implemented the FIFO myself. (I am well aware of those clock-domain crossing issues... and I do not need a complete full or complete empty-flag) It's already running in hardware.

The only thing missing is a timing-constraint to limit the skew of the gray-code-bits, when it passes from one clock-domain to the other. Or can I rely on ISE that the skew/delay of this path (from register to register, no logic between) will always be very small, as it is in the moment? BTW: How is this solved by the core-gen? Does it automatically apply these constraints?

Thomas

"Peter Alfke" schrieb im Newsbeitrag news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

"Thomas Entner" schrieb im Newsbeitrag news:4399c8c0$0$15674$ snipped-for-privacy@newsreader01.highway.telekom.at...

Hi Thomas,

the fromto inside FPGA (no logic levels) can be as much as >10ns !! if it passes local routing accross chip so if very small delays are needed the the P&R must know it

Antti

Hi Antti,

I had expected that :-(

Let's say, my critical FF's are:

signal read_cnt_gray: unsigned(8 downto 0) := (others => '0'); -- in read-clock-domain and signal read_cnt_gray_pre_sync_wr: unsigned(8 downto 0) := (others => -- in write-clock-domain

is there a way to add the timing-constraint in the VHDL-source (so that I can easily reuse the module for different designs, without always editing the ucf-file, etc.)?

Thomas

Something like NET *read_cnt_gray* MAXDELAY=3ns; perhaps?

Thomas, it only depends on your clock speed. Even the domain-crossing registers have a whole clock tick to make up their mind. With Gray-coded values, you already assume that you might unavoidably clock in a mixture of the older and the newer value, but that does not matter with Gray codes. It's either the old or the new value, never anything else. In other words, you don't have to be super-fast, as long as you meet the required (synchronous) timing constraints, determined by the clock rates.

Peter Alfke, Xilinx Applications.

Hi Peter,

your reply made me think... I assumed that with gray-codes I am safe for mismatches from one count to the next, but not if the skew between the bits is more than one complete cycle, because than two bits might be wrong instead of only one. Now I made a gray-code-table on a sheet of paper and I found no situation where even this would be "catastrophic", because even then the count is only of by 1 or 2. (But I think, it can lead to wrong or "jumping" level-indication, even when the effects in the final application are most likely of no concern.)

However, still a controlled delay between this register stages would give me a better feeling, as otherwise you never can know how long the delay of the fill-level-indicator is.

Thanks,

Thomas

"Peter Alfke" schrieb im Newsbeitrag news: snipped-for-privacy@o13g2000cwo.googlegroups.com...

Thanks for the hint,

attribute maxdelay: string; attribute maxdelay of read_cnt_gray: signal is "4ns"; -- ensure that the clock-domain-crossing-pass is short

was what I was looking for...

Thomas

"John_H" schrieb im Newsbeitrag news:1Dmmf.91$ snipped-for-privacy@news-west.eli.net...

Yes, that is a hidden danger with passing more than one bit across a clock domain. The propagation paths across the domain do have to be constrained to ensure the skew between them does not come even close to a full clock period of the faster clock domain.

Without trying to sound defensive: That's exactly what I implied by writing

"In other words, you don't have to be super-fast, as long as you meet the required (synchronous) timing constraints, determined by the clock rates."

Sloppiness that exceeds a clock period will of course always get you in trouble... Peter Alfke, from home