FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6343 Discussions

how to ENABLE/DISABLE parts of an IP-core depending on the instance parameters??

Altera_Forum
Honored Contributor II
1,244 Views

Hi @all, 

 

if have already posted this question in the following thread: http://www.alteraforum.com/forum/showthread.php?t=40155 (post # 3) and i think it is worth starting a new thread for discussing this issue. 

 

My goal is to build a Qsys IP-Core that includes all needed component for different system configurations. the customer should see a configurable black box, which changes its behavior according to parameter settings. 

The following image should demonstrate my aim: 

https://www.alteraforum.com/forum/attachment.php?attachmentid=7286  

 

The example "configurable IP-Core" consists of a SPI-Master-bridge, a dual ported ram and a GPIO. It should be possible to choose with an instance parameter between one of the two possible configurations. Configuration A has a SPI-Master-bridge and the DPROM.Configuration B has only the GPIO.  

 

In QSYS one has the possiblity to declare so called "instance parameter" in the "instance parameter" tab and additionally it is possible to do some restricted modifications of the subcomponent within the "instance script". Restricted, because it is just possible to call the following commands in the callback function: 

 

  • get_parameters 

  • get_parameter_value 

  • get_instance_parameters 

  • get_instance_parameter_value 

  • send_message 

  • set_instance_parameter_value 

 

 

As you can see it is not possible to modify instances and interfaces within QSYS's instance script... 

(for maintaining the IP-Cores it is prefered to edit the IP-Core in QSYS, instade of the *_hw.tcl files) 

 

Currently I am about to evaluate the already mentioned "long-winding solution"(ref. to the link). 

 

I would be glad if some could help me or is discussing about the matter. 

 

with kind regards, 

MrFreshman
0 Kudos
6 Replies
Altera_Forum
Honored Contributor II
364 Views

I'd suggest this simple trick, although I'm not sure it works. 

Use distinct reset signals for the A and B blocks and export them out of Qsys core. 

In the fpga design using the core, hardwire the reset port of the component you don't want to use (let's say B), while connecting the other one (block A reset) to the true reset signal. 

This way I think the synthesizer would trim away all logic related to block B which won't be implemented, as if it had been disabled in Qsys. 

Do the opposite in case you'd like to use block A.
0 Kudos
Altera_Forum
Honored Contributor II
364 Views

You can implement what you are after using the generate callback. 

 

Qsys/SOPC builder does not handle boolean and real valued generics in VHDL, and it also did not used to handle VHDL libraries correctly (in the sense that the auto-created components could not be simulated in Modelsim due to missing library statements). To get around these issues I use the generate callback to create my own top-level instance. In your case, you can have two different HDL implementations, and pick up the one the user selects. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
364 Views

Hi, 

 

thank you for your response. 

 

@Cris72: That's a quite simple trick :) and it would work, as the synthesis tool is optimazing all unconnected components. The problem is to set these reset signals to a determindet value due to the instance parameter set. Currently I am using this kind of trick in my "long-winding solution", since I disable the interfaces of the unused components. 

 

@Dave: Fortunately I have not to simulate the IP-Cores. As I interpret your recommendation, you are using a tcl-file to describe your top-level instance, right? And the top-level consists of several filesets containing VHDL-designs and simulation information. Again these filesets will be modified in the fileset_callback procedure according to the users choice.  

 

Krgds 

MrFreshman
0 Kudos
Altera_Forum
Honored Contributor II
364 Views

 

--- Quote Start ---  

 

@Dave: Fortunately I have not to simulate the IP-Cores. As I interpret your recommendation, you are using a tcl-file to describe your top-level instance, right? And the top-level consists of several filesets containing VHDL-designs and simulation information. Again these filesets will be modified in the fileset_callback procedure according to the users choice.  

 

--- Quote End ---  

 

 

Not quite. I use the Tcl file to *create* the top-level instance.  

 

