Oddities of the fourteennm_simple_iopll model

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.

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

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