nanoSoC prototyping with Xilinx(R) PYNQ(R) platform

dflynn-University of Southampton
Xilinx ZCU104 ZYNQ UltraSCALE+ development board (dflynn-University of Southampton)

This example design flow supports the nanoSoC reference design with the Xilinx ZCU104 development board as a target. This FPGA prototyping environment has a large and capable ZYNQ UltraSCALE+ FPGA, and is fully supported out-of-the-box with Xilinx PYNQ development environment support. The PYNQ environment supports scripted control using Python to manage the FPGA overlays, and all through a built-in web-hosted server implemented on the ZYNQ Arm embedded processors that implements a Jupyter Notebook framework to support documentation and example usage.

Xilinx ZCU104 FPGA development board

Configuring the PYNQ platform

Comprehensive instructions for setting up the board are provided on the PYNQ site:

  https://pynq.readthedocs.io/en/v2.7.0/getting_started/zcu104_setup.html

Follow the instructions for setting up the hostname, non-default password, and network parameters, and ensure the (re-booted) system offers network services.

PYNQ setup for ZCU104 board

FPGA structuring for SoC test-bench

The approach adopted is to use the ZYNQ processing system configuration to provide clocking and reset control to the SoC "Design under Test" (DUT).

The System-on-Chip design is instantiated at the chip level just inside the pad-ring - to present input/output/tri-state-control unidirectional signals rather than bidirectional/tri-stated I/O-s. Care is taken to ensure that the DUT is built independent of Xilinx system IP so in this example flow, the microcontroller design (nanoSoC in this case) is imported in the form of an external IP component.

The testbench "wraps" the DUT with a "socket" that is built, customized to the SoC design using the standard Xilinx Vivado "Block Design" IPXact design capture and tools, to include any specific peripherals - a UART communications channel in this case, plus generic General Purpose Input Output (GPIO) control ports to monitor or stimulate the IO ports.

Testbench design captured in Vivado(R)

The Arm-based ZYNQ processing subsystem is completely independent of the SoC DUT but provides the master clock for the device, which can be reconfigured in the Vivado editor. [Set to 20MHz for basic functional testing in the example implementation flow]

PYNQ clocking control (under ZYNQ PS configuration)

FPGA build scripts

FPGA building of nanoSoC can be done directly using the makefiles by using the command:

make build_fpga FPGA=zcu104 ACCELERATOR=yes

If you have yet to include an accelerator in the design then you can set ACCELERATOR=no

This will run through the build scripts, the exact flow can be found in the makefile.fpga file here. The steps are:

  • package_socket - this packages the FPGA socket as a stand-alone IP. The socket captures communication and I/O from nanoSoC and gives an AXI subordinate to the Zynq processing system
  • package_nanosoc - this packages nanoSoC as a stand-alone IP. As mentioned previously, this is done at the chip level (just below the pad level)
  • build_nanosoc_design - builds the block structure shown previously, connecting the Zynq PS, socket and nanoSoc together
  • output_nanosoc_design - takes the output .xsa file and unzips it to the output directory (nominally: imp/fpga/output/zcu104/overlays)

Target board specific pin map and timing constraints are accessed from the nanosoc_tech/fpga/targets/pynq_zcu104 directory

The overlay and notebook output files are copied out to the directory:

  imp/fpga/output/zcu104/overlays

These files are then ready for use as Xilinx PYNQ programmable logic overlays.

FPGA programming

The PYNQ board, when successfully configured and connected to the network can be mounted as a file system and logged into from a browser.

The build scripts generate both the configuration bit-file (.bit) and hardware description (.hwh) files in the directory:

   imp/fpga/output/zcu104/overlays

(default names of nanosoc_chip.bit and nanosoc_chip.hwh)

Simply copy the imp/fpga/output/zcu104/overlays sub-tree in the PYNQ board pynq/overlays/ directory

Pynq Python Scripts

You can access the pynq environment over ssh and run python scripts directly in the pynq environment.

To enable the pynq environment run:

source /etc/profile.d/pynq_venv.sh 
source /etc/profile.d/xrt_setup.sh 
source /etc/profile.d/boardname.sh 

We have some example python scripts that are used for the nanoSoC CI/CD here

Jupyter Notebook interaction

You can also run Jupyter notebooks in the pynq environment using the instructions here:  https://pynq.readthedocs.io/en/v2.7.0/getting_started/zcu104_setup.html

It should be possible to connect and log into the PYNQ server from a web browser, and select the upload any jupyter notebookts

pynq jupyter notebook dir

Select the ipynb notebook document and this will allow the overlay files to be loaded, checked and run to communicate with the MCU in the FPGA design (through a serial communications driver in this case):

pynq jupyter notebook 1
Pynq Jupyter Notebook establishes Cortex-M0 communication

 

Projects Using This Design Flow

Competition 2024
Competition: Collaboration/Education

IMPLEMENTATION OF FIXED TIME BASED TRAFFIC LIGTH SYSTEM USING FPGA WITH VERILOG HDL.
Reference Design
Active Project
dwn @ soclabs

