Note: This is part 6 of a series on working with FPGAs and in particular the Xilinx Zynq-7000S Programmable System-on-Chip with ARM Cortex-A9 processing core. For part 1, click here: Xilinx ZYNQ System-on-Chip - Getting to know the MiniZed Board
For all parts, click here: Path to Programmable
Note 2: Some of the diagrams in this series of blog posts by their nature need to be extremely dense, but are all reasonably high-res. Click to enlarge them, and then optionally save them (right-click) in order to zoom even further into them.
Introduction
If you’ve ever worked with a microcontroller and then wished it contained just one more timer or PWM module or some other hardware feature, then, like me, perhaps you’re interested in how to implement such devices for yourself using programmable logic! Any building-block you create could be called custom intellectual property (IP). This blog post covers how to get custom hardware (a PWM module in this case) onto a chip along with a microprocessor.
The MiniZedMiniZed is a compact board containing a Xilinx Zynq chip. The Zynq is a piece of silicon with on-board microprocessor (an ARM Cortex-A9) and programmable logic! The programmable logic can be used to implement arbitrary hardware, and the microprocessor can also interface to it if desired.
In the previous blog post, it was discovered how to get communication between the microprocessor (or Processing System or PS as Xilinx calls it) and the programmable logic (PL). It used an interface called AXI, that consists of read and write data busses and an address bus. All of this was mostly done using a graphical block view in the development environment called Xilinx Vivado. The graphical view shows each entity and the bundles of signals or internal routing that connects everything up. Xilinx supplies more than a hundred different ready-made graphical blocks, also known as intellectual property (IP) for use in designs. They are easy to use; just right-click in the diagram view and select Add IP, and then search the list. Once the block is placed, you can double-click it to open up a configuration options window. Any work required to complete the implementation, and signal connections to the rest of the design, can be automatically made by clicking on the green bars marked Run Block Automation or Run Connection Automation - they pop up whenever Vivado thinks you should run it!
Ordinarily when using the PL, a user would describe the desired hardware in a language such as Verilog or VHDL. In this blog post, a variant of AXI is used to connect to such arbitrary PL hardware. The source happens to be Verilog in this blog post, and it describes a pulse width modulation (PWM) circuit that dims an LED on the MiniZed board, based on a value that is selected by the microprocessor.
The purpose of this blog post is to examine how that programmable logic PWM hardware design can be turned into a graphical block that you can reuse in projects.
The PWM Module Hardware Design
A single file, called PWM_Controller_Int.v is supplied as part of the Zynq training course. I’ve reproduced it here since it is a very short piece of HDL content.
I’m not very familiar with Verilog, but basically this code defines a module which has several inputs and outputs. The output reg lines define registered outputs; in other words, there will be some flip-flops or memory that will latch values for those outputs.
Next, there are three blocks of content that all start with always @(posedge Clk). The thing in the brackets is the sensitivity list just containing one signal called Clk. The sensitivity list specifies that if that signal changes (in this case only positive edge changes) then the content in that block will be evaluated. All three blocks run simultaneously. The first block implements a counter with reset capability. The second block implements a binary comparator to test if the counter output is less than the value on the DutyCycle signals or not. The PWM output signal is the comparator output.
The third block implements another comparator that generates an Interrupt signal whenever the DutyCycle is set too high.
The aim of this blog post is to get this Verilog hardware description into a reusable graphical block. Along the way it will also be interesting to see what this description can look like once it has been converted or synthesized into logic.
Create New IP
In Vivado, click on Tools->Create and Package New IP, and follow the steps – they are straightforward, as shown below. An empty folder called ip_repo was specified for the custom IP (eventually this folder will contain a sub-folder for the custom IP). One of the steps allows you to select the PS-PL communication interface, and AXI-Lite was chosen.
After this has been completed, Vivado will have created a PWM_w_Int_1.0 folder (and several sub-folders inside that) in the ip_repo folder! It is now ready for editing, so that the VHDL or Verilog code can be added.
Editing IP
Go to Window->IP Catalog and you can search for the newly created IP, as shown in the screenshots below. Vivado will keep any existing project open, and will open up a whole new Vivado instance for editing the Custom IP. In other words, custom IP is treated like a whole new project.
Once the steps above are complete, a couple of VHDL files will be present in the project source window. The top-level VHDL file for the project will reference the second file, which contains the AXI-Lite slave. The top-level file in this example was automatically called PWM_w_Int_v1_0.vhd
Adding your HDL Content
The PWM module HDL file is placed in the hdl folder that is inside the sub-folder that was created by Vivado, as shown in the steps diagram below. Next, Add Sources is selected within the Flow Navigator pane on the left side of Vivado, and click-through as shown below to get the file added!
When your HDL content (for example in Verilog or VHDL) is added to this Custom IP project in this manner, the top-level VHDL file that was automatically created earlier will need some editing to declare the (a) the signals or ports, (b) declare the PWM module component, and (c) instantiate the component. Just as a refresher (it was discussed in blog 2) the diagram below shows the areas within VHDL where (a)-(c) would need to be entered.
The code below shows the final top-level file PWM_w_Int_v1_0.vhd content. The stuff that was manually added to incorporate the custom PWM module Verilog code is highlighted. You can see it isn’t much.
library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity PWM_w_Int_v1_0 is generic ( -- Users to add parameters here PWM_PERIOD: integer :=20; -- User parameters ends -- Do not modify the parameters beyond this line -- Parameters of Axi Slave Bus Interface S00_AXI C_S00_AXI_DATA_WIDTH : integer := 32; C_S00_AXI_ADDR_WIDTH : integer := 4 ); port ( -- Users to add ports here LED : out std_logic_vector(0 downto 0); Interrupt_Out : out std_logic; PWM_Counter : out std_logic_vector(PWM_PERIOD-1 downto 0); DutyCycle : out std_logic_vector(31 downto 0); -- User ports ends -- Do not modify the ports beyond this line -- Ports of Axi Slave Bus Interface S00_AXI s00_axi_aclk : in std_logic; s00_axi_aresetn : in std_logic; s00_axi_awaddr : in std_logic_vector(C_S00_AXI_ADDR_WIDTH-1 downto 0); s00_axi_awprot : in std_logic_vector(2 downto 0); s00_axi_awvalid : in std_logic; s00_axi_awready : out std_logic; s00_axi_wdata : in std_logic_vector(C_S00_AXI_DATA_WIDTH-1 downto 0); s00_axi_wstrb : in std_logic_vector((C_S00_AXI_DATA_WIDTH/8)-1 downto 0); s00_axi_wvalid : in std_logic; s00_axi_wready : out std_logic; s00_axi_bresp : out std_logic_vector(1 downto 0); s00_axi_bvalid : out std_logic; s00_axi_bready : in std_logic; s00_axi_araddr : in std_logic_vector(C_S00_AXI_ADDR_WIDTH-1 downto 0); s00_axi_arprot : in std_logic_vector(2 downto 0); s00_axi_arvalid : in std_logic; s00_axi_arready : out std_logic; s00_axi_rdata : out std_logic_vector(C_S00_AXI_DATA_WIDTH-1 downto 0); s00_axi_rresp : out std_logic_vector(1 downto 0); s00_axi_rvalid : out std_logic; s00_axi_rready : in std_logic ); end PWM_w_Int_v1_0; architecture arch_imp of PWM_w_Int_v1_0 is -- component declaration component PWM_Controller_Int is generic ( period : integer := 20 ); port ( Clk : in std_logic; DutyCycle : in std_logic_vector(31 downto 0); Reset : in std_logic; PWM_out : out std_logic_vector(0 downto 0); Interrupt: out std_logic; count: out std_logic_vector(period-1 downto 0) ); end component PWM_Controller_Int; component PWM_w_Int_v1_0_S00_AXI is generic ( C_S_AXI_DATA_WIDTH : integer := 32; C_S_AXI_ADDR_WIDTH : integer := 4 ); port ( slave_reg0 : out std_logic_vector(C_S_AXI_DATA_WIDTH-1 downto 0);
S_AXI_ACLK : in std_logic; S_AXI_ARESETN : in std_logic; S_AXI_AWADDR : in std_logic_vector(C_S_AXI_ADDR_WIDTH-1 downto 0); S_AXI_AWPROT : in std_logic_vector(2 downto 0); S_AXI_AWVALID : in std_logic; S_AXI_AWREADY : out std_logic; S_AXI_WDATA : in std_logic_vector(C_S_AXI_DATA_WIDTH-1 downto 0); S_AXI_WSTRB : in std_logic_vector((C_S_AXI_DATA_WIDTH/8)-1 downto 0); S_AXI_WVALID : in std_logic; S_AXI_WREADY : out std_logic; S_AXI_BRESP : out std_logic_vector(1 downto 0); S_AXI_BVALID : out std_logic; S_AXI_BREADY : in std_logic; S_AXI_ARADDR : in std_logic_vector(C_S_AXI_ADDR_WIDTH-1 downto 0); S_AXI_ARPROT : in std_logic_vector(2 downto 0); S_AXI_ARVALID : in std_logic; S_AXI_ARREADY : out std_logic; S_AXI_RDATA : out std_logic_vector(C_S_AXI_DATA_WIDTH-1 downto 0); S_AXI_RRESP : out std_logic_vector(1 downto 0); S_AXI_RVALID : out std_logic; S_AXI_RREADY : in std_logic ); end component PWM_w_Int_v1_0_S00_AXI; signal DutyCycle_int : std_logic_vector(31 downto 0); begin DutyCycle <= DutyCycle_int; -- Instantiation of Axi Bus Interface S00_AXI PWM_w_Int_v1_0_S00_AXI_inst : PWM_w_Int_v1_0_S00_AXI generic map ( C_S_AXI_DATA_WIDTH => C_S00_AXI_DATA_WIDTH, C_S_AXI_ADDR_WIDTH => C_S00_AXI_ADDR_WIDTH ) port map ( slave_reg0 => DutyCycle_int,
S_AXI_ACLK => s00_axi_aclk, S_AXI_ARESETN => s00_axi_aresetn, S_AXI_AWADDR => s00_axi_awaddr, S_AXI_AWPROT => s00_axi_awprot, S_AXI_AWVALID => s00_axi_awvalid, S_AXI_AWREADY => s00_axi_awready, S_AXI_WDATA => s00_axi_wdata, S_AXI_WSTRB => s00_axi_wstrb, S_AXI_WVALID => s00_axi_wvalid, S_AXI_WREADY => s00_axi_wready, S_AXI_BRESP => s00_axi_bresp, S_AXI_BVALID => s00_axi_bvalid, S_AXI_BREADY => s00_axi_bready, S_AXI_ARADDR => s00_axi_araddr, S_AXI_ARPROT => s00_axi_arprot, S_AXI_ARVALID => s00_axi_arvalid, S_AXI_ARREADY => s00_axi_arready, S_AXI_RDATA => s00_axi_rdata, S_AXI_RRESP => s00_axi_rresp, S_AXI_RVALID => s00_axi_rvalid, S_AXI_RREADY => s00_axi_rready ); -- Add user logic here PWM_Controller_Int_Inst : PWM_Controller_Int generic map ( period => PWM_PERIOD ) port map ( Clk => s00_axi_aclk, DutyCycle => DutyCycle_int, Reset => s00_axi_aresetn, PWM_out => LED, Interrupt => Interrupt_Out, count => PWM_Counter ); -- User logic ends end arch_imp;
A couple of additions are needed in the AXI-lite VHDL file too. The entire file is shown below, and the two changes are highlighted.
library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity PWM_w_Int_v1_0_S00_AXI is generic ( -- Users to add parameters here -- User parameters ends -- Do not modify the parameters beyond this line -- Width of S_AXI data bus C_S_AXI_DATA_WIDTH : integer := 32; -- Width of S_AXI address bus C_S_AXI_ADDR_WIDTH : integer := 4 ); port ( -- Users to add ports here slave_reg0: out std_logic_vector(C_S_AXI_DATA_WIDTH-1 downto 0); -- User ports ends -- Do not modify the ports beyond this line -- Global Clock Signal S_AXI_ACLK : in std_logic; -- Global Reset Signal. This Signal is Active LOW S_AXI_ARESETN : in std_logic; -- Write address (issued by master, acceped by Slave) S_AXI_AWADDR : in std_logic_vector(C_S_AXI_ADDR_WIDTH-1 downto 0); -- Write channel Protection type. This signal indicates the -- privilege and security level of the transaction, and whether -- the transaction is a data access or an instruction access. S_AXI_AWPROT : in std_logic_vector(2 downto 0); -- Write address valid. This signal indicates that the master signaling -- valid write address and control information. S_AXI_AWVALID : in std_logic; -- Write address ready. This signal indicates that the slave is ready -- to accept an address and associated control signals. S_AXI_AWREADY : out std_logic; -- Write data (issued by master, acceped by Slave) S_AXI_WDATA : in std_logic_vector(C_S_AXI_DATA_WIDTH-1 downto 0); -- Write strobes. This signal indicates which byte lanes hold -- valid data. There is one write strobe bit for each eight -- bits of the write data bus. S_AXI_WSTRB : in std_logic_vector((C_S_AXI_DATA_WIDTH/8)-1 downto 0); -- Write valid. This signal indicates that valid write -- data and strobes are available. S_AXI_WVALID : in std_logic; -- Write ready. This signal indicates that the slave -- can accept the write data. S_AXI_WREADY : out std_logic; -- Write response. This signal indicates the status -- of the write transaction. S_AXI_BRESP : out std_logic_vector(1 downto 0); -- Write response valid. This signal indicates that the channel -- is signaling a valid write response. S_AXI_BVALID : out std_logic; -- Response ready. This signal indicates that the master -- can accept a write response. S_AXI_BREADY : in std_logic; -- Read address (issued by master, acceped by Slave) S_AXI_ARADDR : in std_logic_vector(C_S_AXI_ADDR_WIDTH-1 downto 0); -- Protection type. This signal indicates the privilege -- and security level of the transaction, and whether the -- transaction is a data access or an instruction access. S_AXI_ARPROT : in std_logic_vector(2 downto 0); -- Read address valid. This signal indicates that the channel -- is signaling valid read address and control information. S_AXI_ARVALID : in std_logic; -- Read address ready. This signal indicates that the slave is -- ready to accept an address and associated control signals. S_AXI_ARREADY : out std_logic; -- Read data (issued by slave) S_AXI_RDATA : out std_logic_vector(C_S_AXI_DATA_WIDTH-1 downto 0); -- Read response. This signal indicates the status of the -- read transfer. S_AXI_RRESP : out std_logic_vector(1 downto 0); -- Read valid. This signal indicates that the channel is -- signaling the required read data. S_AXI_RVALID : out std_logic; -- Read ready. This signal indicates that the master can -- accept the read data and response information. S_AXI_RREADY : in std_logic ); end PWM_w_Int_v1_0_S00_AXI; architecture arch_imp of PWM_w_Int_v1_0_S00_AXI is -- AXI4LITE signals signal axi_awaddr : std_logic_vector(C_S_AXI_ADDR_WIDTH-1 downto 0); signal axi_awready : std_logic; signal axi_wready : std_logic; signal axi_bresp : std_logic_vector(1 downto 0); signal axi_bvalid : std_logic; signal axi_araddr : std_logic_vector(C_S_AXI_ADDR_WIDTH-1 downto 0); signal axi_arready : std_logic; signal axi_rdata : std_logic_vector(C_S_AXI_DATA_WIDTH-1 downto 0); signal axi_rresp : std_logic_vector(1 downto 0); signal axi_rvalid : std_logic; -- Example-specific design signals -- local parameter for addressing 32 bit / 64 bit C_S_AXI_DATA_WIDTH -- ADDR_LSB is used for addressing 32/64 bit registers/memories -- ADDR_LSB = 2 for 32 bits (n downto 2) -- ADDR_LSB = 3 for 64 bits (n downto 3) constant ADDR_LSB : integer := (C_S_AXI_DATA_WIDTH/32)+ 1; constant OPT_MEM_ADDR_BITS : integer := 1; ------------------------------------------------ ---- Signals for user logic register space example -------------------------------------------------- ---- Number of Slave Registers 4 signal slv_reg0 :std_logic_vector(C_S_AXI_DATA_WIDTH-1 downto 0); signal slv_reg1 :std_logic_vector(C_S_AXI_DATA_WIDTH-1 downto 0); signal slv_reg2 :std_logic_vector(C_S_AXI_DATA_WIDTH-1 downto 0); signal slv_reg3 :std_logic_vector(C_S_AXI_DATA_WIDTH-1 downto 0); signal slv_reg_rden : std_logic; signal slv_reg_wren : std_logic; signal reg_data_out :std_logic_vector(C_S_AXI_DATA_WIDTH-1 downto 0); signal byte_index : integer; signal aw_en : std_logic; begin -- I/O Connections assignments slave_reg0 <= slv_reg0;
S_AXI_AWREADY <= axi_awready; S_AXI_WREADY <= axi_wready; S_AXI_BRESP <= axi_bresp; S_AXI_BVALID <= axi_bvalid; S_AXI_ARREADY <= axi_arready; S_AXI_RDATA <= axi_rdata; S_AXI_RRESP <= axi_rresp; S_AXI_RVALID <= axi_rvalid; -- Implement axi_awready generation -- axi_awready is asserted for one S_AXI_ACLK clock cycle when both -- S_AXI_AWVALID and S_AXI_WVALID are asserted. axi_awready is -- de-asserted when reset is low. process (S_AXI_ACLK) begin if rising_edge(S_AXI_ACLK) then if S_AXI_ARESETN = '0' then axi_awready <= '0'; aw_en <= '1'; else if (axi_awready = '0' and S_AXI_AWVALID = '1' and S_AXI_WVALID = '1' and aw_en = '1') then -- slave is ready to accept write address when -- there is a valid write address and write data -- on the write address and data bus. This design -- expects no outstanding transactions. axi_awready <= '1'; elsif (S_AXI_BREADY = '1' and axi_bvalid = '1') then aw_en <= '1'; axi_awready <= '0'; else axi_awready <= '0'; end if; end if; end if; end process; -- Implement axi_awaddr latching -- This process is used to latch the address when both -- S_AXI_AWVALID and S_AXI_WVALID are valid. process (S_AXI_ACLK) begin if rising_edge(S_AXI_ACLK) then if S_AXI_ARESETN = '0' then axi_awaddr <= (others => '0'); else if (axi_awready = '0' and S_AXI_AWVALID = '1' and S_AXI_WVALID = '1' and aw_en = '1') then -- Write Address latching axi_awaddr <= S_AXI_AWADDR; end if; end if; end if; end process; -- Implement axi_wready generation -- axi_wready is asserted for one S_AXI_ACLK clock cycle when both -- S_AXI_AWVALID and S_AXI_WVALID are asserted. axi_wready is -- de-asserted when reset is low. process (S_AXI_ACLK) begin if rising_edge(S_AXI_ACLK) then if S_AXI_ARESETN = '0' then axi_wready <= '0'; else if (axi_wready = '0' and S_AXI_WVALID = '1' and S_AXI_AWVALID = '1' and aw_en = '1') then -- slave is ready to accept write data when -- there is a valid write address and write data -- on the write address and data bus. This design -- expects no outstanding transactions. axi_wready <= '1'; else axi_wready <= '0'; end if; end if; end if; end process; -- Implement memory mapped register select and write logic generation -- The write data is accepted and written to memory mapped registers when -- axi_awready, S_AXI_WVALID, axi_wready and S_AXI_WVALID are asserted. Write strobes are used to -- select byte enables of slave registers while writing. -- These registers are cleared when reset (active low) is applied. -- Slave register write enable is asserted when valid address and data are available -- and the slave is ready to accept the write address and write data. slv_reg_wren <= axi_wready and S_AXI_WVALID and axi_awready and S_AXI_AWVALID ; process (S_AXI_ACLK) variable loc_addr :std_logic_vector(OPT_MEM_ADDR_BITS downto 0); begin if rising_edge(S_AXI_ACLK) then if S_AXI_ARESETN = '0' then slv_reg0 <= (others => '0'); slv_reg1 <= (others => '0'); slv_reg2 <= (others => '0'); slv_reg3 <= (others => '0'); else loc_addr := axi_awaddr(ADDR_LSB + OPT_MEM_ADDR_BITS downto ADDR_LSB); if (slv_reg_wren = '1') then case loc_addr is when b"00" => for byte_index in 0 to (C_S_AXI_DATA_WIDTH/8-1) loop if ( S_AXI_WSTRB(byte_index) = '1' ) then -- Respective byte enables are asserted as per write strobes -- slave registor 0 slv_reg0(byte_index*8+7 downto byte_index*8) <= S_AXI_WDATA(byte_index*8+7 downto byte_index*8); end if; end loop; when b"01" => for byte_index in 0 to (C_S_AXI_DATA_WIDTH/8-1) loop if ( S_AXI_WSTRB(byte_index) = '1' ) then -- Respective byte enables are asserted as per write strobes -- slave registor 1 slv_reg1(byte_index*8+7 downto byte_index*8) <= S_AXI_WDATA(byte_index*8+7 downto byte_index*8); end if; end loop; when b"10" => for byte_index in 0 to (C_S_AXI_DATA_WIDTH/8-1) loop if ( S_AXI_WSTRB(byte_index) = '1' ) then -- Respective byte enables are asserted as per write strobes -- slave registor 2 slv_reg2(byte_index*8+7 downto byte_index*8) <= S_AXI_WDATA(byte_index*8+7 downto byte_index*8); end if; end loop; when b"11" => for byte_index in 0 to (C_S_AXI_DATA_WIDTH/8-1) loop if ( S_AXI_WSTRB(byte_index) = '1' ) then -- Respective byte enables are asserted as per write strobes -- slave registor 3 slv_reg3(byte_index*8+7 downto byte_index*8) <= S_AXI_WDATA(byte_index*8+7 downto byte_index*8); end if; end loop; when others => slv_reg0 <= slv_reg0; slv_reg1 <= slv_reg1; slv_reg2 <= slv_reg2; slv_reg3 <= slv_reg3; end case; end if; end if; end if; end process; -- Implement write response logic generation -- The write response and response valid signals are asserted by the slave -- when axi_wready, S_AXI_WVALID, axi_wready and S_AXI_WVALID are asserted. -- This marks the acceptance of address and indicates the status of -- write transaction. process (S_AXI_ACLK) begin if rising_edge(S_AXI_ACLK) then if S_AXI_ARESETN = '0' then axi_bvalid <= '0'; axi_bresp <= "00"; --need to work more on the responses else if (axi_awready = '1' and S_AXI_AWVALID = '1' and axi_wready = '1' and S_AXI_WVALID = '1' and axi_bvalid = '0' ) then axi_bvalid <= '1'; axi_bresp <= "00"; elsif (S_AXI_BREADY = '1' and axi_bvalid = '1') then --check if bready is asserted while bvalid is high) axi_bvalid <= '0'; -- (there is a possibility that bready is always asserted high) end if; end if; end if; end process; -- Implement axi_arready generation -- axi_arready is asserted for one S_AXI_ACLK clock cycle when -- S_AXI_ARVALID is asserted. axi_awready is -- de-asserted when reset (active low) is asserted. -- The read address is also latched when S_AXI_ARVALID is -- asserted. axi_araddr is reset to zero on reset assertion. process (S_AXI_ACLK) begin if rising_edge(S_AXI_ACLK) then if S_AXI_ARESETN = '0' then axi_arready <= '0'; axi_araddr <= (others => '1'); else if (axi_arready = '0' and S_AXI_ARVALID = '1') then -- indicates that the slave has acceped the valid read address axi_arready <= '1'; -- Read Address latching axi_araddr <= S_AXI_ARADDR; else axi_arready <= '0'; end if; end if; end if; end process; -- Implement axi_arvalid generation -- axi_rvalid is asserted for one S_AXI_ACLK clock cycle when both -- S_AXI_ARVALID and axi_arready are asserted. The slave registers -- data are available on the axi_rdata bus at this instance. The -- assertion of axi_rvalid marks the validity of read data on the -- bus and axi_rresp indicates the status of read transaction.axi_rvalid -- is deasserted on reset (active low). axi_rresp and axi_rdata are -- cleared to zero on reset (active low). process (S_AXI_ACLK) begin if rising_edge(S_AXI_ACLK) then if S_AXI_ARESETN = '0' then axi_rvalid <= '0'; axi_rresp <= "00"; else if (axi_arready = '1' and S_AXI_ARVALID = '1' and axi_rvalid = '0') then -- Valid read data is available at the read data bus axi_rvalid <= '1'; axi_rresp <= "00"; -- 'OKAY' response elsif (axi_rvalid = '1' and S_AXI_RREADY = '1') then -- Read data is accepted by the master axi_rvalid <= '0'; end if; end if; end if; end process; -- Implement memory mapped register select and read logic generation -- Slave register read enable is asserted when valid address is available -- and the slave is ready to accept the read address. slv_reg_rden <= axi_arready and S_AXI_ARVALID and (not axi_rvalid) ; process (slv_reg0, slv_reg1, slv_reg2, slv_reg3, axi_araddr, S_AXI_ARESETN, slv_reg_rden) variable loc_addr :std_logic_vector(OPT_MEM_ADDR_BITS downto 0); begin -- Address decoding for reading registers loc_addr := axi_araddr(ADDR_LSB + OPT_MEM_ADDR_BITS downto ADDR_LSB); case loc_addr is when b"00" => reg_data_out <= slv_reg0; when b"01" => reg_data_out <= slv_reg1; when b"10" => reg_data_out <= slv_reg2; when b"11" => reg_data_out <= slv_reg3; when others => reg_data_out <= (others => '0'); end case; end process; -- Output register or memory read data process( S_AXI_ACLK ) is begin if (rising_edge (S_AXI_ACLK)) then if ( S_AXI_ARESETN = '0' ) then axi_rdata <= (others => '0'); else if (slv_reg_rden = '1') then -- When there is a valid read address (S_AXI_ARVALID) with -- acceptance of read address by the slave (axi_arready), -- output the read dada -- Read address mux axi_rdata <= reg_data_out; -- register read data end if; end if; end if; end process; -- Add user logic here -- User logic ends end arch_imp;
Once all these changes have been made and saved in Vivado, the Source window will show the AXI-lite and the PWM module Verilog file both indented, underneath the top-level VHDL file.
Synthesize the Custom IP
The hardware description in the source files needs to be converted into a lower-level design. Click on Run Synthesis and click through as shown in the screenshots below to achieve this.
Although it’s not essential, (and it would be harder to interpret for a more complicated design) it is possible to explore the schematic to see what the synthesis engine in Vivado did.
The screenshot below shows the majority of the top-level schematic (it is large so a bit of it had to be snipped off the screenshot for clarity). The two blue blocks represent the Verilog PWM module, and the AXI-Lite hardware.
Double-clicking into the PWM blue box, it is possible to explore and see how the Verilog code got translated into lower-level logic.
Packaging the Custom IP Project
Some housekeeping stuff is required, to get the block ready to be usable in any Vivado project. The types of things that need to be done include indicating to Vivado which configuration parameters should be present when the user double-clicks on the block to edit the IP for instance.
All the things that need to be done are listed in a Packaging Steps list that appears when Package IP is clicked in the Flow Navigator on the left side of Vivado. The user needs to click through each of the steps, completing anything as required.
The packaging step titled File Groups needs most work however, and it is caused by the fact that this VHDL example Custom IP project includes Verilog source in the mix, and Vivado doesn’t automatically handle it as it should. There are folder paths with names like VHDL Synthesis, VHDL Simulation, Verilog Synthesis and Verilog Simulation that would ordinarily be used if there wasn’t a mix. However, if there is a mix, then the folders that should be used are to be called just Synthesis and Simulation, and it becomes the user’s task to create these, and add the files there (and delete the incorrect folders). Surprisingly Vivado makes this quite awkward, when at worst case it ought to be a drag-and-drop or simple folder renaming exercise. The messing around is impressive, and it is a lot of steps. Anyway, the steps are shown in the screenshots below.
The PWM period setting is a hidden parameter, and it can be set to become visible in the GUI as shown in the steps below. Vivado also has the capability to recognise or infer certain signals (such as clock and reset) from the custom IP. This is helpful when making and checking connections. For this reason, in the case of the custom IP used in the example here, the Interrupt_Out signal is marked as being of type Interrupt as shown in the steps below too. Finally, in the Review and Package step, the Package IP or Re-Package IP button is clicked to complete it all!
After all this, the sub-folder in the original folder (called ip_repo) that was created at the start of this blog post, will contain everything for the custom IP!
In the next blog post, this custom IP will be used!
Summary
It was great to see that graphical building blocks for custom IP are reasonably straightforward to create. Vivado creates a whole new project window for it, where the user can add their source HDL file, synthesize it, and then follow some packaging steps to make the GUI for it to be usable.
As part of the exercise, it was interesting to see how the source HDL code (in this case Verilog) was used in the top-level VHDL file, and how Vivado can display a schematic view after synthesis, which can be explored.
Thanks for reading!
Top Comments