cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
19,326 Views
Registered: ‎11-03-2013

Xilinx' fifo core

Jump to solution
I'm trying to implement the FIFO I've generated in XILINX' vivado 2013.4, I'm trying to implement it with "generics" , i.e. : 
 
fifo_generator_v10_0 #( 
.C_COMMON_CLOCK(0),
.C_DATA_COUNT_WIDTH(ADDR_WIDTH),
...
) xilinx_dcfifo_i (
.rst (aclr) ,
.wr_clk (wrclk),
...
);
 
but I'm getting an error saying that:
 
[Synth 8-3438] module 'fifo_generator_1' declared at 'c:/ilinx14_fifo/project_1/project_1.srcs/sources_1/ip/fifo_generator_1/fifo_generator_1_stub.v:16' does not have any parameter 'C_COMMON_CLOCK' used as named parameter override ["C:/ilinx14_fifo/project_1/project_1.srcs/sources_1/imports/project_1/ky_cxp_dcfifo.v":80]
 
If I work without the generic part, every thing works great but I need the generic for my project and I don't what to re-generate the IP every time...
I was able to make a "work-around" by copying the entire fifo IP folder from Xilinx' folder to my project and adding the folder as a source, but now I'm getting timing errors within the generated fifo, when I try to synthesis the project(see the attached file). 
Is there any way to use the generated IP with generic or any way to solved the mentioned timing error within the FIFO?
xilinxfifo_timing_1.png
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
27,002 Views
Registered: ‎01-23-2009

That's not entirely true...

 

There are two ways that I can think of (neither of which is particularly simple)...

 

One is to give up on the Xilinx FIFO primitive, and write the entire description of the FIFO in RTL (as was proposed by a previous poster). Use a behavioral description of the underlying RAM using the language template - by writing it (properly) in RTL, the synthesis tool can infer Xilinx block RAMs (but not FIFOs). The RTL description can be paramaterizable in terms of both width and depth, which will result in the proper number and configuration of RAMB18/RAMB36 modules..

 

Then you need to describe the behavior of the read and write pointers using RTL code, and the full and empty flag generation, including any clock crossing circuitry that is necessary (if the FIFO is to be dual clocked). This is less efficient than using the built-in FIFO because you are using fabric logic instead of the built in logic for these functions.

 

The other option is to instantiate the FIFO36 primitives directly. Using generate blocks you can do the conditional and looped instantiations required to generate FIFOs for different widths and depths. You will need lots of cases (widths of 1, 2, <=4, <=9, <=18, <=36, <=72) so that you can maximize the usage of the FIFO36 (and maybe use FIFO18). To get larger FIFOs, you need to cascade them; width [edit] expansion is relatively easy, although you may have to manipulate the FULL and EMPTY flags from the different RAMs to get a combined FULL and EMPTY (particularly if the FIFO is clock crossing).

 

Avrum

View solution in original post

0 Kudos
14 Replies
Highlighted
Xilinx Employee
Xilinx Employee
19,311 Views
Registered: ‎09-20-2012

Hi,

 

You cannot pass on the generic values to the IP from top level instantiation like this. This is because the IP is pre-synthesized out-of-context and since parameters are constants, they are implemented and consumed by the tools so the stub file does not have it. 

 

If you want to do this you need to disable OOC synthesis for IP.

 

You can disable the OOC run for IP by following the below steps:

1. In the IP sources tab, right click on the IP and select "out of context" settings

2. Uncheck the IP and click on OK. Regenerate the output products. Re-run synthesis.

 

Another option is rather than passing the generic values from instantiation, recustomize the core with desired values and re-generate output products. 

 

Thanks,

Deepika.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
Highlighted
Xilinx Employee
Xilinx Employee
18,960 Views
Registered: ‎09-20-2012
@goychman

Is this issue resolved?

Thanks,
Deepika.
Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
18,921 Views
Registered: ‎08-01-2008
I would recommend to use FIFO generator core. Please configure the core as per your application , generate the core and use instantiation template to use with your design. Core also generates example design .
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
Highlighted
Guide
Guide
18,911 Views
Registered: ‎01-23-2009

One thing that is important to understand about IP cores is that they are synthesized out-of-context. This is the case regardless of whether you pre-synthesize them at the time of IP creation, or they automatically get synthesized at the time of synthesis of your top level design.

 

Therefore, for the purpose of synthesis of your top level design, the "source" of the IP is a netlist (a design checkpoint or .dcp file).

 

However, in addition to being able to generate a bitstream, you also need to be able to simulate IP. Rather than doing gate level simulations of the IP, the IP generator also generates a simulation model of the core. The file you were trying to edit (with the .C_* parameters) is merely the behavioral simulation model - it only exists when you are trying to simulate the design, and has no effect on what happens when you synthesize the design. Never change this file - doing so will only change the RTL simulation behavior and therefore make your RTL simulation behave differently than the real core in your FPGA.

 

Stepping back one step, it seems that you want to generate a paramaterizable FIFO. Unfortunately, you can't (at least not directly); the output of the IP generation process is an out-of-context synthesized netlist in the .dcp file, and hence cannot be paramaterized once it has been generated.

 

However, you can parameterize the generation. When you generate an IP from the IP catalog, you can go to the Tcl console and it will show you all the Tcl commands used to generate the IP. This set of Tcl commands is all you need to create a core from scratch. Since these are Tcl commands, you can use Tcl syntax to change them.

 

Here are the commands I get for generating a FIFO

 

create_ip -name fifo_generator -vendor xilinx.com -library ip -module_name my_core
set_property -dict [list CONFIG.Fifo_Implementation {Independent_Clocks_Builtin_FIFO} CONFIG.Performance_Options {First_Word_Fall_Through} CONFIG.Input_Data_Width {8} CONFIG.Input_Depth {2048}] [get_ips my_core]
generate_target all [get_files  c:/MyTemp/test/junk_7series_2014_1/junk_7series_2014_1.srcs/sources_1/ip/my_core/my_core.xci]
create_ip_run [get_files -of_objects [get_fileset sources_1] c:/MyTemp/test/junk_7series_2014_1/junk_7series_2014_1.srcs/sources_1/ip/my_core/my_core.xci]
launch_run  my_core_synth_1

 You can use Tcl to change the 'set_property -dict ...' command to set the properties as you need - specifically, change the Input_Data_Width and Input_Depth. You will have to be careful fo the quoting (probably changing lots of {} to "" so you can use variables in them), and you may want to go away from the -dict format - more like

 

set_property CONFIG.Fifo_Implementation {Independent_Clocks_Builtin_FIFO} [get_ips my_core]
set_property CONFIG.Performance_Options {First_Word_Fall_Through} [get_ips my_core]
set_property CONFIG.Input_Data_Width $my_fifo_width [get_ips my_core]
set_property CONFIG.Input_Depth $my_fifo_depth [get_ips my_core]

Now, each time you run your Tcl script, it will generate a FIFO with the properties you want. If you need multiple different FIFOs, you simply generate more than one with different names and different values for the set_property commands.

 

While this isn't as easy or flexible as using instantiation parameters for a generic module, it can be used to do (more or less) what you want.

 

Avrum

Tags (1)
Highlighted
Scholar
Scholar
18,906 Views
Registered: ‎09-16-2009

Avrun,

 

Thanks for the info on the behavioral sim model vs. the generated netlist.   I wondered how Xilinx was handling this.

 

Your scripts examples are good to know as well, and I'll leverage them whenever I'm forced to use Xilinx IP.

 

But, this exemplifies the mess that is involved with using Xiilnx IP.  It's truly awful.

 

From your script, the noteworthy parts: variables $my_fifo_width, and $my_fifo_depth.  What's missing is how to calculate these values.  For us it's in the verilog (or VHDL) code.  Often derived from a lot of other parameters, and not truly constant until many levels up in the hierarchy.

 

So this leaves further scripting (or something) to somehow calc these values and extract them from the code.  This may require a partial synthesis run.  And then something ugly to extract that info.

 

Now somehow make this fit into your revision control flow, and still have changes mergeable across multiple edits.

 

Now mulitply this by the tens (or hundreds!) or other Xilinx IP in your design - an unmaintainable, horrible mess.

 

And oh yea, if you're using a third party synthesis tool, you're really screwed.

 

All for something's that already has a standard clean solution that's been around for 20+ years (straight RTL).

 

Regards,

 

Mark

0 Kudos
Highlighted
Guide
Guide
18,901 Views
Registered: ‎01-23-2009

Mark,

 

Yes. I agree. It would be MUCH better to be able to paramaterize at instantiation time, rather than jump through all these hoops.

 

It is for this reason that I no longer use IP for anything that can be inferred; I always infer my block RAMs and distributed RAMs since they can be inferred and parameterized at instantiation time (you have to be careful with how you construct the RTL description, but the language templates help).

 

Unfortunately, there is currently no mechanism to infer FIFOs, so you are stuck with instantiating the primitives (FIFO18/FIFO36), or using the IP catalog.

 

One thing, though... It is possible to extract parameters from the RTL in Tcl. Module parameters become properties of the instances, which you can query with

 

get_property MY_PARAMETER [get_cells <instance_of_cell>]

 

