02-23-2018 05:47 AM
Suppose I instantiate a FWFT FIFO (via either XPM or IP catalog) inside my design and configure it to NOT have a registered output.
Later, in my code - I add a register to the data path of this FIFO.
Will the fitter use the dedicated FIFO register or use one from the upstream?
02-23-2018 08:19 AM
I would recommend trying it. It is fairly simple to create small dummy projects to test such questions.
02-23-2018 09:47 AM - edited 02-23-2018 09:47 AM
I'll try it - but it's not enough. What I really want to know:
"Is it GUARANTEED that the fitter will choose the best register possible even if we configured the FIFO's output to be unregistered?"
02-23-2018 10:04 AM
Your question mixes strong requirement terms: "GUARANTEED" with lose definitions: "best".
By this definition, any tool just about meets the requirements. If the tool algorithms decide it's "best" to use the fifo output data register, then it will. If the tool's algorithms decide it's "best" to instead leave the register downstream, then the tool will do that instead. The difference is simply the (undefined) definition of "best". And I'm not trying to play word games here either. There's multiple variables at play, and this is in general, a multi-variable optimization problem.
In the end, if timing is met (it could be in either case) why does it matter?
02-23-2018 11:53 AM - edited 02-23-2018 11:56 AM
I understand what you're saying...
But what if configuring the FIFO as unregistered - explicitly instructs the fitter NOT to use the register at the FIFO's output ?
Essentially dictating it to opt for a "second best" option in the form of an upstream register...is this possible?
02-23-2018 12:16 PM
Ok, I think I understand what you're looking for here.
(Caveat, I don't use the built in Xilinx Fifo's, but I do infer RAMBs which are practically the same in the context of this question).
You've generated a Xilinx Fifo (via whatever tool) and NOT selected the FIFO output register. This matches your design logic requirements.
However sometime during optimization, the tool notices a register is, infact downstream of the FIFO output, and meets the requirements to "pull in" that register to the inside of the FIFO - will the tool do so?
I believe the answer to this question is yes - the optimizer can pull it the FF if it decides to - regardless of the setting you used when you generated the FIFO. Emphasis on can, as the if the design is meeting timing already, it stops further optimizations.
The initial setting used during the fifo generation, is more like a design requirement "I need this fifo to have the single cycle of latency to work with my logic in this place". Later during optimization, moving things around, as long as it logically still meets your design intent, is fine - the tool is doing the job it is supposed to do.
I see messages about FFs being "pulled" into RAMBs all the time in my log reports.