SDSoC Platform Examples

In addition to targeting Zynq andZynq® UltraScale+™ MPSoCdevices, you can build an SDSoC platform that targets anyXilinx®device by using the MicroBlaze processor as the target CPU (add reference toMicroBlaze™documentation). A MicroBlaze platform in SDSoC must be a self-contained system containing an LMB memory, MicroBlaze Debug Module (MDM), UART, and AXI Timer built using the Vivado Design Suite and SDK. A sample MicroBlaze example is in/sample/platforms/artyfolder. The figure below shows a minimal system. Notice that the JTAG UART is enabled in the MDM and appears as an AXI-Lite slave. The system runs on a clock (sys) delivered from the board.

Figure:Minimal MicroBlaze System

The SDSoC runtime requires the platform hardware to include two IPs: a timer for thesds_clock_counter()API, and a UART to print runtime error messages. Since a MicroBlaze processor has a single AXI Master port (M_AXI_DP) to control AXI slaves, a MicroBlaze platform must include an AXI interconnect connected to this port as described inExample: Sharing a Platform IP AXI Port.

MicroBlaze systems that use DDR typically connect the processor to the DDR via MIG using the cache facilities built into the MicroBlaze. An example system is shown below.

Figure:MicroBlaze System with MIG

In the system above, the MicroBlaze is configured with an 8 KB cache. The instruction and data cache ports (M_AXI_DCandM_AXI_IC) are connected to the MIG. The UART is connected to an on-board USB-to-UART converter chip and does not use the JTAG UART from the previous design. The system runs on the user-interface (UI) clock produced by MIG. Other than these differences, the MicroBlaze systems are identical.

Ports on the MIG’s AXI Interconnect IP can be registered using PFM properties as described inDeclaring AXI Portsfor the typeM_AXI_HPwhich is exactly the same as Zynq HP Ports. SDSoC runtime will invalidate or flush buffers in exactly the same way as it does for Zynq devices.

AnSDSoCplatform can include input and output subsystems; for example, analog-to-digital and digital-to-analog converters, or video I/O, by converting raw physical data streams intoAXI4-Streaminterfaces that are exported as part of the platform interface specification. For information on thezc702_axis_iosample platform, see “Using External I/O” in theSDSoC Environment User Guide. This example includes sample applications that demonstrate how an input data stream can be written directly into memory buffers without data loss, and how an application can "packetize" the data stream at the AXI transport level to communicate with other functions (including, but not limited to DMAs) that require packet framing.

Run the following command from the command shell usingzc702_axis_io_dsa.tcl,aVivadoTcl script to build the hardware platform in a batch mode:

vivado –mode batch –source zc702_axis_io_dsa.tcl

Run the following command to build the platform in GUI mode to inspect the hardware system in theVivadoIP integrator:

vivado –mode gui –source zc702_axis_io_dsa.tcl

The command opens theVivadoIDE and builds the platform. The resulting hardware system will look similar to the following block diagram.

Figure:zc702_axis_io Block Diagram

To make this design portable, this platform includes a free-running binary counter that generates a continuous stream of data samples at 50 MHz, which acts as a proxy for data streaming directly from FPGA pins. To convert this input data stream into anAXI4-StreamforSDSoCapplications, the platform connects the counter output to thes_axis_tdataslave port of anAXI4-Streamdata FIFO, with a constant block providing the requireds_axis_tvalidsignal, always one. The data FIFO IP is configured to store up to 1024 samples with an output clock of 100 MHz to provide system elasticity so that the consumer of the stream can process the stream "bubble-free" (i.e., without dropping data samples). In a real platform, the means for converting to anAXI4-Stream, relative clocking and amount of hardware buffering will vary according to system requirements.

Similar to input streaming off of an analog-to-digital converter, this data stream is not packetized, which means theAXI4-Streamhas noTLASTsignal. Consequently, anySDSoCapplication that consumes the data stream must be capable of handling unpacketized streams. Within theSDSoCenvironment, every data mover IP core (e.g., theVivadoAXI4Direct Memory Access IP (AXI DMA)) requires packetizedAXI4-Streams that include theTLASTsignal. To consume the streaming input from this platform, an application must employ direct hardware connections to theAXI4-Streamport.