nanosoc re-usable MCU platform

Experts and Interested People

Members

Related Project Milestones

Project Name Target Date Completed Date Description
IMPLEMENTATION OF FIXED TIME BASED TRAFFIC LIGTH SYSTEM USING FPGA WITH VERILOG HDL. FPGA SoC prototyping with Xilinx(R) PYNQ(R) platform (151)

familiarize with the CAD tool.

Actions

Interested in this topic? Log-in to Add to Your Profile

Comments

Hi David,

Thank you for sharing this project! I've learned a lot from your code. A few comments on the FPGA Build Scripts:

  • For building the pynq_zcu104 project as well as the FPGA IP, a top level module was required to be set in the .tcl scripts; otherwise, all of the files get imported as "Unreferenced" and the project failed to build. I simply added: 

         set_property top cmsdk_mcu_chip [current_fileset]

    after reading in the verilog files in build_fpga_ip.tcl, and 

        set_property top design_1_wrapper [current_fileset]

    after creating the design wrapper in build_mcu_fpga_pynq_zcu104.tcl to fix this issue. 
     
  • Additionally, when creating the IP core, the ipx commands added Xilinx IP to a singular directory for some reason. This created the mcu custom IP to become locked, and I couldn't figure out how to "unlock" the IP. (I am using Vivado 2021.1 as well) In this case, I had to start from the beginning of build_mcu_fpga_pynq_zcu104.tcl. I ran all of the script until the ipx commands. I then used the GUI to manually package the IP with the appropriate settings. I then finished running the .tcl scripts to successfully get the bitstream for the chip.

Thank you for sharing your project!

-Meredith

Hi Meredith,

Thank you for your feedback and workaround. We will address these issues and reproduce them. It's great to see it now. This exemplary project is still in development and strengthened by you and other members of our community. We hope to get it run smoother as much as possible.

Many thanks,

Hakan

Thank you so much Meredith for the detailed review feedback.

I have checked back into git the 'set_property top' fixes identified, but have struggled and failed to get to the bottom of the 'locked' IP issue you reported (which I fail to reproduce in my environment for some reason). I build up the TCL commands from running the IP packaging from the command line and despite spending a fair time digging through the Xilinx documentation have failed to find a clean alternative version. [Would you mind emailing me the journal-transcript when you next run the IPX packaging just in case this is different to what my environment gives?]

Very best wishes and do hope your FPGA prototype is making good progress

  --David

Hey David,

I apologize for my late response. I have been working on other projects at the moment. I have tried to recreate the error with no success. The only thing I can think of- I have been running the .tcl script directly instead of the .scr. Maybe that has something to do with it. I plan on picking this project back up in a few weeks. If I run into this error, I'll be sure to document and share.

Meredith

I have updated the link to the git repository for the SoC Labs' Example Arm Cortex-M0-based microcontroller project. This will ensure that the FPGA implementation build scripts are also synced and updated simultaneously.

John - thanks for reviewing this - and my premature publishing of the confusing hierarchy:

  • https://soclabs.org/design-flow/fpga-prototyping ideally will become the generic Design Flow overview
  • https://soclabs.org/design-flow/fpga-soc-prototyping-xilinxr-pynqr-platform is a project specific example

So in some ways the second is a project that refers (to and from) the Cortex-M0 reference design project and could potentially be linked to form the first as a design-flow example.

Guidance on how to repair hierarchy would be valuable: I could only think of copying to new area and then deleting the original(?)

David,

As a community we are going to have to find our way in structuring information in ways that help us all.

The high level and generic design flow stages are traditionally described from Architectural -> Behavioural -> Logical -> Physical ...

Taking these generic flow stages and instantiating them in say a specific FPGA based flow or a specific ASIC fabrication flow and having the environment, tooling, and implementation specifics described in one place is useful.

I suggest we take some inspiration from object orientation in programming models. Perhaps this item ‘FPGA SoC prototyping with Xilinx…’ is a subclass (or derived class) of the more generic ‘FPGA prototyping’ which is a subclass of all specific design flows including for example ASIC flows.

In that case this should be a child of ‘FPGA prototyping’. You can achieve that by setting the relations in the item.

How to set subclass relations

I hope this helps, John.

image of navigation scheme showing generic high level flows and area for example flows

We have an initial view that has the four high level generic stages of the design flow and then an area where we describe specific example flows. Hopefully we will add some more example flows to David’s initial ‘example flow’ for the Xilinx(R) PYNQ(R) platform. As we develop some additional example flows we will try and discuss how the flow delivers the requirement of the general design flow steps.

Progress is being made to develop FPGA Prototyping design flows for the current and planned SoC Labs reference designs including determining the necessary FPGA resources required to accommodate the varying scale of the  SoC Labs reference design. Flows are being developed for the initial nanoSoC design and an A class reference design. There should be more details becoming available over the next few months.

Add new comment

To post a comment on this article, please log in to your account. New users can create an account.