Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
12 years ago

Change bus width with a FIFO

Hello,

I have a data source of 64bit @ 156.25Mhz and wish to convert this to 32bit @ 312.5Mhz.

I create a Dual Clock FIFO with different widths, invert the 'rdempty' signal and attach it to the 'rdreq' port. This inverted 'rdempty' is also connected to a flip-flop to account for the 1 clock cycle of latency between 'rdreq' and 'rdempty', and becomes the 'data valid' for the 32bit word. The read clock is generated by a PLL from the 156.25Mhz clock.

When I try this out, I find that my improvised 'data valid' for the 32bit data does not work and I end up with more than 2x the number of input words.

I have tried removing the overflow protection and setting the megafunction to optimise for speed since my clocks are synchronised (http://www.alteraforum.com/forum/archive/index.php/t-6684.html) - but there is no change.

The extra data is predictable, which is why I think I have misused the rdempty signal in some way, but from the timing diagrams in the FIFO manual (http://www.altera.co.uk/literature/ug/ug_fifo.pdf) I cannot see why this should not work.

What have I done wrong? Is there an example showing the correct way to convert bus widths that I can use?

SJ

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Maybe not a direct answer to your question but have you considered just using a 64-bit latch with a 32-bit mux rather than a fifo? As long as your data-rate is the same you should be able to pull the data out fast enough before the slower clock writes the next 64-bit word..

    -Mux
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Assuming you're writing a 64-bit value to the FIFO on every clock edge, then 'rdempty' is only going to be active for a single clock cycle when you first power up. Once you've written data to the FIFO it will go inactive, thus making your 'data valid' active permanently from then on.

    Unless, your FIFO buffer size is very small. I can see a case whereby if you're only storing one 64-bit value before trying to read it then 'rdempty' could well go active again preventing any data from being read. I accept you've put a clock cycle delay between them but my suspicion is that may not be sufficient.

    How big did you make your FIFO? Assuming the absolute delay through the FIFO is not of great importance, I suggest you try making it relatively big (anything over a depth of 4 should do) and delaying your 'rdreq' by more clock cycles. Ensure that you are writing 'a good number' of 64-bit values to the FIFO before you attempt to read from it.

    For example: assuming a FIFO depth of 8, ensure you write at least 3 values in before you attempt to read from it. That way you're guaranteeing 'rdempty' never goes active (following the initial data being written).

    Having said all that - I have to agree with Mux. I would be implementing this without the use of a MegaWizard FIFO and doing it in discrete flip-flops. A small array (2 or 4 deep) of 64-bit wide storage, written to using a write pointer on the slower domain. Read the data out using a read pointer having first latched the write pointer across to the faster domain. This will allow you to ensure the read pointer remains 180 degrees out of phase to the write pointer, thus never reading data too early or too late.

    Regards,

    Alex