cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
9,789 Views
Registered: ‎01-20-2017

Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

Hey,

 

I am struggling a little bit with Vivado and its desired design flow. I have a bigger project which I would like to port from Altera/Intel to Xilinx. In the project I am using different Altera/Intel IP-Cores like a multiply and a division core. These cores are instantiated directly with the give IP-template and I am able to automatically parameterize them in correspondence to different Generics which I can set in the top-level module. To change for example the general signal-width I have to change only one Generic in the top-level module and when I re-synthesize the design all IPs are automatically adjusted to the new width.

 

Now I am aiming for the same behavior in Vivado. Finding the right Xilinx IP-Cores was not a problem but I am unable to directly instantiate them with a template or at least somehow automatically parameterize them. Even after many hours of research I could not find how this could be done in proper way.

 

So my question is: How can I instantiate Xilinx IP-Cores directly in my design in Vivado without using the IP Catalog and the manual parametrization via the Costumize IP-GUI? And even more important: How can I parameterize the Xilinx IP-Cores in dependence of Generics like described above?

 

Thanks in advance for your help!

 

Marc

1 Solution

Accepted Solutions
Highlighted
Scholar
Scholar
12,428 Views
Registered: ‎09-16-2009

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

Actually, I can offer more specific advise.  I remembered a thread talking about how to generate the list-of-files for a certain IP (with order too):

 

https://forums.xilinx.com/t5/Synthesis/how-can-i-generate-the-file-list-of-the-IP/m-p/632499/highlight/true#M14727

 

I think you'll find that command useful - it's not complete, you'll still need to hack some, but that command helped me quite a bit.

 

Regards,

 

Mark

View solution in original post

0 Kudos
16 Replies
Highlighted
Moderator
Moderator
9,781 Views
Registered: ‎01-16-2013

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

@marcp,

 

How can I instantiate Xilinx IP-Cores directly in my design in Vivado without using the IP Catalog and the manual parametrization via the Costumize IP-GUI?

> You will need to generate the XIlinx IP core from IP catalog and use the instantiation template to include the IP in the design. Please check "Instantiating IP" at page 35 in below User guide:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/ug896-vivado-ip.pdf

 

Also one quick take video: https://www.youtube.com/watch?v=-NaRIrFSZ38

If you dont want to use the GUI to instantiate the IP from IP catalog then you can use the TCL commands to generate the IP.

 

And even more important: How can I parameterize the Xilinx IP-Cores in dependence of Generics like described above?

> You can use the TCL commands to change the parameters. Check page 80 in the same user guide.

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Guide
Guide
9,756 Views
Registered: ‎01-23-2009

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

This has come up before as a difference in philosophy between Altera and Xilinx.

 

Altera has (at least for a long time) had paramaterizable generic cores. I know they have them for memories and FIFOs, and you are now saying that they also exist for multiplications.

 

Xilinx (at least until recently) did not go down this path at all. IP cores from Xilinx are not paramaterizable - they are configured via their wizards and then instantiated as is (they are even synthesized out-of-context by default, so they cannot have instantiation parameters).

 

In Xilinx, the primary mechanism for getting access to primitives is through inference. If you need a multiplication, then you should just use the * operation and ensure there are enough pipeline stages around the * operation to get the code to map to a DSP48 cell. This is not necessarily perfect, but it works in many cases. The tools provide language templates to help you construct code that will allow proper inference (Tools -> Language Templates -> ...).

 

Xilinx just recently supplemented this with some of their new XPM_* cores (Xilinx Paramaterized Macros), which, in many ways, are similar to what Altera has. Currently, though, there are only three categories; MEMORY, FIFO and CDC (clock domain crossing). So they do not (at least yet) have them for complex mathematical operations.

 

So, you have two choices. The best is to work with inference - if you can get the tools to implement what you want through inference, you can write your own paramaterizable module - the module can be named anything you want (including, say, the name used by the Altera macros) - inside each of the modules you would have the paramaters for configuring it (which can be overridden at instantiation time) and the operations you need are implemented by inference. This is actually a pretty common approach - many people use them for memories (which are inferred pretty well).

 

The other choice is to build a separate IP core for each different instance you need. This can quickly become unmanageable though if you have a lot of different variations on the same core, although you can get some automation through Tcl (as @syedz mentions) since the core generation can be done using the Tcl interface.

 

