cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Anonymous
Not applicable
4,939 Views

IP-Packager: Set a parameter value according to clock frequency

I use IP-Packager for an IP-Core distributed to many customers. Inside the IP-Core I need to know the frequency of the clock connected to the "clk" port of my IP-Core because customers may connect clocks with different frequencies and I need to know the frequency of the clock to calculate some delay values.

 

How can I pass the frequency of the actually connected clock (connection made in IPI) to a parameter of my IP core?

 

Of course I could just introduce a parameter that must be set to the correct clock frequency ba the user. However, this would not only be a very ugly solution but also very error prone. Therefore I would like to do this automatically.

 

0 Kudos
5 Replies
Highlighted
Guide
Guide
4,932 Views
Registered: ‎01-23-2009

Re: IP-Packager: Set a parameter value according to clock frequency

You can't...

 

Normally, IP is synthesized "out of context" (OOC) - that means it is synthesized on its own, outside the context of the main design. So at the time of synthesis, the IP has no idea how it is going to be instantiated inside the design, and hence it cannot extract anything from the parent design.

 

The same is for parameters, IP cannot have instantiation parameters for the same reason; at the time of synthesis, the IP will be synthesized OOC, and hence will not (yet) have the default parameter inside the IP overridden by the instantiation. In fact, the tools will give a Critical Warning (or an error) if you try and use an instantiation parameter when instantiating an IP.

 

In theory, you have more flexibility for an IP that is synthesized globally (not OOC) - this is an option you can set on the IP. However, because IP can (and Xilinx recommends should) be synthesized OOC, it isn't officially supported to override parameters even when the IP is synthesized globally.

 

Avrum

Tags (2)
0 Kudos
Highlighted
Anonymous
Not applicable
4,925 Views

Re: IP-Packager: Set a parameter value according to clock frequency

Do you know why "Xilinx recomments that IP should be synthesized OOC"? As you mentioned, synthesizing IPs globally would be more flexible.

 

I also wrote "it isn't officially supported to override parameters". Does the term "not officially" mean that it is supported but not documented or that it is not supported at all?

 

And most important: If I cannot propagate the clock frequency directly, I will have to implement a parameter that users must set manually. Is there any way to automatically check if this parameter and the frequency of the actually connected clock match and throw an error/warning otherwise?

0 Kudos
Highlighted
Guide
Guide
4,906 Views
Registered: ‎01-23-2009

Re: IP-Packager: Set a parameter value according to clock frequency

Do you know why "Xilinx recomments that IP should be synthesized OOC"? As you mentioned, synthesizing IPs globally would be more flexible.

 

Not explicitly, but I suspect that it cuts down on problems with the IP (and hence less service support). When synthesized OOC, the IP is not affected by things like the synthesis options set for the project. This means that the IP doesn't have to be tested against all combinations of synthesis options - it needs only to be tested against the synthesis options used by the OOC run (which, until recently) weren't really under the control of the user.

 

I also wrote "it isn't officially supported to override parameters". Does the term "not officially" mean that it is supported but not documented or that it is not supported at all?

 

It means you aren't supposed to use it. If you decide to try and it works, then fine, but it isn't guaranteed to work, and if there are any problems with the flow you will be on your own.

 

And most important: If I cannot propagate the clock frequency directly, I will have to implement a parameter that users must set manually. Is there any way to automatically check if this parameter and the frequency of the actually connected clock match and throw an error/warning otherwise?

 

Not that I know of...

 

I can see a mechanism of checking it in your implementation script for the top level (you can get both the value of the parameter and the period of the clock using the "get_property" command), but it would be your implementation script. It might even be possible to integrate it into the tcl.pre script of the implementation process (not synthesis, since your IP is a black box at the time of synthesis), but even this is "non-standard" - you wouldn't be able to ensure that all people using this IP do the same thing.

 

Avrum

0 Kudos
Highlighted
Scholar
Scholar
4,875 Views
Registered: ‎09-16-2009

