PinWire Config Files

Owned by Bill OLeary
Last updated: Oct 24, 2018


Important Concepts when using PinWire Config Files

The settings displayed in the pinWire GUI The PinWire Gui are what will be used to control how wires are named and terminated when the user hits the run button and selects the pins to wire.

The settings can be stored and recalled from a Configuration File (the COMP_CFG_FILE). The Select button in the Working Component section can be used to load the proper settings for the selected component. 

The location of the config files defaults to PROJ_DIR/CE_HDL/PIN_WIRE (where the PROJ_DIR top level .cpm files live)

It is important to backup the whole CE_HDL directory along with the rest of the design data so that the configs you created will be available for use when copying the design from one place to another. The user should include the CE_HDL directory when archiving the design as well.

If a user is working with a specific FPGA within a block, they can store off the settings for the component name given to that FPGA in that block.  For instance if there are 2 of the same FPGA devices in a design which perform different functions, the user can store different rules for each of the 2 FPGAS into 2 different COMP_CFG_FILES  and then recall them when they want to work on the specific instance. Each instance would have a different FPGA_PIN_REPORT, SIG_RENAME_RULES and PWR_RENAME_RULES file.

Lets say we have a design with 2 FPGAs, which are both xilinx XCVU7 devices. One is used as a MEMORY_CONTROLLER and the other is used to implement a PACKET_PROCESSOR. They both use the same schematic symbols of a generic XCVU7 device split into individual IO Banks. Lets say the symbol name is XCVU7_FF1156 

At a minimum the user will need to be able to select a different FPGA_PIN_REPORT for the MEMORY_CONTROLLER and the PACKET_PROCESSOR. The PWR_RAIL_RENAMES file will most likely be different as well, and the user might want to control wire renaming with the SIG_RENAME_RULES separately for each part.

If the design is hierarchical, and the 2 FPGA functions are contained in separate blocks, (lets call one  mem_ctl and the other pkt_proc), then PinWire makes it very easy to store and select the configurations because it automatically creates a config file to store the settings with the block_name concatenated to the component name. So it would create 2 config files named mem_ctl_xcvu7_ff1156_ctl.txt and pkt_proc_xcvu7_ff1156_ctl.txt. When the user uses the Select Component button, it will automatically select the COMP_CFG_FILES using the proper names and in doing so, it gets pinWire ready to work on the proper part. 

If the design is flat, it becomes a little trickier to automatically identify which symbols belong to the MEMORY_CONTROLLER and which belong to the PACKET_PROCESSOR. The user is responsible for picking the right configuration for each symbol they are connecting. So it would be up to the user to create 2 different config file, one for each FPGA in the flat design. (It would be wise to use a naming convention like what was automatically created in the hierarchical deisgn). When they are making connections for the selected FGPA, they will have to make sure they load the settings from the proper config file first.  

Future Musings....For flat designs it seems like adding an identifying property to each symbol for each instance of the FPGA would be very helpful. Lets name that property CE_PW_PART_FUNC. PinWire could concatenate the value of the CE_PW_PART_FUNC property at the end of the COMP_CFG_FILE name. Then it would just be up to the user to make sure the CE_PW_PART_FUNC is properly defined for each symbol instance (this would not be a trivial task for a component that spans more than a handful of symbols (like the large FPGAS we are discussing)  In our example, we could set the CE_PW_PART_FUNC to mem_ctl for all the symbols used to implement the MEMORY_CONTROLLER, and pkt_proc for all the symbols used to implement the PACKET_PROCESSOR.

These concerns are not isolated to FPGAs,  a different sets of SIG_RENAME_RULES and PWR_RAIL_RENAMES might also be required when instantiating multiple devices (large or small) that use the same set of component symbols.