Distributed ram timing qurry

I have several fifos that are small and implemented as distributed ram.There are some timing violations reported on paths between source register of fifo control signals(e.g. read signal) and fifo data output.

This raised some question in my head as how timing is assessed for such fifos (or SRL for that matter). A fifo or SRL chain uses luts plus output register. Wouldn't that mean there is inherently a long path to the output register or should we say it is long but not combinatorial? Is there anyway to improve timing in such designs like fifos or SRL chains.

Regards

Kaz

--------------------------------------- Posted through

formatting link

Reply to
kaz
Loading thread data ...

What you're asking is device-related. What FPGA family are you using? Generally speaking, Xilinx devices can implement distributed memory FIFO pretty well, but you need to limit the depth of the FIFO to get it to run at high clock rates. Also there's a big difference between common-clock FIFO and independent-clock FIFO. The first kind can be implemented in SRL, the second cannot.

Also it would be good to see a full failing path from your timing report (.twr file) to see if this is a logic level issue or a routing length issue.

--
Gabor
Reply to
GaborSzakacs

It is Virtex 6 and I have achieved better than 368MHz at module level. At integration (into very large project) it fails marginally. As I said it is the path from read register to fifo data output (single clock 16 words depth, distributed ram).I don't expect any logic apart from fifo stages implemented in luts. I am just asking if there is anyway to improve such paths. I tried block ram and it failed very badly.

Kaz

--------------------------------------- Posted through

formatting link

Reply to
kaz

(snip, and previously snipped)

Do you mean that it fails, even when timing satisfies the post-route timing data?

That isn't good.

-- glen

Reply to
glen herrmannsfeldt

said

words

stages

such

No, by module level I mean when compiled on its own. The actual project is not based on any incremental approach or logic lock but all the lower modules are just added to project to be fitted freely anywhere it chooses.

Kaz

--------------------------------------- Posted through

formatting link

Reply to
kaz

(snip)

(snip, I wrote)

(snip)

I use Spartan, so it might be different.

Some years ago, I was working on a project where the pre-route timing was so good, maybe twice as fast as it needed to be, and I didn't even bother to look at the post-route timing until I tried it, and it didn't work.

At least for Spartan, the routing is optimized over the whole chip.

Well, there are things that you can do to give hints and such, but it is easily possible that changing one part changes the timing of some unrelated part.

It might be that you can route some modules, keep them fixed while you route others. That probably makes more sense in big designs.

But whatever it does, it should meet post-route timing, and you should run that to be sure that is fast enough.

-- glen

Reply to
glen herrmannsfeldt

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.