xilinx / zcu111-pynq

Board files to build the ZCU111 PYNQ image

🚫 This repository has been archived

The latest ZCU111 board files have moved to https://github.com/Xilinx/RFSoC-PYNQ.

SD card images for the ZCU111 can be found at http://www.pynq.io/board.

---

PYNQ Board Repository for the Zynq UltraScale+ RFSoC ZCU111

This repository contains source files and instructions for building PYNQ to run on the ZCU111 board.

ZCU111 Board Files

Clone this repo, download the ZCU111 petalinux BSP from here, and place it in the ZCU111 folder.

You can then build the image from the PYNQ repo's sdbuild folder with

make BOARDDIR=~/where/you/cloned/this/repo/to

Support

Please ask questions on the PYNQ support forum.

Licenses

Please see the LICENSE file for how the repository and packages are licensed.

zcu111-pynq's Issues

`implicit_type` should be added to `_props`

Package concerning: xrfdc.

The RF-DC c-drivers do not always have implicit setters and getters for one property. It is possible for a setter to be implicit while a getter is explicit and vice versa.

Consider:
u32 XRFdc_SetFabWrVldWords(XRFdc *InstancePtr, u32 Tile_Id, u32 Block_Id, u32 FabricWrVldWords);
and
u32 XRFdc_GetFabWrVldWords(XRFdc *InstancePtr, u32 Type, u32 Tile_Id, u32 Block_Id, u32 *FabricWrVldWordsPtr);

The write valid words function is only for RF-DAC blocks, while the get valid words function is common for both RF-DC blocks.

When parsing the _props tuples in __init__() the implicit_type should be used for each property.

Improve c_type unpacking by using recursive unpacking for a c_type that contains a c_type.

Package concerning: xrfdc.

When getting the IPStatus property of the rfdc class, the property returns a c_type. The xrfdc class fails to correctly unpack a c_type inside a c_type. Some sort of recursive unpacking is required to resolve this issue and simplify user interaction with the class.

ZCU216-PYNQ

Can anybody list the detailed steps for creating this repository for ZCU216 kit ....

Vivado IP Integrator and HDL Wrapper

I've been successfully running the provided RFSoC bitstreams with the "getting started RFSoC" project. I'm at a point now where I would like to create my own bitsream but am having trouble understanding how these overlay's map to a Vivado IP project. Is there any resources that show an IP Overlay creation in Vivado (specific to ZCU111), generate Bitstream, and create Python drivers for my custom IP Block design? At aminimum, an example Vivado project for the ZCU111 with corresponding Overlay would be extremely helpful.

Dict .update() call is not propagated to C driver in xrfdc

Issue raised in this forum post.

When working with dict properties in the xrfdc driver, we need to catch calls to .update() and ensure we pass this to the C driver.

For example, this code should update a subset of the mixer settings but currently does nothing:

event = xrfdc.EVNT_SRC_TILE
new_mixcfg = {
    'Freq' : 474.48,
    'PhaseOffset' : 0.1,
    'EventSource' : event
}
ol.dac_block.MixerSettings.update(new_mixcfg)
ol.dac_block.UpdateEvent(event)

Error with `ThresholdClearMode`

The ADC tile's ThresholdClearMode is broken in two ways:

1. It's calling a C function that doesn't exist ( ThresholdClearMode vs ThresholdClrMode)
2. This is write-only C driver, so assigning a value causes an error

I think we can take this as a chance to improve the way we handle thresholding in general. Backwards compatibility isn't so important when the feature never worked! I'd suggest we add a new level in the hierarchy where each ADC block has two thresholds --- each can be independently configured and cleared.

This deviates from the C API for XRFdc_SetThresholdSettings a little. They have different side-effects depending on the setting's UpdateThreshold field... this is very unnatural for a Python property (we'd expect it to appear side-effect free), and we could easily make this a little more idiomatic.