As you alluded to, though, you need a netlist to do this. For sure, you would have the netlist after synthesis, but I think you might be able to get them after elaboration; i.e. after "synth_design -rtl" (I haven't verified this).

 

If so, then you could

 

---

synth_design -rtl; # which is relatively fast

 

set my_width [get_property FIFO_WIDTH [get_cell <cell_name>]

set my_depth [get_property FIFO_DEPTH[get_cell <cell_name>]

----

 

Then generate the IP you wanted using the commands I sent before. Then you could do the real "synth_design"....

 

There are other problems with this, though, in that when you generate a core, you generate a module not an instance. So each FIFO you use in your design would have to be an instance of a uniquely named module. You would probably have to create black-box definitions for them for the elaboration to pass, and then you would probably have to get the appropriate properties (the ones shown above) from the parent of the FIFO (not the black-box of the FIFO). Then you would probably have to remove the black-box definitions before you generate the IP cores...

 

But, again, all of this is a big pain in the ....

 

Avrum

Tags (1)
Highlighted
Scholar
Scholar
18,896 Views
Registered: ‎09-16-2009

Avrun,

 

Thanks for further info on the extracting the derived parameter names, and the noted info on the further problems the flow will have.    I'm sure I'll be forced to utilize it.

 

As to the Fifo - we just don't use Xilinx FIFOs at all.  We have our own synthesizable one, with inferred depth, width and other options. 

 

Probably takes a minor hardware hit for NOT using the dedicated Xilinx hardware.  The ease of use however trumps that little benefit...

 

Regards,

 

Mark

0 Kudos
Highlighted
Explorer
Explorer
18,847 Views
Registered: ‎11-03-2013

Hello every one,

 

This is some what helpfull, but just to be clear, there is no way to generate a FIFO in xilinx with the parameter I need, during compilation, without using tcl script (THIS IS NOT THE CASE WITH ALTERA FROM MY EXPERIENCE)?

0 Kudos
Highlighted
Guide
Guide
27,003 Views
Registered: ‎01-23-2009

That's not entirely true...

 

There are two ways that I can think of (neither of which is particularly simple)...

 

One is to give up on the Xilinx FIFO primitive, and write the entire description of the FIFO in RTL (as was proposed by a previous poster). Use a behavioral description of the underlying RAM using the language template - by writing it (properly) in RTL, the synthesis tool can infer Xilinx block RAMs (but not FIFOs). The RTL description can be paramaterizable in terms of both width and depth, which will result in the proper number and configuration of RAMB18/RAMB36 modules..

 

Then you need to describe the behavior of the read and write pointers using RTL code, and the full and empty flag generation, including any clock crossing circuitry that is necessary (if the FIFO is to be dual clocked). This is less efficient than using the built-in FIFO because you are using fabric logic instead of the built in logic for these functions.

 

The other option is to instantiate the FIFO36 primitives directly. Using generate blocks you can do the conditional and looped instantiations required to generate FIFOs for different widths and depths. You will need lots of cases (widths of 1, 2, <=4, <=9, <=18, <=36, <=72) so that you can maximize the usage of the FIFO36 (and maybe use FIFO18). To get larger FIFOs, you need to cascade them; width [edit] expansion is relatively easy, although you may have to manipulate the FULL and EMPTY flags from the different RAMs to get a combined FULL and EMPTY (particularly if the FIFO is clock crossing).

 

Avrum

View solution in original post

0 Kudos
Highlighted
Participant
Participant
3,421 Views
Registered: ‎09-11-2014

You're right. It's pitiful.  It's 2017, and there is no FIFO inference in HDL.  Why even put the things in hardware if you aren't going to have a non-archaic means of using them?  

0 Kudos
Highlighted
Participant
Participant
3,238 Views
Registered: ‎01-03-2018

Dear Xilinx, please please wake up and give a simple way of instantiating parameterised FIFOs. Yes now we are in 2018.

 

Thank you very much !

0 Kudos
Highlighted
Participant
Participant
3,230 Views
Registered: ‎01-03-2018
Is there any RTL for synchronous and asynchronous FIFOs that we could use on Xlinx FPGAs. I dont care if i am not using the dedicated FIFO blocks as long as it is simpe and reliable
0 Kudos
Highlighted
Participant
Participant
3,224 Views
Registered: ‎01-03-2018
0 Kudos
Highlighted
Moderator
Moderator
3,210 Views
Registered: ‎06-14-2010

Hello @sachinb_apt1,

 

I would suggest you to post your latest FIFO related question on the BRAM/FIFO forum board instead, as this would be the correct place for this query. Experts in this area would then be able to provide you with the required info.

 

Hope this helps. 

 

Have a nice day

Kind Regards,
Anatoli Curran,
Xilinx Technical Support
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos