Creating Peripherals That Require PowerPC Control:

The standard technique that will be used in this section is to build a top-level template that the user’s HDL-may sit under. The top level template can be auto-generated by XPS and provide memory-mappable registers, interrupt control support, and even the bus interface that is required for PowerPC control. The most beneficial part, is that XPS can generate “template” driver files that, for example, can read and write to auto-generated registers. Controlling a peripheral becomes simply a matter of tying a port in the user’s peripheral to an index or indeces of an auto-generated register. Once again, the process for doing this is to use the “Create or Import Peripheral Wizard.” This wizard can be accessed in XPS from the “Hardware” drop-down -> “Create or Import Peripheral…” The steps are as follows:

  1. For PowerPC control, the user should choose to “create templates for a new peripheral.”
  2. The Wizard will then allow the user to give the peripheral a name – in this case, anything will work
  3. The Wizard will then prompt the user for what bus to place the peripheral on. There are three options: the “OPB,” or On-chip Peripheral Bus, the “PLB,” or Processor Local Bus, and the “FSL,” or Fast Simplex Link. The OPB bus is the slowest and has a static width of 32bits – it is recommended for most peripherals. The PLB is faster and can support a variable width of up to 64bits. It interacts directly with the processor, but the peripheral may not be able to support this bus-type. FSL is only for if the peripheral is to act as a fast simplex link. Typically the OPB bus is the suggested choice.
  4. The Wizard will then prompt for any auto-generated logic the user may want to implement in their design. Typically the “FIFO” and/or “User logic S/W register support” should be picked for implementing memory-mapped peripheral control. This page will also allow the user to implement logic such as interrupt and DMA support among others.
  5. The Wizard will then prompt the user to customize the selections that were made (such as FIFO-types, how many registers, data-widths, etc.)
  6. The Wizard will then prompt for ports to include. Usually the defaults that are already checked are enough for typical memory-mapped control support. For advanced users, more ports can be added.
  7. The Wizard will then ask if the user would like to create simulation files for use in applications such as ModelSim.
  8. The Wizard will then prompt for “optional peripheral implementation support.” Here the user can select whether to add the chosen logic in verilog or VHDL (typically VHDL has more example support included). It will also give the user the option of creating example ISE/XST project files (thus the “devl” folder in the pcores directory). Finally, and most useful, the Wizard will give the user the option of generating template driver files. THIS IS STRONGLY SUGGESTED and will save a lot of development time. The template drivers will, for example, create simply read/write functions for registers and FIFOs – which is typically enough to control the peripheral. The template drivers are also easy to modify/edit to the user’s liking -- or the user can use these drivers to make more abstract functions.
  9. The Wizard will then generate the files in an EDK-compliant format in either the project or EDK repository.

The former group of steps generates a complete EDK-compliant template that the user may wrap his/her HDL in. The process for doing so is VERY easy, provided the user has a solid background in verilog or VHDL programming. The following are the steps for modifying the generated peripheral to interface with the user’s HDL. NOTE: READ the first section of this guide on file-types and structure heirchies for finding and modifying the designated files described herein.

  1. Copy the custom peripheral HDL into the generated peripheral’s pcores\hdl\verilog or pcores\hdl\vhdl folder with the corresponding HDL-type.
  2. If the Verilog/VHDL folder does not exist because the peripherals logic was all one type, simply create the directory required if necessary
  3. Modify the peripheral’s *.pao file – add in the names of all of the other modules/filenames and their logic-type to the existing file. The lib type should be that of (/belong to) the peripherals name – the same library as the top-level and user-logic files.
  4. Add any required netlist (*.ngc or *.edn) files to the netlist directory – create it if necessary
  5. If netlists are used, create the *.bbd file in the pcores\data directory and modify it as necessary adding in the netlist-file definitions in the proper format as described in the File Structure section of this guide.
  6. If netlists are used, modify the *.mpd file to contain “OPTION RUN_NGCBUILD = TRUE” in the Options section. Also add/change “OPTION IMP_NETLIST = TRUE”
  7. In the *.mpd file, change the OPTION HDL parameter to it’s necessary type if any changes in the HDL-types used has been modified -> [MIXED | VHDL | VERILOG]
  8. At this point, it is probably worthwhile to import the peripheral into the XPS project and generate the bitstream for debugging. The peripheral will be non-functional, but any errors in the PAO and BBD files and/or the custom HDL will appear.
  9. If all generates successfully, the user may then proceed to interface their peripherals logic with the user-logic module. The method for doing this is to instantiate the custom peripheral’s top-level (not the auto-generated one) file(s) in user_logic. The rest of what goes on here is to the disgression of the programmer. Provided are just some ideas:

    1. If the user included FIFO/registers, and the peripheral is something like an MGT, the user can tie his/her MGT’s rx-data to one auto-generated register and the tx-data to another auto-generated register.
    2. Tie input ports of the user’s HDL module to indeces of a register for control-support
    3. Tie output ports of a user’s HDL module for debug-support

  10. The template drivers that were automatically generated provide the functions for writing and reading these registers. Thus the user has been granted PowerPC control of their peripheral. Alas, there is still work to be done before the peripheral can completely work.
  11. At this point, it is a good idea to re-scan the user repository, clean the hardware, and regenerate the bitstream for debugging any errors on the user’s part for tying their logic in with the auto-generated HDL.
  12. If this is successful, the user may now feed any top-level ports of their custom HDL that need to connect to other peripherals/external-FPGA-pins up through the user-logic and up to the actual auto-generated top-level file for their peripheral.
  13. The user must then modify the *.mpd file by providing all of the top-level ports and their direction type. If the port is a clock-type input, the user must also append “IOB_STATE=BUF” at the end of the port declaration.
  14. Re-scan the peripheral repositories in XPS, clean the hardware, and regenerate for one final step of syntax/heirchy debugging. At this point, the user may tie their peripheral into the rest of the system as necessary (assuming the user has a solid XPS background to do so)
  15. If all generates correctly, the user may test their peripheral and write C-code to control it using the generated template drivers. If there is an error, it is most likely in the user’s logic.

PREV: Creating Peripherals That do NOT Require PowerPC Control
| HOME | NEXT: Adding *.XBD Compliance to the Peripheral
Last modified 17 years ago Last modified on Jul 12, 2006, 12:04:20 AM