Clock domain crossing FIFO sanity check

Question

Hi all,
   I am having an issue with producing a one clock cycle wide pulse output.  I have dealt with crossing clock domains before but I just want to make sure I am not doing anything wrong.
I have two clock domains that are mesochronous, both are 250MHz from two different external devices that are deskewed in a DCM.
I generate a 1 clock cycle wide pulse from clock domain 1 periodically.  I need this pulse to cross the domain coherently into clock domain 2 so that the period remains the same.  In other words the latency from crossing clock domains must have a a constant latency (the amount of latency does not matter as long as it is the same all the time).
I am using a coregen generated asynchronous block RAM FIFO.  The write enable is the pulse output from clock domain 1 and the empty flag of the FIFO is the output pulse (except I negate it and register the output in an IOB FF clocked with clock domain 2s clock).  The output FF is actually a FDCPE, since it is necessary on power up to send an asynchronous '1' to the device.  Once the asynchronous '1' is outputted, it is cleared and never used again.  I am guessing that an FDCPE primitive will act the same as a FF.
Here is the issue:
  On power up, if it works, it will continue to work at all temperatures for as along as the system is powered on.  If on power up it does not work, it will continue to not work for as long as the system is powered on.  I am assuming this is a power-on phase issue.  Would this have something to do with how I am crossing the clock domains or should I look elsewhere?
When I say it does not work I mean:
Clock domain 1 is from an ADC and clock domain 2 is from a device similar to a DAC.  The output of the DAC feeds back into the ADC.  When it does work, the output I create from the DAC is coherently read from the ADC.  When it does not work, it looks as if the DAC output is started at different clock cycles (multiple phase shifts).  This is why I am assuming that it is due to signal coherency, but we have used this scheme for crossing clock domains multiple times and it has always worked without any issues.
Sorry if this is not enough information.
Thanks

Answer 1

I don't entirely understand the description of the problem you are seeing - we need more context for that. But I will address the clock crossing.
I don't see anything fundamentally wrong with the clock crossing mechanism you are describing. However, it is VERY expensive for what you are using it for. In fact, even though you are using a clock crossing FIFO, you aren't actually using the storage of the FIFO - you are just using the address counters and full/empty flag generation (which is implemented in fabric logic), and completely ignoring/wasting the RAM.
There are many simple circuits for doing this clock crossing. As long as you can ensure that you will never get one pulse less than 3 (maybe even 2) after the previous one, then the circuit shown below (a toggle event synchronizer) is simple cheap and effective
This circuit takes your pulse event on the source clock domain, converts it into a toggle event, which is then synchronized through a two stage synchronizer and then edge detected in the destination domain.
You don't say what tool you are using (Vivado or ISE) - in either tool it will need some constraints.
In Vivado, you should set the ASYNC_REG property  on the two middle flip-flops
set_property ASYNC_REG TRUE [get_cells {signal_meta_reg signal_dst_reg}]
You will also need some sort of exception on the clock crossing (since all clocks in Vivado are related by default). My preferred one is
set_max_delay -datapath_only 4 -from [get_cells event_toggle_reg] -to [get_cells signal_meta_reg]
You should still use this even though both clocks are 4ns periods (so the requirement will end up being 4ns anyway) but the -datapath_only flag tells the tools not to analyze the clock insertion... Furthermore, on this synchronizer, a max_delay isn't technically needed (since there is only one signal being synchronized), so you could set the path as being false, but it is good habit to use this constraint anyway, since other synchronizers need it.
If you can't guarantee that there are 2 clocks between events, then you can use a simple Gray code counter on the source domain to count events, and send the count to the destination side, which will generate one output pulse for each count received - this is basically what the logic in the FIFO is doing, but without carrying around the useless RAM.
And, by the way, if you are going to stick to the FIFO, why not use a distributed RAM based FIFO - you won't need to waste the block RAM... If you make it 64x1, then you will only waste two LUTs for the useless RAM instead of an entire block RAM.
Not that this matters, but you say that the clocks are mesochronous - are they really? To be mesochronous, they need to derive from the same oscillator; they may go through very different paths, but they must come from the same frequency source. Merely both being 250MHz does not make them mesochronous (but, as I say, that doesn't matter for this clock crosser ).
As for the rest of it - I don't think the clock crossing is the source of your problem. Its vaguely possible that you are messing up the FIFO logic by giving it a pulse too close to the deassertion of the reset; the built-in FIFOs have a requirement that the WR_EN not be asserted within a handful of clocks after the deassertion of rst. But you say you are using the block RAM based one, which probably doesn't need this. So its probably not the clock crosser...
Avrum