Avrum

0 Kudos
Highlighted
Visitor
Visitor
9,742 Views
Registered: ‎01-20-2017

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

@syedz and @avrumw thanks for your comprehensive answers.

 

Now the topic is way more clear to me, although I am not very happy with the possible solutions. Inference is indeed one way to solve the general problem. But since my cores need to be highly pipelined I am not sure if I can manage that through inference. Nevertheless I will have a look on it.

 

In general I am very disappointed that, at least in me eyes, something so fundamental is so complicated to realize in Xilinx. If i had the choice, that would be definitely a reason not to work with Xilinx any more. But since I does not have the choice I can only hope that they will improve this soon (maybe with the mentioned XPM_* cores). Until then I think the Tcl script method is the only proper way to go for me.

 

Is the following flow in theory possible?

 

I create a project and add all my custom VHDL-files as well as an arbitrary instance of each IP core which I need. I adjust the Generics in the top-level module in a way I need them for the next synthesis. When I start the synthesis a custom Tcl script is started first which extracts the Generic-Values from my top-level module, adjusts the parameters of the existing IP cores accordingly and than starts a synthesis of the cores. After that the main-synthesis should continue normally and process the whole design with the new cores.

 

That would be a flow which is not exactly as easy as the flow in the Altera/Intel-World, but I would be very close to it.

 

Thank you again,

 

Marc

0 Kudos
Highlighted
Guide
Guide
9,738 Views
Registered: ‎01-23-2009

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

Is the following flow in theory possible?

 

I create a project and add all my custom VHDL-files as well as an arbitrary instance of each IP core which I need. I adjust the Generics in the top-level module in a way I need them for the next synthesis. When I start the synthesis a custom Tcl script is started first which extracts the Generic-Values from my top-level module, adjusts the parameters of the existing IP cores accordingly and than starts a synthesis of the cores. After that the main-synthesis should continue normally and process the whole design with the new cores.

 

In a nutshell, no.

 

There is no point in having an "arbitrary" example of any core. To use the Tcl interface, you really need to use the Tcl commands to create a new IP for each customization of each type of core that you want.

 

You have to realize that for IP cores, each "instance" needs to have a unique module name - these are not customizations of one module, but each one is a different module. 

 

 

Here is an example of the Tcl commands to generate a new RAM module. This RAM module is named "blk_mem_gen_0" and is an IP of type "blk_mem_gen". 

 

 

create_ip -name blk_mem_gen -vendor xilinx.com -library ip -version 8.3 -module_name blk_mem_gen_0 -dir c:/training/golden/labs/Vivado/wave_gen/KC705/verilog/wave_gen.srcs/sources_1/ip
set_property -dict [list CONFIG.Memory_Type {True_Dual_Port_RAM} CONFIG.Use_Byte_Write_Enable {true} CONFIG.Byte_Size {8} CONFIG.Write_Width_A {32} CONFIG.Write_Depth_A {512} CONFIG.Operating_Mode_A {READ_FIRST} CONFIG.Enable_A {Always_Enabled} CONFIG.Write_Width_B {8} CONFIG.Operating_Mode_B {READ_FIRST} CONFIG.Enable_B {Always_Enabled} CONFIG.Register_PortA_Output_of_Memory_Primitives {false} CONFIG.Register_PortB_Output_of_Memory_Primitives {false} CONFIG.Read_Width_A {32} CONFIG.Read_Width_B {8} CONFIG.Port_B_Clock {100} CONFIG.Port_B_Write_Rate {50} CONFIG.Port_B_Enable_Rate {100}] [get_ips blk_mem_gen_0]
generate_target {instantiation_template} [get_files c:/training/golden/labs/Vivado/wave_gen/KC705/verilog/wave_gen.srcs/sources_1/ip/blk_mem_gen_0/blk_mem_gen_0.xci]

The first command (create_ip) creates the IP object.

 

The second command sets all the properties on the object. These are currently done in "dictionary" format, but could be done with individual set_property_commands. You can see that the things you might want to customize (width, depth, etc...) are all properties of the core.

 

The third command actually starts the generation process

 

These commands could be put in a loop with variables controlling the name of the generated core and any other parameters you want to set. Once done, you would have cores for all the different varieties of RAMs.

 

