Difference between revisions of "POD Global description"

Revision as of 00:19, 15 December 2008

= Global overview of POD tools =

Lexical

• Bitstream: binary file resulting of the synthetizing of a FPGA design. Used to program the FPGA.
• Constraint file: file declaring physical constraints (pin positions, pin types, clock frequencies...) within a FPGA.
• FPGA: http://en.wikipedia.org/wiki/FPGA.
• GHDL:Free VHDL simulation software.
• GTKWave: Free wave viewer.
• HDL: Hardware Description Language. Language used to describe digital architectures.
• IP: http://en.wikipedia.org/wiki/IP_core.
• ISE: Xilinx IDE (http://www.xilinx.com).
• Platform: electronic board containing the FPGA.
• Synthesis: FPGA synthesis is the source code compilation equivalent.
• Syscon: Wishbone special component managing clocks and resets within a FPGA.
• TCL: scripting language used in several FPGA environments.
• Virtual Peripheral: IP providing a bus interface.
• Wishbone: Open source FPGA bus from opencores.org (http://www.opencores.org/)
• Wrapper: Wishbone special component converting a bus in an other bus
• XML: http://en.wikipedia.org/wiki/XML

Description

POD is a toolbox of Open Source programs simplifying the integration of Virtual Peripherals (also called components in this document) in FPGAs. A Virtual Peripheral is defined as an FPGA IP (http://en.wikipedia.org/wiki/IP_core) providing a bus interface.

POD is designed to be use by embedded system developers. Beginners with a small knowledge in digital design (FPGA design) will be able to easily integrate and configure virtual peripherals on their platform (an electronic board equiped with a FPGA).

POD wasinitially designed for platforms with one main processor connected to one FPGA, other architectures can be although supported.

Constraints

• POD uses external proprietary software (Xilinx ISE, Altera Quartus,...) to

synthetize and configure the FPGA.

• POD is multi-platform (Windows, Linux, macOS, ...).
• POD generate code in several digital programming languages (VHDL,

Verilog, etc...).

• POD is able to generate drivers for the targeted operating system (actually Linux).

This implies:

• an open architecture with plugins
• a multi-platform language (Python)

figure 1 - Basic platform supported by POD

Software list

POD is composed of three main programs:

• POD ComponentBuilder: ease Virtual Peripheral creation, written in C++ with Qt library (to be done).
• POD Core: project creation, allows adding, deleting, configuring a component (Virtual Peripheral). Command line interface program written in Python.
• POD GUI: Graphical interface to POD core. Written in C++ with Qt (in progress).

POD Core dataflow

The functionnal description is described in figure 2. POD core is based on :

• a component library with at least one XML description file, one hdl file, and one optional driver file for each component.
• a platform description (platform.xml).
• a toolchain description for each process (simulation, synthesis, driver).

Thanks to these elements, applications and projects can be built for a given platform.

POD processor uses these informations to generate:

• a full Xilinx,Altera or other synthesis tools project. This project will be then synthetized, resulting in a binary file ready to be downloaded in the FPGA.
• an optional Device Drivers project, providing ready to use drivers for the target operating system.

figure 2 - Fonctionnal description of POD

Project architecture

A project contains the list of used components, including their connections. Each project is specific to a platform, which has to be choose before adding any Virtual Peripheral.

Platform

A platform mainly describes the given hardware environment in which the FPGA evolves. Moreover, depending on the platform, pre-loaded components can be automatically instantiated. This behaviour is particulary interesting in case of a processor/FPGA connection through an address/data/control bus. Although, the platform can contain libraries to simulate the design, the communication between the FPGA and the processor or any other device present on the board.

Main characteristics of a platform are :

• FPGA identity
• FPGA pins description
• auto-loaded components (for example a processor bus wrapper)
• simulation library

FPGA identity

Describes the properties of the FPGA used with the platform. The properties are :

• component reference
• component family
• speed
• package

FPGA pin description

This part will describe the FPGA pins with their names, positions, electrical characteristics, directions,...

Auto-loaded components

In order to simplify the design around the Wishbone bus, some components, specific to a platform, can be automatically loaded when the platform is defined.

figure 3 - Auto-loaded components in APF9328 platform

Note that FPGA pins are considered just like component by the POD core.

Simulation library

Depending on the platform, several simulation libraries can be used to ease testbench writing. This can be particulary interesting for verifying the communication between the FPGA and the processor.

Virtual Peripheral architecture

Three kinds of components are used in a project:

• Virtual Peripheral
• intercon (connect the components to the main bus), automatically generated.
• platform (specific Virtual Peripheral).

figure 4 - Virtual Peripheral architecture

The component file description contains the following informations:

• version and name : name of the component and its version.
• synthesis file list : files required to synthetize the component.
• drivers file list  : files required to generate the driver.
• generic parameters  : used to configure the component.
• interface list  : describes the inputs/outputs of a component.

Signals description : interface, port, pin

In order to communicate with other components, a Virtual Peripheral declare its connections. These connections are hierarchically organized as follows (smallest entity to the biggest one):

• pin
• port
• interface

figure 5 - Connections exemples

pin:

A pin is equivalent to a net. A pin can be connected to another component pin in the design.

port:

A port has a name, a direction and a size. The port size define the number of pin under it. An example of a port can be a data bus (D0..D7) where the pins have the same meaning.

interface:

An interface gathers one or severals port for one function (ie a processor bus with a data bus, a control bus and an address bus).

If an interface can be reused between several designs (ie an address/data/control bus), it can be interesting to automate the connections on this interface. This can be achieved by defining a bus. Each bus has a XML description file (located in the busses directory of POD) and a Python plugin used to automate the connections. A bus can be defined as a slave or as a master. With these characteristics, POD can connect automatically severals slave bus interfaces to a master bus interface.

Project example

The figure below shows an example of a POD project using a Wishbone bus. The Wishbone bus is a well known internal FPGA bus. Descriptions and specifications can be found here: http://www.opencores.org/projects.cgi/web/wishbone/wishbone.

Our project is composed of:

• one led component (wb_led00), one button (wb_button00) and one I2C controler (i2ccore00). Each of these virtual peripherals are connected to the Intercon. This component is responsible for address decoding and

Wishbone signal connection.

• one Wrapper (imx9328_wb16_wrapper00) used to convert the processor (imx9328) bus into a Wishbone bus.
• one Syscon used to generate the clock and the reset used in the FPGA.
• one Interrupt manager (wb_irq_mngr00) used to allow both button and I2C controller components to interrupt the µP.

figure 6 - POD project example

Two components are automatically generated by pod:

• Intercon
• Top, connects the non Wishbone signals.