ArmadeusWiki - User contributions [en]

Using FPGA

2012-02-12T21:11:28Z

SonZerro: Fix XESS link

__NOTOC__

==Developing on the APF FPGA==

{| border="0" cellpadding="5" cellspacing="5" summary="Hardware Add-Ons by functionalities" width="100%"
|----------------
|- style="background:#f4f4f4; color:black; -moz-border-radius:18px;"

| width="50%" |

=== 1. Starting Up with FPGA ===
All you need to know to play with the Armadeus FPGA.

| width="50%" |
=== Design Tools===
Description of tools used to simulate, to synthesize, and to download/configure FGPA.

* [[ISE WebPack installation on Linux| ISE WebPack (Xilinx's free devt tool) installation]]
* [[How_to_make_a_VHDL_design_in_Ubuntu/Debian| How to setup the FPGA toolchain in Ubuntu/Debian]]
* [[How to simulate post synthesis and post place & route design with GHDL]]

|----------------
|- style="background:#f4f4f4; color:black; -moz-border-radius:18px;"

| width="50%" |

=== 2. Make some examples ===

These examples give the basis to make VHDL design for FPGA.

* [[Simple blinking LED | LED]]
* [[A simple design with Wishbone bus | Complete example with button and led on wishbone bus communication and Linux drivers]]

| width="50%" |

===Using Armadeus FPGA===
Manage the FGPA from Armadeus distribution.

* [[Configure or flash FPGA ?]]
* Configure the FPGA [[FPGA_loader | from Linux]], [[Target_Software_Installation#FPGA_firmware_test | from U-Boot]]
* Flashing FPGA firmware [[Uboot_FPGA_firmware_update_from_Linux | from Linux]], [[Target_Software_Installation#FPGA_firmware_installation | from U-Boot]]
* [[FPGA_register | Access the FPGA address domain from Linux]]
* [[Ho! No FPGA-reset button on armadeus card.]]

|----------------
|- style="background:#f4f4f4; color:black; -moz-border-radius:18px;"

| width="50%" |

=== 3. Automatize FPGA design making ===

==== [[Peripherals On Demand]] ====
For complex projects, POD should be used to simplify design.

| width="50%" |

===VHDL ===

* [[VHDL coding styles|VHDL coding styles & externals documentations]]
* [http://www.xess.com/design_examples.php#XESS_Examples Nice ideas/examples to look at]
* [http://www.opencores.org www.opencores.org]
* [http://www.gmvhdl.com/VHDL.html An Introductory VHDL Tutorial]

|----------------
|- style="background:#f4f4f4; color:black; -moz-border-radius:18px;"

| width="50%" |
=== FPGA Interface ===

* APF9328 : [[IMX9328-Spartan3 interface description]]
* APF27 : [[IMX27-Spartan3A interface description]]
* APF51 : [[IMX51-Spartan6 interface description]]

| width="50%" |

===Links===
Some useful links.

''' Wishbone '''
* [http://cdn.opencores.org/downloads/wbspec_b3.pdf official Wishbone specifications]
* [http://en.wikipedia.org/wiki/Wishbone_%28computer_bus%29 Wikipedia Wishbone doc]

''' Spartan '''
* [http://www.xilinx.com/support/documentation/data_sheets/ds099.pdf Spartan-3 FPGA Family Data Sheet]

''' Orchestra '''
* [http://osocgen.berlios.de/ Orchestra website]
* [http://developer.berlios.de/projects/osocgen/ Orchestra project page]

|}

LinuxInstall

2009-08-06T23:22:54Z

SonZerro: buildroot download

<noinclude>
<big>How-To install Armadeus Software Development Kit (SDK) on Linux systems. This SDK is currently based on the (excellent) [http://buildroot.net/ Buildroot].</big>
</noinclude>

The installation was successfully tested on the following distributions:
* Debian Sarge, Etch & Lenny
* Fedora Core 3 & 4
* Fedora 10
* KUbuntu Edgy Eft (6.10), Gutsy Gibbon (7.10), Hardy Heron (8.04) & Jaunty Jackalope (9.04)
* Mandriva 2006
* SuSE 10.1
* Ubuntu Dapper Drake (6.04), Hardy Heron (8.04) & Intrepid Ibex (8.10)
* Xubuntu Edgy Eft (6.10)

==Prerequisites for Linux installation==
{{Note|From here we assume that your Linux system has a ''make'' version '''greater or equal to''' 3.81. To check it:
<pre class="host">
$ make -v
GNU Make 3.81
...
</pre>
}}

Depending on your distribution, some additional packages are required.

===Debian/Ubuntu based systems===
* you can use the following command to get them (assuming your userid is allowed to use sudo (execution of commands as root)):
<pre class="host">
sudo apt-get install gcc g++ autoconf automake libtool bison flex gettext
sudo apt-get install patch subversion texinfo wget git-core
sudo apt-get install libncurses5 libncurses5-dev
sudo apt-get install zlib1g-dev liblzo2-2 liblzo2-dev
sudo apt-get install libacl1 libacl1-dev
</pre>

Not mandatory but useful to add for compiling some Buildroot packages:
<pre class="host">
sudo apt-get install libglib2.0-dev
sudo apt-get install libnetpbm10-dev (for fbtest)
</pre>

{{Warning|For Ubuntu based systems, the following is now required if your ''/bin/sh'' is '''not''' pointing to ''/bin/bash'':
<pre class="host">
$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 2007-12-08 18:33 /bin/sh -> dash
$ sudo dpkg-reconfigure dash
and select no
</pre>
Indeed dash do not support all the capabilities needed by Buildroot (our build system).
}}

===Mandriva based systems===
* name of packages are different therefore use the lines hereafter instead (assuming sudo is configured to support root commands):
<pre class="host">
sudo urpmi gcc gcc-c++ make autoconf automake libtool bison flex gettext
sudo urpmi patch subversion texinfo wget git
sudo urpmi libncurses5 libncurses-devel
sudo urpmi zlib1-devel liblzo2_2 liblzo-devel
sudo urpmi libacl1 libacl-devel
</pre>

Not mandatory but useful to add some Buildroot packages:
<pre class="host">
sudo urpmi libglib2.0-devel
</pre>

===RPM-based systems===
*like Fedora and CentOS, the following commands should install all the needed prerequisites (assuming root shell):
<pre class="host">
yum install gcc gcc-c++ make autoconf automake libtool bison flex gettext
yum install patch subversion texinfo git
yum install zlib-devel gettext-devel ncurses-devel lzo-devel libacl-devel
</pre>

Not mandatory but useful to add some extra packages:
<pre class="host">
yum install glib2-devel lzo2-devel
</pre>

==Get Armadeus software==
* '''If you are a "careful" user''', then download [http://sourceforge.net/project/showfiles.php?group_id=122057&package_id=133240 the latest stable installation tarball from SourceForge] and detar it wherever you want:
<pre class="host">
$ tar xjvf armadeus-3.1.tar.bz2
</pre>
* '''If you want the last snapshot''',the whole development tree can now be checked out from the new [[GIT_Migration|GIT]] repository. SVN repository is no more maintained !!!
<pre class="host">
$ git clone git://armadeus.git.sourceforge.net/gitroot/armadeus armadeus
</pre>

A directory named ''armadeus/'' or ''armadeus-3.1/'' will be created on your hard-disk and will contain all the files you need.

'''Remarks''':
* '''Do not use spaces''' in the directory name !
* GIT write/push accesses are limited to the integrators ([[User:JulienB|JulienB]], [[User:Salocin68|Salocin68]], [[User:Jorasse|Jorasse]], [[User:FabienM|FabienM]])

==Configure SDK options==
The first time you compile an Armadeus distribution you have to specify the target to work with.
<pre class="host">
$ cd armadeus/ (or armadeus-3.1/)
$ make apf9328_defconfig
</pre>
This command reloads the default configuration to support an [[APF9328|APF9328 board]] and automatically start a Buildroot's configuration menu. For the [[APF27]] it would be:
<pre class="host">
$ make apf27_defconfig
</pre>

{{Note|If you ever made changes in the following steps, at any time you can reload the default configuration with '''make apf9328_defconfig''' or '''make apf27_defconfig'''.}}

[[Image:Menuconfig3.png]]<br>
*If you are not familiar with Buildroot here are some tips:
*# you can move the highlighted item with the "up"/"down" arrow keys
*# with the "left"/"right" arrow keys you can choose between "Select", "Exit" or "Help" buttons
*# "space"/"enter":
*#* selects the currently highlighted item if you are on the "Select" button
*#* go back in previous menu if you are on "Exit" button
*#* show you some Help for current item if you are on "Help" button
*# for more Help about Buildroot commands, select "Help" in the main configuration screen

*In menu:
:<pre class="config">Target options --->
:[*] Armadeus Device Support ---></pre>
:you can check and change the quantity of RAM available on your Armadeus board. Default value 16MB is just fine with all [[APF9328]] boards, for [[APF27]] it could be either 64MB or or 2 x 64MB (in that case be sure to select 2 chips of 64MB instead of 1 chip of 128MB).

*In menu:
:<pre class="config">Target filesystem options --> </pre>
:for each type of filesystems to build, you have the option (''also copy the image to...'') to copy the binary file to secondary location like your tftp server folder (for example ''/tftpboot'').<br>
:Also U-Boot can be copied to a second location (like ''/tftpboot''). You will find the U-Boot options at the end of the list.

*In menu:
:<pre class="config">Kernel -->
:Destination for linux kernel binaries --> </pre>
:you will find options to copy Linux to a secondary location (like ''/tftpboot'')

* You may decrease the compilation time by increasing the number of parallel jobs running simultaneously on your system (the result is not guaranteed). This option is located in
:<pre class="config">Build Options --->
:(1) Number of jobs to run simultaneously</pre>

* During the toolchain/distribution automatic build, a lot of software archives are downloaded from Internet. The downloaded files are put by default in the ''armadeus/downloads/'' directory. '''If you have several views or plan to build the toolchain several times''', we advise you to put all the downloaded files in ''/local/downloads'' (for example). This is done by configuring Buildroot to use this directory for all your views. Nevertheless, buildroot will be downloaded separately for each build environment you set up.
:<pre class="config">Build options --->
:(...) Download dir</pre>
:[[Image:Build_config_menu_download.png]]<br> <br>
:[[Image:Build_config_download.png]]

* After the build, we advise you too to copy all the files in ''downloads/'' on a removable medium, in case you want to install the development tools on several systems.

* Now, Exit the configuration tool and save your configuration

==Launch build==
$ make
The toolchain and the full distribution are automatically built. During this procedure, several files are downloaded from Internet. <br>
'''Please wait for a while.... it takes at least one hour for the first run!'''<br>
The downloaded files are put (by default) in the ''armadeus/downloads/'' directory. Please see the previous chapter to know how to optimize that if you plan to build several views.

==Enjoy the result==
The generated binary files can be found in the subdirectory ''buildroot/binaries/apfXX/'' (where XX is the name of your board):

*''apfXX-u-boot.brec'': only on [[APF9328]]; BRecord image that can be used with the bootstrap, if U-Boot is not installed or not working (see [[BootLoader]] page)
*''apfXX-u-boot.bin'': U-Boot image file to be used with U-Boot itself, (see [[BootLoader#Update_U-Boot | updating U-Boot]])
*''apfXX-linux.bin'': Linux image to use with U-Boot, (see [[Target_Software_Installation#Linux_kernel_installation | updating Linux]])
*''apfXX-rootfs.arm.jffs2'': filesystem/rootfs image to use with U-Boot, (see [[Target_Software_Installation#Linux_rootfs_installation | updating rootfs]])
*''apfXX-rootfs.arm.tar'': for an NFS/MMC based rootfs, (see [[Network_Configuration#Boot_from_NFS | Booting from NFS]] & [[MultiMediaCard#Booting_from_MMC.2FSD | Booting from a MMC/SD]])

'''Please note the new naming convention of binary files and directories'''

The toolchain and project files share a new naming convention too (YY is 4t for APF9328 and 5te for APF27):
*''buildroot/build_armvYY'': contains all non configurable user-space tools
*''buildroot/project_build_armvYY/apfXX'': contains all configurable user-space tools: target filesystem, <b>linux</b>, busybox and <b>u-boot</b>...
*''buildroot/toolchain_build_armvYY'': cross compilation toolchain

More information is available in the [http://buildroot.uclibc.org/buildroot.html buildroot documentation]

* Note: Previous versions of Armadeus SDK stored the generated binary files at different place ''buildroot/binaries/armadeus/'' and file names did not contained any prefix of board name:

:u-boot.brec (BRecord image that can be used with the bootstrap, if U-Boot is not installed or not working)
:u-boot.bin (U-Boot image file for use with U-Boot itself)
:linux-kernel-2.6.xx-arm.bin (Linux image to use with U-Boot)
:rootfs.arm.jffs2 (FileSystem/RootFS image to use with U-Boot)
:rootfs.arm.tar (for an NFS/MMC RootFS)

<noinclude>
==To keep your local copy/repository up-to-date with the armadeus GIT repository==
<pre class="host">
$ git pull
</pre>
This will update your working directory to the latest release.

Note: if "git pull" fails because a directory or a file already exists, then do:
$ rm -rf <this-directory/file>
$ git pull

You can do a:
$ make apf9328_defconfig
to have the latest features automatically activated.

You have to do a '''make''' to rebuild binary files and then upload the binary files to your target.

Note: if definitively everything goes wrong while it worked before the last update.
You can apply the following procedure (all your modifications in buildroot will be lost):
$ rm -rf buildroot/
$ rm Makefile
$ git pull
$ make apf9328_defconfig
$ make

Enjoy!

{{LanguageBar|LinuxInstall|Compilateur croisé|LinuxInstall}}
</noinclude>

LinuxInstall

2009-08-06T13:59:38Z

SonZerro: additional distro tested

<noinclude>
<big>How-To install Armadeus Software Development Kit (SDK) on Linux systems. This SDK is currently based on the (excellent) [http://buildroot.net/ Buildroot].</big>
</noinclude>

The installation was successfully tested on the following distributions:
* Debian Sarge, Etch & Lenny
* Fedora Core 3 & 4
* Fedora 10
* KUbuntu Edgy Eft (6.10), Gutsy Gibbon (7.10), Hardy Heron (8.04) & Jaunty Jackalope (9.04)
* Mandriva 2006
* SuSE 10.1
* Ubuntu Dapper Drake (6.04), Hardy Heron (8.04) & Intrepid Ibex (8.10)
* Xubuntu Edgy Eft (6.10)

==Prerequisites for Linux installation==
{{Note|From here we assume that your Linux system has a ''make'' version '''greater or equal to''' 3.81. To check it:
<pre class="host">
$ make -v
GNU Make 3.81
...
</pre>
}}

Depending on your distribution, some additional packages are required.

===Debian/Ubuntu based systems===
* you can use the following command to get them (assuming your userid is allowed to use sudo (execution of commands as root)):
<pre class="host">
sudo apt-get install gcc g++ autoconf automake libtool bison flex gettext
sudo apt-get install patch subversion texinfo wget git-core
sudo apt-get install libncurses5 libncurses5-dev
sudo apt-get install zlib1g-dev liblzo2-2 liblzo2-dev
sudo apt-get install libacl1 libacl1-dev
</pre>

Not mandatory but useful to add for compiling some Buildroot packages:
<pre class="host">
sudo apt-get install libglib2.0-dev
sudo apt-get install libnetpbm10-dev (for fbtest)
</pre>

{{Warning|For Ubuntu based systems, the following is now required if your ''/bin/sh'' is '''not''' pointing to ''/bin/bash'':
<pre class="host">
$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 2007-12-08 18:33 /bin/sh -> dash
$ sudo dpkg-reconfigure dash
and select no
</pre>
Indeed dash do not support all the capabilities needed by Buildroot (our build system).
}}

===Mandriva based systems===
* name of packages are different therefore use the lines hereafter instead (assuming sudo is configured to support root commands):
<pre class="host">
sudo urpmi gcc gcc-c++ make autoconf automake libtool bison flex gettext
sudo urpmi patch subversion texinfo wget git
sudo urpmi libncurses5 libncurses-devel
sudo urpmi zlib1-devel liblzo2_2 liblzo-devel
sudo urpmi libacl1 libacl-devel
</pre>

Not mandatory but useful to add some Buildroot packages:
<pre class="host">
sudo urpmi libglib2.0-devel
</pre>

===RPM-based systems===
*like Fedora and CentOS, the following commands should install all the needed prerequisites (assuming root shell):
<pre class="host">
yum install gcc gcc-c++ make autoconf automake libtool bison flex gettext
yum install patch subversion texinfo git
yum install zlib-devel gettext-devel ncurses-devel lzo-devel libacl-devel
</pre>

Not mandatory but useful to add some extra packages:
<pre class="host">
yum install glib2-devel lzo2-devel
</pre>

==Get Armadeus software==
* '''If you are a "careful" user''', then download [http://sourceforge.net/project/showfiles.php?group_id=122057&package_id=133240 the latest stable installation tarball from SourceForge] and detar it wherever you want:
<pre class="host">
$ tar xjvf armadeus-3.1.tar.bz2
</pre>
* '''If you want the last snapshot''',the whole development tree can now be checked out from the new [[GIT_Migration|GIT]] repository. SVN repository is no more maintained !!!
<pre class="host">
$ git clone git://armadeus.git.sourceforge.net/gitroot/armadeus armadeus
</pre>

A directory named ''armadeus/'' or ''armadeus-3.1/'' will be created on your hard-disk and will contain all the files you need.

'''Remarks''':
* '''Do not use spaces''' in the directory name !
* GIT write/push accesses are limited to the integrators ([[User:JulienB|JulienB]], [[User:Salocin68|Salocin68]], [[User:Jorasse|Jorasse]], [[User:FabienM|FabienM]])

==Configure SDK options==
The first time you compile an Armadeus distribution you have to specify the target to work with.
<pre class="host">
$ cd armadeus/ (or armadeus-3.1/)
$ make apf9328_defconfig
</pre>
This command reloads the default configuration to support an [[APF9328|APF9328 board]] and automatically start a Buildroot's configuration menu. For the [[APF27]] it would be:
<pre class="host">
$ make apf27_defconfig
</pre>

{{Note|If you ever made changes in the following steps, at any time you can reload the default configuration with '''make apf9328_defconfig''' or '''make apf27_defconfig'''.}}

[[Image:Menuconfig3.png]]<br>
*If you are not familiar with Buildroot here are some tips:
*# you can move the highlighted item with the "up"/"down" arrow keys
*# with the "left"/"right" arrow keys you can choose between "Select", "Exit" or "Help" buttons
*# "space"/"enter":
*#* selects the currently highlighted item if you are on the "Select" button
*#* go back in previous menu if you are on "Exit" button
*#* show you some Help for current item if you are on "Help" button
*# for more Help about Buildroot commands, select "Help" in the main configuration screen

*In menu:
:<pre class="config">Target options --->
:[*] Armadeus Device Support ---></pre>
:you can check and change the quantity of RAM available on your Armadeus board. Default value 16MB is just fine with all [[APF9328]] boards, for [[APF27]] it could be either 64MB or or 2 x 64MB (in that case be sure to select 2 chips of 64MB instead of 1 chip of 128MB).

*In menu:
:<pre class="config">Target filesystem options --> </pre>
:for each type of filesystems to build, you have the option (''also copy the image to...'') to copy the binary file to secondary location like your tftp server folder (for example ''/tftpboot'').<br>
:Also U-Boot can be copied to a second location (like ''/tftpboot''). You will find the U-Boot options at the end of the list.

*In menu:
:<pre class="config">Kernel -->
:Destination for linux kernel binaries --> </pre>
:you will find options to copy Linux to a secondary location (like ''/tftpboot'')

* You may decrease the compilation time by increasing the number of parallel jobs running simultaneously on your system (the result is not guaranteed). This option is located in
:<pre class="config">Build Options --->
:(1) Number of jobs to run simultaneously</pre>

* During the toolchain/distribution automatic build, a lot of software archives are downloaded from Internet. The downloaded files are put by default in the ''armadeus/downloads/'' directory. '''If you have several views or plan to build the toolchain several times''', we advise you to put all the downloaded files in ''/local/downloads'' (for example). This is done by configuring Buildroot to use this directory for all your views:
:<pre class="config">Build options --->
:(...) Download dir</pre>
:[[Image:Build_config_menu_download.png]]<br> <br>
:[[Image:Build_config_download.png]]

* After the build, we advise you too to copy all the files in ''downloads/'' on a removable medium, in case you want to install the development tools on several systems.

* Now, Exit the configuration tool and save your configuration

==Launch build==
$ make
The toolchain and the full distribution are automatically built. During this procedure, several files are downloaded from Internet. <br>
'''Please wait for a while.... it takes at least one hour for the first run!'''<br>
The downloaded files are put (by default) in the ''armadeus/downloads/'' directory. Please see the previous chapter to know how to optimize that if you plan to build several views.

==Enjoy the result==
The generated binary files can be found in the subdirectory ''buildroot/binaries/apfXX/'' (where XX is the name of your board):

*''apfXX-u-boot.brec'': only on [[APF9328]]; BRecord image that can be used with the bootstrap, if U-Boot is not installed or not working (see [[BootLoader]] page)
*''apfXX-u-boot.bin'': U-Boot image file to be used with U-Boot itself, (see [[BootLoader#Update_U-Boot | updating U-Boot]])
*''apfXX-linux.bin'': Linux image to use with U-Boot, (see [[Target_Software_Installation#Linux_kernel_installation | updating Linux]])
*''apfXX-rootfs.arm.jffs2'': filesystem/rootfs image to use with U-Boot, (see [[Target_Software_Installation#Linux_rootfs_installation | updating rootfs]])
*''apfXX-rootfs.arm.tar'': for an NFS/MMC based rootfs, (see [[Network_Configuration#Boot_from_NFS | Booting from NFS]] & [[MultiMediaCard#Booting_from_MMC.2FSD | Booting from a MMC/SD]])

'''Please note the new naming convention of binary files and directories'''

The toolchain and project files share a new naming convention too (YY is 4t for APF9328 and 5te for APF27):
*''buildroot/build_armvYY'': contains all non configurable user-space tools
*''buildroot/project_build_armvYY/apfXX'': contains all configurable user-space tools: target filesystem, <b>linux</b>, busybox and <b>u-boot</b>...
*''buildroot/toolchain_build_armvYY'': cross compilation toolchain

More information is available in the [http://buildroot.uclibc.org/buildroot.html buildroot documentation]

* Note: Previous versions of Armadeus SDK stored the generated binary files at different place ''buildroot/binaries/armadeus/'' and file names did not contained any prefix of board name:

:u-boot.brec (BRecord image that can be used with the bootstrap, if U-Boot is not installed or not working)
:u-boot.bin (U-Boot image file for use with U-Boot itself)
:linux-kernel-2.6.xx-arm.bin (Linux image to use with U-Boot)
:rootfs.arm.jffs2 (FileSystem/RootFS image to use with U-Boot)
:rootfs.arm.tar (for an NFS/MMC RootFS)

<noinclude>
==To keep your local copy/repository up-to-date with the armadeus GIT repository==
<pre class="host">
$ git pull
</pre>
This will update your working directory to the latest release.

Note: if "git pull" fails because a directory or a file already exists, then do:
$ rm -rf <this-directory/file>
$ git pull

You can do a:
$ make apf9328_defconfig
to have the latest features automatically activated.

You have to do a '''make''' to rebuild binary files and then upload the binary files to your target.

Note: if definitively everything goes wrong while it worked before the last update.
You can apply the following procedure (all your modifications in buildroot will be lost):
$ rm -rf buildroot/
$ rm Makefile
$ git pull
$ make apf9328_defconfig
$ make

Enjoy!

{{LanguageBar|LinuxInstall|Compilateur croisé|LinuxInstall}}
</noinclude>

LinuxInstall

2009-08-06T13:45:19Z

SonZerro: formatting

<noinclude>
<big>How-To install Armadeus Software Development Kit (SDK) on Linux systems. This SDK is currently based on the (excellent) [http://buildroot.net/ Buildroot].</big>
</noinclude>

The installation was successfully tested on the following distributions:
* Debian Sarge, Etch & Lenny
* Fedora Core 3 & 4
* Fedora 10
* KUbuntu Edgy Eft (6.10), Gusty Gibbon (7.10), Hardy Heron (8.04) & Jaunty Jackalope (9.04)
* Mandriva 2006
* SuSE 10.1
* Ubuntu Dapper Drake (6.04) & Intrepid Ibex (8.10)
* Xubuntu Edgy Eft (6.10)

==Prerequisites for Linux installation==
{{Note|From here we assume that your Linux system has a ''make'' version '''greater or equal to''' 3.81. To check it:
<pre class="host">
$ make -v
GNU Make 3.81
...
</pre>
}}

Depending on your distribution, some additional packages are required.

===Debian/Ubuntu based systems===
* you can use the following command to get them (assuming your userid is allowed to use sudo (execution of commands as root)):
<pre class="host">
sudo apt-get install gcc g++ autoconf automake libtool bison flex gettext
sudo apt-get install patch subversion texinfo wget git-core
sudo apt-get install libncurses5 libncurses5-dev
sudo apt-get install zlib1g-dev liblzo2-2 liblzo2-dev
sudo apt-get install libacl1 libacl1-dev
</pre>

Not mandatory but useful to add for compiling some Buildroot packages:
<pre class="host">
sudo apt-get install libglib2.0-dev
sudo apt-get install libnetpbm10-dev (for fbtest)
</pre>

{{Warning|For Ubuntu based systems, the following is now required if your ''/bin/sh'' is '''not''' pointing to ''/bin/bash'':
<pre class="host">
$ ls -al /bin/sh
lrwxrwxrwx 1 root root 4 2007-12-08 18:33 /bin/sh -> dash
$ sudo dpkg-reconfigure dash
and select no
</pre>
Indeed dash do not support all the capabilities needed by Buildroot (our build system).
}}

===Mandriva based systems===
* name of packages are different therefore use the lines hereafter instead (assuming sudo is configured to support root commands):
<pre class="host">
sudo urpmi gcc gcc-c++ make autoconf automake libtool bison flex gettext
sudo urpmi patch subversion texinfo wget git
sudo urpmi libncurses5 libncurses-devel
sudo urpmi zlib1-devel liblzo2_2 liblzo-devel
sudo urpmi libacl1 libacl-devel
</pre>

Not mandatory but useful to add some Buildroot packages:
<pre class="host">
sudo urpmi libglib2.0-devel
</pre>

===RPM-based systems===
*like Fedora and CentOS, the following commands should install all the needed prerequisites (assuming root shell):
<pre class="host">
yum install gcc gcc-c++ make autoconf automake libtool bison flex gettext
yum install patch subversion texinfo git
yum install zlib-devel gettext-devel ncurses-devel lzo-devel libacl-devel
</pre>

Not mandatory but useful to add some extra packages:
<pre class="host">
yum install glib2-devel lzo2-devel
</pre>

==Get Armadeus software==
* '''If you are a "careful" user''', then download [http://sourceforge.net/project/showfiles.php?group_id=122057&package_id=133240 the latest stable installation tarball from SourceForge] and detar it wherever you want:
<pre class="host">
$ tar xjvf armadeus-3.1.tar.bz2
</pre>
* '''If you want the last snapshot''',the whole development tree can now be checked out from the new [[GIT_Migration|GIT]] repository. SVN repository is no more maintained !!!
<pre class="host">
$ git clone git://armadeus.git.sourceforge.net/gitroot/armadeus armadeus
</pre>

A directory named ''armadeus/'' or ''armadeus-3.1/'' will be created on your hard-disk and will contain all the files you need.

'''Remarks''':
* '''Do not use spaces''' in the directory name !
* GIT write/push accesses are limited to the integrators ([[User:JulienB|JulienB]], [[User:Salocin68|Salocin68]], [[User:Jorasse|Jorasse]], [[User:FabienM|FabienM]])

==Configure SDK options==
The first time you compile an Armadeus distribution you have to specify the target to work with.
<pre class="host">
$ cd armadeus/ (or armadeus-3.1/)
$ make apf9328_defconfig
</pre>
This command reloads the default configuration to support an [[APF9328|APF9328 board]] and automatically start a Buildroot's configuration menu. For the [[APF27]] it would be:
<pre class="host">
$ make apf27_defconfig
</pre>

{{Note|If you ever made changes in the following steps, at any time you can reload the default configuration with '''make apf9328_defconfig''' or '''make apf27_defconfig'''.}}

[[Image:Menuconfig3.png]]<br>
*If you are not familiar with Buildroot here are some tips:
*# you can move the highlighted item with the "up"/"down" arrow keys
*# with the "left"/"right" arrow keys you can choose between "Select", "Exit" or "Help" buttons
*# "space"/"enter":
*#* selects the currently highlighted item if you are on the "Select" button
*#* go back in previous menu if you are on "Exit" button
*#* show you some Help for current item if you are on "Help" button
*# for more Help about Buildroot commands, select "Help" in the main configuration screen

*In menu:
:<pre class="config">Target options --->
:[*] Armadeus Device Support ---></pre>
:you can check and change the quantity of RAM available on your Armadeus board. Default value 16MB is just fine with all [[APF9328]] boards, for [[APF27]] it could be either 64MB or or 2 x 64MB (in that case be sure to select 2 chips of 64MB instead of 1 chip of 128MB).

*In menu:
:<pre class="config">Target filesystem options --> </pre>
:for each type of filesystems to build, you have the option (''also copy the image to...'') to copy the binary file to secondary location like your tftp server folder (for example ''/tftpboot'').<br>
:Also U-Boot can be copied to a second location (like ''/tftpboot''). You will find the U-Boot options at the end of the list.

*In menu:
:<pre class="config">Kernel -->
:Destination for linux kernel binaries --> </pre>
:you will find options to copy Linux to a secondary location (like ''/tftpboot'')

* You may decrease the compilation time by increasing the number of parallel jobs running simultaneously on your system (the result is not guaranteed). This option is located in
:<pre class="config">Build Options --->
:(1) Number of jobs to run simultaneously</pre>

* During the toolchain/distribution automatic build, a lot of software archives are downloaded from Internet. The downloaded files are put by default in the ''armadeus/downloads/'' directory. '''If you have several views or plan to build the toolchain several times''', we advise you to put all the downloaded files in ''/local/downloads'' (for example). This is done by configuring Buildroot to use this directory for all your views:
:<pre class="config">Build options --->
:(...) Download dir</pre>
:[[Image:Build_config_menu_download.png]]<br> <br>
:[[Image:Build_config_download.png]]

* After the build, we advise you too to copy all the files in ''downloads/'' on a removable medium, in case you want to install the development tools on several systems.

* Now, Exit the configuration tool and save your configuration

==Launch build==
$ make
The toolchain and the full distribution are automatically built. During this procedure, several files are downloaded from Internet. <br>
'''Please wait for a while.... it takes at least one hour for the first run!'''<br>
The downloaded files are put (by default) in the ''armadeus/downloads/'' directory. Please see the previous chapter to know how to optimize that if you plan to build several views.

==Enjoy the result==
The generated binary files can be found in the subdirectory ''buildroot/binaries/apfXX/'' (where XX is the name of your board):

*''apfXX-u-boot.brec'': only on [[APF9328]]; BRecord image that can be used with the bootstrap, if U-Boot is not installed or not working (see [[BootLoader]] page)
*''apfXX-u-boot.bin'': U-Boot image file to be used with U-Boot itself, (see [[BootLoader#Update_U-Boot | updating U-Boot]])
*''apfXX-linux.bin'': Linux image to use with U-Boot, (see [[Target_Software_Installation#Linux_kernel_installation | updating Linux]])
*''apfXX-rootfs.arm.jffs2'': filesystem/rootfs image to use with U-Boot, (see [[Target_Software_Installation#Linux_rootfs_installation | updating rootfs]])
*''apfXX-rootfs.arm.tar'': for an NFS/MMC based rootfs, (see [[Network_Configuration#Boot_from_NFS | Booting from NFS]] & [[MultiMediaCard#Booting_from_MMC.2FSD | Booting from a MMC/SD]])

'''Please note the new naming convention of binary files and directories'''

The toolchain and project files share a new naming convention too (YY is 4t for APF9328 and 5te for APF27):
*''buildroot/build_armvYY'': contains all non configurable user-space tools
*''buildroot/project_build_armvYY/apfXX'': contains all configurable user-space tools: target filesystem, <b>linux</b>, busybox and <b>u-boot</b>...
*''buildroot/toolchain_build_armvYY'': cross compilation toolchain

More information is available in the [http://buildroot.uclibc.org/buildroot.html buildroot documentation]

* Note: Previous versions of Armadeus SDK stored the generated binary files at different place ''buildroot/binaries/armadeus/'' and file names did not contained any prefix of board name:

:u-boot.brec (BRecord image that can be used with the bootstrap, if U-Boot is not installed or not working)
:u-boot.bin (U-Boot image file for use with U-Boot itself)
:linux-kernel-2.6.xx-arm.bin (Linux image to use with U-Boot)
:rootfs.arm.jffs2 (FileSystem/RootFS image to use with U-Boot)
:rootfs.arm.tar (for an NFS/MMC RootFS)

<noinclude>
==To keep your local copy/repository up-to-date with the armadeus GIT repository==
<pre class="host">
$ git pull
</pre>
This will update your working directory to the latest release.

Note: if "git pull" fails because a directory or a file already exists, then do:
$ rm -rf <this-directory/file>
$ git pull

You can do a:
$ make apf9328_defconfig
to have the latest features automatically activated.

You have to do a '''make''' to rebuild binary files and then upload the binary files to your target.

Note: if definitively everything goes wrong while it worked before the last update.
You can apply the following procedure (all your modifications in buildroot will be lost):
$ rm -rf buildroot/
$ rm Makefile
$ git pull
$ make apf9328_defconfig
$ make

Enjoy!

{{LanguageBar|LinuxInstall|Compilateur croisé|LinuxInstall}}
</noinclude>

ArmadeusWiki:Site support

2009-08-06T13:27:31Z

SonZerro:

* Well, the best way to support this project is to join it by buying an APF9328 or APF27 board !
* Le meilleur moyen de "sponsoriser" ce projet est de nous rejoindre en nous commandant une carte APF9328 ou APF27 !

POD installation guide

2009-08-05T09:33:23Z

SonZerro: Ho! Again this second template...

{{Under Construction}}

== Prerequisites ==
=== mandatory ===
* python : POD is written in python.
* pyparsing : a python module to parse files.

=== optional ===
* ghdl, gtkwave : it's not mandatory, POD can generate VHDL testbench ready for ghdl simulator. As it's standard VHDL, another simulator should work.
* ISE Webpack : to generate synthesis project for Xilinx.
* Quartus : to generate synthesis project for Altera.
* ARMadeus SDK : to generate driver project for the Armadeus boards.

== Install from package ==
{{Note| For this moment, package must be created from svn repository. Release will be downloadable soon}}
* Decompress the package PeriphOnDemand-X.X.tar.gz in install directory:
<pre class="host">
$ cd somewhere/
$ tar -zxvf PeriphOnDemand-X.X.tar.gz
</pre>
* Walk through ''periphondemand/'' directory:
<pre class="host">
$ cd periphondemand
</pre>
* Then install POD with root privilege:
<pre class="host">
$ sudo python setup.py install
</pre>

== Generate package from subversion tree ==

* Checkout the source code with following command (subversion is needed):
<pre class="host">
$ svn co https://periphondemand.svn.sourceforge.net/svnroot/periphondemand/trunk periphondemand
$ cd periphondemand/
</pre>
* Make python POD distribution:
<pre class="host">
$ python setup.py sdist
</pre>
* The POD package can be found in directory ''dist/''

== Using svn tree directly ==

on your branche tree add a symbolic link named periphondemand :
<pre class="host">
trunk/$ln -s src periphondemand
</pre>

Modify the binary "pod" file to add the path :
<pre class="host">
vim src/bin/pod
</pre>

Replace :
<source lang="python">
import periphondemand.bin.pod
import sys
periphondemand.bin.pod.main(sys.argv)
</source>

By :
<source lang="python">
import os,sys
sys.path.append("PATH_OF_YOUR_TRUNK/BRANCHE")
import periphondemand.bin.pod
periphondemand.bin.pod.main(sys.argv)
</source>

Then start POD using this binary :
<pre class="host">
$ ./periphondemand/bin/pod
</pre>

Ho! No FPGA-reset button on armadeus card.

2009-08-05T09:32:10Z

SonZerro: Ho! A second template exists!

{{Under Construction}}

That is a constant comment about the armadeus apf9328 card. Most of FPGA designer learn that it's mandatory to use a reset in each module with structure like it:

<source lang="vhdl">
myprocess : process (clk,reset)
begin
if reset = '1' then
-- init values
elsif rising_edge(clk) then
-- processing code
end if;
end process myprocess;
</source>

But by default there is no reset button on card, then what to do ?

== Plug a reset button ==

Of course it's possible to solder a reset button on card, there are a large amount of I/O on connector and one can serve to do it.

== Generate the reset internal ==

But it is possible to use initial state of fpga after configuration with this code:

{{Warning| This code work only with FPGA, because states of flip-flop after configuration is defined to '0'. This can't work with CPLD for example because beginning state is unknown.}}

<source lang="VHDL">
---------------------------------------------------------------------------
Entity clock_and_reset_gen is
---------------------------------------------------------------------------
generic(
invert_reset : std_logic := '0' -- 0 : not invert, 1 invert
);
port
(
-- external signals
ext_clk : in std_logic ;
--internal generated signals
gls_clk : out std_logic ;
gls_reset : out std_logic
);
end entity;

---------------------------------------------------------------------------
Architecture clock_and_reset_gen_1 of clock_and_reset_gen is
---------------------------------------------------------------------------

signal dly: std_logic := '0';
signal rst: std_logic := '0';
signal int_reset : std_logic;

begin

int_reset <= '0';
----------------------------------------------------------------------------
-- RESET signal generator.
----------------------------------------------------------------------------
process(ext_clk)
begin
if(rising_edge(ext_clk)) then
dly <= ( not(int_reset) and dly and not(rst) )
or ( not(int_reset) and not(dly) and rst );

rst <= ( not(int_reset) and not(dly) and not(rst) );
end if;
end process;

gls_clk <= ext_clk;
gls_reset <= rst xor invert_reset ;

end architecture clock_and_reset_gen_1;
</source>

Driver for i.MX GPIO controlled keypads

2009-08-05T09:29:18Z

SonZerro: Use "Under Construction" Template

{{Under Construction}}

==Introduction==
This driver is intented to control matrix keypads connected to i.MX GPIOs

==Installation==
If not already done in standard Armadeus rootfs:
$ make linux-menuconfig
Device Drivers ---> Input device support ---> [*] Keyboards ---> <*> AT keyboard
then
Device Drivers ---> Armadeus specific drivers ---> <M> Armadeus Keypad driver

Reflash rootfs then:
# modprobe imxkeypad
Initializing Armadeus keypad driver
input: imxkeypad as /class/input/input0

==Test==
* use ''target/demos/keypad_test/'' test tool
* If you have a graphical LCD connected to your board (= virtual terminal), then you should see what you type.
* If you don't have any virtual terminal, but only the serial console:
# cat /sys/class/input/input0/event0/dev
13:64
If corresponding device node in /dev/input/ is not existing, then:
# mkdir -p /dev/input
# mknod /dev/input/event0 c 13 64

# cat /dev/input/event0
Then you should see weirds characters when pressing keyboard keys:
�,~~_�,}�}�3T,QToT6,TT�,�;��, � �

==Usage==

Keypad

2009-08-05T09:28:24Z

SonZerro: Use "Under Construction" Template

{{Under Construction}}

==How to connect a keypad to your Armadeus board==

===Introduction===

Your Armadeus board allows you to connect a matrix keypad as input device. The default keypad driver configuration supports 16 keys connected to the i.MXL CSI bus. The current development state of the driver is unfinished and not fully generic but you can easily extend the driver to support keypads up to 36 keys using the whole CSI bus. Development are also ongoing to connect matrix keypads using the FPGA.

===Hardware===
There are 2 solutions to connect a matrix keypad to your Armadeus board:
====Direct connection to i.MXL====
{| cellspacing=5 cellpadding=5 border=0 width=100%
|-
| width="75%" | By default your board supports a direct connection with a 4x4 matrix keypad using the CSI lines: CSI_MCLK, CSI_D0...CSI_D6.
The driver uses the i.MXL GPIO's internal pull-up, therefore your board does not need any additional external resistor.
* Connect the 4 (rows) lines of the keypad to CSI_MCLK, CSI_D0, CSI_D1, CSI_D2 (resp. PORT_A pin 3, 4, 5, 6)
* Connect the 4 (columns) lines of the keypad to CSI_D3, CSI_D4, CSI_D5 CSI_D6 (resp. PORT_A pin 7, 8, 9, 10)
{add a big picture of the keypad link with APF_DEV_LIGHT}
{add a big picture of the keypad link with APF_DEV_FULL}
| [[Image:keypad.svg|thumb|3x4 matrix keypad connected to i.MXL GPIOs|150px]]
|}

====FPGA solution====
Under development...

===Software driver===

[[Driver for i.MX GPIO controlled keypads]]

===Links===

external links (for exemple: locomo driver model)

[[Category:UserInput]]

EFL

2009-08-05T09:27:42Z

SonZerro: Use "Under Construction" Template

{{Under Construction}}

==What is it ?==
http://en.wikipedia.org/wiki/Enlightenment_Foundation_Libraries

==Building the librairies==

===Get the packages===
The buildroot packages of the EFL can be downloaded there :

http://e-ghosting.com/~jujun/EFL-buildroot.tar.bz2

===Compile it===
Select the new options in the menuconfig
and then start make

==RootFS with EFL==

You will need a mmc card !
the rootfs will use 29M (it is not very optimised)

10M tarball :
http://www.e-ghosting.com/~jujun/armadeus/rootfs-EFL.arm.tar.bz2

put the rootfs on a mmc card in ext2 (or change it in the fstab)
and then in uboot :

run mmcboot

== Simple test ==

[[Image:080120_160232.jpg|thumb|Screen Shoot of the example]]<br>

A test using Evas and Ecore and Evas_Ecore

[[CodingWithEFL]]

The source of the above example :

<source lang=c>
#include <stdio.h>
#include <Ecore_Evas.h>
#include <Ecore.h>
#define WIDTH 320
#define HEIGHT 240

Ecore_Evas * ee;
Evas * evas;
Evas_Object * base_rect;
Evas_Object * base_rect_sec;
Evas_Object * img;

int main(){
evas_init();
ecore_init();
//ee = ecore_evas_software_x11_new(NULL, 0, 0, 0, WIDTH, HEIGHT); // When you test on your host computer
ee = ecore_evas_fb_new(NULL, 270, WIDTH, HEIGHT); //When you will run it on the board
ecore_evas_show(ee);
evas = ecore_evas_get(ee);

base_rect = evas_object_rectangle_add(evas);//This is the red rectangle
evas_object_resize(base_rect, WIDTH, HEIGHT-100);
evas_object_color_set(base_rect, 255, 0, 0, 25);
evas_object_show(base_rect);

base_rect_sec = evas_object_rectangle_add(evas);//This is the blue rectangle
evas_object_resize(base_rect_sec, WIDTH-200, HEIGHT);
evas_object_color_set(base_rect_sec, 0, 0, 255, 25);
evas_object_show(base_rect_sec);

img = evas_object_image_add(evas);//This is the png
evas_object_image_file_set(img, "e_logo.png", NULL);
evas_object_resize(img, 241, 195);
evas_object_image_fill_set(img, 0, 0, 241, 195);
evas_object_layer_set(img, -999);
evas_object_show(img);

ecore_main_loop_begin();
return 0;
}
</source>

As you can see, there is no "Violet" rectangle !

== To Do ==
- "stable" buildroot packages
- Use it with the touchscreen (tslib)
- Get events from keyboard
- Edje
- Emotion (hard!)
- More examples

[[Category:Software]]
[[Category:Graphical User Interface]]

Linux 2.6.24 integration

2009-08-05T09:27:02Z

SonZerro: Use "Under Construction" Template

{{Under Construction}}

<br>
<strong> This kernel was not well tested and is only here to test libertas WiFi drivers </strong>
<br>

==2.6.24.3==

*I2C:
** dans drivers/i2c/busses/i2c-imx.h, struct i2c_algorithm n'a plus de champ algo_control
** du coup dans drivers/i2c/busses/i2c-imx.c faut virer i2c_imx_ioctl() ??... pas sur car ça doit bien servir à qqchose

*USB Gadget:
** linux/usb_gadget.h est devenu linux/usb/gadget.h -> à changer dans drivers/usb/gadget/imx_udc.c

*USB Host:
** l'ISP166x est maintenant intégré dans Linux (non testé). Notre driver ne compile plus.

*RTC:
** la DS1374 est désormais intégrée au kernel (non testée, le driver semble bcp plus complet)

*WiFi:
** libertas_sdio ne compile pas sans les "wireless extensions"

===Patches inutiles:===
* 010-linux-2.6.24-imx1 (ne contient que des fichiers plateformes inutiles (Pengu) ) '''-> Supprimé'''
* 012-linux-2.6.24-apm9328 (hack pour utiliser l'APM avec la target scb9328) '''-> Supprimé'''
* 020-linux-2.6.24-scbfb (hack pour le utiliser le LCD à partir de l'APM en utilisant scb9328) '''-> Supprimé'''
* 021-...-apf9328.diff: virer apf9328_defconfig dedans car ça sert à rien avec buildroot, simplification de la partie Kconfig et Makefile (virer MX1FS2 SCB9328)
* 022-...-apf9328-mtd.diff: pareil que ci-dessus

==Drivers test summary==
{| border="1" cellpadding="5" cellspacing="0" summary="MMC+"
|- style="background:#efefef;"
! '''Device''' || colspan="2" | '''Compiling ? <br> Static / Module''' || ''' Working ? ''' || '''Comments'''
|----------------
|'''ADC''' || NA || style="background:#00ff00;" | OK || NT ||
|----------------
|'''Backlight''' || NT || NT || ||
|----------------
|'''CH7024 (Video Out)''' || NT || NA || NT ||
|----------------
|'''DAC''' || NT || NA || NT ||
|----------------
|'''Ethernet (DM9000)''' || NT || NA || NT ||
|----------------
|'''FPGA PS/2''' || NT || NT || NT ||
|----------------
|'''LCD''' || NT || NA || NT || message starting PID 235, tty
|----------------
|'''MMC/SD''' || NT || NA || NT || Linux boot on MMC Ok
|----------------
|'''PWM classic''' || NT || NT || NT || [[PWM]]
|----------------
|'''PWM sound''' || NA || NT || NT || [[PWM]]
|----------------
|'''RTC''' || NT || NT || NT ||
|----------------
|'''Serial''' || NT || NA || NT ||
|----------------
|'''TSC2102''' || NA || NT || NT || ts_test is not compiled :(
|----------------
|'''USB (gadget)''' || NT || NT || NT || [[USB_Gadget]]
|----------------
|'''USB (host)''' || NA || NT || NT ||
|----------------
|'''Watchdog''' || NA || NA || NA ||
|----------------
|}

Linux driver for FPGA controlled keyboards

2009-08-05T09:25:41Z

SonZerro: Use "Under Construction" Template

{{Under Construction}}

==Introduction==
This driver is intented to control FPGA IPs connected to numerous hardware keyboards like:
* [[PS/2]]
* Home made matrix keyboards
The driver is currently named '''apf9328ps2''' but this will be changed soon (or later ;-) ) to reflect its generic capability. Indeed all specific logic is done in the FPGA IP and the exported interface can be standardized.

==Installation==
Now installed by default for APF9328 rootfs (since armadeus-3.0). Not supported on APF27 yet.

==Usage==
<pre class="apf">
# modprobe apf9328ps2
input: AT Raw Set 2 keyboard as /class/input/input0
Armadeus PS/2: APF9328KBD AT adapter OK!
</pre>

* If you have a graphical LCD connected to your board (= virtual terminal), then you should see what you type.
* If you don't have any virtual terminal, but only the serial console, you can do a quick test with:
<pre class="apf">
# cat /dev/input/event0
</pre>
Then you should see weirds characters when pressing the keyboard keys:
<pre class="apf">
�,~~_�,}�}�3T,QToT6,TT�,�;��, � �
</pre>

==Keymap==
* To change keyboard keymap (by default qwerty one):
<pre class="apf">
# loadkmap < /etc/i18n/fr.kmap
</pre>

Mesa

2009-08-05T09:24:41Z

SonZerro: Use "Under Construction" Template

{{Under Construction}}
------
<br>
[[Image:Gears.png]]

==Installation==

armadeus$ make menuconfig
[[Image:Menuconfig_package.png]]

* Choose Mesa

Requires GPM too !!

* copy demo and examples .... on your rootfs

==Usage==
To launch Allegro programs you must do it from a virtual terminal, for example the one opened on the LCD screen after APF boot. <br>'''You won't be able to launch Allegro programs from the serial console !!'''<br>
This implies that you have a keyboard connected to your board (for the moment only PS/2 one are supported if you have an FPGA onboard).

==Links==
* [http://www.mesa3d.org/ Mesa Website]
* http://www.mesa3d.org/glfbdev-driver.html

<br>[[Image:FrenchFlag.png]][[Fr:Mesa| Cette page en français]]

[[Category:Software]]
[[Category:Graphical User Interface]]

Allegro

2009-08-05T09:23:58Z

SonZerro: Use "Under Construction" Template

{{Under Construction}}
------

==Installation==

armadeus$ make menuconfig
[[Image:Menuconfig_package.png]]

* Choose Allegro

For the moment it is only possible to have Allegro as a static library. (Doesn't compile as dynamic one).

* copy demo and examples in ''buildroot/build_armv4t/allegro/demo/'' and ''buildroot/build_armv4t/allegro/examples'' on your rootfs

==Usage==
To launch Allegro programs you must do it from a virtual terminal, for example the one opened on the LCD screen after APF boot. <br>'''You won't be able to launch Allegro programs from the serial console !!'''<br>
This implies that you have a keyboard connected to your board (for the moment only PS/2 one are supported if you have an FPGA onboard).

==Links==
* [http://alleg.sourceforge.net/index.html Allegro project page on SourceForge]

<br>[[Image:FrenchFlag.png]][[Fr:Allegro| Cette page en français]]

[[Category:Software]]
[[Category:Graphical User Interface]]

Trash Fr:Installation de ISE sur Ubuntu Linux

2009-08-05T09:23:13Z

SonZerro: Use "Under Construction" Template

{{Under_Construction}}

Depuis quelque temps déja, Xilinx [http://www.xilinx.com/ise/logic_design_prod/webpack.htm propose sa suite logicielle pour le développent et la synthèse FPGA ISE WebPack pour le système GNU/Linux].

Je vais essayer d'expliquer la marche a suivre pour faire tourner ISE WebPack 9.1i sur Ubuntu Edgy. Je pense que la procédure n'est pas exclusivement réservé à Ubuntu, et que les utilisateurs d'autres distributions devraient s'y retrouver.

* Aller sur [http://www.xilinx.com/ise/logic_design_prod/webpack.htm sur cette page]. Choisir ''Download ISE WebPACK software for Windows and Linux''
* Il vous sera demandé, si ce n'est pas déja fait, de vous inscrire sur le site de Xilinx pour obtenir un compte. On pourra alors télécharger les différents binaires et procéder à l'installation.

* Nous allons télécharger '''ISE WebPACK - WebInstall (16MB)'''. Le fichier téléchargé est une archive tar que nous pouvons décompresser. A la racine des fichiers décompressés, nous trouvons un script exécutable Linux: setup.

* Et là magie, nous nous retrouvons devant un installeur Qt "à la Windows", il vous suffit de suivre les indications à l'écran : le programme vous demande à quel endroit installer les outils, et télécharge automatiquement les différents composants. '''A noter cependant qu'il est nécessaire de lancer le programme en root pour pouvoir installer les drivers de cables JTAG''', ou si vous voulez installer ISE dans un repertoire comme /usr ou /opt. '''Sur Armadeus il n'est pas nécessaire d'avoir le JTAG'''

* Attention cependant l'installation/téléchargement est très long (plus d'une heure avec une connection chez moi) et vous pouvez compter sur 2Go pour l'installation/téléchargement.

Voila votre environnement est opérationnel, vous pouvez synthétiser pour le FPGA :)

[[Image:ISE_install_select.png]]
<br><br>
[[Image:ISE_install_dir.png]]
<br><br>
[[Image:ISE_install_options.png]]
<br><br>
[[Image:ISE_install_options2.png]]
<br><br>
[[Image:ISE_install_update.png]]

==Liens==
* [http://harded.free.fr/site/?p=31 un tutoriel en français de harded.fr (pour la version 7.1i)]
* http://www.xilinx.com/ise/logic_design_prod/webpack.htm

{{LanguageBar|ISE_WebPack_installation_on_Linux|Installation_de_ISE_sur_Ubuntu_Linux|ISE_WebPack_install_auf_Linux}}

Template:Under Construction

2009-08-05T09:21:32Z

SonZerro: typo

'''Page under construction... '''
[[Image:Construction.png]]
''' Informations on this page are not guaranteed !!'''

Current events

2009-08-05T09:18:03Z

SonZerro: /* Libre Software Meeting 2008 */ Typo

==General Assembly / Libre Software Meeting 2009==
* On Wednesday July 8th 2009 occurred the General Assembly in Nantes (France). Special Thanks to SylvainL for the room access.
* Attendees: FabienM, SylvainL, JulienV, JulienP, NicolasD (& his wife ;-)), JulienC, YoannC, GillesD, JeanFrancoisR, YvanR, NicolasC, EricJ, JulienB.

{|border=0 summary="Photos"
|----------------
| [[Image:GA2009-01.jpg|thumb|center|JulienB ]]
|| [[Image:GA2009-02.jpg|thumb|center|L2R: SylvainL, NicolasC, FabienM, NicolasD & his wife, 4 "intruders" of Free-Electron/Calao, JulienP, 3 other "intruders" ]]
|| [[Image:GA2009-03.jpg|thumb|center|L2R: JulienC, YoannC, YvanR, JeanFrancoisR ]]
|| [[Image:GA2009-04.jpg|thumb|center|L2R: JulienP (very serious), NicolasD]]
|----------------
| [[Image:GA2009-05.jpg|thumb|center|L2R: FabienM, SylvainL, JulienV, JulienP ]]
|| [[Image:GA2009-07.jpg|thumb|center|JulienC]]
|| [[Image:GA2009-08.jpg|thumb|center|L2R: GillesD, JeanFrancoisR ]]
|| [[Image:GA2009-09.jpg|thumb|center|L2R: JulienC, YvanR, NicolasC, YoannC ]]
|----------------
| [[Image:GA2009-11.jpg|thumb|center|L2R: 2 intruders (;-)) + JulienC & GillesD]]
|| [[Image:GA2009-12.jpg|thumb|center|L2R:YoannC, GillesD, JeanFrancoisR ]]
|| [[Image:GA2009-15.jpg|thumb|center| L2R:JulienB, YvanR (explaining its project)]]
|| [[Image:GA2009-17.jpg|thumb|center|L2R:JulienB, YvanR (explaining its project) ]]
|----------------
| [[Image:GA2009-21.jpg|thumb|center|L2R:JulienB, YvanR: 2008 contest price award ]]
|| [[Image:GA2009-22.jpg|thumb|center|L2R:JulienB, YvanR: 2008 contest price award ]]
|| [[Image:GA2009-23.jpg|thumb|center|L2R:JulienB, FabienM, NicolasC: at the hotel ]]
|----------------
|}

==Libre Software Meeting 2008==
* On 1st to 3rd July 2008 we attended the [http://2008.rmll.info/ RMLL at Mont de Marsan]:
** [http://free-electrons.com/pub/video/2008/rmll/rmll2008-julien-boibessot-nicolas-colombain-fabien-marteau-armadeus.ogg Video of Embedded systems conference]
** [http://2008.rmll.info/IMG/pdf/armadeus.pdf Slides of the Armadeus presentation]

==General Assembly 2008==
* On Saturday Mar. 9th 2008 occurred the General Assembly in Mulhouse (France).

{|border=0 summary="Photos"
|----------------
|[[Image:AG2008_01.jpg|thumb|center|L2R: Nicolas, Frédéric and Fabien]] || [[Image:AG2008_02.jpg|thumb|center|Nicolas and Frédéric]] || [[Image:AG2008_03.jpg|thumb|center|Julien, Michael and Fabrice]]
|----------------
|[[Image:AG2008_04.jpg|thumb|center|L2R: Nicolas and Frédéric ]] || [[Image:AG2008_05.jpg|thumb|center| L2R: Fabrice and Eric]] || [[Image:AG2008_06.jpg|thumb|center| everyone ;-)]] ||
|----------------
|}

==General Assembly 2007==
* On Saturday Feb. 17th 2007 occured the annual meeting in Mulhouse (France).

{|border=0 summary="Photos"
|----------------
|[[Image:ArmadeusAM07-1.JPG|thumb|center| L2R: Paola, Nicolas, Julien, Sébastien, Michael]] || [[Image:ArmadeusAM07-2.JPG|thumb|center|Paola, Michael]] || [[Image:ArmadeusAM07-3.JPG|thumb|center|Michael, Eric, Fabrice, Frédéric, Julien]]
|----------------
|[[Image:ArmadeusAM07-4.JPG|thumb|center|L2R: Eric, Fabrice, Frédéric,Nicolas, Julien, Michael]] || [[Image:ArmadeusAM07-5.JPG|thumb|center|again ;-)]] ||
|----------------
|}

{{LanguageBar|Current_events|Événements|Ereignisse}}

APF27 FPGA-IMX interface description

2009-08-05T08:45:23Z

SonZerro: Brushed up

This article describe the interface between IMX and Spartan3A on APF27.
Documentation of i.MX interface can be found in the iMX reference manual, chapter 17,
«Wireless External Interface Module ('''WEIM''')».

== Hardware ==

The detailled electronic schematics of apf27 fpga interface can be found on
[http://www.armadeus.com/_downloads/apf27/hardware/apf27_V1.2.pdf this document] page 11. A simplified schema is shown below on figure 1.

[[image:fpgaimx_wire.png|center|500px|thumb|'''figure 1''' - ''FPGA-i.MXL wiring'']]

The signals used in the design are:

* '''CLKO''': Clock generated by i.MX. Used as general clock by the FPGA.
* '''DATA[16]''': 16 bits data bus.
* '''ADDR[13]''': 12 bits address bus, least significant bit (ADDR[0]) is not used because only word access are done.
* '''CS4N_DTACK''': '''C'''hip '''S'''elect 4 or '''D'''ata '''T'''ransmit '''ACK'''nowledge.
* '''CS5''','''CS1''': '''C'''hip '''S'''elect 5 and 1.
* '''EB0N''' and '''EB1N''': For '''E'''nable '''B'''yte, write signal for lower byte and upper byte on data bus.
* '''OEN''': For '''O'''utput '''E'''nable bit, read signal.
* '''DMA_GRANT#''' and '''DMA_REQ#''': Signals to use DMA on i.MX.

Each chip select has its own configuration (timing, address range, ...) that can be used for different slaves in the FPGA.

'''CLKO''' is by default configured to run at 133MHz to be synchronous with the '''WEIM''' bus that is internally clocked at 133MHz, too.

== Chip Select Timings configuration ==

===Present configuration (static timing)===
The default configuration uses '''CS5''' for accessing the FPGA. 32 bits register CS5
is used to configure all timing for this chip select. It's default
configuration is:
* CS5U (Upper 16bits, see page 521 of reference manual ): mw D8002050 00000600
This will add 6 waits state on access to read value correctly (WSC: Wait
State Control).
* CS5L (Lower 16bits,see page 525 of reference manual): mw D8002054 00000D01
Enable chip select (CSEN), Enable for only write access EB[] (EBC) and select data port size to
16bits (DSZ: Data port SiZe).
* CS5A (additionnal register, page 528): mw D8002058 0

* WCR (WEIM Configuration Register): mw D8002060 00002000
Address unshifted for CS5 (AUS5)

[[image:timingstatic.png|center|500px|thumb|'''figure 2''' - ''Static timings chronograms'']]

With this configuration, the access time (read/write) to the FPGA is set to 50ns.

This configuration is interesting because all timings are under control. But
the problem is that to be perfectly synchronous, the FPGA is clocked at 133MHz
like WEIM and some IP design doesn't work at this frequency.

===Alternative configuration (with DTACK)===

To solve the problem, another solution can be the DTACK signal (asynchronous protocol). The DTACK signal
is emmited by the slave to master when write/read is done.
With this solution, access time is variable and the timing is not static any more.

===Timing register configuration===

All register configurations for external memory are done in u-boot.
Configuration file can be found in
''buildroot/project_build_armv5te/<project_name>/u-boot-1.3.4/include/configs/apf27.h''
And is saved in armadeus tree at
''buildroot/target/device/armadeus/apf27/apf27.h

Setup

2009-08-05T07:55:33Z

SonZerro: /* Going further with your board */ typo

On this page, you will find all the useful information you need to configure your Armadeus board for optimum usage.

==First StartUp==
Just got your Armadeus board and want to start playing with it ? Follow these quick steps to setup your environment accordingly:
# Connect your APF to your development board (custom or [[APF9328DevLight|DevLight]]/[[APF9328DevFull|DevFull]]) (your system will be hereafter referred to as "the Target") --->> [[Image:Apf_on_devlight.png|40px]]
# Connect your PC (= "the Host") to your board with a [http://en.wikipedia.org/wiki/Null_modem null-modem RS232 cable] (only Rx/Tx/Gnd signals are needed). If you don't have a RS232 port on your Host, you can use a "USB <-> serial" converter (you'll still require the null-modem cable).
# [[Communicate | Install (minimum) tools to communicate with your APF from your Host.]]
# [[Development_boards_power_supply | Connect the power supply on your development board.]]
# Verify your system is booting by starting Linux: In U-Boot console, type "boot". Several informations will be displayed on your terminal like on this [[Linux start screenshot | screenshot ]] (Default Linux login is "root" with an empty password). '''IF NOT''', walk through [[U-Boot communication quick check|this small checklist]].
# If Linux has successfully started, your system is operational. If you want to add applications to your board or developp custom ones, then you can proceed with the Toolchain installation. [[Setup#Basics | See Basics below]].

===Tutorial===
If you want a more "userfriendly" procedure, you can try this (under construction) tutorial: [[Beginner's_tutorial]]

==Basics for customizing your board==
# [[Toolchain| Install the development environment (=Toolchain) for your board and generate your Linux/rootfs images]]
# [[Target Software Installation| Install/flash your U-Boot, Linux and rootfs freshly generated images on your board]]
# [[Armadeus_3#How-to_develop_with_Armadeus_.2F_customize_your_SDK| Customize your Armadeus SDK]]

==Going further with your board==
* [[Armadeus 3]]: How to use the third generation of Armadeus SDK at a glance (notably for 2.x users). Newcomers can particularly find the chapter [[Armadeus_3#How-to_develop_with_Armadeus_.2F_customize_your_SDK| How-to customize your Armadeus SDK]] interesting.
* [[Network File System configuration| How to configure NFS on Host and Target]]
* [[MultiMediaCard | How to use MMC/SD/microSD cards from Linux on your Armadeus board]]
* [[ALSA|How to play sound with your board]]
* [[Mplayer|How to play videos on your board]]

* [[FrameBuffer]]: How to configure and use the framebuffer for new LCDs
* [[BackLight| How to control the backlight of you graphical LCD (if it supports it)]]
* [[GPIO Driver]]: How to configure the GPIO driver
* [[Boa]]: How install and configure the boa Web server on your board
* [[USB Gadget]]: How to configure your Armadeus board to use it as a USB device (aka Gadget in Linux language)
* [[DAC|Digital to Analog Convertion]]: How to configure and use the DAC on your board
* [[ADC max1027|Analog to Digital Converter]]: How to install and use the on board ADC (max1027)
* [[PWM]]: How to use the i.MX integrated PWM
* [[RTC]]: How to use an external Real Time Clock (Maxim DS1374)
* [[Watchdog]]: How to configure and use the i.MX integrated Watchdog
* [[TV Output]]: How to use the SVideo output of the APF9328DevFull
* [[USB Host]]: How to use USB Host controllers of the APF9328DevFull and APF27
* [[TSC2102 Linux driver| Touchscreen ]]: How to configure and use the touchscreen controller
* [[CAN bus Linux driver]]: How to configure and use the CAN controller of the DevFull
* [[DVI / HDMI]]: How to configure and use the DVI/HDMI controller of the apf27DevFull
* [http://txlab.wordpress.com/2009/03/20/mounting-the-lcd-touchscreen-on-top-of-armadeus-devboard Low cost assembly of LCD & apf27 development board ]: How to mount the LCD touchscreen on top of Armadeus devboard (Thx to Stanislav)

==Advanced==
* [[Ethernet_MAC_address|How to change your board Ethernet MAC address]] (Thanks to Julien Catalano)
* [[BootLoader]]: (U-Boot useful tips)
* [[BootStrap]]: Install U-Boot from scratch or recover your U-Boot if it was corrupted
* [[ JTAG | Support JTAGKey and BDI2000 JTAG probes]]
* [[Serial Transfer| How to transfer files between your Host and your Armadeus board's Linux with the RS232 link]] (if you don't have Ethernet/NFS/TFTP/MMC/USB)

{{LanguageBar|Setup|Configuration|Konfiguration}}

MultiMediaCard

2009-08-05T07:50:26Z

SonZerro: typos

Instructions to use the MultiMediaCard (MMC/SD) on your Armadeus board

==Introduction==

You can use standard MMC/SD/miniSD/microSD cards with your Armadeus board:
* with a DevLight V1, you must have [[MMC/SD | the corresponding connector attached to your development board.]] and use an adaptor for miniSD and microSD
* with a DevLight V2, you can use the onboard microSD connector
* with an [[APF9328DevFull]], you can use the MMC/SD onboard connector and an adaptor for miniSD and microSD
* with an [[APF27Dev]], you can use the onboard microSD connector

All needed drivers are included in the standard Armadeus Linux image.

==Card insertion==
You should see something like that on the Linux console:
<pre class="apf">
# imx-mmc imx-mmc.0: card inserted
mmc0: host does not support reading read-only switch. assuming write-enable.
mmc0: new SD card at address 01b0
mmcblk0: mmc0:01b0 SD512 500224KiB
mmcblk0: p1
</pre>

Note :
If the special files /dev/mmcblk0, /dev/mmcblk0p1 /dev/mmcblk0p2 ... /dev/mmcblk0p7 are NOT present on your filesystem,
create them by hand :
<pre class="apf">
# mknod /dev/mmcblk0 b 179 0
# mknod /dev/mmcblk0p1 b 179 1
# mknod /dev/mmcblk0p2 b 179 2
...
# mknod /dev/mmcblk0p7 b 179 7
</pre>
(It happened to me after upgrading an APF9328+DevLight from version 2.3 to 3.1)

==Mounting the MMC/SD==

* Just mount the MMC like you will do on your PC, for example (FAT32 formatted card):
<pre class="apf">
# mount -t vfat /dev/mmcblk0p1 /mnt/mmc
</pre>
* Then, you can access the MMC's files from the ''/mnt/mmc'' directory

If you have problems with vfat code page, [[MultiMediaCard#VFAT_Code_Page|include the missing code page into the kernel]].

==Booting from MMC/SD==
When your rootfs is too big to be put on the APF Flash, you can always use a MMC/SD like a Hard Drive and boot from it (this is possible because standard Armadeus kernel is compiled with the MMC driver built in).

===Prepare your card===
* On your APF board (to avoid to crash your Host HD), create a good partition table:
<pre class="apf">
# /sbin/fdisk /dev/mmcblk0
Delete all existing partion with 'd'
Create a primary partion: 'n' then 'p' then '1'
Change bootflag to Linux: 't' then '83'
Save partition table: 'w'
(To quit without saving: 'm')
</pre>
* Then, on your PC, format your MMC with Ext2 filesystem (booting on FAT is bad :-) ):
<pre class="host">
$ sudo mkfs.ext2 /dev/sdX1 (replace X with your MMC reader drive letter, if your Laptop has an integrated
MMC reader then use mmcblk0p1 instead of sdX1)
</pre>
* If not automatically detected/mounted by your distribution, mount your MMC/SD on your Host filesystem (for example in ''/media/mmc''):
<pre class="host">
$ sudo mkdir -p /media/mmc
$ sudo mount /dev/sdX1 /media/mmc (replace X with your MMC reader drive letter, if your Laptop has an integrated
MMC reader then use mmcblk0p1 instead of sdX1)
</pre>

===Put your rootfs on the MMC/SD===
* Buildroot should be configured to generate a tar-ed rootfs '''(now done by default)'''.
[armadeus] $ make menuconfig
<pre class="config">
Target filesystem options --->
</pre>
[[Image:Menuconfig_tar_rootfs.png]]
<pre class="host">
[armadeus] $ make
</pre>
* and then uncompress the rootfs to the SD card:
<pre class="host">
$ make shell_env
$ source armadeus_env.sh
$ sudo tar xvf $ARMADEUS_ROOTFS_TAR -C /media/mmc
$ sudo umount /media/mmc
</pre>

===Boot===
* Insert the MMC/SD/microSD in the corresponding slot of your Armadeus board and then under U-Boot do:
<pre class="apf">
BIOS> run mmcboot
</pre>
* if you want to automatically boot from SD at each startup, modify the ''bootcmd'' U-Boot macro:
<pre class="apf">
BIOS> setenv bootcmd run mmcboot
BIOS> saveenv
</pre>
(default bootcmd when you receive your board is ''run jffsboot'' = boot from FLASH)

==Performances==
* [[MMC/SD#Supported_Cards| Show tested cards performances]]

==Troubleshots==
===VFAT Code Page===
If you encounter this message (or something similar):
Unable to load NLS charset cp437
FAT: codepage cp437 not found
you have to add the charset to the supported kernel ones:
$ make linux26-menuconfig
<pre class="config">
File systems --->
-*- Native language support --->
<*> Codepage 437 (United States, Canada)
...
<*> NLS ISO 8859-1 (Latin 1; Western European Languages)
...
</pre>

==Links==

* http://en.wikipedia.org/wiki/MultiMedia_Card

{{LanguageBar|MultiMediaCard|MultiMediaCard|MultiMediaCard}}

[[Category:MassStorage]]

Orchestra

2008-03-26T06:42:58Z

SonZerro: berlios

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.

<center>[[Image:orchestra.png|Description fonctionnelle du système]]</center>

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

Voici un extrait de fichier XML pour un composant à titre d'illustration
<pre>
<?xml version="1.0" encoding="utf-8"?>
<component name="irq_mngr" version="1.0" category="base">

<description>
<![CDATA[
The Interruption Manager is a Wishbone slave component and Armadeus compiliant.
]]>
</description>
...
</component>
</pre>

== La bibliothèque de composants ==

Un composant '''Armadeus Ready''' se compose des éléments suivants:
* un ensemble de fichiers HDL (VHDL ou Verilog)
* un ensemble de fichiers C et H (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 noeud 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.
<pre>
<component name="irq_mngr" version="1.0" category="base">
...
</component>
</pre>

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.
<pre>
<description>
<![CDATA[
The Interruption Manager is a Wishbone slave component and Armadeus compiliant.
]]>
</description>
</pre>
* 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:
** '''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.
<pre>
<hdl_files>
<hdl_file name="irq_mgnr.vhd" scope="all" istop="1" />
</hdl_files>
</pre>
* 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
** '''type''': C'est le type de paramètre, dans un premier temps, uniquement les types suivants sont supportés:
*** '''integer''': pour définir un nombre entier
*** '''std_logic''': pour définir un signal
*** '''std_logic_vector''': pour définir un vecteur
** '''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''': Cet attribut va permettre de définir la valeur par défaut du paramètre
<pre>
<generic_map>
<generic name="irq_count" type="integer" value="16" valid="1..16">
<![CDATA[
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>
</pre>

== 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

*<strong>Project creation</strong>
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.

*<strong>Adding/removing IPs</strong>
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.<br/>
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

*<strong>Project informations</strong>
<u><i>List of Ips</i></u><br/>
The Ips present in the project can be listed as follow:
projectBuilder -listIps

<u><i>IP information</i></u><br/>
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

<u><i>Platform information</i></u><br/>
Platform informations can be displayed as follow:
projectBuilder -viewPlatformInfos

<u><i>Toolchain</i></u><br/>
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.

*<strong>IP set functions</strong>
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

*<strong>Project Build</strong>
Once the IPs added to your project, it can be build with the following command:
projectBuilder -buildProject
<u>Results</u>: several files are created:<br/>
test.scr : script file for the Xilinx XST compiler<br/>
test.prj: project file for the Xilinx XST compiler<br/>
test.log log file

FPGA

2008-03-14T21:11:04Z

SonZerro: /* Synthesis */ new page

==FPGA on APF9328==
The APF9328 is optionally equipped with an Xilinx Spartan-3 FPGA (Field Programmable Gate Array). An FPGA is a configurable digital device. Today, large and complex digital circuits and processor cores fit into FPGAs. To find more information about FPGAs, check the Wikipedia: [http://en.wikipedia.org/wiki/FPGA]

The FPGA on APF9328 is connected to the processor bus of the iMX and to the connector of the APF9328. This makes it possible to design your own peripherals and configure them into the FPGA. Because the FPGA can be reconfigured at any time, it allows you to replace these peripherals (or a part of them), if other functionalities are needed. This is possible even at run-time!

==FPGA Firmware Development==
===Digital Hardware Design===
FPGAs are quite complex digital devices. Modern tools allow to describe the circuits to be implemented an abstract way, which makes it possible to manage the complexity. The trend for new tools is toward higher levels of abstraction in order to be able to manage even more complex devices in future. Nevertheless, at least basic knowledge of digital circuits and gates is necessary to start designing firmware for FPGAs.

===FPGA Design-Flow===
The starting point for the implementation flow is a description of the functionality in a Hardware Description Language (HDL). One of the most commonly used HDLs is ''VHDL'' (Very High Speed Integrated Circuit Hardware Description Language). VHDL files are plain text files and editing can be done in any editor.

This VHDL circuit description can be simulated to verify the functionality.

If everything is working fine, a tool called ''synthesizer'' is used to translate this HDL description in a hardware netlist. Then this netlist is ''mapped'' onto the FPGA technology. After ''Place and Route'' and ''Bitstream generation'', a configuration file for the FPGA is created (''bitfile'').

For more informations about VHDL and the design flow, see [http://en.wikipedia.org/wiki/VHSIC_Hardware_Description_Language]. This page also contains many examples that show how to describe simple electronic circuits in VHDL.

==Armadeus Firmware Development Environment==
===Development Software===
====Synthesis====
For FPGA development, you need the ''Xilinx ISE WebPack'' from Xilinx. It can be downloaded for free (after registration) from the Xilinx homepage
[http://www.xilinx.com/ise/logic_design_prod/webpack.htm]. The WebPack contains all you need to implement a design for the FPGA on the APF9328: Editor, Synthesizer, Mapper, Place and Route Tool, Bitstream generator, and the tools to download a configuration to the FPGA.
ISE WebPack is available for Windows and Linux. See the [[How_to_make_a_VHDL_design_in_Ubuntu/Debian| ISE WebPack installation on Linux]] page for more infos.

====Simulation====
For simulation, Xilinx offers a free version of ''ModelSim'', called ''ModelSim Xilinx Edition (MXE)''. It can also be downloaded from the Xilinx homepage [http://www.xilinx.com/ise/optional_prod/mxe.htm] for free, but registration is required in order to receive a license. MXE is available for Windows only.
The alternative for Linux users is GHDL. More information can be found on the [http://www.armadeus.com/wiki/index.php?title=How_to_make_a_VHDL_design_in_Ubuntu/Debian#Simulation VHDL for Linux] page.

====VHDL code editor====
The editor in ISE is not very useful and inconvenient. In principle, any alternative editor can be used with ISE, but some have special support for VHDL-Code as syntax highlighting, template insertion, indenting and many other cool features that help to write nice and error-free code in less time. The [http://www.iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.html VHDL Mode] for the well known [http://www.gnu.org/software/emacs/ GNU Emacs] editor can be recommended in particular. Emacs is available for all important operating systems.

===Design Implementation===
Implement your design with the ''ISE WebPack'' software. If you are new to VHDL, the information on [http://en.wikipedia.org/wiki/VHSIC_Hardware_Description_Language] can give you a first idea. Tutorials for the ISE software can be downloaded from the Xilinx homepage [http://www.xilinx.com/support/techsup/tutorials].

===Bitstream generation===
When your design is ready and passes the simulation, you can create a ''bitstream file'' that can be downloaded to the FPGA. It contains all the data to configure the FPGA.

In the ISE Project Manager, make sure that a ''Binary Configuration File'' is also created. You can set this option in the properties dialog of the ''Generate Programming file'' process. Activate the option ''Create Binary Configuration File''.

The file with the ending ''.bin'' is now the file you need to configure the FPGA on the Armadeus module.

==Licence==
The firmware for the FPGA has to be licenced under LGPL and BSD.

Please add to each created file a header containing the name of the "company" here it is an association, the maintainer name, the licence.

If a part of a work of an other developper has been reused, please indicate where this part has been found, the author name and keep the original licence. If no licence is specified, assume it is unlicenced.

==FPGA configuration from the iMX board==
===Configuring the FPGA from U-Boot===
See the [[InstallTargetSoftware#FPGA_firmware_installation|InstallTargetSoftware]] page of this wiki.

===Configuring the FPGA from Linux===
See the FPGA loader page [[FPGA loader]] of this wiki for details.

==FPGA timing diagrams==
The following timings diagrams have been taken with an Armadeus release 2.1<br>
<br>

{|border=0 summary="Timings"
|----------------
| [[Image:FPGA_read.png | thumb | center | READ]] ||
| [[Image:FPGA_write_8bits.png | thumb | center | WRITE 8bits]] ||
| [[Image:FPGA_write_8bits.png | thumb | center | WRITE 16bits]] ||
|----------------
|}

==Links==
* http://www.comelec.enst.fr/hdl
* http://www.fpga4fun.com/

[[Image:FrenchFlag.png]] [[Fr:FPGA|Cette page en français]]

Using FPGA

2008-03-14T21:10:09Z

SonZerro: /* Tools */

==Developing on the APF FPGA==
{| border="0" cellpadding="5" cellspacing="5" summary="Hardware Add-Ons by functionnalities"
|----------------
|- style="background:#f4f4f4; color:black; -moz-border-radius:18px;"
|
===Tools===
* [[FPGA | FPGA on APF introduction]]
* [[ISE WebPack installation on Linux]]
* [[How_to_make_a_VHDL_design_in_Ubuntu/Debian| How to setup the FPGA toolchain in Ubuntu/Debian]]
* [[FPGA_loader| Configure FPGA from armadeus-Linux card]]
||

===Xilinx documentation links===
* [http://www.xilinx.com/support/documentation/data_sheets/ds099.pdf Spartan-3 FPGA Family Data Sheet]
|----------------
|- style="background:#f4f4f4; color:black; -moz-border-radius:18px;"
|

===Designs===
* [[FPGA and led]]
* [[A simple design with Wishbone bus]]
* [[Une led qui clignote avec le spartan 3]]

||

===Link VHDL===
* [http://www.chez.com/amouf/syntaxe.htm Syntaxe VHDL (French)]
* [http://www.gmvhdl.com/VHDL.html An Introductory VHDL Tutorial]
* [http://www.xess.com/ho03000.html Nice ideas/examples to look at]
|----------------
|- style="background:#f4f4f4; color:black; -moz-border-radius:18px;"
|

===Orchestra===
* [[FpgaArchitecture | Spécification de l'architecture du FPGA (french)]]
* [[Orchestra | Spécification de l'outil de conception automatique du FPGA (french)]]
* [[FPGA | FPGA project generation with Orchestra]]
* [[OrchestraPython | Elaboration du projet Orchestra en Python (french)]]
||

===Link Orchestra===
* [http://www.opencores.org/projects.cgi/web/wishbone/wbspec_b3.pdf official Wishbone specifications]
* [http://en.wikipedia.org/wiki/Wishbone_%28computer_bus%29 Wikipedia Wishbone doc]
|----------------
|}

FPGA

2008-03-14T20:48:53Z

SonZerro: More structure added

==FPGA on APF9328==
The APF9328 is optionally equipped with an Xilinx Spartan-3 FPGA (Field Programmable Gate Array). An FPGA is a configurable digital device. Today, large and complex digital circuits and processor cores fit into FPGAs. To find more information about FPGAs, check the Wikipedia: [http://en.wikipedia.org/wiki/FPGA]

The FPGA on APF9328 is connected to the processor bus of the iMX and to the connector of the APF9328. This makes it possible to design your own peripherals and configure them into the FPGA. Because the FPGA can be reconfigured at any time, it allows you to replace these peripherals (or a part of them), if other functionalities are needed. This is possible even at run-time!

==FPGA Firmware Development==
===Digital Hardware Design===
FPGAs are quite complex digital devices. Modern tools allow to describe the circuits to be implemented an abstract way, which makes it possible to manage the complexity. The trend for new tools is toward higher levels of abstraction in order to be able to manage even more complex devices in future. Nevertheless, at least basic knowledge of digital circuits and gates is necessary to start designing firmware for FPGAs.

===FPGA Design-Flow===
The starting point for the implementation flow is a description of the functionality in a Hardware Description Language (HDL). One of the most commonly used HDLs is ''VHDL'' (Very High Speed Integrated Circuit Hardware Description Language). VHDL files are plain text files and editing can be done in any editor.

This VHDL circuit description can be simulated to verify the functionality.

If everything is working fine, a tool called ''synthesizer'' is used to translate this HDL description in a hardware netlist. Then this netlist is ''mapped'' onto the FPGA technology. After ''Place and Route'' and ''Bitstream generation'', a configuration file for the FPGA is created (''bitfile'').

For more informations about VHDL and the design flow, see [http://en.wikipedia.org/wiki/VHSIC_Hardware_Description_Language]. This page also contains many examples that show how to describe simple electronic circuits in VHDL.

==Armadeus Firmware Development Environment==
===Development Software===
====Synthesis====
For FPGA development, you need the ''Xilinx ISE WebPack'' from Xilinx. It can be downloaded for free (after registration) from the Xilinx homepage
[http://www.xilinx.com/ise/logic_design_prod/webpack.htm]. The WebPack contains all you need to implement a design for the FPGA on the APF9328: Editor, Synthesizer, Mapper, Place and Route Tool, Bitstream generator, and the tools to download a configuration to the FPGA.
ISE WebPack is available for Windows and Linux. See the [[ISE WebPack installation on Linux]] page for more infos.

====Simulation====
For simulation, Xilinx offers a free version of ''ModelSim'', called ''ModelSim Xilinx Edition (MXE)''. It can also be downloaded from the Xilinx homepage [http://www.xilinx.com/ise/optional_prod/mxe.htm] for free, but registration is required in order to receive a license. MXE is available for Windows only.
The alternative for Linux users is GHDL. More information can be found on the [http://www.armadeus.com/wiki/index.php?title=How_to_make_a_VHDL_design_in_Ubuntu/Debian#Simulation VHDL for Linux] page.

====VHDL code editor====
The editor in ISE is not very useful and inconvenient. In principle, any alternative editor can be used with ISE, but some have special support for VHDL-Code as syntax highlighting, template insertion, indenting and many other cool features that help to write nice and error-free code in less time. The [http://www.iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.html VHDL Mode] for the well known [http://www.gnu.org/software/emacs/ GNU Emacs] editor can be recommended in particular. Emacs is available for all important operating systems.

===Design Implementation===
Implement your design with the ''ISE WebPack'' software. If you are new to VHDL, the information on [http://en.wikipedia.org/wiki/VHSIC_Hardware_Description_Language] can give you a first idea. Tutorials for the ISE software can be downloaded from the Xilinx homepage [http://www.xilinx.com/support/techsup/tutorials].

===Bitstream generation===
When your design is ready and passes the simulation, you can create a ''bitstream file'' that can be downloaded to the FPGA. It contains all the data to configure the FPGA.

In the ISE Project Manager, make sure that a ''Binary Configuration File'' is also created. You can set this option in the properties dialog of the ''Generate Programming file'' process. Activate the option ''Create Binary Configuration File''.

The file with the ending ''.bin'' is now the file you need to configure the FPGA on the Armadeus module.

==Licence==
The firmware for the FPGA has to be licenced under LGPL and BSD.

Please add to each created file a header containing the name of the "company" here it is an association, the maintainer name, the licence.

If a part of a work of an other developper has been reused, please indicate where this part has been found, the author name and keep the original licence. If no licence is specified, assume it is unlicenced.

==FPGA configuration from the iMX board==
===Configuring the FPGA from U-Boot===
See the [[InstallTargetSoftware#FPGA_firmware_installation|InstallTargetSoftware]] page of this wiki.

===Configuring the FPGA from Linux===
See the FPGA loader page [[FPGA loader]] of this wiki for details.

==FPGA timing diagrams==
The following timings diagrams have been taken with an Armadeus release 2.1<br>
<br>

{|border=0 summary="Timings"
|----------------
| [[Image:FPGA_read.png | thumb | center | READ]] ||
| [[Image:FPGA_write_8bits.png | thumb | center | WRITE 8bits]] ||
| [[Image:FPGA_write_8bits.png | thumb | center | WRITE 16bits]] ||
|----------------
|}

==Links==
* http://www.comelec.enst.fr/hdl
* http://www.fpga4fun.com/

[[Image:FrenchFlag.png]] [[Fr:FPGA|Cette page en français]]

Using FPGA

2008-03-14T20:44:38Z

SonZerro: /* Tools */ Toolchain or Design ?!

==Developing on the APF FPGA==
{| border="0" cellpadding="5" cellspacing="5" summary="Hardware Add-Ons by functionnalities"
|----------------
|- style="background:#f4f4f4; color:black; -moz-border-radius:18px;"
|
===Tools===
* [[FPGA | FPGA on APF introduction]]
* [[ISE WebPack installation on Linux]]
* [[How to setup the FPGA toolchain in Ubuntu/Debian]]
* [[FPGA_loader| Configure FPGA from armadeus-Linux card]]
||

===Xilinx documentation links===
* [http://www.xilinx.com/support/documentation/data_sheets/ds099.pdf Spartan-3 FPGA Family Data Sheet]
|----------------
|- style="background:#f4f4f4; color:black; -moz-border-radius:18px;"
|

===Designs===
* [[FPGA and led]]
* [[A simple design with Wishbone bus]]
* [[Une led qui clignote avec le spartan 3]]

||

===Link VHDL===
* [http://www.chez.com/amouf/syntaxe.htm Syntaxe VHDL (French)]
* [http://www.gmvhdl.com/VHDL.html An Introductory VHDL Tutorial]
* [http://www.xess.com/ho03000.html Nice ideas/examples to look at]
|----------------
|- style="background:#f4f4f4; color:black; -moz-border-radius:18px;"
|

===Orchestra===
* [[FpgaArchitecture | Spécification de l'architecture du FPGA (french)]]
* [[Orchestra | Spécification de l'outil de conception automatique du FPGA (french)]]
* [[FPGA | FPGA project generation with Orchestra]]
* [[OrchestraPython | Elaboration du projet Orchestra en Python (french)]]
||

===Link Orchestra===
* [http://www.opencores.org/projects.cgi/web/wishbone/wbspec_b3.pdf official Wishbone specifications]
* [http://en.wikipedia.org/wiki/Wishbone_%28computer_bus%29 Wikipedia Wishbone doc]
|----------------
|}

FPGA

2008-03-14T20:40:52Z

SonZerro: /* Simulation */ GHDL hint

==FPGA on APF9328==
The APF9328 is optionally equipped with an Xilinx Spartan-3 FPGA (Field Programmable Gate Array). An FPGA is a configurable digital device. Today, large and complex digital circuits and processor cores fit into FPGAs. To find more information about FPGAs, check the Wikipedia: [http://en.wikipedia.org/wiki/FPGA]

The FPGA on APF9328 is connected to the processor bus of the iMX and to the connector of the APF9328. This makes it possible to design your own peripherals and configure them into the FPGA. Because the FPGA can be reconfigured at any time, it allows you to replace these peripherals (or a part of them), if other functionalities are needed. This is possible even at run-time!

==FPGA Firmware Development==
===Digital Hardware Design===
FPGAs are quite complex digital devices. Modern tools allow to describe the circuits to be implemented an abstract way, which makes it possible to manage the complexity. The trend for new tools is toward higher levels of abstraction in order to be able to manage even more complex devices in future. Nevertheless, at least basic knowledge of digital circuits and gates is necessary to start designing firmware for FPGAs.

===FPGA Design-Flow===
The starting point for the implementation flow is a description of the functionality in a Hardware Description Language (HDL). One of the most commonly used HDLs is ''VHDL'' (Very High Speed Integrated Circuit Hardware Description Language). VHDL files are plain text files and editing can be done in any editor.

This VHDL circuit description can be simulated to verify the functionality.

If everything is working fine, a tool called ''synthesizer'' is used to translate this HDL description in a hardware netlist. Then this netlist is ''mapped'' onto the FPGA technology. After ''Place and Route'' and ''Bitstream generation'', a configuration file for the FPGA is created (''bitfile'').

For more informations about VHDL and the design flow, see [http://en.wikipedia.org/wiki/VHSIC_Hardware_Description_Language]. This page also contains many examples that show how to describe simple electronic circuits in VHDL.

==Armadeus Firmware Development Environment==
===Development Software===
====Synthesis====
For FPGA development, you need the ''Xilinx ISE WebPack'' from Xilinx. It can be downloaded for free (after registration) from the Xilinx homepage
[http://www.xilinx.com/ise/logic_design_prod/webpack.htm]. The WebPack contains all you need to implement a design for the FPGA on the APF9328: Editor, Synthesizer, Mapper, Place and Route Tool, Bitstream generator, and the tools to download a configuration to the FPGA.
ISE WebPack is available for Windows and Linux. See the [[ISE WebPack installation on Linux]] page for more infos.

====Simulation====
For simulation, Xilinx offers a free version of ''ModelSim'', called ''ModelSim Xilinx Edition (MXE)''. It can also be downloaded from the Xilinx homepage [http://www.xilinx.com/ise/optional_prod/mxe.htm] for free, but registration is required in order to receive a license. MXE is available for Windows only.
The alternative for Linux users is GHDL. More information can be found on the [http://www.armadeus.com/wiki/index.php?title=How_to_make_a_VHDL_design_in_Ubuntu/Debian#Simulation VHDL for Linux] page.

====VHDL code editor====
The editor in ISE is not very useful and inconvenient. In principle, any alternative editor can be used with ISE, but some have special support for VHDL-Code as syntax highlighting, template insertion, indenting and many other cool features that help to write nice and error-free code in less time. The [http://www.iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.html VHDL Mode] for the well known [http://www.gnu.org/software/emacs/ GNU Emacs] editor can be recommended in particular. Emacs is available for all important operating systems.

===Design Implementation===
Implement your design with the ''ISE WebPack'' software. If you are new to VHDL, the information on [http://en.wikipedia.org/wiki/VHSIC_Hardware_Description_Language] can give you a first idea. Tutorials for the ISE software can be downloaded from the Xilinx homepage [http://www.xilinx.com/support/techsup/tutorials].

===Bitstream generation===
When your design is ready and passes the simulation, you can create a ''bitstream file'' that can be downloaded to the FPGA. It contains all the data to configure the FPGA.

In the ISE Project Manager, make sure that a ''Binary Configuration File'' is also created. You can set this option in the properties dialog of the ''Generate Programming file'' process. Activate the option ''Create Binary Configuration File''.

The file with the ending ''.bin'' is now the file you need to configure the FPGA on the Armadeus module.

===Licence===
The firmware for the FPGA has to be licenced under LGPL and BSD.

Please add to each created file a header containing the name of the "company" here it is an association, the maintainer name, the licence.

If a part of a work of an other developper has been reused, please indicate where this part has been found, the author name and keep the original licence. If no licence is specified, assume it is unlicenced.

===Configuring the FPGA from U-Boot===
See the [[InstallTargetSoftware#FPGA_firmware_installation|InstallTargetSoftware]] page of this wiki.

===Configuring the FPGA from Linux===
See the FPGA loader page [[FPGA loader]] of this wiki for details.

===FPGA timing diagrams===
The following timings diagrams have been taken with an Armadeus release 2.1<br>
<br>

{|border=0 summary="Timings"
|----------------
| [[Image:FPGA_read.png | thumb | center | READ]] ||
| [[Image:FPGA_write_8bits.png | thumb | center | WRITE 8bits]] ||
| [[Image:FPGA_write_8bits.png | thumb | center | WRITE 16bits]] ||
|----------------
|}

==Links==
* http://www.comelec.enst.fr/hdl
* http://www.fpga4fun.com/

[[Image:FrenchFlag.png]] [[Fr:FPGA|Cette page en français]]

File:Fpga.png

2008-03-14T20:10:17Z

SonZerro: Chip Icon, LGPL from KDE-LOOK.org

Chip Icon, LGPL from KDE-LOOK.org

FPGA

2008-03-14T19:15:23Z

SonZerro: /* Development Software */ More structure and hint on editors added

==FPGA on APF9328==
The APF9328 is optionally equipped with an Xilinx Spartan-3 FPGA (Field Programmable Gate Array). An FPGA is a configurable digital device. Today, large and complex digital circuits and processor cores fit into FPGAs. To find more information about FPGAs, check the Wikipedia: [http://en.wikipedia.org/wiki/FPGA]

The FPGA on APF9328 is connected to the processor bus of the iMX and to the connector of the APF9328. This makes it possible to design your own peripherals and configure them into the FPGA. Because the FPGA can be reconfigured at any time, it allows you to replace these peripherals (or a part of them), if other functionalities are needed. This is possible even at run-time!

==FPGA Firmware Development==
===Digital Hardware Design===
FPGAs are quite complex digital devices. Modern tools allow to describe the circuits to be implemented an abstract way, which makes it possible to manage the complexity. The trend for new tools is toward higher levels of abstraction in order to be able to manage even more complex devices in future. Nevertheless, at least basic knowledge of digital circuits and gates is necessary to start designing firmware for FPGAs.

===FPGA Design-Flow===
The starting point for the implementation flow is a description of the functionality in a Hardware Description Language (HDL). One of the most commonly used HDLs is ''VHDL'' (Very High Speed Integrated Circuit Hardware Description Language). VHDL files are plain text files and editing can be done in any editor.

This VHDL circuit description can be simulated to verify the functionality.

If everything is working fine, a tool called ''synthesizer'' is used to translate this HDL description in a hardware netlist. Then this netlist is ''mapped'' onto the FPGA technology. After ''Place and Route'' and ''Bitstream generation'', a configuration file for the FPGA is created (''bitfile'').

For more informations about VHDL and the design flow, see [http://en.wikipedia.org/wiki/VHSIC_Hardware_Description_Language]. This page also contains many examples that show how to describe simple electronic circuits in VHDL.

==Armadeus Firmware Development Environment==
===Development Software===
====Synthesis====
For FPGA development, you need the ''Xilinx ISE WebPack'' from Xilinx. It can be downloaded for free (after registration) from the Xilinx homepage
[http://www.xilinx.com/ise/logic_design_prod/webpack.htm]. The WebPack contains all you need to implement a design for the FPGA on the APF9328: Editor, Synthesizer, Mapper, Place and Route Tool, Bitstream generator, and the tools to download a configuration to the FPGA.
ISE WebPack is available for Windows and Linux. See the [[ISE WebPack installation on Linux]] page for more infos.

====Simulation====
For simulation, Xilinx offers a free version of ''ModelSim'', called ''ModelSim Xilinx Edition (MXE)''. It can also be downloaded from the Xilinx homepage [http://www.xilinx.com/ise/optional_prod/mxe.htm] for free, but registration is required in order to receive a license. MXE is available only for Windows :-(

====VHDL code editor====
The editor in ISE is not very useful and inconvenient. In principle, any alternative editor can be used with ISE, but some have special support for VHDL-Code as syntax highlighting, template insertion, indenting and many other cool features that help to write nice and error-free code in less time. The [http://www.iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.html VHDL Mode] for the well known [http://www.gnu.org/software/emacs/ GNU Emacs] editor can be recommended in particular. Emacs is available for all important operating systems.

===Design Implementation===
Implement your design with the ''ISE WebPack'' software. If you are new to VHDL, the information on [http://en.wikipedia.org/wiki/VHSIC_Hardware_Description_Language] can give you a first idea. Tutorials for the ISE software can be downloaded from the Xilinx homepage [http://www.xilinx.com/support/techsup/tutorials].

===Bitstream generation===
When your design is ready and passes the simulation, you can create a ''bitstream file'' that can be downloaded to the FPGA. It contains all the data to configure the FPGA.

In the ISE Project Manager, make sure that a ''Binary Configuration File'' is also created. You can set this option in the properties dialog of the ''Generate Programming file'' process. Activate the option ''Create Binary Configuration File''.

The file with the ending ''.bin'' is now the file you need to configure the FPGA on the Armadeus module.

===Licence===
The firmware for the FPGA has to be licenced under LGPL and BSD.

Please add to each created file a header containing the name of the "company" here it is an association, the maintainer name, the licence.

If a part of a work of an other developper has been reused, please indicate where this part has been found, the author name and keep the original licence. If no licence is specified, assume it is unlicenced.

===Configuring the FPGA from U-Boot===
See the [[InstallTargetSoftware#FPGA_firmware_installation|InstallTargetSoftware]] page of this wiki.

===Configuring the FPGA from Linux===
See the FPGA loader page [[FPGA loader]] of this wiki for details.

===FPGA timing diagrams===
The following timings diagrams have been taken with an Armadeus release 2.1<br>
<br>

{|border=0 summary="Timings"
|----------------
| [[Image:FPGA_read.png | thumb | center | READ]] ||
| [[Image:FPGA_write_8bits.png | thumb | center | WRITE 8bits]] ||
| [[Image:FPGA_write_8bits.png | thumb | center | WRITE 16bits]] ||
|----------------
|}

==Links==
* http://www.comelec.enst.fr/hdl
* http://www.fpga4fun.com/

[[Image:FrenchFlag.png]] [[Fr:FPGA|Cette page en français]]

FpgaArchitecture

2008-01-06T22:08:11Z

SonZerro:

= Spécifications de conception du FPGA =

== Evolutions ==

2006/12/29: MAJ de la partie 1.7 pour décrire plus en détail le programme d'assemblage des IP (Orchestra)

2006/12/21: MAJ en fonction des remarques de tout le monde.

== But ==

Cette page a été créée pour permettre à tous les membres de l'association de discuter de l'architecture qui va être mise en place pour le FPGA présent sur la carte APF9328.

Cette espace doit être vu comme un espace d'échange d'idées. Tout le monde est convié à y participer. Il est préférable d'avoir quelques connaissances en électronique et sur les langages HDL (VHDL ou Verilog), mais ce n'est pas une obligation.

Bonne lecture et merci pour votre participation.

== Les grandes lignes ==

Le FPGA de la carte APF9328 est là pour offrir le maximum de souplesse au projet '''Armadeus''' et permettre d'implanter des fonctionnalités coté '''matériel''' qui seraient trop pénalisantes ou impossibles à implanter coté '''logiciel'''. Bien entendu, pour que cela soit exploitable, il faut également disposer d'un lien entre le FPGA et le processeur i.MX.

Pour réaliser cela, il faut mettre en place un bus de communication entre le FPGA et l'i.MX. Ce bus de communication va permettre le pilotage des fonctionnalités qui seront implantées dans le FPGA. Bref, il faut recréer à l'intérieur du FPGA un bus tel qu'il existe entre l'i.MX et les différents composants de la carte (RAM, Flash, USB, Ethernet, etc.).

Pour gagner en temps de développement et pour pouvoir récupérer des fonctionnalités ou IP (Intellectual Property) déjà existantes, le bus Wishbone a été retenu. Ce bus, dont les spécification ont été placées dans le domaine public, a été conçu spécifiquement pour ce genre de configuration et sur le site '''[http://www.opencores.com www.opencores.com]''' plusieurs IP compatibles avec les spécifications Wishbone sont disponibles.

== Le bus Wishbone ==

(add list of the signals of the wishbone bus here)

(add references to documentation)

La spécification Wishbone décrit un certain nombre de composants de base:
* Des interfaces '''maitres''', ces interfaces sont implantés dans des composants qui seront alors capable d'initier les transferts sur le bus Wishbone
* Des interfaces '''esclaves''', ces interfaces sont implantés dans des composants capables de répondre à des demandes de transferts
* Un composant '''syscon''', ce composant va générer le signal d'horloge qui sera utilisé par tous les composants/interfaces du bus ainsi que le signal de RESET synchrone.
* Un macro composant '''intercon''', ce composant va gérer la connexion de toutes les interfaces maitres et esclaves qui composent le bus interne. Il prend en charge :
** Le décodage/transcodage d'adresse (génération des signaux A0 à A3 selon le mode d'adressage 8/16/32/64 bits)
** le routage du bus de données entre les différentes interfaces maitres et esclaves (conversion big endian/little endian, etc)
** le routage/génération des signaux de contrôle du bus (Read, Write, Chip Select, Output Enable, ACK, etc.)
* Un composant '''arbitre''', ce composant va permettre de partager l'accès au bus ou à un composant de type esclave qui est partagé par plusieurs composants de type maitre.

Les spécifications du bus Wishbone permettent de créer différents types de bus:
* '''Point to Point''': C'est le type de bus le plus simple possible, un composant avec une interface type maitre connecté à un composant avec une interface de type esclave.
* '''Data Flow''': C'est un bus en cascade, à un bout on trouve un composant avec une interface de type maître et à l'autre bout un composant avec une interface de type esclave. Entre les deux composant se trouve une chaine d'un ou plusieurs composants avec une interface de type maitre et de type esclave.
* '''Shared''': C'est un bus sur lequel plusieurs composants sont connectés dessus. Tous les composants se partagent ce bus. Si plusieurs ''maitres'' sont connectés sur ce bus, un seul pourra initier un transfert à un instant donné.
* '''CrossBar''': C'est également un bus de type partagé, par contre dans se cas, on dispose de plusieurs bus. Chaque maitre utilise sont propre bus pour communiquer avec ces esclaves. On peut donc avoir plusieurs transferts en simultané. Le seul cas de blocage/arbitrage est le transfert de plusieurs maitre avec le même esclave.

Il existe également un certain nombre de mécanismes dans la spécification Wishbone pour permettre d'optimiser les temps de transferts sur le bus. Ces optimisations sont de plusieurs nature:
* utilisation de signaux '''ACK''', '''ERR''' et '''RTY''' pour signaler la fin de transfert
* les '''Registered Feedback Bus Cycles''', qui permettent de gagner un cycle d'horloge pour des transferts consécutifs
* les transferts en mode '''Burst'''

== Le lien i.MX <=> FPGA ==

(add timing graph here)

La communication entre l'i.MX et le FPGA passe par les signaux suivants (à vérifier):
* des signaux de contrôle: <strike>RW_n</strike>, OE_n, EB_n[3..2] et CS1_n
* le bus de données sur 16 bits (D[15..0])
* le bus d'adresses sur 12 bits (A[12..1])

Ces signaux sont alors utilisés pour créer une interface Wishbone maitre qui va permettre de communiquer efficacement avec les autres IPs contenus dans le FPGA qui implémenterons une interface wishbone de type esclave.

Etant donné les erratas du composant i.MX concernant le signal DTACK, il n'est pas possible d'implanter une interface Wishbone maitre ''classique''. Ceci entraine les limitations suivantes:
* Pas possible d'utiliser le signal '''ACK''' Wishbone pour terminer le transfert entre FPGA et i.MX.
* Pas possible de mettre en place des optimisations du temps de transfert.

Pour contrer ce problème, il faudra s'assurer que toutes les interfaces esclaves qui seront connectées à l'interface maitre du composant Wishbone i.MX répondent dans un temps fixe donné.<br />
Comme le bus Wishbone est un bus entièrement synchrone, le temps minimal d'un transfert est de 2 cycles de l'horloge Wishbone. Il faut ajouter à cela, un cycle pour la synchronisation des signaux du bus i.MX. Cela nous fait donc un minimum de 3 cycles Wishbone pour un transfert entre le FPGA et l'i.MX.

Etant donné les performances des FPGA actuels, on peut tabler sur une fréquence de fonctionnement d'au moins 100MHz pour le bus Wishbone. Cela nous donne donc un taux de transfert approximatif de 66 Moctets/sec (100MHz * 16bits / 3).

== La composition du système Wishbone ==

[[Image:FPGA_Armadeus.png]]

Le système Wishbone qui sera implanté dans le FPGA se compose des éléments suivants:
* '''i.MX Wrapper''': L'interface i.MX vers le bus Wishbone
* '''Syscon''': Ce composant va gérer les signaux '''CLK''' (généré par une PLL ou directement issu de l'i.MX) et '''RESET''' (synchrone).
* '''Intercon''': Ce composant devra être généré automatiquement par une moulinette, il va faire le lien entre tous les composants faisant parti du '''Système Wishbone'''.
* '''Gestionnaire d'interruption''': Ce composant est un '''esclave wishbone''' et va centraliser toutes les demandes d'interruption et les remonter vers l'i.MX.
* '''Esclaves whisbone''': Ceci représentent tous les autres composants avec une interface wishbone esclave qui sont accessibles via le wrapper i.MX.

Sur le diagramme, il manque un certain nombre de choses:
* Les signaux ''non wishbone'' en entrée ou en sortie sur les '''esclaves wishbone'''
* Le macro composant '''système wishbone'''. Ce macro composant est celui qui sera ensuite instancié dans le design du FPGA. Sur ce composant ne seront visibles que les signaux ''externes'' au système:
** Les signaux issus de l'i.MX
** <strike>Le signal RESET (en entrée) qui sera synchronisé sur l'horloge système</strike> Le signal RESET synchrone du bus Wishbone sera directement généré par le composant syscon à l'aide d'une simple machine d'état.
** Le signal CLK (en entrée) qui sera l'horloge utilisée pour la génération des signaux Wishbone
** Le signal IRQ (en sortie) qui sera utilisé pour remonter les demandes d'interruption vers l'i.MX
** Les signaux d'entrée et de sortie spécifiques aux autres composants connectés sur le bus Wishbone

L'intérêt de créer le composant '''Système Wishbone''', est que cela simplifie la vision dans l'outil conception du FPGA. Il ne suffit plus alors qu'à relier les signaux sur les broches correspondantes du FPGA.

=== i.MX Bridge ===

Ce composant est le point d'accès au bus Wishbone pour l'i.MX et sera le seul à disposer d'une interface Wishbone maitre.

Les fonctions de ce composants sont:
* synchronisation des signaux issus de l'i.MX. Ceci est primordial pour assurer la stabilité de tout le système Wishbone. De plus, le bus de sortie étant asynchrone (l'horloge de génération des signaux n'est pas véhiculée), la resynchronisation des signaux par rapport à l'horloge du bus s'impose.
* gestion du bus de données en 3 états.
* conversion des signaux de contrôle du bus i.MX en signaux Wishbone.

=== Syscom ===

C'est le composant le plus simple du système <strike>, il ne fait que synchroniser le signal RESET en entrée avec le signal d'horloge du système</strike>.

Il va être en charge de la génération du signal RESET synchrone pour le bus Wishbone.

Le signal d'horloge en entrée du composant '''syscon''' sera celui utilisé pour le fonctionnement du bus Wishbone. La fréquence du signal d'horloge devra être assez élevée pour permettre le traitement des signaux issus de l'i.MX. Cela va dépendre de la configuration du chip select utilisé (CS1).

La source du signal d'horloge reste encore à définir, les choix possibles sont:
* directement issu de l'i.MX
* utilisation d'un DCM du Spartan 3

Le choix définitif dépendra principalement des essais ''grandeur nature'' lors de la génération des premiers systèmes whisbone durant la phase de mise en place des composants de base.

=== Intercon ===

Ce composant a la particularité qu'il sera créé automatiquement par un outil (script ou programme). '''Intercom''' a comme fonctionnalités:
* Le décodage d'adresse pour la sélection des différents esclaves du système
* Le routage des bus d'adresses et de données vers les différents esclaves
* La génération des signaux de contrôle pour les différents esclaves.

Etant donné les limitations induites par les erratas de l'i.MX, le composant '''intercom''' remplira les fonctionnalités suivantes:
* le bus de données est figé sur 16 bits
* les cycles de lecture et d'écriture sont de longueur fixe (à priori 3 cycles d'horloge '''à valider''' lors des essais du système de base)
* une interruption est générée en cas de dépassement du temps de cycle d'écriture ou de lecture
* le bus sera de type '''shared''' avec un seul maitre (le Wrapper i.MX).

=== Les composants esclaves ===

<span style="color:#FF0000;">
<big>Suite aux divers discussions issues de ce chapitre. L'organisation et la présences des fichiers dans les répertoires '''doc''' et '''HAL''' n'est pas encore établie. Ce chapitre sera encore à retravailler.</big>
</span>

Pour qu'une IP puisse être facilement inclue dans le système, il faut une certaine organisation. Sinon, à moyen ou à long terme cette IP est morte parce qu'elle sera difficilement exploitable et encore plus difficilement maintenable.

Ce sont des notions qui ne sont pas simples à prendre en considération lors du développement d'un nouveau projet, mais lorsque l'on doit se replonger dans un travail fait par quelqu'un d'autre ou un projet qu'on a laissé en sommeil pendant quelque temps, on est content d'avoir quelque chose à quoi se raccrocher.

Pour développer efficacement, il faut assurer une organisation logique, figée et compréhensible, et le plus simple dans ce genre de cas est de se baser sur la notion de répertoire. Voici les répertoires qui doivent être utilisés par une IP:
* '''doc''': Ce répertoire va contenir toute la documentation nécessaire à l'exploitation de l'IP. On y trouvera une notice ('''readme.txt'''), un fichier de suivi de modification ('''ChangeLog.txt'''), un fichier contenant les évolutions futures prévues ('''todo.txt''') ainsi que tout autre fichier estimé utile par le(s) créateur(s) de l'IP.
* '''hdl''': Ce répertoire va contenir tous les fichiers VHDL (ou Verilog) qui auront été développés spécifiquement pour cette IP.
* '''inc''': Ce répertoire va contenir un fichier d'en-tête ANSI C contenant l'adresse de tous les registres interne de l'IP pour permettre de créer simplement un programme en langage C permettant de contrôler l'IP. '''''Ce répertoire est optionnel et ne s'applique évidement qu'à des IPs ayant une interface de type Wishbone.'''''
* '''HAL''': Ce répertoire va contenir un drivers ou un exemple de logiciel de base permettant l'utilisation de l'IP par un microprocesseur/contrôleur. '''''Ce répertoire est optionnel et ne s'applique évidement qu'à des IPs ayant une interface de type Wishbone.'''''

=== Gestionnaire d'interruption ===

Ce composant esclave est le premier qui sera créé spécifiquement pour le système. Il sera capable de:
* prendre en compte jusqu'à 16 sources d'interruptions différentes (remark: why 16 ???)
* réaliser l'acquittement de chaque interruption individuellement
* masquer/autoriser chaque interruption individuellement

Le composant disposera des registres suivants:
* '''isr_mask''': registre d'autorisation des interruptions. Chaque bit correspond à une interruption (bit0 => IRQ0, bit1 => IRQ1, etc.). Ce registre sera accessible en lecture et en écriture. (remark: what is the default value? How are the bits interpreted? What is the meaning of '0'/'1'?
* '''isr_pend''': ce registre est à double emploi
** '''en lecture''': Les interruptions en attente de traitement
** '''en écriture''': Acquittement des interruptions. Chaque bit à 1 va acquitter l'interruption correspondante.

== Le script / programme d'assemblage des IP ==

Nous allons maintenant parler du coeur du système, du moins de la partie la plus visible de l'iceberg ;-)

La première des priorités, sera de trouver un nom pour cet outil qui reste un peu dans l'esprit du projet. Voici quelques propositions, à vous de compléter ou de voter pour un nom ou plusieurs noms:
* Concerto
* Orchestra

D'après les derniers sondage, '''Orchestra''' serait finalement le nom retenu pour ce logiciel.

=== Principe et fonctionnement ===

Afin de de rendre tout ce système utilisable par le plus grand nombre, il faut être capable de proposer des outils qui vont simplifier la vie de l'utilisateur final ainsi que de l'intégrateur.

Pour cela, il faudra créer un outil soit sous forme de script(s), soit sous forme de programme(s) qui va permettre de réaliser les tâches suivantes:
* Création/gestion d'une bibliothèque de composants '''''Armadeus Ready'''''
* Gestion d'une liste de '''hardware Armadeus'''
* Edition d'un '''système Armadeus'''
* Gestion d'un projet
* Génération automatique du composant '''system''' qui sera implanté dans le FPGA
* Génération automatique d'un banc de tests pour permettre la validation par ModelSim (ou autre logiciel de simulation HDL)
* Génération d'un fichier '''mapping mémoire'''

=== La bibliothèque de composants ===

Pour qu'un composant, c'est-à-dire une IP, soit exploitable par le système, il faut passer par une phase d'intégration qui va permettre de décrire ce composant:
* Nom de l'IP
* Description
* Version
* Identification des fichiers HDL utilisés (VHDL ou Verilog)
* Identification du fichier '''Top''' (le point d'entrée de l'IP)
* Identification des paramètres '''''GENERIC''''' (dans le cas d'une IP en VHDL):
** Type de paramètre (entier, std_logic, etc)
** Valeur par défaut
** Valeurs ou plages de valeurs autorisées
** Description du paramètre
* Identification des signaux Wishbone utilisés par le composant
* Identification du type (maitre ou esclave) et du nombre d'interfaces Wishbone utilisés par ce composant
* Identification des registres internes
** Adresse (Offset par rapport à l'adresse de base)
** Taille (8 ou 16 bits)
** Nom et/ou description

Toutes ces informations seront alors sauvegardées dans un fichier, de préférence dans un format compréhensible et lisible à l'aide de n'importe quel éditeur de texte (XML, ''fichier INI'' ou ''fichier plat'').

Chaque composant identifié par le logiciel se trouvera dans un sous-répertoire (ou dans un fichier archive ?!?) placé dans le répertoire '''Armadeus Components''', chaque sous-répertoire (ou archive) de composant contiendra les données suivantes:
* Le fichier de description du composant '''''Armadeus Ready'''''
* un répertoire '''HDL''' avec les fichiers VHDL/Verilog de l'IP
* un répertoire '''HAL''' avec les fichiers d'un drivers de base (pour Linux ou ''générique'' ?!?)

Le gestionnaire de composants Armadeus doit être capable de réaliser les opérations suivantes:
* Importer un composant ou une liste de composants
* Exporter un composant ou une liste de composants
* Gérer des versions de composants (à voir si cette fonctionnalité est importante/utile)
* Permettre l'ajout/création de composants
* Permettre de supprimer un composant

=== Gestionnaire de plateformes ===

Il faut avoir confiance dans l'avenir, pour l'instant nous ne disposons que d'une seul plateforme de travail, mais ce n'est qu'un début et très certainement d'autres cartes à base de l'i.MX et d'un FPGA vont voir le jour.

Il faut donc prévoir d'ores et déjà cette possibilité et proposer un outil qui va permettre de définir une plateforme. Chaque descripteur de plateforme devra fournir les informations suivantes:
* Type de FPGA
* Emplacement (niveau FPGA, c'est-à-dire la broche utilisée), type (sortie i.MX, oscillateur ou quartz) et fréquence (ou plage de fréquence ?!?) des horloges
* Emplacements/broche du FPGA utilisées ainsi que leur fonctionnalité (signal Wishbone, comme d'un composant externe, signal d'interruption, etc.)

Toutes ces informations seront utilisées par la suite lors de la création d'un projet '''Orchestra/Armadeus'''.

=== Gestionnaire de projet ===

Le rôle du gestionnaire de projet est de permettre de créer, reprendre ou modifier le plus simplement possible une configuration du FPGA pour une carte donnée. Cette configuration sera appelée par la suite un '''système'''.

Tout '''système''' est entièrement décrit par un fichier projet qui contiendra les éléments suivants:
* Le nom du système (éventuellement le même que le nom du projet ?!?)
* Une description du système
* Le type de plateforme utilisé pour ce système
* La source de la fréquence d'horloge du bus Wishbone (broche du FPGA ou DLL/DCM). On pourra éventuellement imaginer la création d'un ''Wizard'' pour simplifier la configuration du DCM.
* La liste de tous les composants '''Armadeus Ready''' inclus dans le système, avec pour chacun de ces composants, les détails suivantes:
** La référence du composant (par rapport à la bibliothèque de composants '''Armadeus Ready''')
** Le nom de l'instance du composant (e.g. UART1, PWM_MOTOR, etc.)
** La connexion des entrées/sorties (vers une broche du FPGA, non utilisé ou relié '''manuellement''')
** La valeur de chaque paramètre '''GENERIC''' du composant, par exemple l'adresse du base de chacune de ses interfaces esclaves connectées au bus Wishbone
** L'horloge utilisée (pour l'instant ce sera toujours celle du bus Wishbone mais peut-être que plus tard ce ne sera plus forcément le cas ;-) )
** Le numéro d'interruption attribué au composant, s'il est capable de généré une demande d'interruption

Comme pour le fichier de description d'un composant Armadeus, le fichier projet devra être dans un format texte compréhensible et lisible à l'aide de n'importe quel éditeur texte (XML, ''fichier INI'' ou ''fichier plat'').

Le fichier projet est le coeur du système et, à partir de celui-ci ainsi que de la librairie de composants '''Armadeus Ready''' + la librairie de plateforme, toute la partie liée au FPGA doit pouvoir être recrée. Bref c'est le seul fichier dont l'utilisateur final aura à ce soucier (sauvegarde, archivage, etc).

Lors de la création d'un nouveau projet, l'utilisateur devra fournir les éléments de base suivants:
* Le nom du système
* Une description
* Le type de plateforme utilisé
* La source de l'horloge Wishbone (broche du FPGA ou DCM) avec éventuellement un ''wizard'' pour la saisie des informations relatives à la programmation du DCM.
* La fréquence du bus Wishbone (éventuellement obtenue automatiquement à partir de la sélection de la source de l'horloge)
* Le nombre de sources d'interruptions autorisées ainsi que l'emplacement en mémoire des registres du gestionnaire d'interruption (par défaut à l'adresse 0x0000).

Une fois que le projet aura été créer, les composants suivants seront ajouté automatiquement au système:
* Un '''Wrapper i.MX''' pour faire le lien avec l'i.MX
* Un '''syscon''' pour la générations des signaux '''CLK''' et '''RESET''' du bus Wishbone
* Un '''Gestionnaire d'interruptions''' si le système doit être capable de remonter des demandes d'interruption.

Par la suite, l'utilisateur pourra modifier le système de base à l'aide des opérations suivantes:
* choisir dans la librairie un composant pour l'ajouter au système
* modifier les paramètres d'un composant du système
* modifier les caractéristiques du projet (nom, fréquence du bus Wishbone, etc.)
* supprimer un composant du système
* attribution automatique des adresses de base sur le bus Wishbone
* attribution automatique des numéros d'interruption
* annulation des dernières modifications (éventuellement)
* sauvegarde/restauration d'un fichier projet

=== Générateur de fichiers ===

C'est ici que va se trouver la partie la plus ardue du projet '''Orchestra''', et c'est en fonction de ce que l'on sera capable de proposer à l'utilisateur final que se fera l'adhésion au projet ou non.

Une fois que l'on aura créer son projet/système Armadeus, il faut encore pouvoir générer au minimum le fichier '''bitstream''' qui va être utiliser pour configurer le FPGA.

C'est ici qu'entre en jeu le générateur de fichiers, qui devra être capable, à l'aide du fichier projet + la librairie de composant + la librairie de plateforme, de générer le fichiers suivants:
* un fichier HDL '''Intercon''' reliant tous les composants placés dans le système qui a été créé par l'utilisateur
* un fichier HDL '''system''' qui va englober tout le système Wishbone tel qu'il a été défini par l'utilisateur
* un fichier HDL '''system_tb''' et un fichier '''.DO''' qui vont pouvoir être utilisés pour la simulation à partir de ModelSim
* un fichier '''system.h''' qui va contenir le plan mémoire du système créé
* un fichier '''tcl''' qui va permettre de créer entièrement et de manière automatique le projet dans l'environnement '''Xilinx ISE''', c'est-à-dire:
** sélection du bon FPGA
** sélection du bon format de sortie (bitstream)
** saisie du pinout du FPGA (nom de chaque broche par rapport au nom du signal sur le schéma)
** programmation du DCM le cas échéant
** définition des signaux d'horloge
** inclusion des fichiers HDL nécessaires au projet
** instanciation du fichier HDL '''sytem'''
** connexion des entrées et sorties du composant '''system'''

(remark: an include file for the operating system has to be generated, so that the drivers know the base address of the hardware-modules)

Comme on peut le voir, le travail pour '''Orchestra''' ne manque pas, reste encore la question du mode de développement ainsi que du langage et la bibliothèque graphique.

Mais ceci est encore une autre histoire, qui pourra être débattu lorsque les premières composants système seront prêt à l'emploi... Peut-être très bientôt :-)

== Gestionnaire d'interruption ==

'''Ce chapitre est donné à titre informatif/propositon et ne tiens pas lieu de spécification.'''

Afin de simplifier la vie des programmeurs systèmes, il faut pouvoir offrir un mécanisme simple de mise en place et de gestion des demandes d'interruption du FPGA.

Pour cela, je propose la solution suivante:
* Mise en place d'un gestionnaire d'interruption générique pour le FPGA. Ce gestionnaire d'interruption sera capable de lire le registre d'interruption (lecture de '''isr_pend''') et de déterminer les interruptions à traiter (via '''isr_mask'''). Il va en suite aiguiller l'exécution de la routine d'interruption vers les routines adéquates pour chaque bit d'interruption valide. L'interruption traitée sera alors acquitée (écriture vers '''isr_pend''').
* Création d'une routine '''''d'enregistrement de vecteur d'interruption'''''. Cette routine va permettre d'ajouter une routine de traitement d'interruption pour un bit d'interruption donné. Pour cela il faudra lui fournir les informations suivantes (via une structure ?!?):
** Le numéro du bit d'interruption (0 à 31)
** La routine de traitement d'interruption pour ce driver
** Un paramètre additionnel à fournir à la routine de traitement d'interruption (pointeur de type '''''void *''''')
** Le nom du drivers (optionnel, permet d'identifier/visualiser les drivers installer éventuellement)
* Création d'une routine de validation d'une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine pour masquer une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine pour désinstaller une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine ou méthode pour visualiser tous les drivers Wishbone installés:
** Leur numéro
** Leur nom
** Leur état (validé/masqué)
** Le nombre de fois qu'ils ont été appelé
** etc.

FpgaArchitecture

2008-01-06T21:55:09Z

SonZerro: /* Le lien i.MX <=> FPGA */

= Spécifications de conception du FPGA =

== Evolutions ==

2006/12/29: MAJ de la partie 1.7 pour décrire plus en détail le programme d'assemblage des IP (Orchestra)

2006/12/21: MAJ en fonction des remarques de tout le monde.

== But ==

Cette page a été créée pour permettre à tous les membres de l'association de discuter de l'architecture qui va être mise en place pour le FPGA présent sur la carte APF9328.

Cette espace doit être vu comme un espace d'échange d'idées. Tout le monde est convié à y participer. Il est préférable d'avoir quelques connaissances en électronique et sur les langages HDL (VHDL ou Verilog), mais ce n'est pas une obligation.

Bonne lecture et merci pour votre participation.

== Les grandes lignes ==

Le FPGA de la carte APF9328 est là pour offrir le maximum de souplesse au projet '''Armadeus''' et permettre d'implanter des fonctionnalités coté '''matériel''' qui seraient trop pénalisantes ou impossibles à implanter coté '''logiciel'''. Bien entendu, pour que cela soit exploitable, il faut également disposer d'un lien entre le FPGA et le processeur i.MX.

Pour réaliser cela, il faut mettre en place un bus de communication entre le FPGA et l'i.MX. Ce bus de communication va permettre le pilotage des fonctionnalités qui seront implantées dans le FPGA. Bref, il faut recréer à l'intérieur du FPGA un bus tel qu'il existe entre l'i.MX et les différents composants de la carte (RAM, Flash, USB, Ethernet, etc.).

Pour gagner en temps de développement et pour pouvoir récupérer des fonctionnalités ou IP (Intellectual Property) déjà existantes, le bus Wishbone a été retenu. Ce bus, dont les spécification ont été placées dans le domaine public, a été conçu spécifiquement pour ce genre de configuration et sur le site '''[http://www.opencores.com www.opencores.com]''' plusieurs IP compatibles avec les spécifications Wishbone sont disponibles.

== Le bus Wishbone ==

(add list of the signals of the wishbone bus here)

(add references to documentation)

La spécification Wishbone décrit un certain nombre de composants de base:
* Des interfaces '''maitres''', ces interfaces sont implantés dans des composants qui seront alors capable d'initier les transferts sur le bus Wishbone
* Des interfaces '''esclaves''', ces interfaces sont implantés dans des composants capables de répondre à des demandes de transferts
* Un composant '''syscon''', ce composant va générer le signal d'horloge qui sera utilisé par tous les composants/interfaces du bus ainsi que le signal de RESET synchrone.
* Un macro composant '''intercon''', ce composant va gérer la connexion de toutes les interfaces maitres et esclaves qui composent le bus interne. Il prend en charge :
** Le décodage/transcodage d'adresse (génération des signaux A0 à A3 selon le mode d'adressage 8/16/32/64 bits)
** le routage du bus de données entre les différentes interfaces maitres et esclaves (conversion big endian/little endian, etc)
** le routage/génération des signaux de contrôle du bus (Read, Write, Chip Select, Output Enable, ACK, etc.)
* Un composant '''arbitre''', ce composant va permettre de partager l'accès au bus ou à un composant de type esclave qui est partagé par plusieurs composants de type maitre.

Les spécifications du bus Wishbone permettent de créer différents types de bus:
* '''Point to Point''': C'est le type de bus le plus simple possible, un composant avec une interface type maitre connecté à un composant avec une interface de type esclave.
* '''Data Flow''': C'est un bus en cascade, à un bout on trouve un composant avec une interface de type maître et à l'autre bout un composant avec une interface de type esclave. Entre les deux composant se trouve une chaine d'un ou plusieurs composants avec une interface de type maitre et de type esclave.
* '''Shared''': C'est un bus sur lequel plusieurs composants sont connectés dessus. Tous les composants se partagent ce bus. Si plusieurs ''maitres'' sont connectés sur ce bus, un seul pourra initier un transfert à un instant donné.
* '''CrossBar''': C'est également un bus de type partagé, par contre dans se cas, on dispose de plusieurs bus. Chaque maitre utilise sont propre bus pour communiquer avec ces esclaves. On peut donc avoir plusieurs transferts en simultané. Le seul cas de blocage/arbitrage est le transfert de plusieurs maitre avec le même esclave.

Il existe également un certain nombre de mécanismes dans la spécification Wishbone pour permettre d'optimiser les temps de transferts sur le bus. Ces optimisations sont de plusieurs nature:
* utilisation de signaux '''ACK''', '''ERR''' et '''RTY''' pour signaler la fin de transfert
* les '''Registered Feedback Bus Cycles''', qui permettent de gagner un cycle d'horloge pour des transferts consécutifs
* les transferts en mode '''Burst'''

== Le lien i.MX <=> FPGA ==

(add timing graph here)

La communication entre l'i.MX et le FPGA passe par les signaux suivants (à vérifier):
* des signaux de contrôle: <strike>RW_n</strike>, OE_n, EB_n[3..2] et CS1_n
* le bus de données sur 16 bits (D[15..0])
* le bus d'adresses sur 12 bits (A[12..1])

Ces signaux sont alors utilisés pour créer une interface Wishbone maitre qui va permettre de communiquer efficacement avec les autres IPs contenus dans le FPGA qui implémenterons une interface wishbone de type esclave.

Etant donné les erratas du composant i.MX concernant le signal DTACK, il n'est pas possible d'implanter une interface Wishbone maitre ''classique''. Ceci entraine les limitations suivantes:
* Pas possible d'utiliser le signal '''ACK''' Wishbone pour terminer le transfert entre FPGA et i.MX.
* Pas possible de mettre en place des optimisations du temps de transfert.

Pour contrer ce problème, il faudra s'assurer que toutes les interfaces esclaves qui seront connectées à l'interface maitre du composant Wishbone i.MX répondent dans un temps fixe donné.<br />
Comme le bus Wishbone est un bus entièrement synchrone, le temps minimal d'un transfert est de 2 cycles de l'horloge Wishbone. Il faut ajouter à cela, un cycle pour la synchronisation des signaux du bus i.MX. Cela nous fait donc un minimum de 3 cycles Wishbone pour un transfert entre le FPGA et l'i.MX.

Etant donné les performances des FPGA actuels, on peut tabler sur une fréquence de fonctionnement d'au moins 100MHz pour le bus Wishbone. Cela nous donne donc un taux de transfert approximatif de 66 Moctets/sec (100MHz * 16bits / 3).

== La composition du système Wishbone ==

[[Image:FPGA_Armadeus.png]]

Le système Wishbone qui sera implanté dans le FPGA se compose des éléments suivants:
* '''i.MX Wrapper''': L'interface i.MX vers le bus Wishbone
* '''Syscon''': Ce composant va gérer les signaux '''CLK''' (généré par une PLL ou directement issu de l'i.MX) et '''RESET''' (synchrone).
* '''Intercon''': Ce composant devra être généré automatiquement par une moulinette, il va faire le lien entre tous les composants faisant parti du '''Système Wishbone'''.
* '''Gestionnaire d'interruption''': Ce composant est un '''esclave wishbone''' et va centraliser toutes les demandes d'interruption et les remonter vers l'i.MX.
* '''Esclaves whisbone''': Ceci représentent tous les autres composants avec une interface wishbone esclave qui sont accessibles via le wrapper i.MX.

Sur le diagramme, il manque un certain nombre de choses:
* Les signaux ''non wishbone'' en entrée ou en sortie sur les '''esclaves wishbone'''
* Le macro composant '''système wishbone'''. Ce macro composant est celui qui sera ensuite instancié dans le design du FPGA. Sur ce composant ne seront visibles que les signaux ''externes'' au système:
** Les signaux issus de l'i.MX
** <strike>Le signal RESET (en entrée) qui sera synchronisé sur l'horloge système</strike> Le signal RESET synchrone du bus Wishbone sera directement généré par le composant syscon à l'aide d'une simple machine d'état.
** Le signal CLK (en entrée) qui sera l'horloge utilisée pour la génération des signaux Wishbone
** Le signal IRQ (en sortie) qui sera utilisé pour remonter les demandes d'interruption vers l'i.MX
** Les signaux d'entrée et de sortie spécifiques aux autres composants connectés sur le bus Wishbone

L'intérêt de créer le composant '''Système Wishbone''', est que cela simplifie la vision dans l'outil conception du FPGA. Il ne suffit plus alors qu'à relier les signaux sur les broches correspondantes du FPGA.

=== i.MX Wrapper ===

Ce composant est le point d'accès au bus Wishbone pour l'i.MX et sera le seul à disposer d'une interface Wishbone maitre.

Les fonctions de ce composants sont:
* synchronisation des signaux issus de l'i.MX. Ceci est primordial pour assurer la stabilité de tout le système Wishbone. De plus, le bus de sortie étant asynchrone (l'horloge de génération des signaux n'est pas véhiculée), la resynchronisation des signaux par rapport à l'horloge du bus s'impose.
* gestion du bus de données en 3 états.
* conversion des signaux de contrôle du bus i.MX en signaux Wishbone.

=== Syscom ===

C'est le composant le plus simple du système <strike>, il ne fait que synchroniser le signal RESET en entrée avec le signal d'horloge du système</strike>.

Il va être en charge de la génération du signal RESET synchrone pour le bus Wishbone.

Le signal d'horloge en entrée du composant '''syscon''' sera celui utilisé pour le fonctionnement du bus Wishbone. La fréquence du signal d'horloge devra être assez élevée pour permettre le traitement des signaux issus de l'i.MX. Cela va dépendre de la configuration du chip select utilisé (CS1).

La source du signal d'horloge reste encore à définir, les choix possibles sont:
* directement issu de l'i.MX
* utilisation d'un DCM du Spartan 3

Le choix définitif dépendra principalement des essais ''grandeur nature'' lors de la génération des premiers systèmes whisbone durant la phase de mise en place des composants de base.

=== Intercon ===

Ce composant a la particularité qu'il sera créé automatiquement par un outil (script ou programme). '''Intercom''' a comme fonctionnalités:
* Le décodage d'adresse pour la sélection des différents esclaves du système
* Le routage des bus d'adresses et de données vers les différents esclaves
* La génération des signaux de contrôle pour les différents esclaves.

Etant donné les limitations induites par les erratas de l'i.MX, le composant '''intercom''' remplira les fonctionnalités suivantes:
* le bus de données est figé sur 16 bits
* les cycles de lecture et d'écriture sont de longueur fixe (à priori 3 cycles d'horloge '''à valider''' lors des essais du système de base)
* une interruption est générée en cas de dépassement du temps de cycle d'écriture ou de lecture
* le bus sera de type '''shared''' avec un seul maitre (le Wrapper i.MX).

=== Les composants esclaves ===

<span style="color:#FF0000;">
<big>Suite aux divers discussions issues de ce chapitre. L'organisation et la présences des fichiers dans les répertoires '''doc''' et '''HAL''' n'est pas encore établie. Ce chapitre sera encore à retravailler.</big>
</span>

Pour qu'une IP puisse être facilement inclue dans le système, il faut une certaine organisation. Sinon, à moyen ou à long terme cette IP est morte parce qu'elle sera difficilement exploitable et encore plus difficilement maintenable.

Ce sont des notions qui ne sont pas simples à prendre en considération lors du développement d'un nouveau projet, mais lorsque l'on doit se replonger dans un travail fait par quelqu'un d'autre ou un projet qu'on a laissé en sommeil pendant quelque temps, on est content d'avoir quelque chose à quoi se raccrocher.

Pour développer efficacement, il faut assurer une organisation logique, figée et compréhensible, et le plus simple dans ce genre de cas est de se baser sur la notion de répertoire. Voici les répertoires qui doivent être utilisés par une IP:
* '''doc''': Ce répertoire va contenir toute la documentation nécessaire à l'exploitation de l'IP. On y trouvera une notice ('''readme.txt'''), un fichier de suivi de modification ('''ChangeLog.txt'''), un fichier contenant les évolutions futures prévues ('''todo.txt''') ainsi que tout autre fichier estimé utile par le(s) créateur(s) de l'IP.
* '''hdl''': Ce répertoire va contenir tous les fichiers VHDL (ou Verilog) qui auront été développés spécifiquement pour cette IP.
* '''inc''': Ce répertoire va contenir un fichier d'en-tête ANSI C contenant l'adresse de tous les registres interne de l'IP pour permettre de créer simplement un programme en langage C permettant de contrôler l'IP. '''''Ce répertoire est optionnel et ne s'applique évidement qu'à des IPs ayant une interface de type Wishbone.'''''
* '''HAL''': Ce répertoire va contenir un drivers ou un exemple de logiciel de base permettant l'utilisation de l'IP par un microprocesseur/contrôleur. '''''Ce répertoire est optionnel et ne s'applique évidement qu'à des IPs ayant une interface de type Wishbone.'''''

=== Gestionnaire d'interruption ===

Ce composant esclave est le premier qui sera créé spécifiquement pour le système. Il sera capable de:
* prendre en compte jusqu'à 16 sources d'interruptions différentes
* réaliser l'acquittement de chaque interruption individuellement
* masquer/autoriser chaque interruption individuellement

Le composant disposera des registres suivants:
* '''isr_mask''': registre d'autorisation des interruptions. Chaque bit correspond à une interruption (bit0 => IRQ0, bit1 => IRQ1, etc.). Ce registre sera accessible en lecture et en écriture.
* '''isr_pend''': ce registre est à double emploi
** '''en lecture''': Les interruptions en attente de traitement
** '''en écriture''': Acquittement des interruptions. Chaque bit à 1 va acquitter l'interruption correspondante.

== Le script / programme d'assemblage des IP ==

Nous allons maintenant parler du coeur du système, du moins de la partie la plus visible de l'iceberg ;-)

La première des priorités, sera de trouver un nom pour cet outil qui reste un peu dans l'esprit du projet. Voici quelques propositions, à vous de compléter ou de voter pour un nom ou plusieurs noms:
* Concerto
* Orchestra

D'après les derniers sondage, '''Orchestra''' serait finalement le nom retenu pour ce logiciel.

=== Principe et fonctionnement ===

Afin de de rendre tout ce système utilisable par le plus grand nombre, il faut être capable de proposer des outils qui vont simplifier la vie de l'utilisateur final ainsi que de l'intégrateur.

Pour cela, il faudra créer un outil soit sous forme de script(s), soit sous forme de programme(s) qui va permettre de réaliser les tâches suivantes:
* Création/gestion d'une bibliothèque de composants '''''Armadeus Ready'''''
* Gestion d'une liste de '''hardware Armadeus'''
* Edition d'un '''système Armadeus'''
* Gestion d'un projet
* Génération automatique du composant '''system''' qui sera implanté dans le FPGA
* Génération automatique d'un banc de tests pour permettre la validation par ModelSim (ou autre logiciel de simulation HDL)
* Génération d'un fichier '''mapping mémoire'''

=== La bibliothèque de composants ===

Pour qu'un composant, c'est-à-dire une IP, soit exploitable par le système, il faut passer par une phase d'intégration qui va permettre de décrire ce composant:
* Nom de l'IP
* Description
* Version
* Identification des fichiers HDL utilisés (VHDL ou Verilog)
* Identification du fichier '''Top''' (le point d'entrée de l'IP)
* Identification des paramètres '''''GENERIC''''' (dans le cas d'une IP en VHDL):
** Type de paramètre (entier, std_logic, etc)
** Valeur par défaut
** Valeurs ou plages de valeurs autorisées
** Description du paramètre
* Identification des signaux Wishbone utilisés par le composant
* Identification du type (maitre ou esclave) et du nombre d'interfaces Wishbone utilisés par ce composant
* Identification des registres internes
** Adresse (Offset par rapport à l'adresse de base)
** Taille (8 ou 16 bits)
** Nom et/ou description

Toutes ces informations seront alors sauvegardées dans un fichier, de préférence dans un format compréhensible et lisible à l'aide de n'importe quel éditeur de texte (XML, ''fichier INI'' ou ''fichier plat'').

Chaque composant identifié par le logiciel se trouvera dans un sous-répertoire (ou dans un fichier archive ?!?) placé dans le répertoire '''Armadeus Components''', chaque sous-répertoire (ou archive) de composant contiendra les données suivantes:
* Le fichier de description du composant '''''Armadeus Ready'''''
* un répertoire '''HDL''' avec les fichiers VHDL/Verilog de l'IP
* un répertoire '''HAL''' avec les fichiers d'un drivers de base (pour Linux ou ''générique'' ?!?)

Le gestionnaire de composants Armadeus doit être capable de réaliser les opérations suivantes:
* Importer un composant ou une liste de composants
* Exporter un composant ou une liste de composants
* Gérer des versions de composants (à voir si cette fonctionnalité est importante/utile)
* Permettre l'ajout/création de composants
* Permettre de supprimer un composant

=== Gestionnaire de plateformes ===

Il faut avoir confiance dans l'avenir, pour l'instant nous ne disposons que d'une seul plateforme de travail, mais ce n'est qu'un début et très certainement d'autres cartes à base de l'i.MX et d'un FPGA vont voir le jour.

Il faut donc prévoir d'ores et déjà cette possibilité et proposer un outil qui va permettre de définir une plateforme. Chaque descripteur de plateforme devra fournir les informations suivantes:
* Type de FPGA
* Emplacement (niveau FPGA, c'est-à-dire la broche utilisée), type (sortie i.MX, oscillateur ou quartz) et fréquence (ou plage de fréquence ?!?) des horloges
* Emplacements/broche du FPGA utilisées ainsi que leur fonctionnalité (signal Wishbone, comme d'un composant externe, signal d'interruption, etc.)

Toutes ces informations seront utilisées par la suite lors de la création d'un projet '''Orchestra/Armadeus'''.

=== Gestionnaire de projet ===

Le rôle du gestionnaire de projet est de permettre de créer, reprendre ou modifier le plus simplement possible une configuration du FPGA pour une carte donnée. Cette configuration sera appelée par la suite un '''système'''.

Tout '''système''' est entièrement décrit par un fichier projet qui contiendra les éléments suivants:
* Le nom du système (éventuellement le même que le nom du projet ?!?)
* Une description du système
* Le type de plateforme utilisé pour ce système
* La source de la fréquence d'horloge du bus Wishbone (broche du FPGA ou DLL/DCM). On pourra éventuellement imaginer la création d'un ''Wizard'' pour simplifier la configuration du DCM.
* La liste de tous les composants '''Armadeus Ready''' inclus dans le système, avec pour chacun de ces composants, les détails suivantes:
** La référence du composant (par rapport à la bibliothèque de composants '''Armadeus Ready''')
** Le nom de l'instance du composant (e.g. UART1, PWM_MOTOR, etc.)
** La connexion des entrées/sorties (vers une broche du FPGA, non utilisé ou relié '''manuellement''')
** L'adresse du base de chacune de ses interfaces esclaves connectées au bus Wishbone
** La valeur de chaque paramètre '''GENERIC''' du composant
** L'horloge utilisée (pour l'instant ce sera toujours celle du bus Wishbone mais peut-être que plus tard ce ne sera plus forcément le cas ;-) )
** Le numéro d'interruption attribué au composant, s'il est capable de généré une demande d'interruption

Comme pour le fichier de description d'un composant Armadeus, le fichier projet devra être dans un format texte compréhensible et lisible à l'aide de n'importe quel éditeur texte (XML, ''fichier INI'' ou ''fichier plat'').

Le fichier projet est le coeur du système et, à partir de celui-ci ainsi que de la librairie de composants '''Armadeus Ready''' + la librairie de plateforme, toute la partie liée au FPGA doit pouvoir être recrée. Bref c'est le seul fichier dont l'utilisateur final aura à ce soucier (sauvegarde, archivage, etc).

Lors de la création d'un nouveau projet, l'utilisateur devra fournir les éléments de base suivants:
* Le nom du système
* Une description
* Le type de plateforme utilisé
* La source de l'horloge Wishbone (broche du FPGA ou DCM) avec éventuellement un ''wizard'' pour la saisie des informations relatives à la programmation du DCM.
* La fréquence du bus Wishbone (éventuellement obtenue automatiquement à partir de la sélection de la source de l'horloge)
* Le nombre de sources d'interruptions autorisées ainsi que l'emplacement en mémoire des registres du gestionnaire d'interruption (par défaut à l'adresse 0x0000).

Une fois que le projet aura été créer, les composants suivants seront ajouté automatiquement au système:
* Un '''Wrapper i.MX''' pour faire le lien avec l'i.MX
* Un '''syscon''' pour la générations des signaux '''CLK''' et '''RESET''' du bus Wishbone
* Un '''Gestionnaire d'interruptions''' si le système doit être capable de remonter des demandes d'interruption.

Par la suite, l'utilisateur pourra modifier le système de base à l'aide des opérations suivantes:
* choisir dans la librairie un composant pour l'ajouter au système
* modifier les paramètres d'un composant du système
* modifier les caractéristiques du projet (nom, fréquence du bus Wishbone, etc.)
* supprimer un composant du système
* attribution automatique des adresses de base sur le bus Wishbone
* attribution automatique des numéros d'interruption
* annulation des dernières modifications (éventuellement)
* sauvegarde/restauration d'un fichier projet

=== Générateur de fichiers ===

C'est ici que va se trouver la partie la plus ardue du projet '''Orchestra''', et c'est en fonction de ce que l'on sera capable de proposer à l'utilisateur final que se fera l'adhésion au projet ou non.

Une fois que l'on aura créer son projet/système Armadeus, il faut encore pouvoir générer au minimum le fichier '''bitstream''' qui va être utiliser pour configurer le FPGA.

C'est ici qu'entre en jeu le générateur de fichiers, qui devra être capable, à l'aide du fichier projet + la librairie de composant + la librairie de plateforme, de générer le fichiers suivants:
* un fichier HDL '''Intercon''' reliant tous les composants placés dans le système qui a été créé par l'utilisateur
* un fichier HDL '''system''' qui va englober tout le système Wishbone tel qu'il a été défini par l'utilisateur
* un fichier HDL '''system_tb''' et un fichier '''.DO''' qui vont pouvoir être utilisés pour la simulation à partir de ModelSim
* un fichier '''system.h''' qui va contenir le plan mémoire du système créé
* un fichier '''tcl''' qui va permettre de créer entièrement et de manière automatique le projet dans l'environnement '''Xilinx ISE''', c'est-à-dire:
** sélection du bon FPGA
** sélection du bon format de sortie (bitstream)
** saisie du pinout du FPGA (nom de chaque broche par rapport au nom du signal sur le schéma)
** programmation du DCM le cas échéant
** définition des signaux d'horloge
** inclusion des fichiers HDL nécessaires au projet
** instanciation du fichier HDL '''sytem'''
** connexion des entrées et sorties du composant '''system'''

Comme on peut le voir, le travail pour '''Orchestra''' ne manque pas, reste encore la question du mode de développement ainsi que du langage et la bibliothèque graphique.

Mais ceci est encore une autre histoire, qui pourra être débattu lorsque les premières composants système seront prêt à l'emploi... Peut-être très bientôt :-)

== Gestionnaire d'interruption ==

'''Ce chapitre est donné à titre informatif/propositon et ne tiens pas lieu de spécification.'''

Afin de simplifier la vie des programmeurs systèmes, il faut pouvoir offrir un mécanisme simple de mise en place et de gestion des demandes d'interruption du FPGA.

Pour cela, je propose la solution suivante:
* Mise en place d'un gestionnaire d'interruption générique pour le FPGA. Ce gestionnaire d'interruption sera capable de lire le registre d'interruption (lecture de '''isr_pend''') et de déterminer les interruptions à traiter (via '''isr_mask'''). Il va en suite aiguiller l'exécution de la routine d'interruption vers les routines adéquates pour chaque bit d'interruption valide. L'interruption traitée sera alors acquitée (écriture vers '''isr_pend''').
* Création d'une routine '''''d'enregistrement de vecteur d'interruption'''''. Cette routine va permettre d'ajouter une routine de traitement d'interruption pour un bit d'interruption donné. Pour cela il faudra lui fournir les informations suivantes (via une structure ?!?):
** Le numéro du bit d'interruption (0 à 31)
** La routine de traitement d'interruption pour ce driver
** Un paramètre additionnel à fournir à la routine de traitement d'interruption (pointeur de type '''''void *''''')
** Le nom du drivers (optionnel, permet d'identifier/visualiser les drivers installer éventuellement)
* Création d'une routine de validation d'une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine pour masquer une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine pour désinstaller une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine ou méthode pour visualiser tous les drivers Wishbone installés:
** Leur numéro
** Leur nom
** Leur état (validé/masqué)
** Le nombre de fois qu'ils ont été appelé
** etc.

FpgaArchitecture

2008-01-06T21:54:13Z

SonZerro: /* Le bus Wishbone */

= Spécifications de conception du FPGA =

== Evolutions ==

2006/12/29: MAJ de la partie 1.7 pour décrire plus en détail le programme d'assemblage des IP (Orchestra)

2006/12/21: MAJ en fonction des remarques de tout le monde.

== But ==

Cette page a été créée pour permettre à tous les membres de l'association de discuter de l'architecture qui va être mise en place pour le FPGA présent sur la carte APF9328.

Cette espace doit être vu comme un espace d'échange d'idées. Tout le monde est convié à y participer. Il est préférable d'avoir quelques connaissances en électronique et sur les langages HDL (VHDL ou Verilog), mais ce n'est pas une obligation.

Bonne lecture et merci pour votre participation.

== Les grandes lignes ==

Le FPGA de la carte APF9328 est là pour offrir le maximum de souplesse au projet '''Armadeus''' et permettre d'implanter des fonctionnalités coté '''matériel''' qui seraient trop pénalisantes ou impossibles à implanter coté '''logiciel'''. Bien entendu, pour que cela soit exploitable, il faut également disposer d'un lien entre le FPGA et le processeur i.MX.

Pour réaliser cela, il faut mettre en place un bus de communication entre le FPGA et l'i.MX. Ce bus de communication va permettre le pilotage des fonctionnalités qui seront implantées dans le FPGA. Bref, il faut recréer à l'intérieur du FPGA un bus tel qu'il existe entre l'i.MX et les différents composants de la carte (RAM, Flash, USB, Ethernet, etc.).

Pour gagner en temps de développement et pour pouvoir récupérer des fonctionnalités ou IP (Intellectual Property) déjà existantes, le bus Wishbone a été retenu. Ce bus, dont les spécification ont été placées dans le domaine public, a été conçu spécifiquement pour ce genre de configuration et sur le site '''[http://www.opencores.com www.opencores.com]''' plusieurs IP compatibles avec les spécifications Wishbone sont disponibles.

== Le bus Wishbone ==

(add list of the signals of the wishbone bus here)

(add references to documentation)

La spécification Wishbone décrit un certain nombre de composants de base:
* Des interfaces '''maitres''', ces interfaces sont implantés dans des composants qui seront alors capable d'initier les transferts sur le bus Wishbone
* Des interfaces '''esclaves''', ces interfaces sont implantés dans des composants capables de répondre à des demandes de transferts
* Un composant '''syscon''', ce composant va générer le signal d'horloge qui sera utilisé par tous les composants/interfaces du bus ainsi que le signal de RESET synchrone.
* Un macro composant '''intercon''', ce composant va gérer la connexion de toutes les interfaces maitres et esclaves qui composent le bus interne. Il prend en charge :
** Le décodage/transcodage d'adresse (génération des signaux A0 à A3 selon le mode d'adressage 8/16/32/64 bits)
** le routage du bus de données entre les différentes interfaces maitres et esclaves (conversion big endian/little endian, etc)
** le routage/génération des signaux de contrôle du bus (Read, Write, Chip Select, Output Enable, ACK, etc.)
* Un composant '''arbitre''', ce composant va permettre de partager l'accès au bus ou à un composant de type esclave qui est partagé par plusieurs composants de type maitre.

Les spécifications du bus Wishbone permettent de créer différents types de bus:
* '''Point to Point''': C'est le type de bus le plus simple possible, un composant avec une interface type maitre connecté à un composant avec une interface de type esclave.
* '''Data Flow''': C'est un bus en cascade, à un bout on trouve un composant avec une interface de type maître et à l'autre bout un composant avec une interface de type esclave. Entre les deux composant se trouve une chaine d'un ou plusieurs composants avec une interface de type maitre et de type esclave.
* '''Shared''': C'est un bus sur lequel plusieurs composants sont connectés dessus. Tous les composants se partagent ce bus. Si plusieurs ''maitres'' sont connectés sur ce bus, un seul pourra initier un transfert à un instant donné.
* '''CrossBar''': C'est également un bus de type partagé, par contre dans se cas, on dispose de plusieurs bus. Chaque maitre utilise sont propre bus pour communiquer avec ces esclaves. On peut donc avoir plusieurs transferts en simultané. Le seul cas de blocage/arbitrage est le transfert de plusieurs maitre avec le même esclave.

Il existe également un certain nombre de mécanismes dans la spécification Wishbone pour permettre d'optimiser les temps de transferts sur le bus. Ces optimisations sont de plusieurs nature:
* utilisation de signaux '''ACK''', '''ERR''' et '''RTY''' pour signaler la fin de transfert
* les '''Registered Feedback Bus Cycles''', qui permettent de gagner un cycle d'horloge pour des transferts consécutifs
* les transferts en mode '''Burst'''

== Le lien i.MX <=> FPGA ==

La communication entre l'i.MX et le FPGA passe par les signaux suivants (à vérifier):
* des signaux de contrôle: <strike>RW_n</strike>, OE_n, EB_n[3..2] et CS1_n
* le bus de données sur 16 bits (D[15..0])
* le bus d'adresses sur 12 bits (A[12..1])

Ces signaux sont alors utilisés pour créer une interface Wishbone maitre qui va permettre de communiquer efficacement avec les autres IPs contenus dans le FPGA qui implémenterons une interface wishbone de type esclave.

Etant donné les erratas du composant i.MX concernant le signal DTACK, il n'est pas possible d'implanter une interface Wishbone maitre ''classique''. Ceci entraine les limitations suivantes:
* Pas possible d'utiliser le signal '''ACK''' Wishbone pour terminer le transfert entre FPGA et i.MX.
* Pas possible de mettre en place des optimisations du temps de transfert.

Pour contrer ce problème, il faudra s'assurer que toutes les interfaces esclaves qui seront connectées à l'interface maitre du composant Wishbone i.MX répondent dans un temps fixe donné.<br />
Comme le bus Wishbone est un bus entièrement synchrone, le temps minimal d'un transfert est de 2 cycles de l'horloge Wishbone. Il faut ajouter à cela, un cycle pour la synchronisation des signaux du bus i.MX. Cela nous fait donc un minimum de 3 cycles Wishbone pour un transfert entre le FPGA et l'i.MX.

Etant donné les performances des FPGA actuels, on peut tabler sur une fréquence de fonctionnement d'au moins 100MHz pour le bus Wishbone. Cela nous donne donc un taux de transfert approximatif de 66 Moctets/sec (100MHz * 16bits / 3).

== La composition du système Wishbone ==

[[Image:FPGA_Armadeus.png]]

Le système Wishbone qui sera implanté dans le FPGA se compose des éléments suivants:
* '''i.MX Wrapper''': L'interface i.MX vers le bus Wishbone
* '''Syscon''': Ce composant va gérer les signaux '''CLK''' (généré par une PLL ou directement issu de l'i.MX) et '''RESET''' (synchrone).
* '''Intercon''': Ce composant devra être généré automatiquement par une moulinette, il va faire le lien entre tous les composants faisant parti du '''Système Wishbone'''.
* '''Gestionnaire d'interruption''': Ce composant est un '''esclave wishbone''' et va centraliser toutes les demandes d'interruption et les remonter vers l'i.MX.
* '''Esclaves whisbone''': Ceci représentent tous les autres composants avec une interface wishbone esclave qui sont accessibles via le wrapper i.MX.

Sur le diagramme, il manque un certain nombre de choses:
* Les signaux ''non wishbone'' en entrée ou en sortie sur les '''esclaves wishbone'''
* Le macro composant '''système wishbone'''. Ce macro composant est celui qui sera ensuite instancié dans le design du FPGA. Sur ce composant ne seront visibles que les signaux ''externes'' au système:
** Les signaux issus de l'i.MX
** <strike>Le signal RESET (en entrée) qui sera synchronisé sur l'horloge système</strike> Le signal RESET synchrone du bus Wishbone sera directement généré par le composant syscon à l'aide d'une simple machine d'état.
** Le signal CLK (en entrée) qui sera l'horloge utilisée pour la génération des signaux Wishbone
** Le signal IRQ (en sortie) qui sera utilisé pour remonter les demandes d'interruption vers l'i.MX
** Les signaux d'entrée et de sortie spécifiques aux autres composants connectés sur le bus Wishbone

L'intérêt de créer le composant '''Système Wishbone''', est que cela simplifie la vision dans l'outil conception du FPGA. Il ne suffit plus alors qu'à relier les signaux sur les broches correspondantes du FPGA.

=== i.MX Wrapper ===

Ce composant est le point d'accès au bus Wishbone pour l'i.MX et sera le seul à disposer d'une interface Wishbone maitre.

Les fonctions de ce composants sont:
* synchronisation des signaux issus de l'i.MX. Ceci est primordial pour assurer la stabilité de tout le système Wishbone. De plus, le bus de sortie étant asynchrone (l'horloge de génération des signaux n'est pas véhiculée), la resynchronisation des signaux par rapport à l'horloge du bus s'impose.
* gestion du bus de données en 3 états.
* conversion des signaux de contrôle du bus i.MX en signaux Wishbone.

=== Syscom ===

C'est le composant le plus simple du système <strike>, il ne fait que synchroniser le signal RESET en entrée avec le signal d'horloge du système</strike>.

Il va être en charge de la génération du signal RESET synchrone pour le bus Wishbone.

Le signal d'horloge en entrée du composant '''syscon''' sera celui utilisé pour le fonctionnement du bus Wishbone. La fréquence du signal d'horloge devra être assez élevée pour permettre le traitement des signaux issus de l'i.MX. Cela va dépendre de la configuration du chip select utilisé (CS1).

La source du signal d'horloge reste encore à définir, les choix possibles sont:
* directement issu de l'i.MX
* utilisation d'un DCM du Spartan 3

Le choix définitif dépendra principalement des essais ''grandeur nature'' lors de la génération des premiers systèmes whisbone durant la phase de mise en place des composants de base.

=== Intercon ===

Ce composant a la particularité qu'il sera créé automatiquement par un outil (script ou programme). '''Intercom''' a comme fonctionnalités:
* Le décodage d'adresse pour la sélection des différents esclaves du système
* Le routage des bus d'adresses et de données vers les différents esclaves
* La génération des signaux de contrôle pour les différents esclaves.

Etant donné les limitations induites par les erratas de l'i.MX, le composant '''intercom''' remplira les fonctionnalités suivantes:
* le bus de données est figé sur 16 bits
* les cycles de lecture et d'écriture sont de longueur fixe (à priori 3 cycles d'horloge '''à valider''' lors des essais du système de base)
* une interruption est générée en cas de dépassement du temps de cycle d'écriture ou de lecture
* le bus sera de type '''shared''' avec un seul maitre (le Wrapper i.MX).

=== Les composants esclaves ===

<span style="color:#FF0000;">
<big>Suite aux divers discussions issues de ce chapitre. L'organisation et la présences des fichiers dans les répertoires '''doc''' et '''HAL''' n'est pas encore établie. Ce chapitre sera encore à retravailler.</big>
</span>

Pour qu'une IP puisse être facilement inclue dans le système, il faut une certaine organisation. Sinon, à moyen ou à long terme cette IP est morte parce qu'elle sera difficilement exploitable et encore plus difficilement maintenable.

Ce sont des notions qui ne sont pas simples à prendre en considération lors du développement d'un nouveau projet, mais lorsque l'on doit se replonger dans un travail fait par quelqu'un d'autre ou un projet qu'on a laissé en sommeil pendant quelque temps, on est content d'avoir quelque chose à quoi se raccrocher.

Pour développer efficacement, il faut assurer une organisation logique, figée et compréhensible, et le plus simple dans ce genre de cas est de se baser sur la notion de répertoire. Voici les répertoires qui doivent être utilisés par une IP:
* '''doc''': Ce répertoire va contenir toute la documentation nécessaire à l'exploitation de l'IP. On y trouvera une notice ('''readme.txt'''), un fichier de suivi de modification ('''ChangeLog.txt'''), un fichier contenant les évolutions futures prévues ('''todo.txt''') ainsi que tout autre fichier estimé utile par le(s) créateur(s) de l'IP.
* '''hdl''': Ce répertoire va contenir tous les fichiers VHDL (ou Verilog) qui auront été développés spécifiquement pour cette IP.
* '''inc''': Ce répertoire va contenir un fichier d'en-tête ANSI C contenant l'adresse de tous les registres interne de l'IP pour permettre de créer simplement un programme en langage C permettant de contrôler l'IP. '''''Ce répertoire est optionnel et ne s'applique évidement qu'à des IPs ayant une interface de type Wishbone.'''''
* '''HAL''': Ce répertoire va contenir un drivers ou un exemple de logiciel de base permettant l'utilisation de l'IP par un microprocesseur/contrôleur. '''''Ce répertoire est optionnel et ne s'applique évidement qu'à des IPs ayant une interface de type Wishbone.'''''

=== Gestionnaire d'interruption ===

Ce composant esclave est le premier qui sera créé spécifiquement pour le système. Il sera capable de:
* prendre en compte jusqu'à 16 sources d'interruptions différentes
* réaliser l'acquittement de chaque interruption individuellement
* masquer/autoriser chaque interruption individuellement

Le composant disposera des registres suivants:
* '''isr_mask''': registre d'autorisation des interruptions. Chaque bit correspond à une interruption (bit0 => IRQ0, bit1 => IRQ1, etc.). Ce registre sera accessible en lecture et en écriture.
* '''isr_pend''': ce registre est à double emploi
** '''en lecture''': Les interruptions en attente de traitement
** '''en écriture''': Acquittement des interruptions. Chaque bit à 1 va acquitter l'interruption correspondante.

== Le script / programme d'assemblage des IP ==

Nous allons maintenant parler du coeur du système, du moins de la partie la plus visible de l'iceberg ;-)

La première des priorités, sera de trouver un nom pour cet outil qui reste un peu dans l'esprit du projet. Voici quelques propositions, à vous de compléter ou de voter pour un nom ou plusieurs noms:
* Concerto
* Orchestra

D'après les derniers sondage, '''Orchestra''' serait finalement le nom retenu pour ce logiciel.

=== Principe et fonctionnement ===

Afin de de rendre tout ce système utilisable par le plus grand nombre, il faut être capable de proposer des outils qui vont simplifier la vie de l'utilisateur final ainsi que de l'intégrateur.

Pour cela, il faudra créer un outil soit sous forme de script(s), soit sous forme de programme(s) qui va permettre de réaliser les tâches suivantes:
* Création/gestion d'une bibliothèque de composants '''''Armadeus Ready'''''
* Gestion d'une liste de '''hardware Armadeus'''
* Edition d'un '''système Armadeus'''
* Gestion d'un projet
* Génération automatique du composant '''system''' qui sera implanté dans le FPGA
* Génération automatique d'un banc de tests pour permettre la validation par ModelSim (ou autre logiciel de simulation HDL)
* Génération d'un fichier '''mapping mémoire'''

=== La bibliothèque de composants ===

Pour qu'un composant, c'est-à-dire une IP, soit exploitable par le système, il faut passer par une phase d'intégration qui va permettre de décrire ce composant:
* Nom de l'IP
* Description
* Version
* Identification des fichiers HDL utilisés (VHDL ou Verilog)
* Identification du fichier '''Top''' (le point d'entrée de l'IP)
* Identification des paramètres '''''GENERIC''''' (dans le cas d'une IP en VHDL):
** Type de paramètre (entier, std_logic, etc)
** Valeur par défaut
** Valeurs ou plages de valeurs autorisées
** Description du paramètre
* Identification des signaux Wishbone utilisés par le composant
* Identification du type (maitre ou esclave) et du nombre d'interfaces Wishbone utilisés par ce composant
* Identification des registres internes
** Adresse (Offset par rapport à l'adresse de base)
** Taille (8 ou 16 bits)
** Nom et/ou description

Toutes ces informations seront alors sauvegardées dans un fichier, de préférence dans un format compréhensible et lisible à l'aide de n'importe quel éditeur de texte (XML, ''fichier INI'' ou ''fichier plat'').

Chaque composant identifié par le logiciel se trouvera dans un sous-répertoire (ou dans un fichier archive ?!?) placé dans le répertoire '''Armadeus Components''', chaque sous-répertoire (ou archive) de composant contiendra les données suivantes:
* Le fichier de description du composant '''''Armadeus Ready'''''
* un répertoire '''HDL''' avec les fichiers VHDL/Verilog de l'IP
* un répertoire '''HAL''' avec les fichiers d'un drivers de base (pour Linux ou ''générique'' ?!?)

Le gestionnaire de composants Armadeus doit être capable de réaliser les opérations suivantes:
* Importer un composant ou une liste de composants
* Exporter un composant ou une liste de composants
* Gérer des versions de composants (à voir si cette fonctionnalité est importante/utile)
* Permettre l'ajout/création de composants
* Permettre de supprimer un composant

=== Gestionnaire de plateformes ===

Il faut avoir confiance dans l'avenir, pour l'instant nous ne disposons que d'une seul plateforme de travail, mais ce n'est qu'un début et très certainement d'autres cartes à base de l'i.MX et d'un FPGA vont voir le jour.

Il faut donc prévoir d'ores et déjà cette possibilité et proposer un outil qui va permettre de définir une plateforme. Chaque descripteur de plateforme devra fournir les informations suivantes:
* Type de FPGA
* Emplacement (niveau FPGA, c'est-à-dire la broche utilisée), type (sortie i.MX, oscillateur ou quartz) et fréquence (ou plage de fréquence ?!?) des horloges
* Emplacements/broche du FPGA utilisées ainsi que leur fonctionnalité (signal Wishbone, comme d'un composant externe, signal d'interruption, etc.)

Toutes ces informations seront utilisées par la suite lors de la création d'un projet '''Orchestra/Armadeus'''.

=== Gestionnaire de projet ===

Le rôle du gestionnaire de projet est de permettre de créer, reprendre ou modifier le plus simplement possible une configuration du FPGA pour une carte donnée. Cette configuration sera appelée par la suite un '''système'''.

Tout '''système''' est entièrement décrit par un fichier projet qui contiendra les éléments suivants:
* Le nom du système (éventuellement le même que le nom du projet ?!?)
* Une description du système
* Le type de plateforme utilisé pour ce système
* La source de la fréquence d'horloge du bus Wishbone (broche du FPGA ou DLL/DCM). On pourra éventuellement imaginer la création d'un ''Wizard'' pour simplifier la configuration du DCM.
* La liste de tous les composants '''Armadeus Ready''' inclus dans le système, avec pour chacun de ces composants, les détails suivantes:
** La référence du composant (par rapport à la bibliothèque de composants '''Armadeus Ready''')
** Le nom de l'instance du composant (e.g. UART1, PWM_MOTOR, etc.)
** La connexion des entrées/sorties (vers une broche du FPGA, non utilisé ou relié '''manuellement''')
** L'adresse du base de chacune de ses interfaces esclaves connectées au bus Wishbone
** La valeur de chaque paramètre '''GENERIC''' du composant
** L'horloge utilisée (pour l'instant ce sera toujours celle du bus Wishbone mais peut-être que plus tard ce ne sera plus forcément le cas ;-) )
** Le numéro d'interruption attribué au composant, s'il est capable de généré une demande d'interruption

Comme pour le fichier de description d'un composant Armadeus, le fichier projet devra être dans un format texte compréhensible et lisible à l'aide de n'importe quel éditeur texte (XML, ''fichier INI'' ou ''fichier plat'').

Le fichier projet est le coeur du système et, à partir de celui-ci ainsi que de la librairie de composants '''Armadeus Ready''' + la librairie de plateforme, toute la partie liée au FPGA doit pouvoir être recrée. Bref c'est le seul fichier dont l'utilisateur final aura à ce soucier (sauvegarde, archivage, etc).

Lors de la création d'un nouveau projet, l'utilisateur devra fournir les éléments de base suivants:
* Le nom du système
* Une description
* Le type de plateforme utilisé
* La source de l'horloge Wishbone (broche du FPGA ou DCM) avec éventuellement un ''wizard'' pour la saisie des informations relatives à la programmation du DCM.
* La fréquence du bus Wishbone (éventuellement obtenue automatiquement à partir de la sélection de la source de l'horloge)
* Le nombre de sources d'interruptions autorisées ainsi que l'emplacement en mémoire des registres du gestionnaire d'interruption (par défaut à l'adresse 0x0000).

Une fois que le projet aura été créer, les composants suivants seront ajouté automatiquement au système:
* Un '''Wrapper i.MX''' pour faire le lien avec l'i.MX
* Un '''syscon''' pour la générations des signaux '''CLK''' et '''RESET''' du bus Wishbone
* Un '''Gestionnaire d'interruptions''' si le système doit être capable de remonter des demandes d'interruption.

Par la suite, l'utilisateur pourra modifier le système de base à l'aide des opérations suivantes:
* choisir dans la librairie un composant pour l'ajouter au système
* modifier les paramètres d'un composant du système
* modifier les caractéristiques du projet (nom, fréquence du bus Wishbone, etc.)
* supprimer un composant du système
* attribution automatique des adresses de base sur le bus Wishbone
* attribution automatique des numéros d'interruption
* annulation des dernières modifications (éventuellement)
* sauvegarde/restauration d'un fichier projet

=== Générateur de fichiers ===

C'est ici que va se trouver la partie la plus ardue du projet '''Orchestra''', et c'est en fonction de ce que l'on sera capable de proposer à l'utilisateur final que se fera l'adhésion au projet ou non.

Une fois que l'on aura créer son projet/système Armadeus, il faut encore pouvoir générer au minimum le fichier '''bitstream''' qui va être utiliser pour configurer le FPGA.

C'est ici qu'entre en jeu le générateur de fichiers, qui devra être capable, à l'aide du fichier projet + la librairie de composant + la librairie de plateforme, de générer le fichiers suivants:
* un fichier HDL '''Intercon''' reliant tous les composants placés dans le système qui a été créé par l'utilisateur
* un fichier HDL '''system''' qui va englober tout le système Wishbone tel qu'il a été défini par l'utilisateur
* un fichier HDL '''system_tb''' et un fichier '''.DO''' qui vont pouvoir être utilisés pour la simulation à partir de ModelSim
* un fichier '''system.h''' qui va contenir le plan mémoire du système créé
* un fichier '''tcl''' qui va permettre de créer entièrement et de manière automatique le projet dans l'environnement '''Xilinx ISE''', c'est-à-dire:
** sélection du bon FPGA
** sélection du bon format de sortie (bitstream)
** saisie du pinout du FPGA (nom de chaque broche par rapport au nom du signal sur le schéma)
** programmation du DCM le cas échéant
** définition des signaux d'horloge
** inclusion des fichiers HDL nécessaires au projet
** instanciation du fichier HDL '''sytem'''
** connexion des entrées et sorties du composant '''system'''

Comme on peut le voir, le travail pour '''Orchestra''' ne manque pas, reste encore la question du mode de développement ainsi que du langage et la bibliothèque graphique.

Mais ceci est encore une autre histoire, qui pourra être débattu lorsque les premières composants système seront prêt à l'emploi... Peut-être très bientôt :-)

== Gestionnaire d'interruption ==

'''Ce chapitre est donné à titre informatif/propositon et ne tiens pas lieu de spécification.'''

Afin de simplifier la vie des programmeurs systèmes, il faut pouvoir offrir un mécanisme simple de mise en place et de gestion des demandes d'interruption du FPGA.

Pour cela, je propose la solution suivante:
* Mise en place d'un gestionnaire d'interruption générique pour le FPGA. Ce gestionnaire d'interruption sera capable de lire le registre d'interruption (lecture de '''isr_pend''') et de déterminer les interruptions à traiter (via '''isr_mask'''). Il va en suite aiguiller l'exécution de la routine d'interruption vers les routines adéquates pour chaque bit d'interruption valide. L'interruption traitée sera alors acquitée (écriture vers '''isr_pend''').
* Création d'une routine '''''d'enregistrement de vecteur d'interruption'''''. Cette routine va permettre d'ajouter une routine de traitement d'interruption pour un bit d'interruption donné. Pour cela il faudra lui fournir les informations suivantes (via une structure ?!?):
** Le numéro du bit d'interruption (0 à 31)
** La routine de traitement d'interruption pour ce driver
** Un paramètre additionnel à fournir à la routine de traitement d'interruption (pointeur de type '''''void *''''')
** Le nom du drivers (optionnel, permet d'identifier/visualiser les drivers installer éventuellement)
* Création d'une routine de validation d'une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine pour masquer une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine pour désinstaller une ''interruption FPGA'' par son numéro (0 à 31)
* Création d'une routine ou méthode pour visualiser tous les drivers Wishbone installés:
** Leur numéro
** Leur nom
** Leur état (validé/masqué)
** Le nombre de fois qu'ils ont été appelé
** etc.

FPGA

2007-05-21T19:22:21Z

SonZerro: /* Development Software */ italic

==FPGA on APF9328==
The APF9328 is optionally equipped with an Xilinx Spartan-3 FPGA (Field Programmable Gate Array). An FPGA is a configurable digital device. Today, large and complex digital circuits and processor cores fit into FPGAs. To find more information about FPGAs, check the Wikipedia: [http://en.wikipedia.org/wiki/FPGA]

The FPGA on APF9328 is connected to the processor bus of the iMX and to the connector of the APF9328. This makes it possible to design your own peripherals and configure them into the FPGA. Because the FPGA can be reconfigured at any time, it allows you to replace these peripherals (or a part of them), if other functionalities are needed. This is possible even at run-time!

==FPGA Firmware Development==
===Digital Hardware Design===
FPGAs are quite complex digital devices. Modern tools allow to describe the circuits to be implemented an abstract way, which makes it possible to manage the complexity. The trend for new tools is toward higher levels of abstraction in order to be able to manage even more coplex devices in future. Nevertheless, at least basic knowledge of digital circuits and gates is necessary to start designing firmware for FPGAs.

===FPGA Design-Flow===
The starting point for the implementation flow is a description of the functionality in a Hardware Description Language (HDL). One of the most commonly used HDLs is ''VHDL'' (Very High Speed Integrated Circuit Hardware Description Language). VHDL files are plain text files and editing can be done in any editor.

This VHDL circuit description can be simulated to verify the functionality.

If everything is working fine, a tool called ''synthesizer'' is used to translate this HDL description in a hardware netlist. Then this netlist is ''mapped'' onto the FPGA technology. After ''Place and Route'' and ''Bitstream generation'', a configuration file for the FPGA is created (''bitfile'').

For more informations about VHDL and the design flow, see [http://en.wikipedia.org/wiki/VHSIC_Hardware_Description_Language]. This page also contains many examples that show how to describe simple electronic circuits in VHDL.

==Armadeus Firmware Development Environment==
===Development Software===
For FPGA development, you need the ''Xilinx ISE WebPack'' from Xilinx. It can be downloaded for free from the Xilinx homepage
[http://www.xilinx.com/ise/logic_design_prod/webpack.htm]. The WebPack contains all you need to implement a design for the FPGA on the APF9328: Editor, Synthesizer, Mapper, Place and Route Tool, Bitstream generator, and the tools to download a configuration to the FPGA.

For simulation, Xilinx offers a free version of ''ModelSim'', called ''ModelSim Xilinx Edition (MXE)''. It can also be downloaded from the Xilinx homepage [http://www.xilinx.com/ise/optional_prod/mxe.htm] for free, but registration is required in order to receive a license.

===Design Implementation===
Implement your design with the ''ISE WebPack'' software. If you are new to VHDL, the information on [http://en.wikipedia.org/wiki/VHSIC_Hardware_Description_Language] can give you a first idea. Tutorials for the ISE software can be downloaded from the Xilinx homepage [http://www.xilinx.com/support/techsup/tutorials].

===Bitstream generation===
When your design is ready and passes the simulation, you can create a ''bitstream file'' that can be downloaded to the FPGA. It contains all the data to configure the FPGA.

In the ISE Project Manager, make sure that a ''Binary Configuration File'' is also created. You can set this option in the properties dialog of the ''Generate Programming file'' process. Activate the option ''Create Binary Configuration File''.

The file with the ending ''.bin'' is now the file you need to configure the FPGA on the Armadeus module.

===Licence===
The firmware for the FPGA has to be licenced under LGPL and BSD.

Please add to each created file a header containing the name of the "company" here it is an association, the maintainer name, the licence.

If a part of a work of an other developper has been reused, please indicate where this part has been found, the author name and keep the original licence. If no licence is specified, assume it is unlicenced.

===Configuring the FPGA from U-Boot===
See the [[InstallTargetSoftware#FPGA_firmware_installation|InstallTargetSoftware]] page of this wiki.

===Configuring the FPGA from Linux===
See the FPGA loader page [[FPGA loader]] of this wiki for details.

==Links==
* http://www.comelec.enst.fr/hdl
* http://www.fpga4fun.com/

[[Image:FrenchFlag.png]] [[Fr:FPGA|Cette page en français]]

Domotic

2007-05-07T20:31:04Z

SonZerro:

=Building blocks for your armadeus-based home management system=
*[[Boa|Boa (Embedded Webserver)]]
*[[GPIO_Driver]]
*[[ADC_max1027|Analog-Digital Converter]]
*[[DAC|Digital-Analog Converter]]
*[[IR_Receiver]]
*[[Wireless interface]]

MemberList

2007-04-01T23:33:38Z

SonZerro:

==Here is the list of the members and their skills==

*0: Novice
*1: Notions. At least one successfull experiment
*2: Confirmed

{|border=1 summary="Member list"
|----------------
| '''Name''' || '''Linux Apps'''|| '''Linux Drivers'''|| '''FPGA''' || '''Board Design''' || '''Projet/Domain'''
|----------------
|[[User:Salocin68|Nicolas Colombain]] || 1 || 1 || 1 || 2 || domotics
|----------------
|[[User:JulienB|Julien Boibessot]] || 2 || 2 || 0 || 1 || multimedia
|----------------
|[[User:JeanBaptisteM|Jean-Baptiste Mayer]] || 2 || 1 || 1 || 1 || robotics
|----------------
|[[User:NicolasA|Nicolas Aguirre]] || 2 || 0 || 1 || 1 || multimedia
|----------------
|[[User:BenoitC|Benoît Canet]] || 2 || 0 || 0 || 0 || multimedia
|----------------
|[[User:SonZerro|Sonzerro]] || 0 || 0 || 1 || 2 || domotics
|----------------
|[[User:HenriG|Henri Geist]] || 1 || 1 || 0 || 1 || robotics
|----------------
|[[User:BorredonB|Bernard Borredon]] || 2 || 1 || 0 || 1 || domotics
|----------------
|}

MemberList

2007-04-01T21:21:34Z

SonZerro:

MTF-T035

2007-03-26T20:52:13Z

SonZerro: /* LCD orders */

== TFT Specifications ==
The MTF-T035 320x240 3.5" color TFT display from Microtips is the default TFT display supported.
Two pin compatible versions are available. One with touchscreen (analog outputs) and one without.
The MTF-T035 is provided with a 4 white led backlight.

The specification can be found here:
[http://www.microtipsusa.com/product_pdfs/Color%20TFT/MTF-T035DHSLP-A%20(24BIT,%20parallel,%20external%20BL%20control,%20anti-glare,%20TP).pdf]

Some photos are although available here:
[[Board Pictures]]

== Adapter Board ==
This kind of LCD requires an adapter board.
The small board generates the required bias voltages, integrates a white led driver and provides a standard 2.54 connector interface.
It has to be noted that a simple 3.3V supply must be used.

The <strong>schematics</strong> can be found here:
[http://www.armadeus.com/downloads/lcd_adapt_MTFT035/schematics.pdf]

The <strong>assembly drawings</strong> can be found here:
[http://www.armadeus.com/downloads/lcd_adapt_MTFT035/assembly.pdf]

Note that the pin 1 of the connectors are although written in the top layer copper.

== Connections with the DevLight ==
Just connect signals with same names together. <strong>Use only short wires !</strong>

The DevLight schematics and specification may be usefull:
[http://www.armadeus.com/products_APF9328DevLight.html]

Once done verify the connections by means of your multimeter.
<strong>Do not forget to check the 3.3V supply polarity on the LCD_adapt board before to power up the system !</strong>

== LCD orders ==
Please add your name and the LCD type you want to the list below.
On order will be placed in two/three weeks.
The production of the LCD Adapter board has been launched.
Expected delivery date: Week 17/18

*Rachid Koucha: 1x LCD_Touchscreen
*ThomasB: 1x LCD (with or without touchscreen)??
*Sonzerro: 1x LCD_Touchscreen
*Olivier Coutanceau: 1x LCD_Touchscreen
*Arnaud Coffinet : 1x LCD_Touchscreen
*Henri Geist : 1x LCD_Touchscreen
*JulienB: 1x LCD_Touchscreen

MTF-T035

2007-03-26T20:51:35Z

SonZerro: /* LCD orders */ now it's clear

== TFT Specifications ==
The MTF-T035 320x240 3.5" color TFT display from Microtips is the default TFT display supported.
Two pin compatible versions are available. One with touchscreen (analog outputs) and one without.
The MTF-T035 is provided with a 4 white led backlight.

The specification can be found here:
[http://www.microtipsusa.com/product_pdfs/Color%20TFT/MTF-T035DHSLP-A%20(24BIT,%20parallel,%20external%20BL%20control,%20anti-glare,%20TP).pdf]

Some photos are although available here:
[[Board Pictures]]

== Adapter Board ==
This kind of LCD requires an adapter board.
The small board generates the required bias voltages, integrates a white led driver and provides a standard 2.54 connector interface.
It has to be noted that a simple 3.3V supply must be used.

The <strong>schematics</strong> can be found here:
[http://www.armadeus.com/downloads/lcd_adapt_MTFT035/schematics.pdf]

The <strong>assembly drawings</strong> can be found here:
[http://www.armadeus.com/downloads/lcd_adapt_MTFT035/assembly.pdf]

Note that the pin 1 of the connectors are although written in the top layer copper.

== Connections with the DevLight ==
Just connect signals with same names together. <strong>Use only short wires !</strong>

The DevLight schematics and specification may be usefull:
[http://www.armadeus.com/products_APF9328DevLight.html]

Once done verify the connections by means of your multimeter.
<strong>Do not forget to check the 3.3V supply polarity on the LCD_adapt board before to power up the system !</strong>

== LCD orders ==
Please add your name and the LCD type you want to the list below.
On order will be placed in two/three weeks.
The production of the LCD Adapter board has been launched.
Expected delivery date: Week 17/18

*Rachid Koucha: 1x LCD_Touchscreen
*ThomasB: 1x LCD (with or without touchscreen)??
*Michael Lerjen: 1x LCD_Touchscreen
*Olivier Coutanceau: 1x LCD_Touchscreen
*Arnaud Coffinet : 1x LCD_Touchscreen
*Henri Geist : 1x LCD_Touchscreen
*JulienB: 1x LCD_Touchscreen

MTF-T035

2007-03-26T20:51:19Z

SonZerro: /* LCD orders */ order

== TFT Specifications ==
The MTF-T035 320x240 3.5" color TFT display from Microtips is the default TFT display supported.
Two pin compatible versions are available. One with touchscreen (analog outputs) and one without.
The MTF-T035 is provided with a 4 white led backlight.

The specification can be found here:
[http://www.microtipsusa.com/product_pdfs/Color%20TFT/MTF-T035DHSLP-A%20(24BIT,%20parallel,%20external%20BL%20control,%20anti-glare,%20TP).pdf]

Some photos are although available here:
[[Board Pictures]]

== Adapter Board ==
This kind of LCD requires an adapter board.
The small board generates the required bias voltages, integrates a white led driver and provides a standard 2.54 connector interface.
It has to be noted that a simple 3.3V supply must be used.

The <strong>schematics</strong> can be found here:
[http://www.armadeus.com/downloads/lcd_adapt_MTFT035/schematics.pdf]

The <strong>assembly drawings</strong> can be found here:
[http://www.armadeus.com/downloads/lcd_adapt_MTFT035/assembly.pdf]

Note that the pin 1 of the connectors are although written in the top layer copper.

== Connections with the DevLight ==
Just connect signals with same names together. <strong>Use only short wires !</strong>

The DevLight schematics and specification may be usefull:
[http://www.armadeus.com/products_APF9328DevLight.html]

Once done verify the connections by means of your multimeter.
<strong>Do not forget to check the 3.3V supply polarity on the LCD_adapt board before to power up the system !</strong>

== LCD orders ==
Please add your name and the LCD type you want to the list below.
On order will be placed in two/three weeks.
The production of the LCD Adapter board has been launched.
Expected delivery date: Week 17/18

*Rachid Koucha: 1x LCD_Touchscreen
*ThomasB: 1x LCD (with or without touchscreen)??
*Michael Lerjen: 1x LCD_Touchscreen??
*Olivier Coutanceau: 1x LCD_Touchscreen
*Arnaud Coffinet : 1x LCD_Touchscreen
*Henri Geist : 1x LCD_Touchscreen
*JulienB: 1x LCD_Touchscreen

MTF-T035

2007-03-26T20:50:04Z

SonZerro: /* Adapter Board */ typo

== TFT Specifications ==
The MTF-T035 320x240 3.5" color TFT display from Microtips is the default TFT display supported.
Two pin compatible versions are available. One with touchscreen (analog outputs) and one without.
The MTF-T035 is provided with a 4 white led backlight.

The specification can be found here:
[http://www.microtipsusa.com/product_pdfs/Color%20TFT/MTF-T035DHSLP-A%20(24BIT,%20parallel,%20external%20BL%20control,%20anti-glare,%20TP).pdf]

Some photos are although available here:
[[Board Pictures]]

== Adapter Board ==
This kind of LCD requires an adapter board.
The small board generates the required bias voltages, integrates a white led driver and provides a standard 2.54 connector interface.
It has to be noted that a simple 3.3V supply must be used.

The <strong>schematics</strong> can be found here:
[http://www.armadeus.com/downloads/lcd_adapt_MTFT035/schematics.pdf]

The <strong>assembly drawings</strong> can be found here:
[http://www.armadeus.com/downloads/lcd_adapt_MTFT035/assembly.pdf]

Note that the pin 1 of the connectors are although written in the top layer copper.

== Connections with the DevLight ==
Just connect signals with same names together. <strong>Use only short wires !</strong>

The DevLight schematics and specification may be usefull:
[http://www.armadeus.com/products_APF9328DevLight.html]

Once done verify the connections by means of your multimeter.
<strong>Do not forget to check the 3.3V supply polarity on the LCD_adapt board before to power up the system !</strong>

== LCD orders ==
Please add your name and the LCD type you want to the list below.
On order will be placed in two/three weeks.
The production of the LCD Adapter board has been launched.
Expected delivery date: Week 17/18

*Rachid Koucha: 1x LCD_Touchscreen
*ThomasB: 1x LCD (with or without touchscreen)??
*Michael Lerjen: 1x LCD (with or without touchscreen)??
*Olivier Coutanceau: 1x LCD_Touchscreen
*Arnaud Coffinet : 1x LCD_Touchscreen
*Henri Geist : 1x LCD_Touchscreen
*JulienB: 1x LCD_Touchscreen

Members

2007-03-26T20:47:56Z

SonZerro: /* Here are the places where the swiss members are living */

==Here are the places where the french members are living==
Work in progress !!

<div style="position: relative">[[Image:France.jpg]]

<div style="position: absolute; left: 350px; top: 250px">
{| style="background:transparent"
|-
| Besançon(1)
|}
</div>
<div style="position: absolute; left: 350px; top: 320px">
{| style="background:transparent"
|-
| Lyon(1)
|}
</div>
<div style="position: absolute; left: 310px; top: 220px">
{| style="background:transparent"
|-
| Dijon(1)
|}
</div>
<div style="position: absolute; left: 400px; top: 180px">
{| style="background:transparent"
|-
| Mulhouse(3)
|}
</div>
<div style="position: absolute; left: 400px; top: 210px">
{| style="background:transparent"
|-
| Montbéliard/Belfort(2)
|}
</div>
<div style="position: absolute; left: 410px; top: 120px">
{| style="background:transparent"
|-
| Strasbourg(2)
|}
</div>
<div style="position: absolute; left: 250px; top: 10px">
{| style="background:transparent"
|-
| Lille(1)
|}
</div>
<div style="position: absolute; left: 250px; top: 70px">
{| style="background:transparent"
|-
| Amiens(1)
|}
</div>
<div style="position: absolute; left: 250px; top: 150px">
{| style="background:transparent"
|-
| Paris(13)
|}
</div>
<div style="position: absolute; left: 300px; top: 120px">
{| style="background:transparent"
|-
| Soisson(1)
|}
</div>
<div style="position: absolute; left: 150px; top: 190px">
{| style="background:transparent"
|-
| Angers(1)
|}
</div>
<div style="position: absolute; left: 180px; top: 170px">
{| style="background:transparent"
|-
| Le Mans(1)
|}
</div>
<div style="position: absolute; left: 250px; top: 480px">
{| style="background:transparent"
|-
| Perpignan(1)
|}
</div>
<div style="position: absolute; left: 350px; top: 450px">
{| style="background:transparent"
|-
| Aix/Marseille(1)
|}
</div>
<div style="position: absolute; left: 200px; top: 400px">
{| style="background:transparent"
|-
| Toulouse(1)
|}
</div>
<div style="position: absolute; left: 200px; top: 350px">
{| style="background:transparent"
|-
| Périgueux(1)
|}
</div>
</div>

==Here are the places where the swiss members are living==
Work in progress !!

<div style="position: relative">[[Image:Suisse.jpg]]

<div style="position: absolute; left: 50px; top: 150px">
{| style="background:transparent"
|-
| Lausanne(1)
|}
</div>

<div style="position: absolute; left: 150px; top: 30px">
{| style="background:transparent"
|-
| Basel(1)
|}
</div>

<div style="position: absolute; left: 220px; top: 50px">
{| style="background:transparent"
|-
| Zürich(1)
|}
</div>

==Here are the places where the belgian members are living==
Work in progress !!

==Here are the places where the german members are living==
* Munich (1)
Work in progress !!

==Here are the places where the irish members are living==
* Dublin(1)
Work in progress !!

FAQ

2006-10-31T22:37:38Z

SonZerro: typos

==General Questions==

===What is the "Armadeus Project" intended for ?===
The goal of this project is to allow everyone to easily develop embedded Open Source systems.
When all the embedded systems in the world will run open source software, life will be better ;-)

===What is the legal status of the project ?===
The Armadeus Project is a french non-profit association (loi 1901) held in Mulhouse, France (68). We accept members from everywhere.
Board production is done by a privately held company.

===What does "Armadeus" mean ?===
"Armadeus" is the contraction of "ARM" and "Amadeus". Indeed we choosed ARM architecture for its symplicity and efficiency and our boards are as gifted to run embedded systems as Mozart was for composing music. Moreover, Armadeus project is born in 2006, year of the 250th Mozart's Birthday.

===How do I become a member ?===
You become a member as soon as you purchase at least one main board (here an APF9328). This will ensure that new members will develop on the same basis. After that you will receive your userid and your password to participate to this Wiki and project activities. Everyone is welcome.

===Why become a member ?===
* Benefit from special prices on the products (the goal of the association is not to make money)
* Participate to the development of new boards
* Increase your experience
* Enjoy working with other developers.

===Restrictions===
* The boards provided by the association can not be used in a commercial product unless this product belongs to the association
* The software/firmware developments realized within the association have to be GPL/LGPL compliant
* The Armadeus Association can not be blamed of the wrong usage or malfunction of the development performed within the association

===How do I get help ?===
First take a look at the whole Wiki. If you can't find help contact us directly: [[Help:Contents]]. If you are located in France, we have members in Besançon, Montbéliard & Mulhouse who can provide you help. For Swiss members, we can provide help in Basel, Lausanne & Zürich.

===Board prices===
* APF9328 wihtout FPGA, ADC and DAC: 75 euros
* FPGA supplement (XC3S200): +20 euros (depending on quantities)
* APF9328 DevLight: 45 euros

Taxes are included to the price but not the shipment
A Paypal account is mandatory

Remarks:
* No accessory (cable, power supply...) is delivered with the boards. You can purchase them by your favorite distributor for a few $
* Grouped orders can be organized for some components like LCDs, special connectors...

==Hardware Questions==

===What does an Armadeus APF9328 board contain ?===
The heart of the APF9328 board is a i.MXL processor from Freescale (ex Motorola) with an ARM920T core running at 200MHz. It has the following integrated peripherals:
* LCD controller (TFT, CSTN, STN)
* USB 1.1 device
* 2 x SPI
* I2C
* 2 x Serial
* MMC/SD controller
* Serial bootstrap mode (removing the need of JTAG interface)
* a lot of General Purpose Input/Output, depending on the configured peripherals

Around this processor, the board is equipped with:
* 16MBytes of high speed SDRAM
* 8MBytes of NOR Flash
* 10/100Mbits Ethernet controller
* Xilinx Spartan3 FPGA (optional)
* an ADC and a DAC (optional)
* level converters for serial, USB and Ethernet
* 2 connectors for accessing main signals

Have a look at this link for more informations: [http://http://www.armadeus.com/downloads/apf9328/documentation/dataSheet_APF9328.pdf]

===What is the DevLight board ?===
APF9328 boards were designed to be as small as possible and ready to be embedded on any systems. So an APF9328 is not usable alone. You should see it much more like a module you can plug in everywhere.
To develop for APF9328 boards you can either develop your own "motherboard" and plug the APF9328 into it or use the one we develop for our needs.
Currently only the DevLight board is available. It contains:
* a serial connector
* an USB connector
* an Ethernet connector
* a prototype zone to test your developments
* a DC power regulator

For more informations look at here:
[http://www.armadeus.com/downloads/apf9328DevLight/documentation/dataSheet_APF9328_DevLight.pdf]

A DevFull board is currently in production and will contain:
* an AC97 + touchscreen chip
* 4 more serial ports
* a MMC connector
* ...

===Are the Armadeus boards RoHS compliant ?===
Yes

==Software Questions==
<br>
<br>

[[Image:FrenchFlag.png]][[Fr:FAQ | Cette page en Français]]

FPGA

2006-10-25T21:07:24Z

SonZerro: typo...

FPGA

2006-10-25T21:05:24Z

SonZerro: Page completed

FPGA

2006-10-22T10:44:25Z

SonZerro:

FPGA

2006-10-22T10:39:47Z

SonZerro:

FPGA

2006-10-22T09:50:41Z

SonZerro: New page: FPGA design flow

Help:Contents

2006-10-22T08:49:02Z

SonZerro:

You are lost/disappointed and require Help ?

* Please first read the [[FAQ]].

* There are some very interesting presentations of Linux usage in embedded context here: http://free-electrons.com

* You can send an email on the mailing list (under construction)

* at last resort, you can contact us directly: '''wiki (at) armadeus (dot) com'''

WindowsInstall

2006-10-18T19:46:53Z

SonZerro: /* Prerequisites for Window$ installation */ put packages in alphabetical order

How-To install Armadeus Software Development Kit for Window$

The toolchain can also be built on a windows system. To do this, Cygwin (a Linux emulation tool) has to be installed first.

==Prerequisites for Window$ installation==

Install cygwin: http://www.cygwin.com
Remark: do not delete the package folder (ftp%xxxx) otherwise the synchronization between the installed packages and the available ones will no more be done !

Choose the default installation (nothing to modify) and add the following packages by clicking one time on the "skip" icon:
* devel -> binutils
* devel -> bison
* devel -> flex
* devel -> gcc-core
* devel -> gcc-g++
* devel -> gdb
* devel -> gettext-devel
* devel -> libncurses-devel
* devel -> make
* devel -> patchutils
* devel -> subversion
* system -> util-linux
* web -> wget

==Installation==

Open a cygwin shell and follow this procedure:

==Get Armadeus software==
$ svn co svn://ericjarrige.homelinux.org/armadeus/trunk armadeus --username <<YOUR USERNAME>> --password <<YOUR PASS>>
A directory named armadeus/ will be created on your hard-disk and will contain all the files you need.

If not, then download installation archive from SourceForge: http://sourceforge.net/projects/armadeus and detar it (tar -xvf filename).

==Configure Armadeus software==
$ cd armadeus/
$ make menuconfig (or just make the first time).
This will launch the buildroot configuration.
in Board Support Option menu, select your armadeus board (apf/apm9328), the RAM size (16/32MB) and so on...
* Choose GDB version 6.3 if you need a debugger
* If you need the LIBSTD C++, add this in the menuconfig/toolchain options/additional gcc options:
--disable-libstdcxx-pch. This will disable the use of the precompiler headers
* Exit the configuration tool and save your config

==Launch build==
$ make
The toolchain is built automatically. During this procedure, several files are downloaded from the web. Please wait for a while.... it takes at least one hour for the first run!

===Known Problems===
* compilation crash with uclibc-0.9.28: run make again
* compilation crash with gdb 6.3: run make again
* compilation crash with linux 2.6.12: run make again

==Enjoy the result==
The generated binary files can be found in the subdirectory armadeus/software/buildroot:

* '''u-boot.brec''' (can be used with the bootstrap, if U-Boot is not installed or not working, see [[BootLoader]] page)
* '''u-boot.bin''' (for download with uboot, see [[BootLoader]] "Update u-boot" page)
* '''linux-kernel-2.6.xx-arm.bin''' (for download with uboot, see InstallLinux)
* '''rootfs.arm_nfpu.jffs2''' (for download with uboot, see InstallFileSystem?)
* '''rootfs.arm_nfpu.tar''' (for an nfsroot, see RootNFS?)

==To keep your copy up-to-date within the armadeus tree==
$ svn update
This will update your working directory to the latest release.

Note: if "svn update" fails because a directory or a file already exists, then do:
$ rm -rf <this-directory/file>
$ svn update

You can do a:
$ make defconfig
to have the latest features automatically activated and a
$ make menuconfig
to set again your personnal parameters (SDRAM size...).

You have to do a '''make''' to rebuild binary files end then upload the binary files to your target.

Note: if definitively everything goes wrong while it worked before the last update.
You can apply the following procedure:
$ rm -rf software/buildroot
$ rm Makefile
$ make
$ make

FAQ

2006-10-18T19:45:00Z

SonZerro: /* What does an Armadeus APF9328 board contains ? */ rephrased...

==General Questions==

===What is the "Armadeus Project" intended for ?===
The goal of this project is to allow everyone to easily develop embedded Open Source systems.
When all the embedded systems in the world will run open source software, life will be better ;-)

===What is the legal status of the project ?===
The Armadeus Project is a french "non-profit" association (loi 1901) held in Mulhouse, France (68). We accept members from everywhere.
Board production is done by a privately held company.

===What does "Armadeus" mean ?===
"Armadeus" is the contraction of "ARM" and "Amadeus". Indeed we choosed ARM architecture for its symplicity and efficiency and our boards are as gifted to run embedded systems as Mozart was for composing music. Moreover, Armadeus project is born in 2006, year of the 250th Mozart's Birthday.

===How do I become a member ?===
You have to pay a small fee. You will receive an Armadeus board, userid and password to participate to this Wiki and project activities. Everyone is welcome.

===What is the fee for becoming a member ?===
You will have to pay 150 euros. You will get an APF9328 board (iMXl @ 200Mhz, 16Mbytes SDRAM, 8Mbytes Flash, FPGA), a "DevLight" development board, and all you need to start developping/collaborating.
You can get a "reduced" APF9328 board (without FPGA, ADC & DAC) for a 130 euros registration fee.

===How do I get help ?===
First take a look at the whole Wiki. If you can't find help contact us directly. If you are located in France, we have members in Besançon, Montbéliard & Mulhouse who can provide you help. For Swiss members, we can provide help in Basel, Lausanne & Zürich.

==Hardware Questions==

===What does an Armadeus APF9328 board contain ?===
The heart of the APF9328 board is a i.MXL processor from Freescale (ex Motorola) with an ARM920T core running at 200MHz. It has the following integrated peripherals:
* LCD controller (TFT, CSTN, STN)
* USB 1.1 device
* 2 x SPI
* I2C
* 2 x Serial
* MMC/SD controller
* Serial bootstrap mode (removing the need of JTAG interface)
* a lot of General Purpose Input/Output, depending on the configured peripherals

Around this processor, the board is equipped with:
* 16MBytes of high speed SDRAM
* 8MBytes of NOR Flash
* 10/100Mbits Ethernet controller
* Xilinx Spartan3 FPGA (optional)
* an ADC and a DAC (optional)
* level converters for serial, USB and Ethernet
* 2 connectors for accessing main signals

Have a look at this link for more informations: [http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MXL&nodeId=0162468rH311432973ZrDR]

===What is the DevLight board ?===
APF9328 boards were designed to be as small as possible and ready to be embedded on any systems. So an APF9328 is not usable alone. You should see it much more like a module you can plug in everywhere.
To develop for APF9328 boards you can either develop your own "motherboard" and plug the APF9328 into it or use the one we develop for our needs.
Currently only the DevLight board is available. It contains:
* a serial connector
* an USB connector
* an Ethernet connector
* a prototype zone to test your developments
* a DC power regulator

A DevFull board is currently in production and will contain:
* an AC97 + touchscreen chip
* 4 more serial ports
* a MMC connector
* ...

===Are the Armadeus boards RoHS compliant ?===
Yes

==Software Questions==
<br>
<br>

[[Image:FrenchFlag.png]][[Fr:FAQ | Cette page en Français]]

FAQ

2006-10-18T19:37:48Z

SonZerro: /* What is the legal status of the project ? */ typo

==General Questions==

===What is the "Armadeus Project" intended for ?===
The goal of this project is to allow everyone to easily develop embedded Open Source systems.
When all the embedded systems in the world will run open source software, life will be better ;-)

===What is the legal status of the project ?===
The Armadeus Project is a french "non-profit" association (loi 1901) held in Mulhouse, France (68). We accept members from everywhere.
Board production is done by a privately held company.

===What does "Armadeus" mean ?===
"Armadeus" is the contraction of "ARM" and "Amadeus". Indeed we choosed ARM architecture for its symplicity and efficiency and our boards are as gifted to run embedded systems as Mozart was for composing music. Moreover, Armadeus project is born in 2006, year of the 250th Mozart's Birthday.

===How do I become a member ?===
You have to pay a small fee. You will receive an Armadeus board, userid and password to participate to this Wiki and project activities. Everyone is welcome.

===What is the fee for becoming a member ?===
You will have to pay 150 euros. You will get an APF9328 board (iMXl @ 200Mhz, 16Mbytes SDRAM, 8Mbytes Flash, FPGA), a "DevLight" development board, and all you need to start developping/collaborating.
You can get a "reduced" APF9328 board (without FPGA, ADC & DAC) for a 130 euros registration fee.

===How do I get help ?===
First take a look at the whole Wiki. If you can't find help contact us directly. If you are located in France, we have members in Besançon, Montbéliard & Mulhouse who can provide you help. For Swiss members, we can provide help in Basel, Lausanne & Zürich.

==Hardware Questions==

===What does an Armadeus APF9328 board contains ?===
This board is build around an i.MXl processor from Freescale (ex Motorola). This 32bits processor is an ARM920T core running at 200Mhz and has the following integrated peripherals:
* LCD controller (TFT, CSTN, STN)
* USB 1.1 device
* 2xSPI
* I2C
* 2xserial
* MMC/SD controller
* Serial bootstrap mode (removing the need of JTAG interface)
* a lot of General Purpose Input/Output, depending on the configured peripherals

Have a look at this link for more informations: [http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MXL&nodeId=0162468rH311432973ZrDR]

On our board it is associated with:
* 16Mbytes of high speed SDRAM
* 8Mbytes of NOR Flash
* 10/100Mbits Ethernet controller
* Xilinx Spartan3 FPGA (optional)
* an ADC and a DAC (optional)
* level converters for serial, USB and Ethernet
* 2 connector for accessing main signals

===What is the DevLight board ?===
APF9328 boards were designed to be as small as possible and ready to be embedded on any systems. So an APF9328 is not usable alone. You should see it much more like a module you can plug in everywhere.
To develop for APF9328 boards you can either develop your own "motherboard" and plug the APF9328 into it or use the one we develop for our needs.
Currently only the DevLight board is available. It contains:
* a serial connector
* an USB connector
* an Ethernet connector
* a prototype zone to test your developments
* a DC power regulator

A DevFull board is currently in production and will contain:
* an AC97 + touchscreen chip
* 4 more serial ports
* a MMC connector
* ...

===Are the Armadeus boards RoHS compliant ?===
Yes

==Software Questions==
<br>
<br>

[[Image:FrenchFlag.png]][[Fr:FAQ | Cette page en Français]]