1. Home
  2. Field-Programmable Gate Arrays
  3. Need info: Altera dual-port & fifo act different (func vs VITAL)

Need info: Altera dual-port & fifo act different (func vs VITAL)

I have a number of Dual-Port Rams and FIFOs that I've implemented with Quartus II 6.0 sp#1, targeting a Stratix II device.

When I simulate with my test bench in the "functional" world, everything acts as expected.

When I compile the .vho/.sdo files and run against a slightly modified test bench (differences in output file names and the test bench calling out the VITAL version of the FPGA implementation), it appears that there is an additional register delay that has been introduced into the Dual-Port/Fifo implementations.

Is this normal? Or do I need to make some type of adjustment for this behavior? I don't quite know how to explain/justify the differences at this point.

I had specified in the Megawizard setup for each of the memory types, that the output was registered -- I'd think that the functional model would work the same as the gate level implementation of the Fifos/Rams.

Reply to
Bob
Loading thread data ...

Dual clock or single clock? I'll assume from here on down that it is single clock. If it's a dual clock memory then you go down a different path (I'll discuss this at the end of the post).

Good

No

You don't justify them, you find the cause of them. The most likely explanation is that your testbench is not adhering to the setup timing of the final routed design. Check that the signals arrive at the input to the design with at least the amount of time specified in the timing report output file. If this is the problem then in essence your testbench is 'violating' the timing of the device. When that happens lots of things can go wrong, what you're seeing would be simply a symptom of that.

If timing is not being violated and this is a single clock design then you'll find that pre-route and post-route simulations match clock for clock....without exception...regardless of what the actual design is.

If you do have two clocks running around then where signals move from one clock domain to the other than the 'extra' delay that you're seeing is not unexpected and there isn't really anything that you can do about it. Just like in the real world where you can't count on two async clocks to have any phase relationship and clock domain crossing can cause an extra clock cycle delay you'll see the same thing at times when comparing pre/post-route sims.

KJ

Reply to
KJ

Hmm...

I am using a single clock. I have routed the bottom 6 bits of data (both into and out of the FIFO), along with the clock, read-enable and write enable signals.

-> On writing...both functional and gate level seem to have data aligned properly with clock and write-enable signals. No problem here.

-> On reading...gate level needs an additional clock to get data out of the FPGA.

I may not have the "exact" setup for the external control signals that control the reading from the FPGA. I'm awaiting access to the legacy board design that has an external FIFO that uses the same control lines that I'm feeding the internal one in my design (I'm creating a "superset" of the existing FPGA design).

Still running a bit confused on this. I worked with a local Arrow FAE and found that I needed to introduce a 1 ns clock delay on two of my 3 clocks (on the ones that

are derived from the "master" clock source) to eliminate my hold timing issues. I've modified both functional and gated test benches to compensate for this issue. Still don't have a clue why the legacy synchronous FIFO mode is acting different

between functional and gate level. Could someone explain this better to me?

-Bob

KJ wrote:

Reply to
Bob

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.