Implementation
This section covers the implementation of XML input descriptions and how they relate to end-user host design integration.
Attention
This example, assumes that BUS_LINK_LIB=axi4_lib, using the XML2VHDL
--bus_library "axi4_lib" argument at generation time.
Register Maps
<?xml version="1.0" encoding="ISO-8859-1"?>
<node id="REGISTERMAP_XML_NODENAME">
<node id="FULL_RW_REGISTER" address="0x0" mask="0xFFFFFFFF" permission="rw" description="A 32 bit read/write register."/>
<node id="MASKED_REGISTER" address="0x4" mask="0xFFFFF" permission="rw" description="A masked, 20 bit, read/write register."/>
<node id="FULL_RD_REGISTER" address="0x8" mask="0xFFFFFFFF" permission="r" description="A 32 bit read-only register"/>
<node id="FULL_WR_REGISTER" address="0xc" mask="0xFFFFFFFF" permission="w" description="A 32 bit write-only register"/>
<node id="BITFIELD_REGISTER" address="0x10" description="A bit-field register." >
<node id="ONE_RW_BITFIELD" mask="0x00000001" permission="rw" description="A single read/write bit in a bit-field register."/>
<node id="ONE_RD_BITFIELD" mask="0x00000002" permission="r" description="A single read-only bit in a bit-field register."/>
<node id="ONE_WR_BITFIELD" mask="0x00000004" permission="w" description="A single write-only bit in a bit-field register."/>
<node id="ONE_RW_BYTEFIELD" mask="0x0000FF00" permission="rw" description="A single read/write byte in a bit-field register."/>
<node id="ONE_RD_BYTEFIELD" mask="0x00FF0000" permission="r" description="A single read-only byte in a bit-field register."/>
<node id="ONE_WR_BYTEFIELD" mask="0xFF000000" permission="w" description="A single write-only byte in a bit-field register."/>
</node>
</node>
Considering the above XML description of a collection of registers, defined in
a XML file named: XML_FILENAME_memory_map.xml.
The top-level node is assigned the name REGISTERMAP_XML_NODENAME via the id= attribute.
This name is applied to abstract away the actual memory-mapped addresses by allowing
associated Software to reference via ID, without the end-user needing to
keep track of the assigned base-address - which may well change once the complete
memory-map of the final system has been generated.
In terms of the tree structure hierarchy, the top-level node representing the XML description is classed as the parent node. First-level nodes (without their own child nodes) are defining registers. The remaining nodes, which do have child nodes are further breaking down the register to provide second-level bit-field descriptions.
Note
With no knowledge of how this XML input file connects to memory-maps above this this description (i.e. whether this connects to, and is linked to an Interconnect description). The top-level and first-level have the same meaning. This demotes the first-level child node to the second-level and the second-level to third-level descriptions - in keeping with the levels described in the Hierarchical Tree Structure section.
The description attribute for each node is used to describe its own attribute
values. See Register Maps for more details on each attribute.
Note
The _BITFIELD nodes produce an additional hierarchical level as described
above and in the Hierarchical Tree Structure section.
VHDL Output
Package File Entries
The above XML input example description will result in the following
VHDL record types to be generated in the axi4lite_REGISTERMAP_XML_NODENAME_pkg.vhd
package file.
-- Register Records
type t_axi4lite_REGISTERMAP_XML_NODENAME_BITFIELD_REGISTER is record
ONE_RW_BITFIELD : std_logic;
ONE_RD_BITFIELD : std_logic;
ONE_WR_BITFIELD : std_logic;
ONE_RW_BYTEFIELD : std_logic_vector(7 downto 0);
ONE_RD_BYTEFIELD : std_logic_vector(7 downto 0);
ONE_WR_BYTEFIELD : std_logic_vector(7 downto 0);
end record;
type t_axi4lite_REGISTERMAP_XML_NODENAME is record
FULL_RW_REGISTER : std_logic_vector(31 downto 0);
MASKED_REGISTER : std_logic_vector(19 downto 0);
FULL_RD_REGISTER : std_logic_vector(31 downto 0);
FULL_WR_REGISTER : std_logic_vector(31 downto 0);
BITFIELD_REGISTER : t_axi4lite_REGISTERMAP_XML_NODENAME_BITFIELD_REGISTER;
end record;
-- Register Decoded Records
type t_axi4lite_REGISTERMAP_XML_NODENAME_BITFIELD_REGISTER_decoded is record
ONE_RW_BITFIELD : std_logic;
ONE_RD_BITFIELD : std_logic;
ONE_WR_BITFIELD : std_logic;
ONE_RW_BYTEFIELD : std_logic;
ONE_RD_BYTEFIELD : std_logic;
ONE_WR_BYTEFIELD : std_logic;
end record;
type t_axi4lite_REGISTERMAP_XML_NODENAME_decoded is record
FULL_RW_REGISTER : std_logic;
MASKED_REGISTER : std_logic;
FULL_RD_REGISTER : std_logic;
FULL_WR_REGISTER : std_logic;
BITFIELD_REGISTER : t_axi4lite_REGISTERMAP_XML_NODENAME_BITFIELD_REGISTER_decoded;
end record;
These record structures allow the generated register map references to be referenced,
and connected to the end-user host design using VHDL record notation
based on signal names related to register and/or node id= attribute values
given in the original XML input file. This improves VHDL file
readability and provides context to register names and bit-fields.
In this example, two records are defined, one for each level of hierarchy
(second-level and third-level). The first two records directly map to the
register descriptions - where the std_logic_vector width is determined
from the mask= attribute (a width of 1 will result in a std_logic).
It can be seen that third-level bit-field description record types are defined
before they are referenced at the second-level.
An additional set of records suffixed with _decoded are also generated. It
should be noted that these are all single bit std_logic types and are used
in the end-user host design to either indicate the Bus-side has modified a
value, or by the Logic-side to assert write enable signals to control when the
end-user host design modifies these register or child bit-field entries.
Note
Using these generated VHDL record structures allows for a layer of abstraction between the registers described in the XML input files and those as they appear in the end-user host design. By developing control and support software inline with FPGA Firmware, this ensures changes in register address locations do not require changes to the underlying end-user host design. This including adding new registers/registers as signals interfacing with the resulting VHDL entity DO NOT change.
Caution
The above abstraction DOES NOT account for major changes, like renaming
registers/registers with child bit-fields node links via their id=
attributes; and/or register/child bit-field removal. This will change the
record types and their expansion to end-user host design logic.
Top-level Component
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
library axi4_lib;
use axi4_lib.axi4lite_pkg.all;
library XML_LINK_LIB;
use XML_LINK_LIB.axi4lite_REGISTERMAP_XML_NODENAME_pkg.all;
entity axi4lite_REGISTERMAP_XML_NODENAME is
port(
axi4lite_aclk : in std_logic;
axi4lite_aresetn : in std_logic;
axi4lite_mosi : in t_axi4lite_mosi;
axi4lite_miso : out t_axi4lite_miso;
axi4lite_REGISTERMAP_XML_NODENAME_in_we : in t_axi4lite_REGISTERMAP_XML_NODENAME_decoded;
axi4lite_REGISTERMAP_XML_NODENAME_in : in t_axi4lite_REGISTERMAP_XML_NODENAME;
axi4lite_REGISTERMAP_XML_NODENAME_out_we : out t_axi4lite_REGISTERMAP_XML_NODENAME_decoded;
axi4lite_REGISTERMAP_XML_NODENAME_out : out t_axi4lite_REGISTERMAP_XML_NODENAME
);
end entity;
The above XML input example description will result in the following
VHDL entity/architecture (component) to be generated in the
axi4lite_REGISTERMAP_XML_NODENAME.vhd file.
Standard ports include an AXI4-Lite interface, including a clock and
active-low reset. The axi4lite_mosi and axi4lite_miso types are declared
in the externally provided axi4_lib.axi4lite_pkg.vhd package file.
The other signals types are defined in the XML2VHDL generated package file,
described above.
Attention
Currently, axi4lite_pkg.vhd IS NOT provided with XML2VHDL. See
VHDL libraries.
The end-user does not need to worry about the inner workings of this generated entity/architecture (component). It just needs to be integrated with the end-user host design, by creating an instance of this VHDL component (using the entity instantiation method). The end-user also needs to declare and connect these ports to/from the host design. Once the component is integrated into the end-user host design, it can remain untouched. with the corresponding VHDL record types being expended to connect to the end-user host design as required.
Caution
The expanded VHDL records can only remain untouched in the
end-user host design if NO major changes, like renaming
registers/registers with child bit-fields node links via their id=
attributes; and/or register/child bit-field removal. This will change the
record types and their expansion to end-user host design logic.
End-user host designs can interface with generated register/register child bit-fields from the Logic-side, by connecting to the expanded record entry, to perform reads:
No additional FPGA resources are required as it’s just a wire connected to a signal. The Logic-side ALWAYS has read access to the instantaneous value of the output port
axi4lite_REGISTERMAP_XML_NODENAME_out.The end-user host design is able to monitor Bus-side writes using the corresponding
axi4lite_REGISTERMAP_XML_NODENAME_out_werecord entry. This will be asserted for a single clock-cycle whenever the Bus-side writes to this location.
For writing to registers/child bit-fields, the Logic-side needs to consider:
if the
hw_permissions=node attribute is omitted or sethw_permissions=""no", the portsaxi4lite_REGISTERMAP_XML_NODENAME_inandaxi4lite_REGISTERMAP_XML_NODENAME_in_wewill not be generated.To perform a write, if
hw_permissions="w", then the end-user host design can immediately write values directly using the input portaxi4lite_REGISTERMAP_XML_NODENAME_in; orIf using
hw_permissions="we", in addition to presenting the write data onaxi4lite_REGISTERMAP_XML_NODENAME_in, the correspondingaxi4lite_REGISTERMAP_XML_NODENAME_in_werecord entry needs to be asserted for a single clock-cycle.
Example Instantiation
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
-- doclibstart
library axi4_lib;
use axi4_lib.axi4lite_pkg.all;
library XML_LINK_LIB;
use XML_LINK_LIB.axi4lite_REGISTERMAP_XML_NODENAME_pkg.all;
-- doclibend
entity axi4lite_REGISTERMAP_XML_NODENAME_example is
port(
-- AXI4Lite Bus Signals
axi4lite_aclk : in std_logic;
axi4lite_aresetn : in std_logic;
axi4lite_mosi : in t_axi4lite_mosi;
axi4lite_miso : out t_axi4lite_miso;
--
FULL_RW_REGISTER_in : in std_logic_vector(31 downto 0);
MASKED_REGISTER_in : in std_logic_vector(19 downto 0);
FULL_WR_REGISTER_in : in std_logic_vector(31 downto 0);
ONE_RW_BITFIELD_in : in std_logic;
ONE_RW_BYTEFIELD_in : in std_logic_vector(7 downto 0);
FULL_RW_REGISTER_out : out std_logic_vector(31 downto 0);
MASKED_REGISTER_out : out std_logic_vector(19 downto 0);
FULL_RD_REGISTER_out : out std_logic_vector(31 downto 0);
ONE_RW_BITFIELD_out : out std_logic;
ONE_RW_BYTEFIELD_out : out std_logic_vector(7 downto 0)
);
end entity axi4lite_REGISTERMAP_XML_NODENAME_example;
architecture struct of axi4lite_REGISTERMAP_XML_NODENAME_example is
-- docsignalstart
-- Signal declarations: ----------------------------------------------------
signal axi4lite_REGISTERMAP_XML_NODENAME_in_we : t_axi4lite_REGISTERMAP_XML_NODENAME_decoded;
signal axi4lite_REGISTERMAP_XML_NODENAME_in : t_axi4lite_REGISTERMAP_XML_NODENAME;
signal axi4lite_REGISTERMAP_XML_NODENAME_out_we : t_axi4lite_REGISTERMAP_XML_NODENAME_decoded;
signal axi4lite_REGISTERMAP_XML_NODENAME_out : t_axi4lite_REGISTERMAP_XML_NODENAME;
-- docsignalend
begin
-- docinststart
-- Instantiate the generated XML2VHDL component
inst_axi4lite_REGISTERMAP_XML_NODENAME : entity XML_LINK_LIB.axi4lite_REGISTERMAP_XML_NODENAME
port map(
axi4lite_aclk => axi4lite_aclk,
axi4lite_aresetn => axi4lite_aresetn
axi4lite_mosi => axi4lite_mosi,
axi4lite_miso => axi4lite_miso,
axi4lite_REGISTERMAP_XML_NODENAME_in_we => axi4lite_REGISTERMAP_XML_NODENAME_in_we,
axi4lite_REGISTERMAP_XML_NODENAME_in => axi4lite_REGISTERMAP_XML_NODENAME_in,
axi4lite_REGISTERMAP_XML_NODENAME_out_we => axi4lite_REGISTERMAP_XML_NODENAME_out_we,
axi4lite_REGISTERMAP_XML_NODENAME_out => axi4lite_REGISTERMAP_XML_NODENAME_out
);
-- docinstend
-- Examples mapping input signals to XML2VHDL in records:
axi4lite_REGISTERMAP_XML_NODENAME_in.FULL_RW_REGISTER <= FULL_RW_REGISTER_in;
axi4lite_REGISTERMAP_XML_NODENAME_in.MASKED_REGISTER <= MASKED_REGISTER_in;
axi4lite_REGISTERMAP_XML_NODENAME_in.FULL_WR_REGISTER <= FULL_WR_REGISTER_in;
axi4lite_REGISTERMAP_XML_NODENAME_in.BITFIELD_REGISTER.ONE_RW_BITFIELD <= ONE_RW_BITFIELD_in;
axi4lite_REGISTERMAP_XML_NODENAME_in.BITFIELD_REGISTER.ONE_RW_BYTEFIELD <= ONE_RW_BYTEFIELD_in;
-- Examples mapping input signals to XML2VHDL out records:
FULL_RW_REGISTER_out <= axi4lite_REGISTERMAP_XML_NODENAME_out.FULL_RW_REGISTER;
MASKED_REGISTER_out <= axi4lite_REGISTERMAP_XML_NODENAME_out.MASKED_REGISTER;
FULL_RD_REGISTER_out <= axi4lite_REGISTERMAP_XML_NODENAME_out.FULL_RD_REGISTER;
ONE_RW_BITFIELD_out <= axi4lite_REGISTERMAP_XML_NODENAME_out.BITFIELD_REGISTER.ONE_RW_BITFIELD;
ONE_RW_BYTEFIELD_out <= axi4lite_REGISTERMAP_XML_NODENAME_out.BITFIELD_REGISTER.ONE_RW_BYTEFIELD;
end architecture struct;
The above VHDL example, shows how the end-user can connect the generated VHDL into the end-user host design.
Attention
The implementation and integration of XML2VHDL generated VHDL into the end-user host design is the responsibility of the designer. This WILL NOT be automated by XML2VHDL.
This example demonstrates how the VHDL records can be expanded to connect to ports and/or signals in the end-user host design.
Interconnects
<?xml version="1.0" encoding="ISO-8859-1"?>
<node id="IC_XML_NODENAME" address="0x0" hw_type="ic">
<node id="EXAMPLE_IC_0" address="0x0000" link="XML_FILENAME_memory_map_output.xml"/>
<node id="EXAMPLE_IC_1" address="0x8000" link="XML_FILENAME_memory_map_output.xml"/>
<node id="EXAMPLE_IC_2" address="0xC000" link="XML_FILENAME_memory_map_output.xml"/>
</node>
Considering the above XML description of a collection of Interconnects,
defined in a XML file named: XML_FILENAME_ic_memory_map.xml.
The top-level node is assigned the name IC_XML_NODENAME via the id= attribute.
This name is applied to abstract away the actual memory-mapped addresses by allowing
associated Software to reference via ID, without the end-user needing to
keep track of the assigned base-address - which may well change once the complete
memory-map of the final system has been generated.
Each node in this example Interconnect is linked to the same XML2VHDL generated
XML output file: XML_FILENAME_memory_map_output.xml
using the link= node attribute.
Each Interconnect node must be assigned an address-offset, this is handled via
the address= node attribute.
Caution
It is the responsibility of the designer to ensure the address-offsets between Interconnect nodes are assigned enough addresses between nodes to accommodate the total address-size of the XML2VHDL generated XML output file it is linked with.
Attention
While this example is linking the each Interconnect node to the same output, it is possible to link to any other XML2VHDL generated output XML file. The only exception to this, it that it MUST NOT be linked to itself.
In terms of the tree structure hierarchy, the top-level node representing the XML description is classed as the parent node. Each Interconnect node is a first-level node. The linked XML2VHDL generated XML outputs for each Interconnect node will be second-level, and third-level (depending on if the corresponding registers have child bit-field descriptions).
Note
With no knowledge of how this XML input file connects to memory-maps above this this description (i.e. whether this connects to, and is linked to an Interconnect description). The top-level and first-level have the same meaning.
VHDL Output
Package File Entries
The above XML input example description will result in the following
VHDL package files to generated, each are needed in the end-user
host design - from the library linked at XML2VHDL generation time using the
--slave_library argument.
axi4lite_IC_XML_NODENAME_ic_pkg.vhdaxi4lite_IC_XML_NODENAME_mmap_pkg.vhd
In order to reference the Interconnect nodes using their id= attribute a
custom VHDL type is generated in the axi4lite_IC_XML_NODENAME_mmap_pkg.vhd
package file. The convention of XML2VHDL is to prefix the node id= value
with id_ for easy reference. It also creates a VHDL constant which
should be used when declaring corresponding VHDL arrays in the end-user
host design:
type t_axi4lite_mmap_slaves is (
id_EXAMPLE_IC_0,
id_EXAMPLE_IC_1,
id_EXAMPLE_IC_2
);
The axi4lite_IC_XML_NODENAME_mmap_pkg.vhd also contains a VHDL
function to allow the corresponding VHDL arrays to be indexed using
this identifier:
function axi4lite_mmap_get_id(str_id: t_axi4lite_mmap_slaves) return integer;
function axi4lite_mmap_get_id(str_id : t_axi4lite_mmap_slaves) return integer is
variable ret: integer := -1;
begin
ret := t_axi4lite_mmap_slaves'pos(str_id);
return ret;
end function;
Note
Using these generated custom VHDL types and constant allows for a layer of
abstraction between the Interconnect node id= attribute values in
the XML input files, to those as they appear in the end-user host design.
By developing control and support software inline with FPGA Firmware,
this ensures changes to Interconnect structure and/or address-space locations
does not require changes to the underlying end-user host design. This includes
the addition of new Interconnect links, as signals interfacing with the resulting
VHDL entity DO NOT change.
Caution
The above abstraction DOES NOT account for major changes, like
renaming Interconnect node links via their id=
attributes; and/or node removal. This will change the VHDL custom types
and their reference identifiers in the end-user host design logic.
Top-level Component
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
library axi4_lib;
use axi4_lib.axi4lite_pkg.all;
library XML_LINK_LIB;
use XML_LINK_LIB.axi4lite_IC_XML_NODENAME_ic_pkg.all;
use XML_LINK_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.all;
entity axi4lite_IC_XML_NODENAME_ic is
port(
axi4lite_aclk : in std_logic;
axi4lite_aresetn : in std_logic;
axi4lite_mosi : in t_axi4lite_mosi;
axi4lite_miso : out t_axi4lite_miso;
axi4lite_mosi_arr : in t_axi4lite_mosi;
axi4lite_miso_arr : out t_axi4lite_miso;
);
end entity;
The above XML input example Interconnect description will result in the
following VHDL entity/architecture (component) to be generated via the
axi4lite_IC_XML_NODENAME_ic.vhd file.
Standard ports include an AXI4-Lite interface, including a clock and
active-low reset. The axi4lite_mosi and axi4lite_miso types are declared.
Ports of arrays of these signals are also completed. Where each array element
corresponds to a connection to the Interconnect nodes.
Attention
Currently, axi4lite_pkg.vhd IS NOT provided with XML2VHDL. See
VHDL libraries.
The end-user does not need to worry about the inner workings of this generated entity/architecture (component). It just needs to be integrated with the end-user host design, by creating an instance of this VHDL component (using the entity instantiation method). The end-user also needs to declare and connect these ports to/from the host design. Once the component is integrated into the end-user host design, it can remain untouched.
Caution
The referencing to VHDL array identifiers can remain untouched in the
end-user host design if NO major changes, like renaming Interconnect
node links via their id= attributes; and/or node removal. This will
change the custom VHDL types and their referencing in the end-user
host design logic.
End-user host designs can interface with generated VHDL arrays from the Bus-side, by connecting to the corresponding VHDL array indexes to the correct down-stream memory-maps as required by the end-user host design.
Example Instantiation
library axi4_lib;
use axi4_lib.axi4lite_pkg.all;
library XML_LINK_LIB;
use XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_ic_pkg.all;
use XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.all;
-- doclibend
entity axi4lite_IC_XML_NODENAME_ic_example is
port(
-- AXI4Lite Bus Signals
axi4lite_aclk : in std_logic;
axi4lite_aresetn : in std_logic;
axi4lite_mosi : in t_axi4lite_mosi;
axi4lite_miso : out t_axi4lite_miso
);
end entity axi4lite_IC_XML_NODENAME_ic_example;
architecture struct of axi4lite_IC_XML_NODENAME_ic_example is
-- Signal declarations: ----------------------------------------------------
signal axi4lite_IC_XML_NODENAME_mosi_arr : t_axi4lite_mosi_arr(0 to XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.c_axi4lite_mmap_nof_slave - 1);
signal axi4lite_IC_XML_NODENAME_miso_arr : t_axi4lite_miso_arr(0 to XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.c_axi4lite_mmap_nof_slave - 1);
-- docsignalend
begin
-- docinststart
-- Instantiate the generated XML2VHDL Interconnect component
inst_axi4lite_IC_XML_NODENAME_ic : entity XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_ic
port map(
axi4lite_aclk => axi4lite_aclk,
axi4lite_aresetn => axi4lite_aresetn,
axi4lite_mosi => axi4lite_mosi,
axi4lite_miso => axi4lite_miso,
axi4lite_miso_arr => axi4lite_IC_XML_NODENAME_mosi_arr,
axi4lite_mosi_arr => axi4lite_IC_XML_NODENAME_miso_arr
);
-- Instantiate the generated XML2VHDL linked components
inst_axi4lite_REGISTERMAP_XML_NODENAME_0 : entity XML_LINK_LIB.axi4lite_REGISTERMAP_XML_NODENAME
port map(
axi4lite_aclk => axi4lite_aclk,
axi4lite_aresetn => axi4lite_aresetn
axi4lite_mosi => axi4lite_IC_XML_NODENAME_mosi_arr(axi4lite_mmap_get_id(XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.id_EXAMPLE_IC_0)),
axi4lite_miso => axi4lite_IC_XML_NODENAME_miso_arr(axi4lite_mmap_get_id(XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.id_EXAMPLE_IC_0)),
axi4lite_REGISTERMAP_XML_NODENAME_in_we => axi4lite_REGISTERMAP_XML_NODENAME_0_in_we,
axi4lite_REGISTERMAP_XML_NODENAME_in => axi4lite_REGISTERMAP_XML_NODENAME_0_in,
axi4lite_REGISTERMAP_XML_NODENAME_out_we => axi4lite_REGISTERMAP_XML_NODENAME_0_out_we,
axi4lite_REGISTERMAP_XML_NODENAME_out => axi4lite_REGISTERMAP_XML_NODENAME_0_out
);
inst_axi4lite_REGISTERMAP_XML_NODENAME_1 : entity XML_LINK_LIB.axi4lite_REGISTERMAP_XML_NODENAME
port map(
axi4lite_aclk => axi4lite_aclk,
axi4lite_aresetn => axi4lite_aresetn
axi4lite_mosi => axi4lite_IC_XML_NODENAME_mosi_arr(axi4lite_mmap_get_id(XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.id_EXAMPLE_IC_1)),
axi4lite_miso => axi4lite_IC_XML_NODENAME_miso_arr(axi4lite_mmap_get_id(XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.id_EXAMPLE_IC_1)),
axi4lite_REGISTERMAP_XML_NODENAME_in_we => axi4lite_REGISTERMAP_XML_NODENAME_1_in_we,
axi4lite_REGISTERMAP_XML_NODENAME_in => axi4lite_REGISTERMAP_XML_NODENAME_1_in,
axi4lite_REGISTERMAP_XML_NODENAME_out_we => axi4lite_REGISTERMAP_XML_NODENAME_1_out_we,
axi4lite_REGISTERMAP_XML_NODENAME_out => axi4lite_REGISTERMAP_XML_NODENAME_1_out
);
inst_axi4lite_REGISTERMAP_XML_NODENAME_2 : entity XML_LINK_LIB.axi4lite_REGISTERMAP_XML_NODENAME
port map(
axi4lite_aclk => axi4lite_aclk,
axi4lite_aresetn => axi4lite_aresetn
axi4lite_mosi => axi4lite_IC_XML_NODENAME_mosi_arr(axi4lite_mmap_get_id(XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.id_EXAMPLE_IC_2)),
axi4lite_miso => axi4lite_IC_XML_NODENAME_miso_arr(axi4lite_mmap_get_id(XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.id_EXAMPLE_IC_2)),
axi4lite_REGISTERMAP_XML_NODENAME_in_we => axi4lite_REGISTERMAP_XML_NODENAME_2_in_we,
axi4lite_REGISTERMAP_XML_NODENAME_in => axi4lite_REGISTERMAP_XML_NODENAME_2_in,
axi4lite_REGISTERMAP_XML_NODENAME_out_we => axi4lite_REGISTERMAP_XML_NODENAME_2_out_we,
axi4lite_REGISTERMAP_XML_NODENAME_out => axi4lite_REGISTERMAP_XML_NODENAME_2_out
);
end architecture struct;
The above VHDL example, shows how the end-user can connect the generated VHDL into the end-user host design.
Attention
The implementation and integration of XML2VHDL generated VHDL into the end-user host design is the responsibility of the designer. This WILL NOT be automated by XML2VHDL.
This example demonstrates how the VHDL records can be expanded to connect to ports and/or signals in the end-user host design.
Tip
To improve readability, it is recommended to store the Interconnect node identifiers in VHDL constants, and use the constants to index the generated VHDL arrays.
-- Constant declarations: --------------------------------------------------
constant c_IC_XML_NODENAME_nof_secondaries : natural := XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.c_axi4lite_mmap_nof_slave;
constant c_IC_XML_NODENAME_EXAMPLE_IC_0_id : natural := axi4lite_mmap_get_id(XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.id_EXAMPLE_IC_0);
constant c_IC_XML_NODENAME_EXAMPLE_IC_1_id : natural := axi4lite_mmap_get_id(XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.id_EXAMPLE_IC_1);
constant c_IC_XML_NODENAME_EXAMPLE_IC_2_id : natural := axi4lite_mmap_get_id(XML_LINKED_LIB.axi4lite_IC_XML_NODENAME_mmap_pkg.id_EXAMPLE_IC_2);
-- Signal declarations: ----------------------------------------------------
signal axi4lite_IC_XML_NODENAME_mosi_arr : t_axi4lite_mosi_arr(0 to c_IC_XML_NODENAME_nof_secondaries - 1);
signal axi4lite_IC_XML_NODENAME_miso_arr : t_axi4lite_miso_arr(0 to c_IC_XML_NODENAME_nof_secondaries - 1);
inst_axi4lite_REGISTERMAP_XML_NODENAME_0 : entity XML_LINK_LIB.axi4lite_REGISTERMAP_XML_NODENAME
port map(
axi4lite_aclk => axi4lite_aclk,
axi4lite_aresetn => axi4lite_aresetn
axi4lite_mosi => axi4lite_IC_XML_NODENAME_mosi_arr(c_IC_XML_NODENAME_EXAMPLE_IC_0_id),
axi4lite_miso => axi4lite_IC_XML_NODENAME_miso_arr(c_IC_XML_NODENAME_EXAMPLE_IC_0_id),
axi4lite_REGISTERMAP_XML_NODENAME_in_we => axi4lite_REGISTERMAP_XML_NODENAME_0_in_we,
axi4lite_REGISTERMAP_XML_NODENAME_in => axi4lite_REGISTERMAP_XML_NODENAME_0_in,
axi4lite_REGISTERMAP_XML_NODENAME_out_we => axi4lite_REGISTERMAP_XML_NODENAME_0_out_we,
axi4lite_REGISTERMAP_XML_NODENAME_out => axi4lite_REGISTERMAP_XML_NODENAME_0_out
);
inst_axi4lite_REGISTERMAP_XML_NODENAME_1 : entity XML_LINK_LIB.axi4lite_REGISTERMAP_XML_NODENAME
port map(
axi4lite_aclk => axi4lite_aclk,
axi4lite_aresetn => axi4lite_aresetn
axi4lite_mosi => axi4lite_IC_XML_NODENAME_mosi_arr(c_IC_XML_NODENAME_EXAMPLE_IC_1_id),
axi4lite_miso => axi4lite_IC_XML_NODENAME_miso_arr(c_IC_XML_NODENAME_EXAMPLE_IC_1_id),
axi4lite_REGISTERMAP_XML_NODENAME_in_we => axi4lite_REGISTERMAP_XML_NODENAME_1_in_we,
axi4lite_REGISTERMAP_XML_NODENAME_in => axi4lite_REGISTERMAP_XML_NODENAME_1_in,
axi4lite_REGISTERMAP_XML_NODENAME_out_we => axi4lite_REGISTERMAP_XML_NODENAME_1_out_we,
axi4lite_REGISTERMAP_XML_NODENAME_out => axi4lite_REGISTERMAP_XML_NODENAME_1_out
);
inst_axi4lite_REGISTERMAP_XML_NODENAME_2 : entity XML_LINK_LIB.axi4lite_REGISTERMAP_XML_NODENAME
port map(
axi4lite_aclk => axi4lite_aclk,
axi4lite_aresetn => axi4lite_aresetn
axi4lite_mosi => axi4lite_IC_XML_NODENAME_mosi_arr(c_IC_XML_NODENAME_EXAMPLE_IC_2_id),
axi4lite_miso => axi4lite_IC_XML_NODENAME_miso_arr(c_IC_XML_NODENAME_EXAMPLE_IC_2_id),
axi4lite_REGISTERMAP_XML_NODENAME_in_we => axi4lite_REGISTERMAP_XML_NODENAME_2_in_we,
axi4lite_REGISTERMAP_XML_NODENAME_in => axi4lite_REGISTERMAP_XML_NODENAME_2_in,
axi4lite_REGISTERMAP_XML_NODENAME_out_we => axi4lite_REGISTERMAP_XML_NODENAME_2_out_we,
axi4lite_REGISTERMAP_XML_NODENAME_out => axi4lite_REGISTERMAP_XML_NODENAME_2_out
);