Designing for the FPGA Pin Mapper

Ari Mahpour
|  Created: July 7, 2021  |  Updated: September 24, 2021
Designing for the FPGA Pin Mapper

It is a well-known fact that FPGA IO names must meet specific syntax requirements in Verilog or VHDL. The naming convention used in Altium Designer schematics doesn’t always meet these criteria specified by the hardware description languages (HDL). As a result, there can often be a mismatch between PCB net names and the actual FPGA signal names. As more users experiment with the FPGA Pin Mapper tool in Altium Designer, they will discover that the naming convention used in Altium Designer schematics may not always be legal in the FPGA design realm. This article will review some common pitfalls and ways to overcome those challenges when incorporating FPGAs into your PCB design project.

Net Naming Challenges

As mentioned in the introduction, it is common to find PCB designs using net names for FPGA IOs that don’t match the actual names in the FPGA HDL. This can occur simply because the engineer who designed the board may not sync with the FPGA designer who wrote the HDL. Another reason why this mismatch can occur is that the net names used in Altium Designer itself may not be legal in Verilog or VHDL. For example, net names such as “\c\h\i\p\_\r\s\t” (to indicate active low in the schematic) or SPI.MISO (a net brought out of a signal harness) is entirely legal in Altium Designer but not acceptable in HDL. To address “\c\h\i\p\_\r\s\t,” we need to make sure not to use the backslash. While it is fun to have that cute little bar go across your net names and ports, is it worth it? Appending an active low signal with “_n” (e.g. “reset_n”) or prepending it with “n” (e.g. “nRST”) is a general practice people will use in the HDL realm and would be good to be consistent with on the schematics as therefore this sell. Signal Harnesses in Altium Designer, however, require one extra step should you choose to use them.

Example: Signal Harnesses and FPGAs

We have a schematic sheet containing an FPGA IO bank and a few signal harnesses in the following example.

Figure 1: A simple schematic example using Signal Harnesses with an FPGA
Figure 1: A simple schematic example using Signal Harnesses with an FPGA

If you carefully look at the design, you will notice that the signal harness need not be broken out. All we need to do is reference the signal harness hierarchy using dot designators:

Figure 2: Using dot designators to expand a Signal Harness
Figure 2: Using dot designators to expand a Signal Harness

These signal harnesses are, in fact, just instantiations of a single harness type. We place them on the schematic by navigating to Place > Harness > Predefined Harness Connector.

Figure 3: Reusing Predefined Harnesses
Figure 3: Reusing Predefined Harnesses

Our Predefined Harness Connector looks like this:

Figure 4: Demonstration of a Predefined Harness
Figure 4: Demonstration of a Predefined Harness

In our schematic, we have instantiated three SPI harnesses: FLASH, SD, and ACTUATOR. Since we’re using the dot designator, there is nothing else we need to do.

Once we move to the FPGA Pin Mapper tool, we soon discover providing our FPGA designers with illegal signal names. In SystemVerilog, these “hierarchical names” would be useful to us if we were able to synthesize Interface Modports, but, alas, that is not supported by most FPGA tools when writing this article. As a result, the whole pin naming synchronization tool provides no use to us if we decide to use this net naming scheme.

Solution

To achieve harmony between the PCB design and the FPGA synthesis tools, we must use net names to be legal in our HDL. There can be many approaches to resolving this issue. In this article, we will review two different solutions.

The first option could be to keep your harness hierarchical names and perform pin swapping/synchronization within Altium Designer. Once the synchronization is complete, the FPGA pin file (CSV format) will be updated to reflect the changes performed in Altium Designer. These net names will now look like hierarchical names (e.g., “SPI.SDO”) which are not legal. A simple fix would be to add a stage of modifying the CSV pin file using an external script before importing it back into your FPGA design. If you want to run this operation in Altium Designer, this could be a Delphi script. If you’d like to run this in the FPGA tool, this could happen before importing the pin file into the FPGA synthesis tool (e.g., These extra lines in your TCL script when running Vivado). If you’d like to run it standalone, you could put together a very concise Python script to perform a string replace function for you as well.

Another option would be to expand the signal harnesses and then rename the nets. A simple, clean approach would be to replace the period with an underscore (e.g., This, “SPI.MISO becomes “SPI_MISO”) like so:

Figure 5: Using an underscore in replacement of a period for net names
Figure 5: Using an underscore in replacement of a period for net names

Make sure to keep your expanded harnesses separate from the FPGA IO net names to ensure proper pin swapping. Figure 6 demonstrates the separation between the expanded harnesses and the FPGA net names themselves.

Figure 6: Expanding Signal Harnesses to use legal net names
Figure 6: Expanding Signal Harnesses to use legal net names

This method requires a bit more work on the schematic side but ensures a clean transition from schematic capture to FPGA synthesis.

Conclusion

This article reviewed the challenges one may face when using specific net naming conventions and the FPGA Pin Mapper tool. One particular situation where issues occur is with Signal Harnesses and the FPGA Pin Mapper. Using hierarchical net names for Signal Harnesses, users will find that these names will not translate legally into the FPGA synthesis tool. Two proposed solutions were offered in the article: one focusing on script automation and the other requiring more work on the schematic capture side. Either solution will work. Therefore, this extra design should weigh which methodology works best for them.

Would you like to find out more about how Altium can help you with your next PCB design? Talk to an expert at Altium and learn more about making design decisions with ease and confidence.

About Author

About Author

Ari is an engineer with broad experience in designing, manufacturing, testing, and integrating electrical, mechanical, and software systems. He is passionate about bringing design, verification, and test engineers together to work as a cohesive unit.

Recent Articles

Back to Home