Forum Discussion
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_Intel4 years ago
Frequent Contributor
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