Difference between revisions of "Orchestra"

From ArmadeusWiki
Jump to: navigation, search
m (→‎Les composants)
 
(17 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
Info: The development tree of the Orchestra Tool of Armadeus Project has been moved to
 +
http://developer.berlios.de/projects/osocgen/
 +
 
== Vue d'ensemble du système Orchestra ==
 
== Vue d'ensemble du système Orchestra ==
  
Line 24: Line 27:
 
** '''board''': pour une plateforme
 
** '''board''': pour une plateforme
 
** '''project''': pour un projet
 
** '''project''': pour un projet
−
* Le corps d'une balise est utilisé pour la description ou un commentaire relatif à l'élément représenté par la balise. Afin de ne pas avoir de problème liés aux caractères ou séquences d'échappement XML, ces textes seront placés dans une section '''CDATA'''. Ainsi il sera possible de saisir du code XML ou HTML pour faire de la mise en page par exemple.
+
* Le corps d'une balise est utilisé pour la description ou un commentaire relatif à l'élément représenté par la balise.  
  
 
Voici un extrait de fichier XML pour un composant à titre d'illustration
 
Voici un extrait de fichier XML pour un composant à titre d'illustration
−
<pre>
+
<source lang="xml">
 
<?xml version="1.0" encoding="utf-8"?>
 
<?xml version="1.0" encoding="utf-8"?>
 
<component name="irq_mngr" version="1.0" category="base">
 
<component name="irq_mngr" version="1.0" category="base">
  
 
   <description>
 
   <description>
−
    <![CDATA[
 
 
       The Interruption Manager is a Wishbone slave component and Armadeus compiliant.
 
       The Interruption Manager is a Wishbone slave component and Armadeus compiliant.
−
    ]]>
 
 
   </description>
 
   </description>
 
...
 
...
 
</component>
 
</component>
−
</pre>
+
</source>
 
   
 
   
  
−
== La bibliothèque de composants ==
+
=== Les composants ===
  
 
Un composant '''Armadeus Ready''' se compose des éléments suivants:
 
Un composant '''Armadeus Ready''' se compose des éléments suivants:
 
* un ensemble de fichiers HDL (VHDL ou Verilog)
 
* un ensemble de fichiers HDL (VHDL ou Verilog)
−
* un ensemble de fichiers C et H (optionnel)
+
* un ensemble de fichiers C,H,Makefile et configuration (optionnel)
 
* un fichier XML qui va décrire entièrement le composant
 
* un fichier XML qui va décrire entièrement le composant
  
−
Nous allons maintenant nous intéresser au contenu de ce fichier XML et en premier lieu avec les attributs dont dispose le noeud de base '''component''':
+
Nous allons maintenant nous intéresser au contenu de ce fichier XML et en
 +
premier lieu avec les attributs dont dispose le nœud de base '''component''':
 +
 
 
* '''name''': le nom du composant (IP), de préférence pas plus de 16 caractères.
 
* '''name''': le nom du composant (IP), de préférence pas plus de 16 caractères.
 
* '''version''': la version du composant
 
* '''version''': la version du composant
 
* '''category''': la catégorie dans laquelle le composant se situe. Par exemple: base, communication, etc.
 
* '''category''': la catégorie dans laquelle le composant se situe. Par exemple: base, communication, etc.
−
<pre>
+
 
−
<component name="irq_mngr" version="1.0" category="base">
+
<source lang="xml">
 +
<component category="User Component" name="led" version="1.0">
 
...
 
...
 
</component>
 
</component>
−
</pre>
+
</source>
  
 
Sous le noeud de base se trouve les éléments suivants:
 
Sous le noeud de base se trouve les éléments suivants:
 
* Le noeud '''description''' (optionnel) qui va contenir une description plus ou moins détaillée du composant.
 
* Le noeud '''description''' (optionnel) qui va contenir une description plus ou moins détaillée du composant.
−
<pre>
+
 
 +
<source lang="xml">
 
<description>
 
<description>
−
  <![CDATA[
 
 
     The Interruption Manager is a Wishbone slave component and Armadeus compiliant.
 
     The Interruption Manager is a Wishbone slave component and Armadeus compiliant.
−
  ]]>
 
 
</description>
 
</description>
−
</pre>
+
</source>
−
* le noeud '''hdl_files''' va contenir la liste des fichiers VHDL ou Verilog qui composent l'IP. Chaque fichier est placé dans une base '''hdl_file''' et les attributs suivant sont proposés:
+
 
 +
* Le nœud '''driver_files''' contient les fichiers aux drivers concernant l'IP. Pour chaque architecture, on crée un nœud architecture avec un attribut "name" pour le nom de l'architecture. Chaque fichier est placé dans une base '''driver_file''' avec les attributs suivants :
 +
** '''name''' : nom du fichier.
 +
 
 +
<source lang="xml">
 +
<driver_files>
 +
<architecture name="linux">
 +
<driver_file name="led.h">
 +
<driver_file name="led.c">
 +
<driver_file name="Makefile">
 +
<driver_file name="Konfig">
 +
</architecture>
 +
</driver_files>
 +
</source>
 +
 
 +
Dans cet exemple, les fichiers seront inclus dans le répertoire ''drivers/linux/'' du zip. L'outil générera un header pour les registres avec le nom du composant plus _register, dans le cas du composant exemple led nous aurons ''led_register.h'' à inclure dans le code du driver.
 +
 
 +
* le nœud '''hdl_files''' va contenir la liste des fichiers VHDL ou Verilog qui composent l'IP. Chaque fichier est placé dans une base '''hdl_file''' et les attributs suivant sont proposés:
 
** '''name''': C'est le nom du fichier. Le chemin vers le fichier est donné en relatif par rapport à l'emplacement du fichier XML de description du composant.
 
** '''name''': C'est le nom du fichier. Le chemin vers le fichier est donné en relatif par rapport à l'emplacement du fichier XML de description du composant.
 
** '''scope''': Cet attribut va permettre de donner la ''portée'' du fichier, c'est-à-dire pour quel utilisation ce fichier est prévu. Voici quelques valeurs pour cet attribut:
 
** '''scope''': Cet attribut va permettre de donner la ''portée'' du fichier, c'est-à-dire pour quel utilisation ce fichier est prévu. Voici quelques valeurs pour cet attribut:
Line 75: Line 95:
 
*** '''tb''': le fichier n'est pas synthétisable et ne fonctionne que dans le cadre de bancs de tests.
 
*** '''tb''': le fichier n'est pas synthétisable et ne fonctionne que dans le cadre de bancs de tests.
 
** '''istop''': Cet attribut va permettre d'identifier le fichier '''TOP''' de l'IP. Il n'y a que 2 valeurs possible 0 (valeur par défaut) ou 1 (pour indiquer le fichier TOP). Il faut définir au moins 1 fichier TOP. Si plusieurs fichiers TOP sont déclarés, par exemple si une IP est spécialisable en fonction du type de carte, toutes les entités des fichiers TOP doivent avoir la même signature.
 
** '''istop''': Cet attribut va permettre d'identifier le fichier '''TOP''' de l'IP. Il n'y a que 2 valeurs possible 0 (valeur par défaut) ou 1 (pour indiquer le fichier TOP). Il faut définir au moins 1 fichier TOP. Si plusieurs fichiers TOP sont déclarés, par exemple si une IP est spécialisable en fonction du type de carte, toutes les entités des fichiers TOP doivent avoir la même signature.
−
<pre>
+
 
 +
<source lang="xml">
 
<hdl_files>
 
<hdl_files>
 
   <hdl_file name="irq_mgnr.vhd" scope="all" istop="1" />
 
   <hdl_file name="irq_mgnr.vhd" scope="all" istop="1" />
 
</hdl_files>
 
</hdl_files>
−
</pre>
+
</source>
−
* le noeud '''generic_map''' est utilisé pour <u>contenir la déclaration des paramètres GENERIC disponibles sur l'élément TOP de l'IP '''si celui-ci est un fichier VHDL'''</u>. Chaque entrée GENERIC de l'IP va être représentée par une balise '''generic''' qui va entièrement décrire la paramètre à l'aide des attributs suivants:
+
 
−
** '''name''': C'est le nom du paramètre GENERIC qui doit être identique au nom utilisé dans l'IP
+
* le nœud '''interface''' permet de définir les différentes interfaces utilisées dans le composant. Les attributs sont les suivants :
−
** '''type''': C'est le type de paramètre, dans un premier temps, uniquement les types suivants sont supportés:
+
** '''name''': le nom du port tel que définit dans l'entity.
−
*** '''integer''': pour définir un nombre entier
+
** '''type''': Le type de signal Wishbone (GLS si non wishbone).
−
*** '''std_logic''': pour définir un signal
+
*** <tt>WBM</tt> Wishbone Master.
−
*** '''std_logic_vector''': pour définir un vecteur
+
*** <tt>WBS</tt> Wishbone Slave.
 +
*** <tt>WBC</tt> Wishbone Clock.
 +
*** <tt>GLS</tt> Interface non Wishbone.
 +
** '''clockandreset''': Nom du domaine d'horloge rattaché à l'interface.
 +
 
 +
<source lang="xml">
 +
<interfaces>
 +
        <interface clockandreset="CANDR" name="LED" type="GLS"/>
 +
        <interface name="CANDR" type="WBC" />
 +
        <interface clockandreset="CANDR" name="SLED" type="WBS" />
 +
</interfaces>
 +
</source>
 +
 
 +
* Le nœud '''registers''' permet de définir le nom et l'adresse des registres de l'IP. Le nom des registres doit correspondre à ceux utiliser dans le driver.
 +
** '''name''' : nom du registre.
 +
** '''offset''' : adresse du registre en hexadécimale (0x0000,0x0003,...)
 +
** '''desc''' : description du registre
 +
 
 +
<source lang="xml">
 +
<registers>
 +
<register name="reg_led" offset=0x0 desc="led value" />
 +
</registers>
 +
</source>
 +
 
 +
* Le nœud '''interrupts''' permet de définir le (les?) nom de l'interruption utilisée s'il y a lieu dans le driver (par un #define). Orchestra définira ensuite la position de l'interruption dans l'irq_mngr.
 +
 
 +
<source lang="xml">
 +
<interrupts>
 +
<interrupt name="WB_BUTTON_IRQ" />
 +
</interrupt>
 +
</source>
 +
 
 +
* Le nœud '''generics''' est utilisé pour contenir la déclaration des paramètres GENERIC disponibles sur l'élément TOP de l'IP '''si celui-ci est un fichier VHDL'''.
 +
** ''TODO: à définir plus précisément''
 +
** '''name''' : nom contenu dans le VHDL
 +
** '''public''' : Cet attribut permet de spécifier si c'est à l'utilisateur ou à orchestra de définir la valeur.
 
** '''valid''': Cet attribut va permettre de définir la ou les valeurs ou plages de valeurs valide pour ce paramètre. Le format de ce champ n'est pas encore totalement défini, soit sous forme d'expression régulière soit sous la forme suivante:
 
** '''valid''': Cet attribut va permettre de définir la ou les valeurs ou plages de valeurs valide pour ce paramètre. Le format de ce champ n'est pas encore totalement défini, soit sous forme d'expression régulière soit sous la forme suivante:
 
*** '''1..16''' ==> de 1 (inclus) à 16 (inclus)
 
*** '''1..16''' ==> de 1 (inclus) à 16 (inclus)
 
*** '''8|16|32''' ==>  8 '''ou''' 16 '''ou''' 32
 
*** '''8|16|32''' ==>  8 '''ou''' 16 '''ou''' 32
 
*** '''1..16|32''' ==> de 1 à 16 '''ou''' 32
 
*** '''1..16|32''' ==> de 1 à 16 '''ou''' 32
−
** '''value''': Cet attribut va permettre de définir la valeur par défaut du paramètre
+
** '''value''' : la valeur par défaut  
−
<pre>
+
 
−
<generic_map>
+
<source lang="xml">
−
  <generic name="irq_count" type="integer" value="16" valid="1..16">
+
<generics>
−
    <![CDATA[
+
<generic name="brightness" public=true default="middle" valid="low|middle|strong" />
−
      irq_count gives the maximum allowed interruption sources.
+
−
    ]]>
+
−
  </generic>
+
−
  <generic name="irq_level" type="std_logic" value="1" valid="0|1">
+
−
    <![CDATA[
+
−
      irq_level gives the irq output signal active level.
+
−
    ]]>
+
−
  </generic>
+
 
</generics>
 
</generics>
−
</pre>
+
</source>
 +
 
 +
 
 +
* le nœud '''ports''' contient les ports la définition de tous les ports utilisés par le composant. Chaque entrée PORT de l'IP va être représentée par une balise '''port''' qui va entièrement décrire la paramètre à l'aide des attributs suivants:
 +
** '''name''' : le nom du port.
 +
** '''interface''': le nom de l'interface à laquelle le port est rattaché.
 +
** '''type''': Le type de signal Wishbone (EXPORT si non wishbone).
 +
 
 +
<source lang="xml">
 +
<ports>
 +
        <port interface="CANDR" name="WBC_CANDR_RESET" type="RST" />
 +
        <port interface="CANDR" name="WBC_CANDR_CLK" type="CLK" />
 +
        <port interface="SLED" name="WBS_SLED_WRITEDATA" type="DAT" />
 +
        <port interface="SLED" name="WBS_SLED_READDATA" type="DAT" />
 +
        <port interface="SLED" name="WBS_SLED_STROBE" type="STB" />
 +
        <port interface="SLED" name="WBS_SLED_WRITE" type="WE" />
 +
        <port interface="SLED" name="WBS_SLED_ACK" type="ACK" />
 +
        <port interface="LED" name="GLS_LED_EXPORT" type="EXPORT" />
 +
</ports>
 +
</source>
 +
 
 +
Pour une reconnaissance automatique par le parser, le code VHDL devra respecter le format suivant :
 +
<tt><type_interface>_<nom_interface>_<nom_signal></tt>
 +
 
 +
=== Les plateformes ===
 +
 
 +
=== Les projets ===
 +
 
 +
 
 +
== Orchestra ProjectBuilder ==
 +
This program is used to generate the target firmware based on the specified IPs.
 +
A list of the available commands can be displayed like that: projectBuilder
 +
 
 +
*'''Project creation'''
 +
Before to be able to add Ips to a project, it has to be created:
 +
projectBuilder -createProject test platform.xml
 +
Where test is the name of the project and platform.xml the platform description file. This file contains informations like the type of the FPGA used on a particular platform. <br/>
 +
<u>Result</u>: creation of a  test.pro file.
 +
 +
*'''Adding/removing IPs'''
 +
Once the project created, IPs can be added like that:
 +
projectBuilder -addIp myIp ip.xml ip_constraint.xml
 +
where myIp is the instance name of the IP ip.xml and ip_constraint.xml the
 +
constraint file for myIp.  The local .pro file is used that's why the it must
 +
not be specified in the command line
 +
 
 +
Ips can be removed like that:
 +
projectBuilder -removeIp myIp
 +
 
 +
*'''Project informations'''
 +
''List of Ips''
 +
 
 +
The Ips present in the project can be listed as follow:
 +
projectBuilder -listIps
 +
 +
''IP information''
 +
 
 +
Informations concerning a particular Ip within the project can be retrieved like that:
 +
projectBuilder -viewIpInfos myIp
 +
A list of all the ArmadeusReady Ips can be generated like that:
 +
projectBuilder -listArmadeusReadyIps
 +
 
 +
''Platform information''
 +
 
 +
Platform informations can be displayed as follow:
 +
projectBuilder -viewPlatformInfos
 +
 
 +
''Toolchain''
 +
 
 +
The toolchain used to compile the project can be specified as follow:
 +
projectBuilder -setToolchain xilinx
 +
It has be noted that the xilinx toolchain is the only tooclhain for the moment.
 +
 +
*'''IP set functions'''
  
−
== Les plateformes ==
+
An IP instance has its own base address and its own interrupt ID within a project.  This two parameters can be changed like that:
 +
projectBuilder -clearIpAddress myIP
 +
projectBuilder -setIPBaseAddress myIP 0X0008  where 0X0008 is the new base address of the IP 
 +
projectBuilder -setInterrupt myIP 0X0001 where 0X0001 si the new interrupt number of the IP
  
−
== Les projets ==
+
*'''Project Build'''
 +
Once the IPs added to your project, it can be build with the following command:
 +
projectBuilder -buildProject
 +
<u>Results</u>: several files are created:
 +
*'''test.scr''' : script file for the Xilinx XST compiler
 +
*'''test.prj''' : project file for the Xilinx XST compiler
 +
*'''test.log''' : log file

Latest revision as of 16:47, 28 March 2008

Info: The development tree of the Orchestra Tool of Armadeus Project has been moved to http://developer.berlios.de/projects/osocgen/

Vue d'ensemble du système Orchestra

Une image étant souvent plus explicite qu'un long texte, voici, schématiquement, le principe de fonctionnement retenu pour Orchestra.

Description fonctionnelle du système

On peut reconnaitre de ce schéma, que le système se repose sur:

  • une bibliothèque de composants Armadeus Ready
  • une bibliothèque de plateformes
  • un projet
  • une liste de fichiers modèles

A l'aide des ces composants le processeur orchestra va générer:

  • un projet Xilinx complet, c'est-à-dire que l'on pourra lancer les outils Xilinx en ligne de commande avec ce projet et générer ainsi les fichiers nécessaires pour le fonctionnement du FPGA. Ce projet pourra également servir de base et être compléter par l'utilisateur pour y inclure d'autres fonctionnalités n'ayant aucun lien avec l'i.MX.
  • un projet Device Driver, cette sortie est optionnelle et dépendra fortement du type de composants utilisés lors de la construction du système. En effet, ces composants devront inclure une partie driver.

Format de base des fichiers XML

Avant de donner plus de détails sur les fichiers XML traités et/ou générés par Orchestra, voici quelques règles de codage qui seront globalement appliquées :

  • Tous les fichiers XML commencent avec une entête définissant le type de codage utilisé pour les caractères.
  • Toutes les balises et tous les attributs des balises sont en minuscule.
  • Un fichier XML décrit un seul élément, le noeud de base permettra d'identifier le contenu du fichier :
    • component: pour un composant
    • board: pour une plateforme
    • project: pour un projet
  • Le corps d'une balise est utilisé pour la description ou un commentaire relatif à l'élément représenté par la balise.

Voici un extrait de fichier XML pour un composant à titre d'illustration 

<?xml version="1.0" encoding="utf-8"?>
<component name="irq_mngr" version="1.0" category="base">

  <description>
      The Interruption Manager is a Wishbone slave component and Armadeus compiliant.
  </description>
...
</component>


Les composants

Un composant Armadeus Ready se compose des éléments suivants:

  • un ensemble de fichiers HDL (VHDL ou Verilog)
  • un ensemble de fichiers C,H,Makefile et configuration (optionnel)
  • un fichier XML qui va décrire entièrement le composant

Nous allons maintenant nous intéresser au contenu de ce fichier XML et en premier lieu avec les attributs dont dispose le nœud de base component:

  • name: le nom du composant (IP), de préférence pas plus de 16 caractères.
  • version: la version du composant
  • category: la catégorie dans laquelle le composant se situe. Par exemple: base, communication, etc.
<component category="User Component" name="led" version="1.0">
...
</component>

Sous le noeud de base se trouve les éléments suivants:

  • Le noeud description (optionnel) qui va contenir une description plus ou moins détaillée du composant.
<description>
    The Interruption Manager is a Wishbone slave component and Armadeus compiliant.
</description>
  • Le nœud driver_files contient les fichiers aux drivers concernant l'IP. Pour chaque architecture, on crée un nœud architecture avec un attribut "name" pour le nom de l'architecture. Chaque fichier est placé dans une base driver_file avec les attributs suivants :
    • name : nom du fichier.
<driver_files>
	<architecture name="linux">
		<driver_file name="led.h">
		<driver_file name="led.c">
		<driver_file name="Makefile">
		<driver_file name="Konfig">
	</architecture>
</driver_files>

Dans cet exemple, les fichiers seront inclus dans le répertoire drivers/linux/ du zip. L'outil générera un header pour les registres avec le nom du composant plus _register, dans le cas du composant exemple led nous aurons led_register.h à inclure dans le code du driver.

  • le nœud hdl_files va contenir la liste des fichiers VHDL ou Verilog qui composent l'IP. Chaque fichier est placé dans une base hdl_file et les attributs suivant sont proposés:
    • name: C'est le nom du fichier. Le chemin vers le fichier est donné en relatif par rapport à l'emplacement du fichier XML de description du composant.
    • scope: Cet attribut va permettre de donner la portée du fichier, c'est-à-dire pour quel utilisation ce fichier est prévu. Voici quelques valeurs pour cet attribut:
      • all: le fichier doit toujours être inclus (valeur par défaut)
      • xilinx: le fichier n'est exploitable que pour des composants/outils de chez Xilinx
      • altera: le fichier n'est exploitable que pour des composants/outils de chez Altera
      • tb: le fichier n'est pas synthétisable et ne fonctionne que dans le cadre de bancs de tests.
    • istop: Cet attribut va permettre d'identifier le fichier TOP de l'IP. Il n'y a que 2 valeurs possible 0 (valeur par défaut) ou 1 (pour indiquer le fichier TOP). Il faut définir au moins 1 fichier TOP. Si plusieurs fichiers TOP sont déclarés, par exemple si une IP est spécialisable en fonction du type de carte, toutes les entités des fichiers TOP doivent avoir la même signature.
<hdl_files>
  <hdl_file name="irq_mgnr.vhd" scope="all" istop="1" />
</hdl_files>
  • le nœud interface permet de définir les différentes interfaces utilisées dans le composant. Les attributs sont les suivants :
    • name: le nom du port tel que définit dans l'entity.
    • type: Le type de signal Wishbone (GLS si non wishbone).
      • WBM Wishbone Master.
      • WBS Wishbone Slave.
      • WBC Wishbone Clock.
      • GLS Interface non Wishbone.
    • clockandreset: Nom du domaine d'horloge rattaché à l'interface.
<interfaces>
        <interface clockandreset="CANDR" name="LED" type="GLS"/>
        <interface name="CANDR" type="WBC" />
        <interface clockandreset="CANDR" name="SLED" type="WBS" />
</interfaces>
  • Le nœud registers permet de définir le nom et l'adresse des registres de l'IP. Le nom des registres doit correspondre à ceux utiliser dans le driver.
    • name : nom du registre.
    • offset : adresse du registre en hexadécimale (0x0000,0x0003,...)
    • desc : description du registre
<registers>
	<register name="reg_led" offset=0x0 desc="led value" />
</registers>
  • Le nœud interrupts permet de définir le (les?) nom de l'interruption utilisée s'il y a lieu dans le driver (par un #define). Orchestra définira ensuite la position de l'interruption dans l'irq_mngr.
<interrupts>
	<interrupt name="WB_BUTTON_IRQ" />
</interrupt>
  • Le nœud generics est utilisé pour contenir la déclaration des paramètres GENERIC disponibles sur l'élément TOP de l'IP si celui-ci est un fichier VHDL.
    • TODO: à définir plus précisément
    • name : nom contenu dans le VHDL
    • public : Cet attribut permet de spécifier si c'est à l'utilisateur ou à orchestra de définir la valeur.
    • valid: Cet attribut va permettre de définir la ou les valeurs ou plages de valeurs valide pour ce paramètre. Le format de ce champ n'est pas encore totalement défini, soit sous forme d'expression régulière soit sous la forme suivante:
      • 1..16 ==> de 1 (inclus) à 16 (inclus)
      • 8|16|32 ==> 8 ou 16 ou 32
      • 1..16|32 ==> de 1 à 16 ou 32
    • value : la valeur par défaut 
<generics>
 <generic name="brightness" public=true default="middle" valid="low|middle|strong" />
</generics>


  • le nœud ports contient les ports la définition de tous les ports utilisés par le composant. Chaque entrée PORT de l'IP va être représentée par une balise port qui va entièrement décrire la paramètre à l'aide des attributs suivants:
    • name : le nom du port.
    • interface: le nom de l'interface à laquelle le port est rattaché.
    • type: Le type de signal Wishbone (EXPORT si non wishbone).
<ports>
        <port interface="CANDR" name="WBC_CANDR_RESET" type="RST" />
        <port interface="CANDR" name="WBC_CANDR_CLK" type="CLK" />
        <port interface="SLED" name="WBS_SLED_WRITEDATA" type="DAT" />
        <port interface="SLED" name="WBS_SLED_READDATA" type="DAT" />
        <port interface="SLED" name="WBS_SLED_STROBE" type="STB" />
        <port interface="SLED" name="WBS_SLED_WRITE" type="WE" />
        <port interface="SLED" name="WBS_SLED_ACK" type="ACK" />
        <port interface="LED" name="GLS_LED_EXPORT" type="EXPORT" />
</ports>

Pour une reconnaissance automatique par le parser, le code VHDL devra respecter le format suivant : <type_interface>_<nom_interface>_<nom_signal>

Les plateformes

Les projets

Orchestra ProjectBuilder

This program is used to generate the target firmware based on the specified IPs. A list of the available commands can be displayed like that: projectBuilder

  • Project creation

Before to be able to add Ips to a project, it has to be created: 

projectBuilder -createProject test platform.xml

Where test is the name of the project and platform.xml the platform description file. This file contains informations like the type of the FPGA used on a particular platform.
Result: creation of a test.pro file.

  • Adding/removing IPs

Once the project created, IPs can be added like that: 

projectBuilder -addIp myIp ip.xml ip_constraint.xml

where myIp is the instance name of the IP ip.xml and ip_constraint.xml the constraint file for myIp. The local .pro file is used that's why the it must not be specified in the command line

Ips can be removed like that: 

projectBuilder -removeIp myIp
  • Project informations

List of Ips

The Ips present in the project can be listed as follow: 

projectBuilder -listIps

IP information

Informations concerning a particular Ip within the project can be retrieved like that: 

projectBuilder -viewIpInfos myIp

A list of all the ArmadeusReady Ips can be generated like that: 

projectBuilder -listArmadeusReadyIps

Platform information

Platform informations can be displayed as follow: 

projectBuilder -viewPlatformInfos

Toolchain

The toolchain used to compile the project can be specified as follow: 

projectBuilder -setToolchain xilinx

It has be noted that the xilinx toolchain is the only tooclhain for the moment.

  • IP set functions

An IP instance has its own base address and its own interrupt ID within a project. This two parameters can be changed like that: 

projectBuilder -clearIpAddress myIP
projectBuilder -setIPBaseAddress myIP 0X0008   where 0X0008 is the new base address of the IP  
projectBuilder -setInterrupt myIP 0X0001 where 0X0001 si the new interrupt number of the IP
  • Project Build

Once the IPs added to your project, it can be build with the following command: 

projectBuilder -buildProject

Results: several files are created:

  • test.scr : script file for the Xilinx XST compiler
  • test.prj : project file for the Xilinx XST compiler
  • test.log : log file
Retrieved from "http://armadeus.org/wiki/index.php?title=Orchestra&oldid=3735"