Difference between revisions of "POD Global description"
(New page: = Global overview of POD tools = == Lexical == * Bistream: binary file resulting of the synthetizing of a FPGA design. Used to program the FPGA. * Constraint file. file declaring the phys...) |
m (Global description moved to POD Global description) |
(No difference)
| |
Revision as of 00:14, 15 December 2008
Contents
Global overview of POD tools
Lexical
- Bistream: binary file resulting of the synthetizing of a FPGA design. Used to program the FPGA.
- Constraint file. file declaring the 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
- IP: http://en.wikipedia.org/wiki/IP_core
- ISE: Xilinx IDE (http://www.xilinx.com)
- Platform: electronics board containing the FPGA
- Synthesis: FPGA synthesis is the "parallel" of the compilation process for source code
- Syscon: Wishbone special component managing the clocks and the resets within a FPGA
- TCL: scripting language used in several FPGA environments
- Virtual Peripheral: IP with 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 Peripheral (called also 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 for embedded system developers. Novices 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).
Despite the fact that POD is initially designed for platforms with one main processor connected to one FPGA, other architectures can be although supported. architectures.
Constraints
- POD uses external proprietary software (ISE Xilinx, Quartus Altera,...) to
synthetize and configure the FPGA.
- POD is multi-platform (Windows, Linux, macOS, ...).
- POD can 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)
Software list
POD is composed of three main programs:
- POD ComponentBuilder: ease Virtual Peripheral creation. Written in C++ with Qt (to be done).
- POD Core: project creation, allows adding, deleting, configuring a component (Virtual Peripheral)and generate a project. Written in Python. Command line interface (usable).
- POD GUI: Graphical interface to POD core. Written in C++ with Qt (in progress).
POD Core data flow
The general principle is described 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, Application/projects can be built for a given platform.
POD processor uses these informations to generate:
- a complete Xilinx/Altera/... project. This project will be then synthetized. A binary file is generated at the end of this process. This file can be downloaded in the FPGA.
- an optional Device Drivers project, providing ready to use drivers for the selecting operating system.
Project architecture
A project contains a lits of the components used, including the connections between them. A project is specific to a platform and thus the first element which has to be defined is the platform. Then Virtual Peripherals can be added.
Platform
A platform mainly describes the given hardware environment where 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. The platform can contain although libraries to simulate the design, the communication between the FPGA and the processor or an 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
To simplify the design around the wishbone bus, some components, specific to a platform, can be automatically loaded when the platform is defined.
It has to be noted that FPGA pins are seen exactly the same way as the pins of a component ie POD core does not make differences between them
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 within a project:
- Virtual Peripheral
- intercon (connect the components to the main bus). automatically generated
- platform (specific Virtual Peripheral).
The component file description contains the following informations:
- version and name :
- 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 has to publish its connections. These connections are hierarchically organized as follows (smallest entity to the biggest one):
- pin
- port
- interface
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 an open source 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 decoding the addesses and for connecting the Wishbone signals to the components.
- one Wrapper (imx9328_wb16_wrapper00) used to convert the processor (imx9328) bus into a Wishbone bus.
- one Syscon used to generate the clocks and the reset used in the FPGA.
- one Interrupt manager (wb_irq_mngr00). The button and the I2C controller components can thus interrupt the processor
Two components are automatically generated by pod:
- Intercon
- Top, connects the non Wishbone signals.