But, this is cumbersome. Each of these cores becomes different runs that need to be synthesized as part of your main project synthesis (which takes time), and there is lots of stuff generated on disk for each one. For a RAM, I wouldn't do this, since it is easier to infer...

 

As for extracting the required values from the RTL code - that would be extremely hard to do...

 

 

 

With proper naming conventions and some really wild scripting that reads in the RTL code, finds the modules/instances (by text matching), extracting the module name and the instantiation parameters, you could then populate what you need in the Tcl script. You could then create the modules you need. But again, in your RTL, each instantiation would need to use a unique module name - one that could be created by the Tcl with the correct values for the properties...

 

Tt is also unclear where you would run this Tcl script (that extracts the parameters and builds the cores). This script would need to be run every time you change any of the RTL instantiations. One option would be to blow them away each time you want to start synthesis and recreate them all from scratch. Or you might be able to do something along the lines of "if this already exists then skip it, but that's more complex - particularly if you need it to recognize that a parameter has changed. Whichever way you go, this will take a fair bit of compute time to do. It's also messy and completely tied to your own coding style.

 

Furthermore, doing it in the tcl.pre for synthesis would result in your synthesis being declared out of date each time you do it - basically it would break the dependency management stuff in Vivado project mode.

 

All told, it's almost certainly not a good way to go...

 

As for being disappointed that this Altera flow doesn't work in Xilinx, that's natural - we always want what we are used to... Like everything, there are pros and cons to each vendor's solutions - trust me, you get the same emotions going the other way around. I hope that Xilinx does continue with the XPM stuff and extend it to other areas - I have seen this being a pretty emotional hot-button for people switching from Altera before...

 

Avrum

0 Kudos
Highlighted
Visitor
Visitor
9,711 Views
Registered: ‎01-20-2017

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

@avrumw thanks again for your perfect answer! Really really good support here!

 

I think I was not entirely clear about what I wanted to do: The idea was not to create one instance of each core type that I need but to create one core-instance for every position in the design where some external IP is required. So if for example 6 multipliers are used in my whole design, I would create 6 instances of a multiplier core, all having already a unique name by which they are addressed in my custom VHDL code. So in the end the idea is to have a working design with all the needed cores in a default configuration, which should be changed as soon as I change some Generics. My plan for the core-update was to use exactly the Tcl commands you stated without the first one for the creation.

 

But that indeed would not affect the other points you mentioned. The problems of extracting the parameters from the VHDL-files and where the script could be started remain. Also the long synthesis time would be problematic.

 

So in the end I totally agree with you that the suggested flow is not a good way to solve my problems.

 

But then the question arises: What is a good way to solve my problem? Assuming that the inference concept would not work because of high pipelining demands, what is the suggested flow of Xilinx in such a case? I see that Tcl commands or scripts can be utilized somehow. But at the moment I see no clear way to integrate them into an easy-to-use and an easy manageable flow.

 

Thank you again,

 

Marc

0 Kudos
Highlighted
Guide
Guide
9,685 Views
Registered: ‎01-23-2009

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

I suggest you try inference first. You can do a lot more than you think with generate statements and inference - I have successfully in the past controlled pipelining with parameters; I used a generate statement which either connected two things together with a wire or a pipeline stage based on the value of the parameter/generic controlling the 'generate if'. I am not saying this is definitely the way to go, nor that it is trivial to do, but a lot of things are possible.

 

Furthermore, since you are talking about multiplication as the basic operation you are concerned about, you are probably going to end up using the DSP48 cells. These cells can run blindingly fast (500+MHz) as long as you code for "enough" pipelining (3 for a single DSP48, potentially more if you are cascading). The tools are also quite good at mapping pipelined mathematical operations into the DSP48.

 

If that doesn't work, then we can look at other options, but this is going to be (by far) the best solution if it works.

 

Avrum

0 Kudos
Highlighted
Scholar
Scholar
9,683 Views
Registered: ‎09-16-2009

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

marcp wrote:

So my question is: How can I instantiate Xilinx IP-Cores directly in my design in Vivado without using the IP Catalog and the manual parametrization via the Costumize IP-GUI? And even more important: How can I parameterize the Xilinx IP-Cores in dependence of Generics like described above?

 


