How_to_make_a_"yellow"_block - david-macmahon/wiki_convert_test GitHub Wiki

This page currently describes in detail the process followed in creating a Simulink interface for an ADC block. This process is similar for any yellow blocks. The intention here is to remove some of the 'black magic' mystique of the toolflow in generating .bit/.bof files. PLEASE direct questions and feedback to the mailing list ([email protected]). If all goes well, you will be able to create the wrapper in less than a day of work, including time for lunch!

This process is filled with acronyms; if you see one that's unfamiliar, you may find it in the Appendix at the end.

Step 1: Create the top-level block (ETA: < 2 hours)

0. Name the block

  • Seriously. The name gets used over and over again, and it's PAINFUL if you want to change the name later. Take 2 minutes now and give it an awesome name. This guide will refer to the generic block being made as "block_name".

1. Draw the block

  • Open a new .mdl from the Simulink library Pull the block BEE_XPS/1new_yellow_block. This block is entirely blank. You can draw the simulation interface if necessary, or you can wait till later (Step 3). All ADCs should have a simulation interface to allow test signals from MATLAB)--otherwise the benefits of a Simulink based toolflow vanish if you can't simulate meaningfully.

2. Set the block tag

  • Right-click the block, select 'Block Properties...' Set the "Tag" field to the value "xps:block_name".

3. Edit "XPS_<hw_sys>_base/system.mhs" (Optional)

  • BACK THIS FILE UP IF YOU DO NOT HAVE PERSISTENT SVN ACCESS. Certain lines are added to the .mhs depending on which cores are instantiated. In this case, control wires from the OPB and other places are added to the file if and only if a block with the tag "xps:adc" is instantiated. Extend the necessary conditionals, demarcated with the "#IF# ()".

4. Create the folder 'mlib_devel_10_1/xps_library/@xps_block_name/'. This is a MATLAB OOP object.

  • The most important file here is "xps_block_name.m". See one of the many other folders starting with '@' for reference. The purpose of each type of struct is explained in greater detail on the wiki page XPS Block Class Fields Parameters can be passed down to your HDL by appropriate modification of the 'parameters' struct:

    Example: parameters.USE_ADC0 = '1';

    HDL pinouts: The struct 'ext_ports' specifies names for Xilinx V5 pins in the UCF.

    Format: ext_ports.io_port_name = { bit_width 'in'
ucf_port_name port_index 'vector=true' struct()
ucf_constraint_type}
  -
    Note: You do NOT need board schematics to look up the Xilinx
    pin names. Instead, they are listed in a table which you
    load from xps_library/BEE2_hw_routes.mat
Set your own values for bit_width, ucf_port_name,
port_index, ucf_constraint_type
  -
    Note 1: your ucf_port_name must match what your HDL
    expects at the top level.
    change ucf_constraint_type to the appropriate type (e.g.
    LVCMOS25 for single ended 2.5V signals, etc.) these
    constraints can be declared in the same file by
    Note 2: ucf_constraint_type = struct('IOSTANDARD',
    io_standard, 'DIFF_TERM', diff_term);
      -
        replace io_standard and diff_term by their appropriate
        values

    Specify the version number of your pcore

    Different version numbers allow multiple versions of you pcore
to live in harmony in the same directory. The version number is
specified in the EDK pcore folder name. Start with '1.00.a'.

Step 2: Integrate in the EDK pcore (ETA: 3 hours)

Xilinx EDK implements all of the standard features of Xilinx ISE, but in text based form (appropriate for development embedded in other programs). It has its own language similar in structure to VHDL/Verilog, with complete documentation. The vital information is contained mostly in the discussion of the *.mhs (Microprocessor Hardware Specification).

Root directory for new pcore: $MLIB_ROOT/xps_lib/PLATFORM_NAME/pcores/block_name_interface_v1_00_a/

  • data/

    block_name_interface_v2_1_0.bbd: Black Box Definition
  -
    List out .ngc filenames in '../netlist' that are used in
    '../hdl/\*'. This list is COMMA SEPARATED, not newline
    separated. Don't let Xilinx get you like it got Suraj.
block_name_interface_v2_1_0.mpd: Microprocessor Peripheral
Description
  -
    Sets the direction of the top-level interface ports.
block_name_interface_v2_1_0.pao: Peripheral Analysis Order
  -
    \- specify HDL MODULES (not FILES) that are referenced in
    the HDL code
    \- Try to start with the deepest module first. The order is
    semi-relevant.
\- The mysterious v2_1_0 is the result of the line "PARAMETER
VERSION = 2.1.0" in XPS_ROACH_base/system.mhs

    hdl/

    \- it is possible to use a mixture of Verilog and VHDL files IF
specified in the MPD
verilog/
vhdl/

    coregen/

    For Xilinx Coregen projects. Keep \*.xco, \*.cgp here.

    netlist/

    \- Black box files, possibly from the Xilinx Coregen. The only
required files are \*.xco, \*.veo, \*.ngc

With this directory in play, you're ready to start compiling. Start from MATLAB, run bee_xps, and compile your test design (can be as simple as just the new yellow block, the System Generator Tokens, and the MSSGE block). Error messages will print to the MATLAB prompt.

Step 3: Mask Scripting (ETA: Depends highly on the quality of the interface you want to make)

'mlib_devel_10_1/xps_library/block_name_mask.m'

  • The toolflow magic relies heavily on naming conventions. The main purpose of this file is to rename the 'Gateway In' blocks to follow this convention. Use an existing file for reference. Most of the work is in A Simulink Mask Scripting tutorial can be found here.

Appendix: Buzzwords

  • IO: Input/Output
  • UCF: User Constraints File. This is a file parsed by the Xilinx tools where all the necessary pins from the FPGA get aliased to designer-selected names.
  • V5: Virtex 5, the center part for the ROACH.
  • HDL: Hardware Description Language, specifically Verilog/VHDL
  • pcore: Peripheral Core
⚠️ **GitHub.com Fallback** ⚠️