Re: IP-Packager: Set a parameter value according to clock frequency


@avrumw wrote:

Do you know why "Xilinx recomments that IP should be synthesized OOC"? As you mentioned, synthesizing IPs globally would be more flexible.

 

Not explicitly, but I suspect that it cuts down on problems with the IP (and hence less service support). When synthesized OOC, the IP is not affected by things like the synthesis options set for the project. This means that the IP doesn't have to be tested against all combinations of synthesis options - it needs only to be tested against the synthesis options used by the OOC run (which, until recently) weren't really under the control of the user.

 


We use "Global" flows almost exclusively, and regularly override parameter values of Xilinx IP.  That said, we don't use most of the Xilinx "wizards" such as IP packager, nor IP Integrator. 

 

One just needs to be careful in following the allowed values and/or ranges/etc.  Often we'll run a few example designs through the wizard to make sure we understand the parameter controls fully.

 

I still an dumbfounded that Xilinx has standardized on OOC flows for IP management.  It's like asking software folks to "share" IP by trading around assembly files.  It's just so backward-looking and a (much) lower level of abstraction.  We try and advocate wherever we can for Xilinx to stop this sillyness and just standardize (or at least allow!) a Just-The-RTL design methodology.

 

That said one needs to be careful.  For instance we add assertions to our RTL to check for illegal parameter values or out-of-range values.  This includes clock periods.  I'm not sure what sort of trouble you're having with these parameters, but they're just like any other.  As an example from our "clocks and resets" module that we've used for many years, we've got code like so:

 

generate
case( C_FAMILY )
  "virtex6": 
  begin : virtex6_mmcm_gen
    initial
    begin : v6_bad_config_check
        // http://www.xilinx.com/support/answers/38133.htm // We must throw an ERROR if REFCLK in > 315 MHz AND
        // DIVCLK_DIVIDE == ( 3 or 4 )
        if ( ( CLK_REF_PERIOD_NS < 3.175 ) && (( VCO_DIV == 3 ) || ( VCO_DIV == 4 )) )
        begin  : gen_bad_config
            $display ("DRC ERROR: clocks.v: Invalid Virtex 6 clock Config");
            $finish;
        end
    end
...

endcase
endgenerate

 

Our clock module takes the "CLK_REF_PERIOD_NS" and does some math with it, as well as a conditional to check for validity.  Note that the failure mechanism above (the error reporting and abort) worked in ISE, but needs to be changed for Vivado.

 

If you'd like more details, I'd be happy to add more.

 

Regards,

 

Mark

 

Highlighted
Scholar
Scholar
4,867 Views
Registered: ‎04-26-2012

Re: IP-Packager: Set a parameter value according to clock frequency

@markcurry "I still an dumbfounded that Xilinx has standardized on OOC flows for IP management.  It's like asking software folks to "share" IP by trading around assembly files.  It's just so backward-looking and a (much) lower level of abstraction. "

 

 Much of IP {dis}Integrator is a gigantic step backwards from either plain-old-RTL or the older ISE XPS - the crippled, bottom-up-only Vivado OOC being just one of many problems.

 

 Done properly, OOC can be useful for huge designs. XPS also built large projects out-of-context, but first PLATGEN propagated parameters down from the top, then only resynthesized those modules whose parameters had changed.

 

 Although XPS was 'clunkier' in some ways, I found it useful for auto-stitching together large designs full of AXI/AXIS stuff.

 

 XPS pcores had standard, well defined parameters for things like device family and clock frequency, which could readily be used for conditional generates and asserts in the RTL.

 

There was an entire reference manual describing all the file formats needed for XPS IP packaging, instead of the Vivado click-the-packaging-wizard-and-pray approach.

 

And don't get me started on the choice of schematic-entry-or-tcl for IPI's "high level" design entry- capturing designs in tcl is not high level design, especially when the undocumented Xilinx IP properties being scripted change every release!

 

-Brian

0 Kudos