diff --git a/docs/source/changelog.rst b/docs/source/changelog.rst index c8b3112aee..571a329f33 100644 --- a/docs/source/changelog.rst +++ b/docs/source/changelog.rst @@ -254,4 +254,4 @@ Documentation updated: 16 Dec 2016 * Pmod Haptic motor * Pmod TH02 * Added USB WiFI driver - + \ No newline at end of file diff --git a/docs/source/getting_started.rst b/docs/source/getting_started.rst index 051d1d9306..e6c70bdd8b 100644 --- a/docs/source/getting_started.rst +++ b/docs/source/getting_started.rst @@ -13,6 +13,7 @@ If you have one of the following boards, you can follow the quick start guide. getting_started/pynq_z1_setup.rst getting_started/pynq_z2_setup.rst + getting_started/zcu104_setup.rst If you have another Zynq board see the following guide: @@ -34,9 +35,7 @@ Connecting to Jupyter Notebook Once your board is setup, to connect to Jupyter Notebooks open a web browser and navigate to: - * http://192.168.2.99:9090 If your board is connected to a computer via a static IP address - - * http://pynq:9090 if your board is connected to a router or network + * http://192.168.2.99 If your board is connected to a computer via a static IP address If your board is configured correctly you will be presented with a login @@ -50,7 +49,7 @@ After logging in, you will see the following screen: :align: center The default hostname is **pynq** and the default static IP address is -**192.168.2.99**. If you changed the hostname or static IP of the board, you +**192.168.2.99**. If you changed the static IP of the board, you will need to change the address you browse to. The first time you connect, it may take a few seconds for your computer to @@ -105,7 +104,6 @@ the navigation bar. .. code-block:: console \\192.168.2.99\xilinx # If connected to a Computer with a Static IP - \\pynq\xilinx # If connected to a Network/Router with DHCP When prompted, the username is **xilinx** and the password is **xilinx**. The following screen should appear: @@ -119,7 +117,6 @@ Location and type one of the following in the box: .. code-block:: console smb://192.168.2.99/xilinx # If connected to a Computer with a Static IP - smb://pynq/xilinx # If connected to a Network/Router with DHCP When prompted, the username is **xilinx** and the password is **xilinx** diff --git a/docs/source/getting_started/network_connection.rst b/docs/source/getting_started/network_connection.rst index 3aeaabe384..1530552cd7 100644 --- a/docs/source/getting_started/network_connection.rst +++ b/docs/source/getting_started/network_connection.rst @@ -23,7 +23,7 @@ Connect directly to a computer (Static IP): 1. :ref:`assign-your-computer-a-static-IP` 2. Connect the board to your computer's Ethernet port - 3. Browse to http://192.168.2.99:9090 + 3. Browse to http://192.168.2.99 Connect to a Network Router ^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -36,6 +36,6 @@ Connect to a Router/Network (DHCP): 1. Connect the Ethernet port on your board to a router/switch 2. Connect your computer to Ethernet or WiFi on the router/switch - 3. Browse to http://pynq:9090 or http://:9090 + 3. Browse to http:// 4. Optional: :ref:`change-the-hostname` 5. Optional: :ref:`configure-proxy-settings` diff --git a/docs/source/getting_started/other_boards.rst b/docs/source/getting_started/other_boards.rst index 63d503cff3..fc7818a0c4 100644 --- a/docs/source/getting_started/other_boards.rst +++ b/docs/source/getting_started/other_boards.rst @@ -34,7 +34,7 @@ off-the-shelf board, or a custom board you developed yourself. Board recommendations for development ------------------------------------- - * Any Zynq device (including single-core) + * Any Zynq/Zynq Ultrascale+ device (including single-core) * >=512 MB DRAM * SD Card (>=8GB) or other bootable source * Network connection; Ethernet or WiFi diff --git a/docs/source/getting_started/pynq_image.rst b/docs/source/getting_started/pynq_image.rst index 8ea3dbd346..815493f70d 100644 --- a/docs/source/getting_started/pynq_image.rst +++ b/docs/source/getting_started/pynq_image.rst @@ -4,21 +4,11 @@ PYNQ image ********** -PYNQ is delivered as a bootable image that can be written to an SD card or -other media and used to boot the board. +Pre-compiled images +------------------- -Supported boards ----------------- - -Pre-compiled images are available for the following boards and can be used -to make a bootable MicroSD card: - -=========================== ========================================================================================= - Board Download PYNQ image -=========================== ========================================================================================= - Pynq-Z1 board (Digilent) `Pynq-Z1 v2.1 image `_ - Pynq-Z2 board (TUL) `Pynq-Z2 v2.2 image `_ -=========================== ========================================================================================= +Pre-compiled images for supported boards can be found via the +`PYNQ boards `_ page. If you already have a MicroSD card preloaded with a PYNQ image for your board, you don't need to rewrite it unless you want to restore or update your diff --git a/docs/source/getting_started/zcu104_setup.rst b/docs/source/getting_started/zcu104_setup.rst new file mode 100644 index 0000000000..3f14d42f61 --- /dev/null +++ b/docs/source/getting_started/zcu104_setup.rst @@ -0,0 +1,72 @@ +.. _ZCU104-setup: + +******************* +ZCU104 Setup Guide +******************* + +Prerequisites +============= + + * `ZCU104 board `_ + * Computer with compatible browser (`Supported Browsers + `_) + * Ethernet cable + * Micro USB cable (optional) + * Micro-SD card with preloaded image, or blank card (Minimum 8GB recommended) + +Getting Started Video +===================== + +You can watch the getting started video guide, or follow the instructions in +:ref:`ZCU104-board-setup`. + +.. raw:: html + + + +
+
+ + +.. _ZCU104-board-setup: + +Board Setup +=========== + + .. image:: ../images/zcu104_setup.png + :align: center + + 1. Set the **Boot** Dip Switches (SW6) to the following positions: + (This sets the board to boot from the Micro-SD card) + + * Dip switch 1 (Mode 0): On (down position in diagram) + * Dip switch 2 (Mode 1): Off (up position in diagram) + * Dip switch 3 (Mode 2): Off (up) + * Dip switch 4 (Mode 3): Off (up) + + 2. Connect the 12V power cable. Note that the connector is keyed and can only + be connected in one way. + + 3. Insert the Micro SD card loaded with the appropriate PYNQ image into the + **MicroSD** card slot underneath the board + + 4. (Optional) Connect the USB cable to your PC/Laptop, and to the + **USB JTAG UART** MicroUSB port on the board + + 5. Connect the Ethernet port by following the instructions below + + 6. Turn on the board and check the boot sequence by following the instructions + below + +.. _turning-on-the-ZCU104: + +Turning On the ZCU104 +---------------------- + +As indicated in step 6, slide the power switch to the *ON* position to turn on +the board. A **Red** LED and some additional yellow board LEDs will come on to +confirm that the board has power. After a few seconds, the red LED will +change to **Yellow**. This indicates that the bitstream has been downloaded +and the system is booting. + + .. include:: network_connection.rst diff --git a/docs/source/glossary.rst b/docs/source/glossary.rst index d6d642c906..963d2d6dc6 100644 --- a/docs/source/glossary.rst +++ b/docs/source/glossary.rst @@ -15,7 +15,7 @@ A-G A board support package (BSP) is a collection of low-level libraries and drivers. The Xilinx® software development Kit (SDK) uses a BSP to form the lowest layer of your application software stack. Software applications must link against or run on top of a given software platform using the APIs that it provides. Therefore, before you can create and use software applications in SDK, you must create a board support package FPGA - `Field Programmable Gate Arrays (FPGAs) `_ are semiconductor devices that are based around a matrix of configurable logic blocks (CLBs) connected via programmable interconnects. FPGAs can be reprogrammed to desired application or functionality requirements after manufacturing. This feature distinguishes FPGAs from Application Specific Integrated Circuits (ASICs), which are custom manufactured for specific design tasks. + Field Programmable Gate Arrays (FPGAs) are semiconductor devices that are based around a matrix of configurable logic blocks (CLBs) connected via programmable interconnects. FPGAs can be reprogrammed to desired application or functionality requirements after manufacturing. This feature distinguishes FPGAs from Application Specific Integrated Circuits (ASICs), which are custom manufactured for specific design tasks. H-R === diff --git a/docs/source/images/hdmi_in_subsystem.png b/docs/source/images/hdmi_in_subsystem.png index 4341572aa9..6885982696 100644 Binary files a/docs/source/images/hdmi_in_subsystem.png and b/docs/source/images/hdmi_in_subsystem.png differ diff --git a/docs/source/images/hdmi_out_subsystem.png b/docs/source/images/hdmi_out_subsystem.png index 7635378c71..e46cd56991 100644 Binary files a/docs/source/images/hdmi_out_subsystem.png and b/docs/source/images/hdmi_out_subsystem.png differ diff --git a/docs/source/images/video_subsystem.png b/docs/source/images/video_subsystem.png index bfbd6ae8fb..b625aeb1c9 100644 Binary files a/docs/source/images/video_subsystem.png and b/docs/source/images/video_subsystem.png differ diff --git a/docs/source/images/zcu104_base_overlay.png b/docs/source/images/zcu104_base_overlay.png new file mode 100644 index 0000000000..0ec1c7e877 Binary files /dev/null and b/docs/source/images/zcu104_base_overlay.png differ diff --git a/docs/source/images/zcu104_setup.png b/docs/source/images/zcu104_setup.png new file mode 100644 index 0000000000..22d9db8efb Binary files /dev/null and b/docs/source/images/zcu104_setup.png differ diff --git a/docs/source/index.rst b/docs/source/index.rst index b05b5bb21c..be3491d2c6 100755 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -7,8 +7,8 @@ PYNQ Introduction ***************** -Xilinx® makes Zynq® devices, a class of All Programmable Systems on Chip (APSoC) -which integrates a multi-core processor (Dual-core ARM® Cortex®-A9) and a Field +Xilinx® makes Zynq® and Zynq Ultrascale+™ devices, a class of programmable System on Chip (SoC) +which integrates a multi-core processor (Dual-core ARM® Cortex®-A9 or Quad-core ARM® Cortex®-A53) and a Field Programmable Gate Array (FPGA) into a single integrated circuit. FPGA, or programmable logic, and microprocessors are complementary technologies for embedded systems. Each meets distinct requirements for embedded systems that @@ -19,8 +19,8 @@ Project Goals The main goal of **PYNQ**, **Py**\ thon Productivity for Zy\ **nq**, is to make it easier for designers of embedded systems to exploit the unique benefits of -APSoCs in their applications. Specifically, PYNQ enables architects, engineers -and programmers who design embedded systems to use Zynq APSoCs, without having +Xilinx devices in their applications. Specifically, PYNQ enables architects, engineers +and programmers who design embedded systems to use Zynq devices, without having to use ASIC-style design tools to design programmable logic circuits. PYNQ achieves this goal in three ways: @@ -62,7 +62,7 @@ PYNQ achieves this goal in three ways: operating system. This goal is achieved by adopting a web-based architecture, which is also browser agnostic. We incorporate the open-source Jupyter notebook infrastructure to run an Interactive Python (IPython) kernel and a - web server directly on the ARM Cortex A9 of the Zynq device. The web server + web server directly on the ARM processor of the Zynq device. The web server brokers access to the kernel via a suite of browser-based tools that provide a dashboard, bash terminal, code editors and Jupyter notebooks. The browser tools are implemented with a combination of JavaScript, HTML and CSS and run diff --git a/docs/source/jupyter_notebooks.ipynb b/docs/source/jupyter_notebooks.ipynb index 876d8df020..d6a7200570 100755 --- a/docs/source/jupyter_notebooks.ipynb +++ b/docs/source/jupyter_notebooks.ipynb @@ -491,7 +491,7 @@ }, { "cell_type": "code", - "execution_count": null, + "execution_count": 1, "metadata": {}, "outputs": [], "source": [ @@ -988,4 +988,4 @@ }, "nbformat": 4, "nbformat_minor": 1 -} +} \ No newline at end of file diff --git a/docs/source/pynq_libraries.rst b/docs/source/pynq_libraries.rst index 286d4e81ff..6afe4cd309 100644 --- a/docs/source/pynq_libraries.rst +++ b/docs/source/pynq_libraries.rst @@ -62,6 +62,7 @@ IP pynq_libraries/audio.rst pynq_libraries/axigpio.rst + pynq_libraries/axiiic.rst pynq_libraries/dma.rst pynq_libraries/logictools.rst pynq_libraries/video.rst @@ -103,7 +104,7 @@ PS control .. toctree:: :maxdepth: 1 - + pynq_libraries/pmbus.rst PL control @@ -114,3 +115,5 @@ PL control pynq_libraries/overlay.rst pynq_libraries/pl.rst + pynq_libraries/pynqmb_reference.rst + diff --git a/docs/source/pynq_libraries/axigpio.rst b/docs/source/pynq_libraries/axigpio.rst index 5c4503d192..840d9a5703 100644 --- a/docs/source/pynq_libraries/axigpio.rst +++ b/docs/source/pynq_libraries/axigpio.rst @@ -17,9 +17,21 @@ the PL. Each AXI GPIO can have up to two channels each with up to 32 pins. .. image:: ../images/gpio.png :align: center -The direction, and width of each channel can be set with the -``setdirection()``, and ``setlength()`` methods. -The ``read()`` and ``write()`` methods are used to read and write data. +The ``read()`` and ``write()`` methods are used to read and write data +on a channel (all of the GPIO). + +``setdirection()`` and ``setlength()`` can be used to configure the IP. +The direction can be 'in', 'out', and 'inout'. + +By default the direction +is 'inout'. Specifying 'in' or 'out' will only allow read and writes to +the IP respectively, and trying to *read* an 'out' or *write* an 'in' +will cause an error. + +The length can be set to only write a smaller range of the GPIO. + +The GPIO can also be treated like an array. This allows specific bits to +be set, and avoids the need to use a bit mask. The interrupt signal, *ip2intc_irpt* from the AXI GPIO can be connected directly @@ -33,54 +45,55 @@ section. The LED, Switch, Button and RGBLED classes extend the AxiGPIO controller and are customized for the corresponding peripherals. These classes -expect an AXI GPIO instance called ``[led|switche|button|rgbleds]_gpio`` +expect an AXI GPIO instance called ``[led|switch|button|rgbleds]_gpio`` to exist in the overlay used with this class. Examples -------- -Note that this example uses the AxiGPIO instances in the base overlay -directly with the AxiGPIO class. This example is for illustration, to show how to use the AxiGPIO class. -In practice, the LED, Button, Switches, and RGBLED classes which extend -the AxiGPIO class should be used for these peripherals. +In practice, the LED, Button, Switches, and RGBLED classes may be available +to extend the AxiGPIO class should be used for these peripherals in an overlay. After an overlay has been loaded, an AxiGPIO instance can be instantiated -by passing the AxiGPIO name to the class. +by passing the name of the AXI GPIO controller to the class. .. code-block:: Python from pynq import Overlay + from pynq.lib import AxiGPIO ol = Overlay("base.bit") - ip_instance = ol.ip_dict['leds_gpio'] - buttons = AxiGPIO(ip_instance).channel1 + led_ip = ol.ip_dict['gpio_leds'] + switches_ip = ol.ip_dict['gpio_switches'] + leds = AxiGPIO(led_ip).channel1 + switches = AxiGPIO(switches_ip).channel1 -.. code-block:: Python +Simple read and writes: - mask = 0x3 # Mask which controls which bits are written to +.. code-block:: Python - buttons.setdirection("out") - buttons.setlength(2) - buttons.write(0x2, mask) # Write 0x2 to the LEDs + mask = 0xffffffff + leds.write(0xf, mask) + switches.read() -.. code-block:: Python +Using AXI GPIO as an array: - ip_instance = ol.ip_dict['switches_gpio'] - switches = AxiGPIO(ip_instance).channel1 +.. code-block:: Python switches.setdirection("in") switches.setlength(3) switches.read() - More information about the AxiGPIO module and the API for reading, writing and waiting for interrupts can be found in the :ref:`pynq-lib-axigpio` sections. -For more examples see the "Buttons and LEDs demonstration" notebook on the -PYNQ-Z1 board at: +For more examples see the "Buttons and LEDs demonstration" notebook for the +PYNQ-Z1/PYNQ-Z2 board at: .. code-block:: console /base/board/board_btns_leds.ipynb + +The same notebook may be found in the corresponding folder in the GitHub repository. diff --git a/docs/source/pynq_libraries/axiiic.rst b/docs/source/pynq_libraries/axiiic.rst new file mode 100644 index 0000000000..00b7752c68 --- /dev/null +++ b/docs/source/pynq_libraries/axiiic.rst @@ -0,0 +1,30 @@ +.. _pynq-libraries-axiiic: + +AxiIIC +====== + +The AxiIIC class provides methods to read from , and write to an AXI IIC +controller IP. + + +The ``send()`` and ``receive()`` methods are used to read and write data. + +.. code-block:: Python + + send(address, data, length, option=0) + + * address is the address of the IIC peripheral + * data is an array of bytes to be sent to the IP + * length is the number of bytes to be transferred + * option allows an IIC *repeated start* + + .. code-block:: Python + receive(address, data, length, option=0) + + * address is the address of the IIC peripheral + * data is an array of bytes to receive data from the IP + * length is the number of bytes to be received + * option allows an IIC *repeated start* + +More information about the AxiIIC module and the API for reading, writing +and waiting can be found in the :ref:`pynq-lib-axiiic` sections. diff --git a/docs/source/pynq_libraries/dma.rst b/docs/source/pynq_libraries/dma.rst index 1672c87352..86a59def58 100644 --- a/docs/source/pynq_libraries/dma.rst +++ b/docs/source/pynq_libraries/dma.rst @@ -18,7 +18,7 @@ an IP. .. image:: ../images/dma.png :align: center -The read channel will read from PS DRAM, and write to a stream. The Write channel +The read channel will read from PS DRAM, and write to a stream. The write channel will read from a stream, and write back to PS DRAM. Note that the DMA expects any streaming IP connected to the DMA (write channel) to @@ -31,17 +31,24 @@ in the C code. Examples -------- -This example assumes the overlay contains two AXI Direct Memory Access IP, one -with a read channel from DRAM, and an AXI Master stream interface (for an output -stream), and the other with a write channel to DRAM, and an AXI Slave stream -interface (for an input stream). The two DMAs are connected in a loopback -configuration through an AXI FIFO. +This example assumes the overlay contains an AXI Direct Memory Access IP, +with a read channel (from DRAM), and an AXI Master stream interface (for an output +stream), and the other with a write channel (to DRAM), and an AXI Slave stream +interface (for an input stream). -In the Python code, two DMA instances are created, one for sending data, and the -other for receiving. +In the Python code, two contiguous memory buffers are created using ``Xlnk``. The +DMA will read the input_buffer and send the data to the AXI stream master. The +DMA will write back to the output_buffer from the AXI stream slave. +The AXI streams are connected in loopback so that after sending and receiving data +via the DMA the contents of the input buffer will have been transferred to the +output buffer. -Two memory buffers, one for input, and the other for output are allocated. +Note that when instantiating a DMA, the default maximum transaction size is +14-bits (i.e. 2^14 = 16KB). For larger DMA transactions, make sure to increase +this value when configuring the DMA in your Vivado IPI design. + +The code to download the bitstream is not shown. .. code-block:: Python @@ -51,8 +58,7 @@ Two memory buffers, one for input, and the other for output are allocated. xlnk = Xlnk() - dma_send = ol.axi_dma_from_ps_to_pl - dma_recv = ol.axi_dma_from_pl_to_ps + dma = ol.axi_dma input_buffer = xlnk.cma_array(shape=(5,), dtype=np.uint32) output_buffer = xlnk.cma_array(shape=(5,), dtype=np.uint32) @@ -72,10 +78,10 @@ Transfer the input_buffer to the send DMA, and read back from the recv DMA to th .. code-block:: Python - dma_send.sendchannel.transfer(input_buffer) - dma_recv.recvchannel.transfer(output_buffer) - dma_send.sendchannel.wait() - dma_recv.recvchannel.wait() + dma.sendchannel.transfer(input_buffer) + dma.recvchannel.transfer(output_buffer) + dma.sendchannel.wait() + dma.recvchannel.wait() .. code-block:: console diff --git a/docs/source/pynq_libraries/mmio.rst b/docs/source/pynq_libraries/mmio.rst index 742f7ae66c..8aabc78961 100644 --- a/docs/source/pynq_libraries/mmio.rst +++ b/docs/source/pynq_libraries/mmio.rst @@ -41,8 +41,8 @@ In this example, data is written to an IP and read back from the same address. mmio = MMIO(IP_BASE_ADDRESS, ADDRESS_RANGE) data = 0xdeadbeef - self.mmio.write(ADDRESS_OFFSET, data) - result = self.mmio.read(ADDRESS_OFFSET) + mmio.write(ADDRESS_OFFSET, data) + result = mmio.read(ADDRESS_OFFSET) This example assumes the memory mapped area defined for the MMIO, from ``0x40000000`` to ``0x40001000``, is accessible to the PS. diff --git a/docs/source/pynq_libraries/pmbus.rst b/docs/source/pynq_libraries/pmbus.rst index 369f9f21c0..9e2814e7f7 100644 --- a/docs/source/pynq_libraries/pmbus.rst +++ b/docs/source/pynq_libraries/pmbus.rst @@ -9,7 +9,7 @@ libsensors API (https://github.com/lm-sensors/lm-sensors) to provide access to monitoring sensors. ``pynq.pmbus`` API ----------------- +------------------ All sensors can be found using the ``pynq.get_rails()`` function which returns a dictionary mapping the name of the voltage rail to a ``Rail`` class. Each ``Rail`` @@ -17,7 +17,7 @@ has members for the ``voltage``, ``current`` and ``power`` sensors, the current reading of which can be obtained from the ``value`` attribute. The ``DataRecorder`` ------------------- +-------------------- The other aspect of the PMBus library is the ``DataRecorder`` class which provides a simple way to record the values of one or more sensors during a diff --git a/docs/source/pynq_overlays.rst b/docs/source/pynq_overlays.rst index 8f4c0173e6..146e4e16be 100644 --- a/docs/source/pynq_overlays.rst +++ b/docs/source/pynq_overlays.rst @@ -43,3 +43,4 @@ by many other software developers working at the application level. pynq_overlays/loading_an_overlay.ipynb pynq_overlays/pynqz1 pynq_overlays/pynqz2 + pynq_overlays/zcu104 diff --git a/docs/source/pynq_overlays/loading_an_overlay.ipynb b/docs/source/pynq_overlays/loading_an_overlay.ipynb index c523ebf143..ee36a23d9f 100644 --- a/docs/source/pynq_overlays/loading_an_overlay.ipynb +++ b/docs/source/pynq_overlays/loading_an_overlay.ipynb @@ -6,7 +6,11 @@ "source": [ "# Loading an Overlay\n", "\n", - "By default, the *base* overlay is loaded at boot time on PYNQ-Z1 board. New overlays can be installed or copied to the board and can be loaded as the system is running. \n", + "By default, an overlay (bitstream) called *base* is downloaded into", + "the PL at boot time. The *base* overlay can be considered like", + "a reference design for a board.\n", + "New overlays can be installed or copied to ", + "the board and can be loaded into the PL as the system is running. \n", "\n", "An overlay usually includes:\n", "\n", diff --git a/docs/source/pynq_overlays/pynqz1.rst b/docs/source/pynq_overlays/pynqz1.rst index 46e88bf665..871286d8fe 100644 --- a/docs/source/pynq_overlays/pynqz1.rst +++ b/docs/source/pynq_overlays/pynqz1.rst @@ -4,10 +4,23 @@ PYNQ-Z1 Overlays **************** -The PYNQ-Z1 has a Zynq XC7Z020-1CLG400C, 512MB DDR3, 1G Ethernet, USB 2.0, -MicroSD, Uart, Microphone, 3.5mm mono audio output jack, 2x HDMI that can be -used as input/output, 4 push-buttons, 2 slide switches, 4 LEDs, 2 RGB LEDs, -2x Pmod ports, and 1x Arduino header. +The PYNQ-Z1 board has the following features: + + * Zynq XC7Z020-1CLG400C + * 512MB DDR3 + * 1G Ethernet + * USB 2.0 + * MicroSD + * Uart + * Microphone + * 3.5mm mono audio output jack + * 2x HDMI (can be used as input or output) + * 4 push-buttons + * 2 slide switches + * 4 LEDs + * 2 RGB LEDs + * 2x Pmod ports + * 1x Arduino header For details on the PYNQ-Z1 board including `PYNQ-Z1 reference manual `_ diff --git a/docs/source/pynq_overlays/pynqz2.rst b/docs/source/pynq_overlays/pynqz2.rst index f4377b6e84..cc994566ef 100644 --- a/docs/source/pynq_overlays/pynqz2.rst +++ b/docs/source/pynq_overlays/pynqz2.rst @@ -4,11 +4,25 @@ PYNQ-Z2 Overlays **************** -The PYNQ-Z2 has a Zynq XC7Z020-1CLG400C, 512MB DDR3, 1G Ethernet, USB 2.0, -MicroSD, Uart, Microphone, 3.5mm mono audio output jack, 2x HDMI that can be -used as input/output, 4 push-buttons, 2 slide switches, 4 LEDs, 2 RGB LEDs, -2x Pmod ports, and 1x Arduino header and 1x RaspberryPi header. Note that 8 -pins of the RaspberryPi header are shared with one of the Pmod ports. +The PYNQ-Z2 board has the following features: + + * Zynq XC7Z020-1CLG400C + * 512MB DDR3 + * 1G Ethernet + * USB 2.0 + * MicroSD + * Uart + * ADAU1761 Audio Codec with 3.5mm HP/Mic and line-in jacks + * 2x HDMI (can be used as input or output) + * 4 push-buttons + * 2 slide switches + * 4 LEDs + * 2 RGB LEDs + * 2x Pmod ports + * 1x Arduino header + * 1x RaspberryPi header + +Note that 8 pins of the RaspberryPi header are shared with one of the Pmod ports. For details on the PYNQ-Z2 board including reference manual, schematics, constraints file (xdc), @@ -16,7 +30,6 @@ see the `PYNQ-Z2 webpage `_ The following overlays are include by default in the PYNQ image for the PYNQ-Z2 board: - .. toctree:: :maxdepth: 1 diff --git a/docs/source/pynq_overlays/zcu104.rst b/docs/source/pynq_overlays/zcu104.rst new file mode 100644 index 0000000000..c252d2d9d3 --- /dev/null +++ b/docs/source/pynq_overlays/zcu104.rst @@ -0,0 +1,66 @@ +.. _ZCU104-overlays: + +**************** +ZCU104 Overlays +**************** + +The ZCU104 board has the following features: + +Device + + * Zynq UltraScale+ XCZU7EV-2FFVC1156 MPSoC + +Configuration + + * USB-JTAG FT4232H + * Dual Quad-SPI flash memory + * MicroSD Card + +Memory + + * PS DDR4 64-bit Component + * Quad-SPI flash + * Micro SD card slot + +Control & I/O + + * 4x directional pushbuttons + * DIP switches + * PMBUS, clocks, and I2C bus switching + * USB2/3 + +Expansion Connectors + + * FMC LPC (1x GTH) + * 3 PMOD connectors + * PL DDR4 SODIMM Connector – 64 bit + +Communication & Networking + + * USB-UARTs with FT4232H JTAG/3xUART Bridge + * RJ-45 Ethernet connector + * SATA (M.2) for SSD access + +Display + + * HDMI 2.0 video input and output (3x GTH) + * DisplayPort (2x GTR) + +Power + + * 12V wall adaptor or ATX + +For details on the ZCU104 board including reference manual, schematics, +constraints file (xdc), +see the `Xilinx ZCU104 webpage `_ + +The following overlays are include by default in the PYNQ image for the ZCU104 board: + +.. toctree:: + :maxdepth: 1 + + zcu104/zcu104_base_overlay + +Other third party overlays may also be available for this board. See the +`PYNQ community webpage `_ for details of +third party overlays and other resources. \ No newline at end of file diff --git a/docs/source/pynq_overlays/zcu104/zcu104_base_overlay.rst b/docs/source/pynq_overlays/zcu104/zcu104_base_overlay.rst new file mode 100644 index 0000000000..e9ed6cbe0b --- /dev/null +++ b/docs/source/pynq_overlays/zcu104/zcu104_base_overlay.rst @@ -0,0 +1,162 @@ +.. _ZCU104-base-overlay: + +Base Overlay +============ + +The purpose of the *base* overlay design for any PYNQ supported board is to +allow peripherals on a board to be used out-of-the-box. + +The design includes hardware IP to control peripherals on +the target board, and connects these IP blocks to the Zynq PS. If a base +overlay is available for a board, peripherals can be used from the Python +environment immediately after the system boots. + +Board peripherals typically include GPIO devices (LEDs, Switches, Buttons), +Video, and other custom interfaces. + +As the base overlay includes IP for the peripherals on a board, it can also be +used as a reference design for creating new customized overlays. + +In the case of general purpose interfaces, for example Pmod or Arduino headers, +the base overlay may include a PYNQ MicroBlaze. A PYNQ MicroBlaze allows +control of devices with different interfaces and protocols on the same port +without requiring a change to the programmable logic design. + +See :ref:`pynq-libraries` for more information on PYNQ MicroBlazes. + +ZCU104 Block Diagram +-------------------- + +.. image:: ../../images/zcu104_base_overlay.png + :align: center + + +The base overlay on ZCU104 includes the following hardware: + + * DisplayPort & HDMI (Input and Output) + * User LEDs, Switches, Pushbuttons + * 2x Pmod PYNQ MicroBlaze + + +HDMI +---- + +The ZCU104 has 2x HDMI ports supporting HDMI 2.0 video input and output. The +HDMI interfaces are controlled by HDMI IP in the programmable logic. + +The HDMI IP is connected through a video DMA to PS DRAM. Video can be streamed +from the +HDMI *in* to memory, and from memory to HDMI *out*. This allows processing of +video data from python, or writing an image or Video stream from Python to the +HDMI out. + +Note that the ZCU104 also has a DisplayPort connected to the PS. While the +Display port is not part of the Overlay (as it is always connected) video data +can be streamed from the HDMI PL sources +to the DisplayPort. + +Note that while Jupyter notebook supports embedded video, video captured from +the HDMI will be in raw format and would not be suitable for playback in a +notebook without appropriate encoding. + +HDMI In +^^^^^^^ + +The HDMI in IP can capture standard HDMI resolutions. After a HDMI source has +been connected, and the HDMI controller for the IP is started, it will +automatically detect the incoming data. The resolution can be read from the HDMI +Python class, and the image data can be streamed to the PS DRAM. + +HDMI Out +^^^^^^^^ + +Data can be streamed from the PS DRAM to the HDMI output. The HDMI Out +controller contains framebuffers to allow for smooth display of video data. + +See example video notebooks in the ``/base/video`` directory +on the board. + + +User IO +------- + +The board has 4x user LEDs, 4x dip-switches, 4x push buttons. These IO are +controlled via AXI GPIO controllers in the PL. +In the ZCU104 base overlay, these IO are routed to the PS GPIO, and can be +controlled directly from Python. + +PYNQ MicroBlaze +--------------- + +PYNQ MicroBlazes are dedicated MicroBlaze soft-processor +subsystems that allow peripherals with different IO standards to be connected to +the system on demand. This allows a software programmer to use a wide range of +peripherals with different interfaces and protocols. By using a PYNQ MicroBlaze, +the same overlay can be used to support different peripheral without requiring a +different overlay for each peripheral. + +The ZCU has 2x Pmod PYNQ MicroBlaze, one connected to PMOD 0, and the other to PMOD 1. connecting to each type of corresponding interface. +Note that PMOD 2 is connected to the PS I2C and is not available as a general purpose Pmod port. + +PYNQ MicroBlaze block diagram and examples can be found in +:ref:`pynq-microblaze-subsystem`. + +Python API +---------- + +The Python API for the peripherals in the base overlay is covered in +:ref:`pynq-libraries`. Example notebooks are also provided on the board to +show how to use the base overlay. + +Rebuilding the Overlay +---------------------- + +The project files for the overlays can be found here: + +.. code-block:: console + + /boards//base + +Linux +^^^^^ +A Makefile is provided to rebuild the base overlay in Linux. The Makefile calls +two tcl files. The first Tcl files compiles any HLS IP used in the design. The +second Tcl builds the overlay. + +To rebuild the overlay, source the Xilinx tools first. Then assuming PYNQ has +been cloned: + +.. code-block:: console + + cd /boards/ZCU104/base + make + +Windows +^^^^^^^ +In Windows, the two Tcl files can be sourced in Vivado to rebuild the overlay. +The Tcl files to rebuild the overlay can be sourced from the Vivado GUI, or +from the Vivado Tcl Shell (command line). + +To rebuild from the Vivado GUI, open Vivado. In the Vivado Tcl command line +window change to the correct directory, and source the Tcl files as indicated +below. + +Assuming PYNQ has been cloned: + +.. code-block:: console + + cd /boards/ZCU104/base + source ./build_base_ip.tcl + source ./base.tcl + +To build from the command line, open the Vivado Tcl Shell, and run the +following: + +.. code-block:: console + + cd /boards/ZCU104/base + vivado -mode batch -source build_base_ip.tcl + vivado -mode batch -source base.tcl + +Note that you must change to the overlay directory, as the tcl files has +relative paths that will break if sourced from a different location. diff --git a/docs/source/pynq_package.rst b/docs/source/pynq_package.rst index 7f64093db0..86467b0bf5 100644 --- a/docs/source/pynq_package.rst +++ b/docs/source/pynq_package.rst @@ -25,9 +25,12 @@ Data Movement modules: Sysfs API * pynq.xlnk - Implements Contiguous Memory Allocation for PYNQ DMA -Interrupt/AsyncIO Module: + +Additional modules: * pynq.interrupt - Implements PYNQ asyncio + * pynq.pmbus - PYNQ class for reading power measurements from PMBus + * pynq.uio - Sub-packages: @@ -37,15 +40,14 @@ Sub-packages: .. toctree:: :hidden: - - pynq_package/pynq.interrupt + pynq_package/pynq.gpio + pynq_package/pynq.interrupt pynq_package/pynq.lib pynq_package/pynq.mmio pynq_package/pynq.overlay - pynq_package/pynq.ps pynq_package/pynq.pl + pynq_package/pynq.ps + pynq_package/pynq.pmbus + pynq_package/pynq.uio pynq_package/pynq.xlnk - - - diff --git a/docs/source/pynq_package/pynq.lib.rst b/docs/source/pynq_package/pynq.lib.rst index 2ef9c7ac73..11ca683ddc 100644 --- a/docs/source/pynq_package/pynq.lib.rst +++ b/docs/source/pynq_package/pynq.lib.rst @@ -24,17 +24,18 @@ Subpackages: .. toctree:: :hidden: + pynq.lib/pynq.lib.arduino pynq.lib/pynq.lib.audio pynq.lib/pynq.lib.axigpio + pynq.lib/pynq.lib.axiiic pynq.lib/pynq.lib.button pynq.lib/pynq.lib.dma pynq.lib/pynq.lib.led + pynq.lib/pynq.lib.logictools + pynq.lib/pynq.lib.pmod pynq.lib/pynq.lib.pynqmicroblaze pynq.lib/pynq.lib.rgbled + pynq.lib/pynq.lib.rpi pynq.lib/pynq.lib.switch - pynq.lib/pynq.lib.usb_wifi pynq.lib/pynq.lib.video - pynq.lib/pynq.lib.arduino - pynq.lib/pynq.lib.pmod - pynq.lib/pynq.lib.rpi - pynq.lib/pynq.lib.logictools + pynq.lib/pynq.lib.wifi diff --git a/docs/source/pynq_package/pynq.lib/pynq.lib.axigpio.rst~ b/docs/source/pynq_package/pynq.lib/pynq.lib.axigpio.rst~ deleted file mode 100644 index 86e82338b5..0000000000 --- a/docs/source/pynq_package/pynq.lib/pynq.lib.axigpio.rst~ +++ /dev/null @@ -1,7 +0,0 @@ -pynq.lib.axigpio Module -===================== - -.. automodule:: pynq.lib.axigpio - :members: - :undoc-members: - :show-inheritance: diff --git a/docs/source/pynq_package/pynq.lib/pynq.lib.axiiic.rst b/docs/source/pynq_package/pynq.lib/pynq.lib.axiiic.rst new file mode 100644 index 0000000000..7a7ec72463 --- /dev/null +++ b/docs/source/pynq_package/pynq.lib/pynq.lib.axiiic.rst @@ -0,0 +1,12 @@ +.. _pynq-lib-axiiic: + +pynq.lib.axiiic Module +======================= + +The pynq.lib.axiiic module is a driver for interacting with the Xilinx Axi IIC +IP Block. + +.. automodule:: pynq.lib.iic + :members: + :undoc-members: + :show-inheritance: diff --git a/docs/source/pynq_package/pynq.lib/pynq.lib.logictools.rst b/docs/source/pynq_package/pynq.lib/pynq.lib.logictools.rst index c17c66dfd8..b10a9881f6 100644 --- a/docs/source/pynq_package/pynq.lib/pynq.lib.logictools.rst +++ b/docs/source/pynq_package/pynq.lib/pynq.lib.logictools.rst @@ -34,3 +34,11 @@ pynq.lib.logictools.trace_analyzer Module :members: :undoc-members: :show-inheritance: + +pynq.lib.logictools.waveform Module +----------------------------------- + +.. automodule:: pynq.lib.logictools.waveform + :members: + :undoc-members: + :show-inheritance: diff --git a/docs/source/pynq_package/pynq.lib/pynq.lib.logictools.rst~ b/docs/source/pynq_package/pynq.lib/pynq.lib.logictools.rst~ deleted file mode 100644 index b3280b59d4..0000000000 --- a/docs/source/pynq_package/pynq.lib/pynq.lib.logictools.rst~ +++ /dev/null @@ -1,4 +0,0 @@ -pynq.lib.logictools Package -=========================== - - diff --git a/docs/source/pynq_package/pynq.lib/pynq.lib.usb_wifi.rst b/docs/source/pynq_package/pynq.lib/pynq.lib.usb_wifi.rst deleted file mode 100644 index e034974507..0000000000 --- a/docs/source/pynq_package/pynq.lib/pynq.lib.usb_wifi.rst +++ /dev/null @@ -1,10 +0,0 @@ -pynq.lib.usb_wifi Module -======================== - -The pynq.lib.usb_wifi module is a python module for interacting with USB WiFI -dongles. This module can be used to connect and disconnect to wireless networks. - -.. automodule:: pynq.lib.usb_wifi - :members: - :undoc-members: - :show-inheritance: diff --git a/docs/source/pynq_package/pynq.lib/pynq.lib.video.rst b/docs/source/pynq_package/pynq.lib/pynq.lib.video.rst index 4a3f291fe7..6af0361417 100644 --- a/docs/source/pynq_package/pynq.lib/pynq.lib.video.rst +++ b/docs/source/pynq_package/pynq.lib/pynq.lib.video.rst @@ -6,7 +6,76 @@ pynq.lib.video Module The pynq.lib.video module is a driver capturing streaming HDMI input, producing streaming HDMI output and hardware-accelerated colorspace conversion. -.. automodule:: pynq.lib.video + +pynq.lib.video.clocks Module +---------------------------- + +.. automodule:: pynq.lib.video.clocks + :members: + :undoc-members: + :show-inheritance: + +pynq.lib.video.common Module +---------------------------- + +.. automodule:: pynq.lib.video.common + :members: + :undoc-members: + :show-inheritance: + +pynq.lib.video.dma Module +------------------------- + +.. automodule:: pynq.lib.video.dma + :members: + :undoc-members: + :show-inheritance: + +pynq.lib.video.drm Module +------------------------- + +.. automodule:: pynq.lib.video.drm + :members: + :undoc-members: + :show-inheritance: + +pynq.lib.video.dvi Module +------------------------- + +.. automodule:: pynq.lib.video.dvi + :members: + :undoc-members: + :show-inheritance: + +pynq.lib.video.frontend Module +------------------------------ + +.. automodule:: pynq.lib.video.frontend :members: :undoc-members: :show-inheritance: + + +pynq.lib.video.hierarchies Module +--------------------------------- + +.. automodule:: pynq.lib.video.hierarchies + :members: + :undoc-members: + :show-inheritance: + +pynq.lib.video.pipeline Module +------------------------------ + +.. automodule:: pynq.lib.video.pipeline + :members: + :undoc-members: + :show-inheritance: + +pynq.lib.video.xilinx_hdmi Module +--------------------------------- + +.. automodule:: pynq.lib.video.xilinx_hdmi + :members: + :undoc-members: + :show-inheritance: \ No newline at end of file diff --git a/docs/source/pynq_package/pynq.lib/pynq.lib.wifi.rst b/docs/source/pynq_package/pynq.lib/pynq.lib.wifi.rst new file mode 100644 index 0000000000..f5a16a77f7 --- /dev/null +++ b/docs/source/pynq_package/pynq.lib/pynq.lib.wifi.rst @@ -0,0 +1,10 @@ +pynq.lib.wifi Module +==================== + +The pynq.lib.wifi module is a python module for interacting with WiFI adapters. +This module can be used to connect and disconnect to wireless networks. + +.. automodule:: pynq.lib.wifi + :members: + :undoc-members: + :show-inheritance: diff --git a/docs/source/pynq_package/pynq.pmbus.rst b/docs/source/pynq_package/pynq.pmbus.rst new file mode 100644 index 0000000000..9aca62ffc8 --- /dev/null +++ b/docs/source/pynq_package/pynq.pmbus.rst @@ -0,0 +1,9 @@ +.. _pynq-pmbus: + +pynq.pmbus Module +================= + +.. automodule:: pynq.pmbus + :members: + :undoc-members: + :show-inheritance: diff --git a/docs/source/pynq_package/pynq.uio.rst b/docs/source/pynq_package/pynq.uio.rst new file mode 100644 index 0000000000..a31cf69ed9 --- /dev/null +++ b/docs/source/pynq_package/pynq.uio.rst @@ -0,0 +1,9 @@ +.. _pynq-uio: + +pynq.uio Module +=============== + +.. automodule:: pynq.uio + :members: + :undoc-members: + :show-inheritance: diff --git a/docs/source/pynq_sd_card.rst b/docs/source/pynq_sd_card.rst index 3578cbc6eb..925755c0e3 100644 --- a/docs/source/pynq_sd_card.rst +++ b/docs/source/pynq_sd_card.rst @@ -32,18 +32,19 @@ and recent VM image is recommended. The flow provided has been tested on Ubuntu To build the image follow the steps below: - 1. Install the correct version of Vivado and SDK + 1. Install the correct version of PetaLinux and optionally Vivado and SDK 2. Install dependencies using the following script -The correct version of the Vivado and SDK is shown below: +The correct version of Xilinx tools for each PYNQ release is shown below: ================ ================ -Release version Vivado and SDK +Release version Xilinx Tool Version ================ ================ v1.4 2015.4 v2.0 2016.1 v2.1 2017.4 v2.2 2017.4 +v2.3 2018.2 ================ ================ .. code-block:: console @@ -59,101 +60,91 @@ v2.2 2017.4 cd /sdbuild/ make -The build flow can take several hours. +The build flow can take several hours. By default images for all of the +supported boards will be built. To build for specific boards then pass a +``BOARDS`` variable to make + +.. code-block:: console + + make BOARDS=Pynq-Z1 Retargeting to a Different Board ================================ -While the root filesystem is portable between different Zynq boards the boot -files will have to be customised for each board. The boot files can be found in - -.. code-block:: console - - /sdbuild/boot_configs +Additional boards are supported through external *board repositories*. A board +repository consists of a directory for each board consisting of a spec file and +any other files. The board repository is treated the same way as the ``/boards`` directory. -There is a standardised flow for Zynq-7000 boards defined in +Elements of the specification file +---------------------------------- -.. code-block:: console - - /sdbuild/boot_configs/common/Zynq7000.makefile +The specification file should be name ``.spec`` where BOARD is the name +of the board directory. A minimal spec file contains the following information -This file is customised by setting a number of variables and providing paths to -some setup scripts. The Board-specific ``config`` file is by convention placed -in: +.. code-block:: makefile -.. code-block:: console - - /sdbuild/boot_configs/-defconfig + ARCH_${BOARD} := arm + BSP_${BOARD} := mybsp.bsp + BITSTREAM_${BOARD} := mybitstream.bsp +where ``${BOARD}`` is also the name of the board. The ARCH should be arm for +Zynq-7000 or aarch64 for Zynq UltraScale+. If no bitstream is provided then the +one included in the BSP will be used by default. All paths should be relative +to the board directory. -Variables in config -------------------- +To customise the BSP a ``petalinux_bsp`` folder can be included in the board +directory the contents of which will be added to the provided BSP before the +project is created. See the ZCU104 for an example of this in action. This is +designed to allow for additional drivers, kernel or boot-file patches and +device tree configuration that are helpful to support elements of PYNQ to be +added to a pre-existing BSP. -The config file must define several variables: +If a suitable PetaLinux BSP is unavailable for the board then this can be left +blank and an HDF file provided in the board directory. The system.hdf file +should be placed in the ``petalinux_bsp/hardware_project`` folder and a new +generic BSP will be created as part of the build flow. - * **BOARD**: e.g. PYNQ-Z1. This is used to customize some parts of the flow, - and will ultimately be used by Python - * **BOARD_PART**: e.g. xc7z020clg400-1. This is used to create a Vivado - project and generate a Hardware Description File (.hdf) for use in Xilinx SDK. - * **BOARD_CONSTRAINTS**: Path to the constraints file (.xdc) containing the - top level constraints file for the board. - * **PS_CONFIG_TCL**: The path to a tcl file that configures the instantiated - Processing System IP. - * **LINUX_REPO**: The GitHub path to the Linux repository to clone from - * **LINUX_COMMIT**: The GitHub hash from which to clone the linux repository - * **LINUX_CONFIG**: The path to the Linux configuration file (.config) - * **UBOOT_REPO**: The GitHub path to the UBoot repository to clone from - * **UBOOT_COMMIT**: The GitHub hash from which to clone the UBoot repository - * **UBOOT_CONFIG**: The path to the UBoot configuration file (.config) - * **BOARD_DTSI**: The path to the devicetree fragment applied to the device - tree generated by Xilinx SDK. +Board-specific packages +----------------------- -The config file can define several optional variables +A ``packages`` directory can be included in board directory with the same +layout as the ``/sdbuild/packages`` directory. Each +subdirectory is a package that can optionally be installed as part of image +creation. See ``/sdbuild/packages/README.md`` for a +description of the format of a PYNQ sdbuild package. - * **BOOT_BITSTREAM**: The bitstream file (.bit) to be downloaded onto the PL - at boot +To add a package to the image you must also define a +``STAGE4_PACKAGE_${BOARD}`` variable in your spec file. These can either +packages in the standard sdbuild library or ones contained within the board +package. It is often useful to add the ``pynq`` package to this list which will +ensure that a customised PYNQ installation is included in your final image. -Build Flow Description ----------------------- +Using the PYNQ package +---------------------- -The SD Card build flow starts by creating a simple Vivado Project using the -**BOARD**, **BOARD_PART**, **BOARD_CONSTRAINTS**, and **PS_CONFIG** -variables. This vivado project is used to generate a Hardware Description File -(.hdf) for Xilinx SDK. +The ``pynq`` package will treat your board directory the same as any of the +officially supported boards. This means, in particular, that: -Following the creation of the Hardware Description File, the First State -Bootloader (FSBL) and Device Tree file are created. While the FSBL is not -customisable, the device tree can be modified by adding or reconfiguring -entries or by **BOARD_DTSI**. + 1. A ``notebooks`` folder, if it exists, will be copied into the + ``jupyter_notebooks`` folder in the image. Notebooks here will overwrite any of + the default ones. + 2. Any directory containing a bitstream will be treated as an overlay and + copied into the overlays folder of the PYNQ installation. Any notebooks will + likewise by installed in an overlay-specific subdirectory. -Next, the **LINUX_REPO** and **UBOOT_REPO** repositories are cloned, checked out -and configured. -Finally, the **BOOT_BITSTREAM** is packaged. +Building from a board repository +================================ -Once a boot configuration is defined for a board it needs to be incorporated -into a release which live in the following folder: +To build from a third-party board repository pass the BOARDDIR variable to the +sdbuild makefile. .. code-block:: console - /sdbuild/releases - -A release is a single (.config) file defining the variables: - - * **BOOT_CONFIG**: Path to the name of the project folder in boot_configs - * **ROOTFS_CONFIG**: Should be consistent with the OS to be installed on board - (e.g. Pynq-Z1-Xenial). - -================ ================ -Release version OS -================ ================ -v1.4 Ubuntu Wily -v2.0 Ubuntu Wily -v2.1 Ubuntu Xenial -v2.2 Ubuntu Xenial -================ ================ - -While the root filesystem is designed around the Pynq-Z1 board it should work on -any board with similar connectivity, i.e. PS attached Ethernet and USB host -ports. + cd /sdbuild/ + make BOARDDIR=${BOARD_REPO} +The board repo should be provided as an absolute path. The BOARDDIR variable +can be combined with the BOARD variable if the repository contains multiple +boards and only a subset should be built. diff --git a/pynq/lib/video/xilinx_hdmi.py b/pynq/lib/video/xilinx_hdmi.py index 9d56e322c7..fba44c53ba 100644 --- a/pynq/lib/video/xilinx_hdmi.py +++ b/pynq/lib/video/xilinx_hdmi.py @@ -33,6 +33,7 @@ import cffi import os +import warnings from pynq import DefaultIP from .frontend import VideoInFrontend, VideoOutFrontend from .constants import LIB_SEARCH_PATH @@ -173,7 +174,7 @@ def start(self): raise RuntimeError("Could not set PHY clock") elif frequency == 0: raise RuntimeError("Display does not support HDMI 2.0") - print(f"Frequency: {frequency}") + print("Frequency: {}".format(frequency)) for c in self.clocks: c.set_clock(frequency, _hdmi_lib.HdmiTx_line_rate(self.handle)) _hdmi_lib.HdmiTx_start(self.handle) diff --git a/pynq/ps.py b/pynq/ps.py index 586f74bda9..92b2f208ae 100755 --- a/pynq/ps.py +++ b/pynq/ps.py @@ -608,22 +608,27 @@ class _ClocksUltrascale(_ClocksMeta): 1 << PLX_CTRL_ODIV1_WIDTH, 1), np.arange(1 << PLX_CTRL_ODIV0_WIDTH))).reshape(-1)))) - IOPLL_CTRL = Register(CRL_APB_ADDRESS + IOPLL_CTRL_OFFSET) - RPLL_CTRL = Register(CRL_APB_ADDRESS + RPLL_CTRL_OFFSET) + if CPU_ARCH_IS_SUPPORTED: + IOPLL_CTRL = Register(CRL_APB_ADDRESS + IOPLL_CTRL_OFFSET) + RPLL_CTRL = Register(CRL_APB_ADDRESS + RPLL_CTRL_OFFSET) - PL_CLK_CTRLS = [Register(CRL_APB_ADDRESS + PL0_CTRL_OFFSET), - Register(CRL_APB_ADDRESS + PL1_CTRL_OFFSET), - Register(CRL_APB_ADDRESS + PL2_CTRL_OFFSET), - Register(CRL_APB_ADDRESS + PL3_CTRL_OFFSET)] + PL_CLK_CTRLS = [Register(CRL_APB_ADDRESS + PL0_CTRL_OFFSET), + Register(CRL_APB_ADDRESS + PL1_CTRL_OFFSET), + Register(CRL_APB_ADDRESS + PL2_CTRL_OFFSET), + Register(CRL_APB_ADDRESS + PL3_CTRL_OFFSET)] - ACPU_CTRL = Register(CRF_APB_ADDRESS + ACPU_CTRL_OFFSET) + ACPU_CTRL = Register(CRF_APB_ADDRESS + ACPU_CTRL_OFFSET) - APLL_CTRL = Register(CRF_APB_ADDRESS + APLL_CTRL_OFFSET) - DPLL_CTRL = Register(CRF_APB_ADDRESS + DPLL_CTRL_OFFSET) - VPLL_CTRL = Register(CRF_APB_ADDRESS + VPLL_CTRL_OFFSET) + APLL_CTRL = Register(CRF_APB_ADDRESS + APLL_CTRL_OFFSET) + DPLL_CTRL = Register(CRF_APB_ADDRESS + DPLL_CTRL_OFFSET) + VPLL_CTRL = Register(CRF_APB_ADDRESS + VPLL_CTRL_OFFSET) + + PL_SRC_PLL_CTRLS = [IOPLL_CTRL, IOPLL_CTRL, RPLL_CTRL, DPLL_CTRL] + ACPU_SRC_PLL_CTRLS = [APLL_CTRL, APLL_CTRL, DPLL_CTRL, VPLL_CTRL] + else: + warnings.warn("Pynq does not support the CPU Architecture: {}" + .format(CPU_ARCH), ResourceWarning) - PL_SRC_PLL_CTRLS = [IOPLL_CTRL, IOPLL_CTRL, RPLL_CTRL, DPLL_CTRL] - ACPU_SRC_PLL_CTRLS = [APLL_CTRL, APLL_CTRL, DPLL_CTRL, VPLL_CTRL] @classmethod def set_pl_clk(mcs, clk_idx, div0=None, div1=None, @@ -743,22 +748,27 @@ class _ClocksZynq(_ClocksMeta): 1 << FCLKX_CTRL_ODIV1_WIDTH, 1), np.arange(1 << FCLKX_CTRL_ODIV0_WIDTH))).reshape(-1)))) - ARM_PLL_CTRL = Register(SLCR_BASE_ADDRESS + ARM_PLL_CTRL_OFFSET) - DDR_PLL_CTRL = Register(SLCR_BASE_ADDRESS + DDR_PLL_CTRL_OFFSET) - IO_PLL_CTRL = Register(SLCR_BASE_ADDRESS + IO_PLL_CTRL_OFFSET) + if CPU_ARCH_IS_SUPPORTED: + ARM_PLL_CTRL = Register(SLCR_BASE_ADDRESS + ARM_PLL_CTRL_OFFSET) + DDR_PLL_CTRL = Register(SLCR_BASE_ADDRESS + DDR_PLL_CTRL_OFFSET) + IO_PLL_CTRL = Register(SLCR_BASE_ADDRESS + IO_PLL_CTRL_OFFSET) + + PL_SRC_PLL_CTRLS = [IO_PLL_CTRL, IO_PLL_CTRL, + ARM_PLL_CTRL, DDR_PLL_CTRL] - PL_SRC_PLL_CTRLS = [IO_PLL_CTRL, IO_PLL_CTRL, - ARM_PLL_CTRL, DDR_PLL_CTRL] + PL_CLK_CTRLS = [Register(SLCR_BASE_ADDRESS + FCLK0_CTRL_OFFSET), + Register(SLCR_BASE_ADDRESS + FCLK1_CTRL_OFFSET), + Register(SLCR_BASE_ADDRESS + FCLK2_CTRL_OFFSET), + Register(SLCR_BASE_ADDRESS + FCLK3_CTRL_OFFSET)] - PL_CLK_CTRLS = [Register(SLCR_BASE_ADDRESS + FCLK0_CTRL_OFFSET), - Register(SLCR_BASE_ADDRESS + FCLK1_CTRL_OFFSET), - Register(SLCR_BASE_ADDRESS + FCLK2_CTRL_OFFSET), - Register(SLCR_BASE_ADDRESS + FCLK3_CTRL_OFFSET)] + ARM_CLK_CTRL = Register(SLCR_BASE_ADDRESS + ARM_CLK_CTRL_OFFSET) - ARM_CLK_CTRL = Register(SLCR_BASE_ADDRESS + ARM_CLK_CTRL_OFFSET) + ARM_SRC_PLL_CTRLS = [ARM_PLL_CTRL, ARM_PLL_CTRL, + DDR_PLL_CTRL, IO_PLL_CTRL] + else: + warnings.warn("Pynq does not support the CPU Architecture: {}" + .format(CPU_ARCH), ResourceWarning) - ARM_SRC_PLL_CTRLS = [ARM_PLL_CTRL, ARM_PLL_CTRL, - DDR_PLL_CTRL, IO_PLL_CTRL] @classmethod def set_pl_clk(mcs, clk_idx, div0=None, div1=None, diff --git a/sdbuild/README.md b/sdbuild/README.md index 4617ed0c8a..9f4a8e325c 100644 --- a/sdbuild/README.md +++ b/sdbuild/README.md @@ -97,6 +97,17 @@ the final image. ## Porting to a new board +There are two flows for porting to a new board. The simplest approach is to +take a pre-existing PetaLinux BSP and our pre-built board-agnostic imagea +appropriate to the architecture - arm for Zynq-7000 and aarch64 for Zynq +UltraScale+. The `scripts/image_from_prebuilt.sh` script will take these two +components and create an image without needing to run the whole image creation +flow. See that script for the details of the arguments that are needed. + +For more substantial board support you will need to create a board repository +based on either a PetaLinux BSP or an HDF file from Vivado. The steps to create +a board repository are detailed below. + ### Step 1: Prepare the folder First you need to create folder to act as a board repository - `myboards` in this example - and create a subfolder to hold the spec for