Toward an intuitive system design environment

&

May 03, 2016

sandeepduttarroane,-May 03, 2016

Advanced systems are becoming increasingly complex, forcing manufacturers to spend correspondingly greater time developing and debugging each device -- typically with little visibility into system-level interactions of multiple components. Visual System Integrator (VSI) is a unique tool that facilitates system design and integration by enabling designers to graphically describe their heterogeneous systems completely and accurately. Based on this description, the tool automatically generates drivers required for communication across standard interfaces. Consequently, architects and engineers can focus on their key differentiators rather than on designing and debugging standard data transport and device drivers. VSI is flexible enough to allow the user to extend or replace the implementation of any of the runtime components. In this article we explore the different aspects of this novel development environment, including hardware platform description, application development, as well as built-in runtime and trace facility.

Describing the Hardware Platform
The VSI Platform description environment accelerates platform creation and maintenance by providing an intuitive visual environment for the task, enabling system architects and even software developers to rapidly create and iterate on complex hardware platforms. Figure 1 below illustrates a platform composed of and FPGA board connected to an external host. Note that the user specifies which interfaces to elevate at system level.

click for larger image

Figure 1. VSI platform description

A VSI platform description starts by defining “Execution Contexts”, or entities that are capable of executing “code”. In this example it consists of an x86 based host server and a Xilinx Virtex-7 FPGA.

For the software execution contexts (x86), the user specifies the details such as the number of processors, cross compiler to use (if any). For the FPGA context the user specifies the part number of the FPGA being used along with the specifications of the board.

The user then describes the connectivity between the execution contexts, in this example the FPGA board is connected to the x86 using PCI/e. The PCI/e driver as well as the FPGA PCI/e interface is configured using intuitive dialog boxes. The connection between “execution contexts” are termed “Platform Interfaces”.

The platform description contains the interfaces that allow the system to communicate with the external world. In this example, we use an Ethernet MAC in the FPGA. The interfaces of the Ethernet block that are exposed to the application system are marked in the platform description as “System Interfaces”, denoted by the vertical lines on the Ethernet MAC in Figure 1. The other parameters of the Ethernet MAC including clocking structures required for the interfaces are also described in the platform.

The platform specification is packaged for use by by application systems by “Compiling Platform”. This generates the meta data required for use by application systems. The Platform can be changed and recompiled during the lifetime of a project to accommodate changing hardware requirements.

Developing an Application
The application development process begins by “Importing” the platform the application is going to use. Execution contexts and system interfaces are imported into the application development platform as shown in Figure 2 (a) below.

click for larger image

Figure 2a

Other details of the platform description are not shown in the application development “canvas”, this allows the application developer to focus on “algorithms” and core differentiating features without having to worry about low level “platform issues” such clocking and I/O handling.

Application development involves adding blocks of “code” to execution contexts. The “code” blocks can come from libraries provided for each “type” of execution context (x86/ARM has a different library from FPGAs), in Figure 2(a) the “TCP Server” block comes from the “Software Library” and the “DSP Function” blocks comes from the FPGA library. The libraries are extensible (Users can add blocks into the libraries). Existing C/C++ code can also be imported into an execution context using an intuitive code import interface. HLS synthesizable C/C++ code can be imported into an FPGA execution context. Synthesizable C/C++ blocks can be moved between FPGA & Software contexts, as shown in Figure 2(b) below.

click for larger image

Figure 2b

The block interfaces are connected to describe how the data flows between the different blocks, connections A through F in Figures 2(a) and 2(b) shows the data flow graph for this example application.

Once the connections are completed the user can “Generate the complete” system, which generates the outputs shown in Figure 3 below.

click for larger image

Figure 3

The “System Compiler” takes both the “Platform description” and the “Application System” as inputs and generates:

  1. Complete software projects for “all” the software execution contexts, the software projects are generated using CMAKE which allows the user to import the project into an IDE of their choice (Visual Studio, Eclipse, Qt are some of the IDEs that are already supported).
  2. For the synthesizable C/C++ blocks that are present in the “Application system” the compiler generates “HLS wrappers” (including the #pragmas required for interface synthesis) and complete Vivado HLS projects, the compiler also generates the AXI infrastructure & connections to the handshaking & clocking signals as required to connect these HLS blocks to the rest of the System,
  3. The compiler generates complete and separate projects for all FPGA “execution contexts” specified.

The compiler also generates all the code and scripts required to initialize the “Device Drivers”.

Next Page >>

 

< Previous
Page 1 of 2
Next >

Loading comments...

Most Commented