-- avs_single_port_ram_template.vhd -- library ieee; use ieee.std_logic_1164.all; entity avs_single_port_ram_template is port ( -- Reset and clock clk : in std_logic; rstN : in std_logic; -- Avalon Slave Interface avs_read : in std_logic; avs_write : in std_logic; avs_addr : in std_logic_vector(ADDR_WIDTH_MINUS_1_VAL downto 0); avs_byteen : in std_logic_vector(BYTEEN_WIDTH_MINUS_1_VAL downto 0); avs_wrdata : in std_logic_vector(DATA_WIDTH_MINUS_1_VAL downto 0); avs_rddata : out std_logic_vector(DATA_WIDTH_MINUS_1_VAL downto 0); avs_rdvalid : out std_logic; avs_wait : out std_logic ); end entity; architecture avs_wrapper of avs_single_port_ram_template is component avs_single_port_ram is generic ( ADDR_WIDTH : integer; BYTEEN_WIDTH : integer; DATA_WIDTH : integer ); port ( clk : in std_logic; rstN : in std_logic; avs_read : in std_logic; avs_write : in std_logic; avs_addr : in std_logic_vector( ADDR_WIDTH-1 downto 0); avs_byteen : in std_logic_vector(BYTEEN_WIDTH-1 downto 0); avs_wrdata : in std_logic_vector( DATA_WIDTH-1 downto 0); avs_rddata : out std_logic_vector( DATA_WIDTH-1 downto 0); avs_rdvalid : out std_logic; avs_wait : out std_logic ); end component; begin u1: component avs_single_port_ram generic map ( ADDR_WIDTH => ADDR_WIDTH_VAL, BYTEEN_WIDTH => BYTEEN_WIDTH_VAL, DATA_WIDTH => DATA_WIDTH_VAL ) port map ( clk => clk, rstN => rstN, avs_read => avs_read, avs_write => avs_write, avs_addr => avs_addr, avs_byteen => avs_byteen, avs_wrdata => avs_wrdata, avs_rddata => avs_rddata, avs_rdvalid => avs_rdvalid, avs_wait => avs_wait ); end architecture;  

 

and the Tcl file "fills in the details" using the generate call-back 

 

# -----------------------------------------------------------------# Generation# -----------------------------------------------------------------# proc generate {} { send_message info "Starting generation of the RAM" # Output file location and instance name set outlang set outdir set outname if { == 0} { send_message info "language = $outlang, file = $outdir/$outname.vhd" } else { send_message warning "This component will be generated using VHDL." } # Get the parameter values; # These parameters require the following settings above: # - AFFECTS_GENERATION true # This setting enables the calls to get_parameter_value # - HDL_PARAMETER false # This parameter suppresses a check for these generics # in the top-level generated file. Those generics are # hidden inside the top-level instance. # set params { BYTEEN_WIDTH ADDR_WIDTH DATA_WIDTH} foreach param $params { # Get the parameters from SOPC Builder set $param # Print the parameters to the generate console eval send_message info \"$param = $$param\" } # Create the 'minus 1' versions set BYTEEN_WIDTH_MINUS_1 set ADDR_WIDTH_MINUS_1 set DATA_WIDTH_MINUS_1 # Instance file generation # # - read in the template file # - use Tcl string replacement to create an instance # version of the template # - write out the template file # # Open the template file set file "avs_single_port_ram_hw_template.txt" if {} { send_message error "open $file failed" } # Read the template into a buffer set buffer close $fd # Replace the entity and architecture strings set buffer $buffer] # Replace the generic values (suffixed by _VAL in the template) set params { BYTEEN_WIDTH ADDR_WIDTH DATA_WIDTH BYTEEN_WIDTH_MINUS_1 ADDR_WIDTH_MINUS_1 DATA_WIDTH_MINUS_1} foreach param $params { eval set buffer \ \$buffer\] } # Write the instance file set file "$outdir/$outname.vhd" if {} { send_message error "open $file failed" } puts $fd $buffer close $fd # Add the generated file to the project add_file "$outdir/$outname.vhd" {SYNTHESIS SIMULATION} }  

 

I've uploaded the code. I just pulled this out of my code tree, it should work, but if I've missed a file, let me know and I'll upload a working example. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
364 Views

Hi Dave, 

 

thank you a lot for your effort and the uploaded example code. It seems quite complex, but I think I know how it works.  

In principle this version opens a template(a wrapper that instantiates the component), modifies the content, such as file name and the values of the generic parameters, and stores it again with a different name.  

 

Next week I will evaluate this suggestion and let you know if you have missed a file. 

After the evaluation I will be able to discuss about the benefits and drawbacks of this suggestion. 

 

Krgds, 

MrFreshman
0 Kudos
Altera_Forum
Honored Contributor II
364 Views

 

--- Quote Start ---  

 

In principle this version opens a template(a wrapper that instantiates the component), modifies the content, such as file name and the values of the generic parameters, and stores it again with a different name.  

 

--- Quote End ---  

 

Yep. It stores it with the name Qsys wants to see. 

 

 

--- Quote Start ---  

 

Next week I will evaluate this suggestion and let you know if you have missed a file. 

After the evaluation I will be able to discuss about the benefits and drawbacks of this suggestion. 

 

--- Quote End ---  

 

Sure, give it a try. If it doesn't work, just create your own simple component and get it working without a generate statement. Then add the generate logic. That is pretty much how I figured out how to use this feature. 

 

Cheers, 

Dave
0 Kudos
Reply