Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for additional boards #151

Open
yyhanafy opened this issue Feb 24, 2022 · 4 comments
Open

Support for additional boards #151

yyhanafy opened this issue Feb 24, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@yyhanafy
Copy link

Hello and thank you for writing!
In general, supporting a different development board is not too complex, but there are three requirements:

  1. The FPGA (programming logic) must have direct access to DDR (satisfied for both ZCU102 and Alveo U280)
  2. The FPGA (programming logic) must have direct access to Ethernet (not satisfied)
  3. The FPGA (programming logic) must have direct access to a UART interface (satisfied for ZCU102, but not for Alveo U280)

We use a module from GRLIB to control the ESP instance via Ethernet, which means that the on-board Ethernet PHY should be connected directly to the FPGA fabric. The Alveo U280 does not have Ethernet, so it's not an option at the moment. The ZCU102, instead, does have it, but the on-board PHY is exposed to the PS-side Ethernet MAC, and not to the FPGA fabric. The PS-side Ethernet module does not support receiving debug messages; it can only be used as a normal peripheral.

Having said that, there is a more complicated, but feasible, solution for the ZCU102: it is possible to use one master port between the PS and the PL to control the ESP instance, thus replacing entirely the Ethernet debug module.
This solution is more complex than just porting the constrain files, because it requires some design changes.

A design template for the ZCU102 board is something we would like to have, because the board is very popular.
Would you be interested in contributing? This type of porting is not documented in a tutorial, because each FPGA board is slightly different and there is no single recipe to do it, but I can help with every step (feel free to email me if you are interested).

At a high level, these are the steps:

  • Create a design template without the GRETH IP from GRLIB and expose the AHB interface at the top-level module: edcl_ahbmo and edcl_ahbmi.
  • Create the mig.tcl script (using the Vivado IP Catalog) to generate the Xilinx MIG IP for the PL-side DDR4 and assuming to use the CLK_125 from the ZCU102 board as the reference clock.
  • Adapt the mig wrapper for the new IP (similar to what we did for the VCU118: ahb2mig_up.vhd)
  • Use the Vivado IP integrator to create a system with
    • the Zynq MPSoC processing system and its reset logic
    • one AXI2AHB-Lite adapter, connected to a master port PS (the PS is the master)
    • a reference clock for the ESP system
  • Define the address map of the AXI2AHB-Lite adapter: this will be the debug interface used by the ARM processor to control the instance of ESP
  • Create a wrapper that connects the ESP top with system generated at the previous step
  • Boot the ZYNQ with a basic image (e.g. our zynq-template) and use mmap to expose the AXI2AHB-Lite address range to user space. Then control ESP (e.g. load the bootloader on the bootrom, load the OS image in DDR, send the reset to the processor core, ...) by simply reading and writing to the appropriate offsets within the mmapped buffer.
  • Eventually wrap the calls to mmap in a higher-level C application.

Originally posted by @paulmnt in #68 (comment)

@yyhanafy yyhanafy reopened this Feb 24, 2022
@yyhanafy
Copy link
Author

I have a VC709 board which is very similar to the VC707, I think the changes needed should be minimal to create the new target, but I do not know where to start, I need some help doing that!!

Regards
--Y

@yyhanafy
Copy link
Author

yyhanafy commented Mar 2, 2022

From what I have seen so far, it's only the pin out that should be changed, specifically in the constraints folder? can somebody verify this?

@jzuckerman
Copy link
Member

Sorry for the delayed response. I'm not familiar with the VC709, but in general, when adding a new board you definitely need to change the pinout. You also may need to generate the MIG (memory controller) and SGMII (ethernet) IP for that particular board. You can see how that's done for the various supported boards in the constraints/ folder. If those IPs end up changing at all, you may need to create a new top.vhd in the corresponding folder in the socs directory for the new board. Hope this helps, and please follow up with other questions as you progress.

@jzuckerman jzuckerman added the enhancement New feature or request label Jul 24, 2023
@HelpDesperatelyNeeded
Copy link

I would like help trying to port the design to the Nexys A7-100T board.

I think that I need to create an IP in Vivado using your files first, then instantiate a memory controller or interface and the Ethernet IP in the IP integrator. However, I can't identify the files which should be used to create the first IP.

Do you think any other changes would be required?

Also, do you know what the correct values of L2, LLC and ACC cache set and way numbers for the SoC Generator GUI would be for the Nexys board?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants