Difference between revisions of "POD Global description"

From ArmadeusWiki
Jump to: navigation, search
m
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +

 
= Global overview of POD tools =
 
= Global overview of POD tools =
  
 
== Lexical ==
 
== Lexical ==
* Bistream: binary file resulting of the synthetizing of a FPGA design. Used to program the FPGA.
+
* Bitstream: 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.  
+
* Constraint file: file declaring physical constraints (pin positions, pin types, clock frequencies...) within a FPGA.  
* FPGA: http://en.wikipedia.org/wiki/FPGA
+
* FPGA: http://en.wikipedia.org/wiki/FPGA.
* GHDL:[http://ghdl.free.fr/ Free VHDL simulation software]
+
* GHDL:[http://ghdl.free.fr/ Free VHDL simulation software].
* GTKWave: [http://home.nc.rr.com/gtkwave/ Free wave viewer]
+
* GTKWave: [http://home.nc.rr.com/gtkwave/ Free wave viewer].
* HDL: Hardware Description Language. Language used to  
+
* HDL: Hardware Description Language. Language used to describe digital architectures.
* IP: http://en.wikipedia.org/wiki/IP_core
+
* IP: http://en.wikipedia.org/wiki/IP_core.
* ISE: Xilinx IDE (http://www.xilinx.com)
+
* ISE: Xilinx IDE (http://www.xilinx.com).
* Platform: electronics board containing the FPGA
+
* Platform: electronic board containing the FPGA.
* Synthesis: FPGA synthesis is the "parallel" of the compilation process for source code
+
* Synthesis: FPGA synthesis is the source code compilation equivalent.
* Syscon: Wishbone special component managing the clocks and the resets within a FPGA  
+
* Syscon: Wishbone special component managing clocks and resets within a FPGA.
* TCL: scripting language used in several FPGA environments
+
* TCL: scripting language used in several FPGA environments.
* Virtual Peripheral: IP with providing a bus interface
+
* Virtual Peripheral: IP providing a bus interface.
 
* Wishbone: Open source FPGA bus from opencores.org (http://www.opencores.org/)
 
* Wishbone: Open source FPGA bus from opencores.org (http://www.opencores.org/)
 
* Wrapper: Wishbone special component converting a bus in an other bus
 
* Wrapper: Wishbone special component converting a bus in an other bus
Line 21: Line 22:
 
== Description ==
 
== 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 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 for embedded system developers. Novices with a  
+
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
 
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).
 
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
+
POD was initially designed for platforms with one main processor
 
connected to one FPGA, other architectures can be although supported.
 
connected to one FPGA, other architectures can be although supported.
architectures.
 
  
 
=== Constraints ===
 
=== Constraints ===
  
* POD uses external proprietary software (ISE Xilinx, Quartus Altera,...) to
+
* POD uses external proprietary software (Xilinx ISE, Altera Quartus,...) to
 
synthetize and configure the FPGA.  
 
synthetize and configure the FPGA.  
 
* POD is multi-platform (Windows, Linux, macOS, ...).
 
* POD is multi-platform (Windows, Linux, macOS, ...).
* POD can generate code in several digital programming languages (VHDL,
+
* POD generate code in several digital programming languages (VHDL,
 
Verilog, etc...).  
 
Verilog, etc...).  
 
* POD is able to generate drivers for the targeted operating system (actually Linux).
 
* POD is able to generate drivers for the targeted operating system (actually Linux).
Line 48: Line 49:
 
== Software list ==
 
== Software list ==
 
POD is composed of three main programs:  
 
POD is composed of three main programs:  
* POD ComponentBuilder: ease Virtual Peripheral creation. Written in C++ with Qt (to be done).
+
* 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)and generate a project. Written in Python. Command line interface (usable).
+
* 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 GUI: Graphical interface to POD core. Written in C++ with Qt (in progress).
  
== POD Core data flow ==
+
== POD Core dataflow ==
  
The general principle is described figure 2. POD core is based on :
+
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 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 platform description (platform.xml).
 
* a toolchain description for each process (simulation, synthesis, driver).
 
* a toolchain description for each process (simulation, synthesis, driver).
  
Thanks to these elements, Application/projects can be built for a given platform.
+
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.
  
 
[[image:POD.png|center|frame|200px|'''figure 2''' - ''Fonctionnal description of POD'']]
 
[[image:POD.png|center|frame|200px|'''figure 2''' - ''Fonctionnal description of POD'']]
 
'''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 ==
 
== Project architecture ==
  
A project contains a lits of the components used, including the connections between
+
A project contains the list of used components, including their connections.
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.
+
Each project is specific to a platform, which has to be choose before adding
 +
any Virtual Peripheral.
  
 
=== Platform ===
 
=== 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.   
+
A platform mainly describes the given hardware environment in which the FPGA
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.
+
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 :
 
Main characteristics of a platform are :
Line 100: Line 102:
 
==== Auto-loaded components ====
 
==== 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.  
+
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.  
  
  
 
[[image:autoLoadedComponents.png|center|frame|200px|'''figure 3''' - ''Auto-loaded components in APF9328 platform'']]
 
[[image:autoLoadedComponents.png|center|frame|200px|'''figure 3''' - ''Auto-loaded components in APF9328 platform'']]
  
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
+
Note that FPGA pins are considered just like component by the POD core.
  
 
==== Simulation library ====
 
==== Simulation library ====
Line 111: Line 113:
 
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.
 
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 ===
+
=== Virtual Peripheral architecture ===
  
Three kinds of components are used within a project:
+
Three kinds of components are used in a project:
 
* Virtual Peripheral
 
* Virtual Peripheral
* intercon (connect the components to the main bus). automatically generated  
+
* intercon (connect the components to the main bus), automatically generated.
 
* platform (specific Virtual Peripheral).  
 
* platform (specific Virtual Peripheral).  
  
Line 121: Line 123:
  
 
The component file description contains the following informations:
 
The component file description contains the following informations:
* ''' version and name ''':
+
* ''' version and name ''': name of the component and its version.
 
* ''' synthesis file list''' : files required to synthetize the component.
 
* ''' synthesis file list''' : files required to synthetize the component.
 
* ''' drivers file list ''' : files required to generate the driver.
 
* ''' drivers file list ''' : files required to generate the driver.
Line 127: Line 129:
 
* ''' interface list ''' : describes the inputs/outputs of a component.  
 
* ''' interface list ''' : describes the inputs/outputs of a component.  
  
==== Signals description : Interface, port, pin ====
+
==== Signals description : interface, port, pin ====
In order to communicate with other components, a Virtual Peripheral has to publish its connections.
+
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):
 
These connections are hierarchically organized as follows (smallest entity to the biggest one):
 
* pin
 
* pin
Line 136: Line 138:
 
[[image:connections.png|center|thumb|500px|'''figure 5''' - ''Connections exemples'']]
 
[[image:connections.png|center|thumb|500px|'''figure 5''' - ''Connections exemples'']]
  
===== pin =====
+
===== pin: =====
  
A pin is equivalent to a net. A pin can be connected to another component pin in
+
A pin is equivalent to a net. A pin can be connected to another component pin in the design.
the design.
+
  
===== port =====
+
===== 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.
 
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 =====
+
===== 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).  
 
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).  
Line 151: Line 152:
 
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.
 
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.  
 
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.
+
With these characteristics, POD can connect automatically severals slave bus interfaces to a master bus interface.
  
 
== Project example ==
 
== Project example ==
  
 
The figure below shows an example of a POD project using a '''Wishbone''' bus.  
 
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.
+
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:
 
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 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 '''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 '''Syscon''' used to generate the clock 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
+
* one '''Interrupt manager''' (wb_irq_mngr00) used to allow both button and I2C controller components to interrupt the µP.
  
  
Line 170: Line 172:
 
* '''Intercon'''
 
* '''Intercon'''
 
* '''Top''', connects the non Wishbone signals.
 
* '''Top''', connects the non Wishbone signals.
 +
[[Category:POD]]

Latest revision as of 09:44, 20 March 2009



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 was initially 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.