Oddities of the fourteennm_simple_iopll model

[roeekalinsky]

I'm trying to sort through the various atom and megafunction library representations that seem to exist for the Stratix 10 IOPLL, and encountering a variety of oddities. Please help shed some light on the following:

It appears that the primary WYSIWYG model of the physical primitive is module fourteennm_iopll found in the fourteennm atom library. That's consistent with Altera's general library organization. So far so good.

Now, the fourteennm_iopll module conditionally makes reference to a sub-module called fourteennm_simple_iopll, which appears to be a simplified and less feature rich subset of fourteennm_iopll. Ok, nice to have a simplified model that can be used where it suffices.

But the relationship of references between fourteennm_iopll and fourteennm_simple_iopll appears to be backwards. This is where the oddities begin.

Firstly, just the fact that the full featured model acts as a wrapper for the simplified model (or at least conditionally), and not the reverse.

Secondly, the fourteennm_simple_iopll module is defined in the altera_lnsim.sv library, not the fourteennm atom library. This creates a library dependency that is in the opposite direction of the norm. It makes the fourteennm atom library dependent on altera_lnsim, whereas normally the reverse is true, altera_lnsim is dependent on the various atom libraries for device-specific primitives (twentynm, etc.).

Thirdly, the fourteennm_simple_iopll module is present in altera_lnsim.sv, and can therefore be instantiated directly in a design, and does simulate properly. But in synthesis, instantiating it in a design causes Quartus to error out, complaining that design library altera_lnsim (or altera_lnsim_ver, either one) does not contain primary unit fourteennm_simple_iopll. In other words, the fourteennm_simple_iopll module exists in the altera_lnsim library provided in the Quartus install, but Quartus appears to be unaware of it.

So...

What is fourteennm_simple_iopll all about? For what purpose does it exist, and how is it meant to be used?

Is it or is it not supported for direct instantiation in a design? And if so, how, as the standard method of referring to altera_lnsim library components doesn't appear to work?

And why does it reside in the altera_lnsim library of all places? A 14nm only component residing in a pan-family library, where it logically doesn't belong, and where it creates abnormal dependencies between the libraries?

Please shed some light.

Thanks,
-Roee

[EngWei_O_Intel]

Hi Roee

I believe you are scanning through the internal modules on S10 IOPLL sim model. Taking those modules for instantiation in user design is not supported. If you are seeing issue in using "IOPLL Intel FPGA IP", please let us know.

Thanks.

[roeekalinsky]

Hi @EngWei_O_Intel, thanks for the response.

The fundamental problem with using "IOPLL Intel FPGA IP" is that the wizard-generated IP is then hard-coded for a specific configuration, not configurable via HDL generics/parameters from above. It is generated for one configuration, and has to be regenerated for any different configuration. That's fine for initial explorations or for instantiation inside a one-off design. But that's not fine, fundamentally not usable, inside designs that need to be broadly re-usable, portable, and configurable via parameters from HDL layers above.

So, yes, I'm looking at the HDL-configurable components underneath, trying to identify what HDL-configurable module I can instantiate. And at that, what I'm finding is a tangled mess of inconsistencies between a number of different models. So among what exists, please tell me which are usable. Beyond what I've already described in my original post, I see the following:

• System Verilog module fourteennm_iopll defined in fourteennm_atoms.sv: What appears to the WYSIWYG model for the primitive. Can be simulated and instantiated, but provided without documentation for its very large number of ports and configuration parameters.

• VHDL entity fourteennm_iopll defined in fourteennm_atoms.vhd: At a glance this appears to be just the VHDL equivalent of the System Verilog module of the same name. However, there are numerous inconsistencies in the configuration parameter default values between the SV and the VHDL version, leading to ambiguity as to which default parameter values are in effect in synthesis when fourteennm_iopll is instantiated in a design. Also, interestingly, the VHDL version of fourteennm_iopll does not make use of fourteennm_simple_iopll, another inconsistency between the SV and VHDL models for the same primitive.

• System Verilog module fourteennm_simple_iopll defined in altera_lnsim.sv: Described in my original post.

• Verilog module stratix10_altera_iopll defined in .../altera_iopll_1931/synth/stratix10_altera_iopll.v, a sub-module generated by the "IOPLL Intel FPGA IP": This module instantiates fourteennm_iopll, and explicitly sets many but not all of its configuration parameters (see issue above with ambiguity of conflicting default parameter values). The stratix10_altera_iopll sub-module doesn't appear to change between different configurations, and is configured via HDL parameters by the wrapper layer above. The wrapper layer above appears to be where the "IOPLL Intel FPGA IP" generator hard-codes configuration parameter values for the specific configuration that's generated, including configuration-dependent values for various undocumented configuration parameters.

• System Verilog module simple_iopll_stratix10 defined in ..../quartus/libraries/megafunctions/simple_iopll_stratix10.sv: This "megafunction" appears to be yet another variation on the theme of a simplified wrapper for fourteennm_iopll. And this one stands alone, unrelated to the "IOPLL Intel FPGA IP". Found it just by snooping around. Haven't found any supporting documentation for it, but the module appears simple enough, self-explanatory. It too explicitly sets many but not all of the fourteennm_iopll's configuration parameters, so I can only presume/hope that the defaults for omitted parameters are appropriate. Is use of the simple_iopll_stratix10 megafunction "supported"?

Thanks,

-Roee

[EngWei_O_Intel]

Hi Roee

I understand your usage wish. Since taking the submodules underneath the IP for independent usage is not supported by our team, and yes it is expected to have no publication of collateral on it, and we do not have insight on the intention of implementation of them, we are not able to comment on this. I will release this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you. 

Eng Wei

[roeekalinsky]

Hi @EngWei_O_Intel,

I understand that you won't provide documentation nor support for direct use of the WYSIWYG component or any sub-component of the wizard-generated IP. That's an unfortunate policy, but so be it.

Can you please answer my question then regarding quartus/libraries/megafunctions/simple_iopll_stratix10.sv? This module, again, is not a sub-component of the wizard-generated IP. It is a different megafunction that could potentially serve a similar purpose, and exists independently of the wizard-generated IP. So, what's the status of this megafunction simple_iopll_stratix10.sv? is it functional? Is it supported?

Please let me know.

Thanks,
-Roee

[EngWei_O_Intel]

Hi Roee

We don't recommend to individually instantiate the submodules from libraries that are not generated through Quartus IP Catalog or Platform Designer (qsys) tools. Every IP provided from Intel need to be instantiated through IP Catalog or Platform Designer tools. Beyond that we have to get in touch directly with Marketing or Engineering team for support. Thanks.