Problem with parameters when instantiating custom build component

[Altera_Forum]

Hi to all 

 I'm new here, so I hope this is the right Forum...  I have a problem with a self made IP Component. I wrote the code in VHDL and build a Custom Component out of the *.vhd with Qsys.  The component has four Parameters. In my Qsys System I added four instantianons of the Component. They should have different  Parameters. So here's the Problem. When alle the parameters are the same, the System can be generated and compiled in Quartus Prime 16.1.  When I differ only the first of the parameters Qsys generates a system_... .vhd file in the \System\synthesis folder of my project for every different instance and  i can generate and compile everything.  But when only the second, third or fourth parameter variates, Qsys generates only one system...vhd file. Generating the system works fine, but when I want to compile my project in Quartus the following message appears:  Error (10652): VHDL Assertion Statement at system_sinc_u_os_1.vhd(65): assertion is false - report "Supplied generics do not match expected generics" (FAILURE or ERROR) Error (12152): Can't elaborate user hierarchy "soc_ent:inst|System:u0|system_sinc_u_os_1:sinc_u_os_2"  Why does Qsys check only the first parameter on differences? Can i force Qsys to generate a System_...vhd for every instance of my component? Or did i do anything else wrong?  Looking forward to answers. Thanks.  Greetings

[Altera_Forum]

Weird. I presume each instance of the custom component in the Qsys system has its own unique name. 

 How did you set up the parameters in the Component Editor? They must all be set to editable. How are the parameters set up?

[Altera_Forum]

Hey,  

yes each componet has its own unique name. The parameters are all set to editable. The name, the default value and the type were automatically written from my *.vhd file while analyzing. And I haven't changed them. They have no Group. I only added a tooltip to two of them.

[Altera_Forum]

Googling the error message "Supplied generics do not match expected generics" produced this: 

 http://flink-project.ch/multiple_subdevices_with_the_same_number_of_ports  So this appears to be a problem with Qsys. The described workaround is pretty involved, but at least there is one!

[Altera_Forum]

No, you should not have to do all that. Is there any way the generics are getting overridden by something higher up in the component's hierarchy? 

 Can you post the VHDL code for the generics and maybe a screenshot of the Parameters tab in the Component Editor?

[Altera_Forum]

Hi 

 Thanks for your efforts.  @rsefton: Thanks for the link. I thought about changing the files manually before, but I really want to avoid this steps. Because they have to  de done again and again every time I regenerate the system... So I hope there is an other solution.  @ sstrell: As i see it right, there is nothing higher in the components hierarchy. Here is the generics part of the *.vhd. And I attached a picture of the parameters in the Component Editor and one where you can see how they are instantiatet in the Qsys System.     library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all;  library work; use work.SINC_pkg.all;  ----------------------------------entity--------------------------------------------------- entity APB_SINC is  generic (  MSB : integer := 16;   OSR : integer := 100;  CTRL : integer := 2;   ORDER : integer := 3 );  port (  PCLK : in std_logic;  PRESETn : in std_logic;  PENABLE : in std_logic;  PSEL : in std_logic;  PADDR : in std_logic_vector(4 downto 0);  PWRITE : in std_logic;  PWDATA : in std_logic_vector(31 downto 0);  PRDATA : out std_logic_vector(31 downto 0);  PREADY : out std_logic;  PSLVERR : out std_logic;  IOMAESDATA : in std_logic;  IOMEASCLK : in std_logic;  IOMEASVALUE : out std_logic_vector(MSB-1 downto 0)  ); end APB_SINC;  https://www.alteraforum.com/forum/attachment.php?attachmentid=13255 https://www.alteraforum.com/forum/attachment.php?attachmentid=13256

[Altera_Forum]

Hi 

Here is an update to my Problem. I build another custom component with generics. And this one works fine. I have also instantiated it a few times.  When generating the System Qsys doesn't generate those system_... .vhd files in the \System\synthesis folder of my project. It refers directly to the component within my VHDL Script. I checked all the differences between the new component that works and the older one which doesn't. But i found no mistake. I'm really in a bad end with this.   Does anyone know what triggers the generating of this system_... .vhd files in the \System\synthesis folder???  Thanks.

[spektrath]

Hi

i got a similar issue when instanciating such a component with variable signal width.

Every time a new signal width is parametrized a new  Qsys wrapper is generated by Platform Designer.

This wrapper checks all it's generics if they match the first instance of this variation.

If now an additional instance of this component is generated with the same variable signal width, but with other generics differing from the first instance, than Qsys Generation runs smoothly, but synthesis fails with exactly this error message. ("Supplied generics do not match expected generics")

Temporary work around is to don't use two instances with same variable signal width but other different parameters.

If this is not possible, then either

* manually uncomment the generic checks of the varying parameter in the generated QSys files under <Qsys system name>\synthesis\<instance_name.vhd>

* create new instance wrappers for all occuring generic variations, even with same signal interface.
  Then modify <Qsys system.vhd> by adding the lacking variations component declarations and instanciations ...
  (that is what your flink- project link does)

* make your Qsys-component not with variable width signals

* Somehow hide the variable width signal some other way from QSys ...

* Maybe it's possible to force QSYS into generating all the required instance wrappers by adding a dummy signal which changes with all parameter variations ...

* Or Maybe there's a future QSys which can better deal with this case

Hope that helps a bit.

Cheers

[FHint]

Hi,

I hope it's okay to revive this thread.
I have had the same problem and solved it by adding a dummy interface to the component whose width was controlled by an otherwise unused generic, that had to be changed from intance to instance.

I called the generic channel_id:

add_parameter channel_id integer
set_parameter_property channel_id DEFAULT_VALUE 1
set_parameter_property channel_id ALLOWED_RANGES 1:64
set_parameter_property channel_id HDL_PARAMETER true
set_parameter_property channel_id AFFECTS_ELABORATION true
set_parameter_property channel_id AFFECTS_GENERATION true

And the interface dummy:

# 
# connection point dummy
# 
add_interface dummy conduit end
set_interface_property dummy associatedClock ""
set_interface_property dummy associatedReset ""
set_interface_property dummy ENABLED false
set_interface_property dummy EXPORT_OF ""
set_interface_property dummy PORT_NAME_MAP ""
set_interface_property dummy CMSIS_SVD_VARIABLES ""
set_interface_property dummy SVD_ADDRESS_GROUP ""

add_interface_port dummy dummy_o dummy Output

As you can see the ENABLED property is set to false, so the interface is not even shown in the platform designer.
In the ellaboration callback I set the width of the output port to the channel_id:

set_port_property dummy_o WIDTH_EXPR "channel_id"

In the VHDL code of the component I added the port, too:

dummy_o : out std_logic_vector(channel_id-1 downto 0);

With these few lines added to the TCL and VHDL files there were individual instantiations created.

I hope this solution works for other users too. I used Quartus Prime 21.1 SE.

Best Regards,
Florian