MicroZed Chronicles: Pin Planning

Most of the boards we have examined in this series, have been development board with fixed IO providing limited flexibility. This makes…

Adam Taylor
5 years ago

Most of the boards we examined in this series have been development board with fixed IO providing limited flexibility. This makes using them pretty straightforward.

However, while working with a system on module (SoM) we face different challenges when we design our own carrier card as on a SoM all of the IO is broken out.

Therefore, we need to ensure the pin out is correct and that all of necessary design rules checks (DRC) pass before we commit to the carrier card design.

In this way working with a SoM is the same as developing our own Zynq / Zynq MPSoC board. We want to ensure:

  • The pin out is correct and does not break any banking rules.
  • The pin out provides a solution which is not excessively noisy when simultaneous switching is considered.

When it comes to ensuring the our pin out is correct, we can use a Vivado pin planning project.

All we need to get started with a pin planning project is a list of the inputs and outputs. Ideally within a CSV format, this can often be provided from the schematic entry tool.

If you are unable to access a CSV list of the ports, we can always use a TCL script once the project is open to add in the ports, e.g.

create_port TMP_I2C_SCL -direction out

Creating a pin planning project is very similar to creating a normal RTL project, but on the project type dialog we select I/O planning.

We then have the option to import either a CSV or XDC file which defines the ports and the initial location of the ports.

Once the project opens, we will see both the device footprint and the device overview.

One of the first things we can do is select the clock regions tab, choosing a clock region will highlight it both on the package and device view.

Using the I/O ports tab we can then define the IO standard, direction, drive strengths, pull ups, etc. for each port in the design. These parameters, of course, can be saved into a XDC file.

Once we have configured the ports as desired for the initial design, the next step is to allocate the ports to the package pins.

However, before we do so we may want to ensure some pins are not used. We do this, for example, in high reliability designs and if want to ensure a critical pin cannot short to another pin.

To prevent a pin from being used, within the package view we can select a pin, right click on it and select “set prohibit.”

When this is performed you will see a red circle with a diagonal line indicating the pin cannot be used with a port.

Upon completing the pin allocation, we are then able to double check the allocation does not break any rules by running the DRC.

We can select the most appropriate DRC from the rules. Any errors which are identified can then be corrected early in the project before they become fixed and unchangeable.

After we are happy with the DRC results, the final step is to analyse the simultaneous switching noise (SSN).

Once we have corrected pin out for both SSN and DRC issues, we can be happy that the pin out is one we can work with going forward for our design. We then have two options that we can write out the necessary XDC files and use them within an RTL project.

Alternatively, we can covert the pin planning project into an RTL project and get started on the development of our application.

See My FPGA / SoC Projects: Adam Taylor on Hackster.io

Get the Code: ATaylorCEngFIET (Adam Taylor)

Access the MicroZed Chronicles Archives with over 270 articles on the Zynq / Zynq MpSoC updated weekly at MicroZed Chronicles.’

Adam Taylor
Adam Taylor is an expert in design and development of embedded systems and FPGA’s for several end applications (Space, Defense, Automotive)
Latest articles
Sponsored articles
Related articles
Latest articles
Read more
Related articles