System Logic

[bae_moon]

I'm trying to implement an Asymmetrical fifo on a Virtex 6 with the following parameters:

FWFT,  Din: 512bit, Depth: 1024, Dout: 128bit, (Read depth: 4096), Program Full: 768, Program Empty: 1024, Fifo Valid, both wr_clk, and rd clk is driven by a single clock.

When I synthesize and run the design, I see that the Fifo Valid only goes high after RD_EN is issued (even though fifo program full/ empty/ full/ etc signals indicate that the data is present inside the fifo).  Also, the dout for the next rd word in the fifo shows up before the rd_en, but the data stays on after the rd_en (on the very first word), and after that point, it's 1 latency for the read.

Any idea why this would be happening?

[gszakacs]

It's not completely clear, but you seem to be describing the operation of a FWFT FIFO

just the way it is intended to be:

First-pushed data shows up on the outputs as soon as it "falls through" the FIFO.

If more than one word is in the FIFO, asserting the read enable will cause

the next word to show up on the output of the FIFO on the next rising edge of the clock.

"Valid" output indicates that the data you read on the previous cycle was not read before.

If this is not what you're seeing, perhaps you could post waveforms.

-- Gabor

[bae_moon]

The problem is that when the first data is available at the dout (empty being deasserted), valid isn't getting asserted (with no rd_en assertion since the beginning) until the rd_en is finally asserted, and that the first data remains on the dout after the first rd_en cycle (thus showing 1 cycle latency).  This is more resembles the standard fifo operation, and not how FWFT should behave according the user's guide.

I will see if I can create chip scope the fifo I/Os.  I have verified that the behavioral model seems to be working ok in the simulation, FYI.

[eteam00]

I have verified that the behavioral model seems to be working ok in the simulation

Oft-repeated word-of-mouth advice is that the Xilinx FIFOs should be simulated with the structural model, and not with the behavioural model.

From UG175 (v9.1, page 158):

Note: If independent clocks or common clocks with built-in FIFO is selected, the user must use the structural model, as the behavioral model does not support the built-in FIFO configurations.

and

The structural models are designed to provide a more accurate model of FIFO behavior at the cost of simulation time. These models will provide a closer approximation of cycle accuracy across clock domains for asynchronous FIFOs. No asynchronous FIFO model can be 100% cycle accurate as physical relationships between the clock domains, including temperature, process, and frequency relationships, affect the domain crossing indeterminately.

To generate structural models, select Structural and VHDL or Verilog in the Xilinx CORE Generator project options.

-- Bob Elkind

[rcingham]

"Oft-repeated word-of-mouth advice is that the Xilinx FIFOs should be simulated with the structural model, and not with the behavioural model."

I heartily concur.

[bae_moon]

While I would agree that the structural model would reflect the actual FPGA better, the problem I'm seeing is through chipscope, and it does not appear to be how the fifo should act when FWFT is enabled.  The behavioral model was simulated just to verify that what I read from the user's guide is acurate. 

The problem remains regardless if I simulate through structural model or behavioral model.

[gszakacs]

---

bae_moon wrote:

While I would agree that the structural model would reflect the actual FPGA better, the problem I'm seeing is through chipscope, and it does not appear to be how the fifo should act when FWFT is enabled.  The behavioral model was simulated just to verify that what I read from the user's guide is acurate. 

The problem remains regardless if I simulate through structural model or behavioral model.

---

The problem may be that your expectation of how the FIFO should work does not match the

actual FIFO design.  If you run the Structural simulation, then you can see how it should work.  If

this matches ChipScope, then you know the FIFO is working as intended, and you need to

adjust your design accordingly.  If not, there are other issues with the build.

-- Gabor

[bae_moon]

If the structural fifo matches what I'm seeing in the chipscope, then I would say the fifo generator wizard isn't working properly as I have selected FWFT, and from all I can tell, it should work like how the behavioral model is working.

Even if there were other issues with the blocks surrounding it, I can't think of any reason why Valid would get suppressed until the RD_EN is issued unless FWFT mode isn't active.  If the ISE somehow thinks that there are no block mem available for these fifos and it replaced with another mode (thus not allowing FWFT) that would explain the behavior that I'm seeing. 

[gszakacs]

The point is that you can keep on guessing why ChipScope is showing you what you see

or you can re-run simulation with the structural models.  There's no point in assuming that

the behavioral model is right just because it matches what you expect to see.  In the end,

the structural model will show what XST is attempting to build for you.  If your design doesn't

work with the structural model, you need to either find a better FIFO or find a work-around for

the actual FIFO behavior.

- Gabor