Marc,

 

I haven't followed everything you've tried, but I'll reiterate others advice.  The first step is try hard to use inference.  That's the easiest solution.  Xilinx has synthesis guides for how to infer common operations.  The second step, is to use what XPMs Xilinx does offer.  Xilinx only went after the low hanging fruit here, and only offers XPM versions of few of their IP cores.

 

Lacking that, it's not hard to look at the output of whatever Xilinx Wizard, and get at the underlying parameterized RTL. I disagree with Avrum's assessment of a Xilinx versus Altera IP strategy.  It's Xilinx vs everyone else.  Xilinx has a really skewed view of IP management.

 

Xilinx IP designs are typically done just as everyone else in the industry does it.  Parameterized designs, with pretty good documentation, using industry standard principles, and methodologies.  Now none of it is perfect (no design is), but for just about everything I've looked at, decent.

 

But unfortunately, for whatever reasons, Xilinx prefers to hide this parameterized IP beneath mounds of cluttered, non-standard, revision control unfriendly, hard tied to the tool version,  wizards and other "schematic capture" like flows.  And then make these klunky flows the only "officially" supported flows. 

 

So what do we do?  We run whatever "wizard of the day" Xilinx has (be sure to never use OOC - always select Global generation), to generate one example IP instance.  We examine the output files, and pick out the underlying RTL.  We might run more than one example to see what it's doing with parameterization. Typically (like over 90% of the time), this is just changing a value entered into a GUI dialog box into a parameter assignment in the resulting code.  We just change these back to a real parameter exposed at the top-level IP.

 

We don't typically "expose" every parameter - just those we'd like to control.  And to be clear, we don't modify any of the Xilinx IP output files. Typically, the tools generate a "wrapper" level or "Example" design of some sort.  We take those generated wrappers, and use those as reference for our own wrappers (with parameters).  All underlying IP is untouched.

 

All the RTL (unmodified Xilinx IP), and our wrappers/etc are checked into revision control.  All the "wizard" junk is thrown away.

 

This effort takes a little upfront time.  But pays off greatly down the road for us.  If you're interested in more info, I can fill in more details and/or examples.

 

Regards,

 

Mark

 

Highlighted
Guide
Guide
9,670 Views
Registered: ‎01-23-2009

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

Mark (not Marc!),

 

The flow you are describing (while completely non-standard and will give any Xilinx FAE a heart attack - they don't even want you to use Global synthesis!) sounds like a reasonable approach for at least some cores. I have done similar things for some of the simpler cores (things like the clock wizard, for example).

 

However, for some other cores, this probably won't work. For example, the multiplier wizard (I am pretty sure) generates completely different pieces of code (instantiating different numbers of DSP48 cells with different connections and configurations) depending on the values you specify in the Multiplier Wizard. It doesn't use parameters and loops (like some others do). So, I don't think this will work for the case in question (which started as a discussion about multipliers...)

 

But, at least in principle, I agree (and we are also agreeing). When possible, "something else" is preferable to the IP stuff - inference, direct primitive instantiation, etc... In some cases, you can use the RTL generated by an IP wizard as you do (since many do generate parameterized synthesizable code), in others simply using the generated RTL as a template.

 

Of course, this discussion only applies to stuff that you plan to instantiate in your RTL design. If you are using the IP integrator, you must use the IP cores...

 

Avrum

0 Kudos
Highlighted
Scholar
Scholar
9,628 Views
Registered: ‎09-16-2009

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

@avrumw wrote:

Mark (not Marc!),

 

The flow you are describing (while completely non-standard and will give any Xilinx FAE a heart attack - they don't even want you to use Global synthesis!) sounds like a reasonable approach for at least some cores. I have done similar things for some of the simpler cores (things like the clock wizard, for example).



Avrum,

 

We've come to a pretty good understanding with our FAE and other support team as to how we need to use vendor IP.  However, your points are all valid - Xilinx doesn't approve of these flows, and in fact tries to hide that it's even possible.  Which just goes to emphasize the absurdity of the Xilinx "default" flows even more.  All this nonsense and reverse engineering, to enable ... regular, industry standard RTL design.  A lot of duplicated work (from both Xilinx, and their customers) would be avoided if Xilinx just embraced industry standard methodologies.

 

Regards,

 

Mark

0 Kudos
Highlighted
Visitor
Visitor
7,260 Views
Registered: ‎01-20-2017

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

@avrumw and @markcurry (great name by the way ;)), thank you very much for your answers!

 

I am glad to hear, that I am not the only one who is struggling with the official design flows of Xilinx and who thinks that the IP-management is kind of wired.

 

As you both suggested I had a look on the inference possibilities and it already worked good for some of the IPs in my design. For the rest I will also try it, but I am sure that I will come to a point where I have to switch to another solution for the remaining IPs.

 


@markcurry wrote:

So what do we do?  We run whatever "wizard of the day" Xilinx has (be sure to never use OOC - always select Global generation), to generate one example IP instance.  We examine the output files, and pick out the underlying RTL.  We might run more than one example to see what it's doing with parameterization. Typically (like over 90% of the time), this is just changing a value entered into a GUI dialog box into a parameter assignment in the resulting code.  We just change these back to a real parameter exposed at the top-level IP.

 

We don't typically "expose" every parameter - just those we'd like to control.  And to be clear, we don't modify any of the Xilinx IP output files. Typically, the tools generate a "wrapper" level or "Example" design of some sort.  We take those generated wrappers, and use those as reference for our own wrappers (with parameters).  All underlying IP is untouched.

 

All the RTL (unmodified Xilinx IP), and our wrappers/etc are checked into revision control.  All the "wizard" junk is thrown away.

 

This effort takes a little upfront time.  But pays off greatly down the road for us.  If you're interested in more info, I can fill in more details and/or examples.


 

Even before I posted my initial post here in the forum I have tried exactly the flow you are describing (because it is very close to the Altera flow I was using). The problem was that as soon as I had written my own wrapper, of course including the needed library for the certain IP-Core (I have tested it with the multiply core so the library was mult_gen_v12_0_12), the synthesis/implementation failed. It seems that the library is missing. The exact error output from Vivado was:

 

[Project 1-486] Could not resolve non-primitive black box cell 'mult_gen_v12_0_12' instantiated as 'U0' ["[...]MultiplierCoreWrapper.vhd":85] <- This is where the multiplier is instantiated inside the wrapper.

 

[DRC INBB-3] Black Box Instances: Cell 'U0' of type 'U0/mult_gen_v12_0_12' has undefined contents and is considered a black box.  The contents of this cell must be defined for opt_design to complete successfully.

 

This is even the case when I use the wizard to add an instance of the same IP to project. The automatically generated wrapper than looks exactly the same as mine and it includes the same library. Since the generated IP is working (of course) the library has to be somewhere in the project. But my self written wrapper is still not working. It seems that Vivado somehow tracks, if the files are generated by the wizard or by yourself and based on that sometimes does not provide "access" to all resource in the project (like the library).

To solve this problem I went deep in the Vivado folders searching for the "raw" library and I was able to find it. But after manually including and adjusting it (by changing the "Library"-property to the right name) the synthesis is failing again. This time with some decryption-problem:

 

[Synth 8-5809] Error generated from encrypted envelope. ["C:/Xilinx/Vivado/2017.1/data/ip/xilinx/mult_gen_v12_0/hdl/mult_gen_v12_0_vh_rfs.vhd":241]

 

Mark, did you discover the same problems? Could you maybe elaborate a little more on how you are getting your wrappers to work properly?

 

Thank you, best regards,

 

Marc

0 Kudos
Highlighted
Scholar
Scholar
7,240 Views
Registered: ‎09-16-2009

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

Marc,

 

You're initial error was just the missing reference to mult_gen_v12_0_12.  Sounds like you found the source file to that, and included it, but now are running into the (insert vulgarity here) "Error generated from encrypted envelope" message.  There's nothing wrong with the decryption, it's an underlying problem.

 

Sigh.  We deal with these on at least a weekly basis.  They are a another wonderful (that's sarcasm btw) feature of some modern Xilinx designs, that cause too much grief.  With the release of the IEEE standard for encryption, Xilinx has a new hammer, and every problem looks like a nail.  When it was first released, Xilinx had a tendency to '"encrypt everything" because why not?: Why shouldn't we encrypt a model for a multiplier?  Must be lots of cutting edge stuff in there... They're realizing that this is not without it's cost, and I think is starting to rethink the "encrypt everything" mindset. 

 

In any case you have some basic syntax/sematic error in that core file.  It's likely a compile order problem - the (encrypted) library is referencing another library, that you've not compiled yet.  Or just is compiled in the wrong order.  Or an include file can't be found. Or a ".mif" that needs to be read in can't be found. Or...

 

In any case, it's something minor and easily fixed...If you had access to the unencrypted source, or a more precise error message.  You'd be able to figure out the problem in seconds. 

 

But absent that, you're left to fumble around in the dark for days, and maybe involve Xilinx support.  Great use of everyone's time right?

 

I suggest trying to export example simulation and/or testbenches from whatever wizard you used.  Try and figure out the required list of files, and compile order, for the IP you're using.  Play around with it is about the only tool you've got.

 

Sorry can't offer much more precise advice. 

 

Regards,

 

Mark

0 Kudos
Highlighted
Scholar
Scholar
12,429 Views
Registered: ‎09-16-2009

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

Actually, I can offer more specific advise.  I remembered a thread talking about how to generate the list-of-files for a certain IP (with order too):

 

https://forums.xilinx.com/t5/Synthesis/how-can-i-generate-the-file-list-of-the-IP/m-p/632499/highlight/true#M14727

 

I think you'll find that command useful - it's not complete, you'll still need to hack some, but that command helped me quite a bit.

 

Regards,

 

Mark

View solution in original post

0 Kudos
Highlighted
Visitor
Visitor
7,209 Views
Registered: ‎01-20-2017

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

Mark,

 

thank you very very much!! That was the solution!!

 

With the help of the command (from the link you provided) I was able to discover all library dependencies for the different IP cores as well es the desired compile order. After including the missing libraries and changing the "Library"-Property of each library to right name my self written wrappers started to work. Even though it was a lot of fumbling around and trail and error to find the libraries, renaming them right and to figure out which generic is responsible for what, I am now very happy that it is finally working.

 

Regarding your whole opinion on the current policies of Xilinx and their strange work flows I totally agree with you! I have no clue whats the idea of Xilinx behind this massive obstructions for the designers. As you said right, it only costs time, which nowadays nobody has anymore... I now finally have a solution, or lets better call it a work-around, for my problem. But in the end it took me over week to create a few dynamically configurable IP-cores. When I initially implemented my design on Altera the same work took me about an hour. I can only hope the guys at Xilinx rethink their strategies soon because otherwise they maybe will loose a lot of costumers which are switching to others vendors. Vendors which are caring more about meaningful design flows.

 

Thank you again! It was a really great support!

 

(In this case it would make sense to mark your last two answers as "accepted solution". But unfortunately I can mark only one, so will select your answer with the link because it was final break-through.)

 

Best regards,

 

Marc

 

 

Highlighted
Participant
Participant
5,929 Views
Registered: ‎01-03-2018

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

@avrumm "Currently, though, there are only three categories; MEMORY, FIFO and CDC".... Isnt this incorrect. The XPM*cores dont have FIFOs. Please correct me if i am wrong

0 Kudos
Highlighted
Participant
Participant
5,927 Views
Registered: ‎01-03-2018

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

Sorry About that. It seems i was looking at an older document that didnt have FIFO in XPM*cores list.

I had to google xilinx ug974 2018 2017 to reach the latest guide which had them. Google ug974 shows up 2016 link.

 

 

 

0 Kudos
Highlighted
Contributor
Contributor
1,694 Views
Registered: ‎12-11-2007

Re: Direct instantiation and parameterization of Xilinx IP-Cores in Vivado

Jump to solution

It's nearly 4th quarter of 2019 now.  Has Xilinx made any changes in this area to help the designers with direct instantiation of Xilinx IP cores instead of going through all of the above cumberstome steps when having to modify IP parameters?  I have a design that requires many parameterized data width instances of AXI IP blocks that are not of the inferrable type such as AXI4 Stream NxM switches and data width converters so inference is not really an option for these.  Another aspect of the IP Generator in need of an overhaul is providing it with support for generating SystemVerilog code.  SV's interface feature would greatly simplify IP core instantiations in higher level RTL. 

0 Kudos