CHAP3 CSE Exercices

Chapitre 3
Etude de cas d’un

processeur hardcore
du SoPC Zedbord
Année Universitaire 2019-2020
1
Présentation du SoPC cible: zedbord
Présentation
La ZedBoard est une carte de développement conçue par Digilent

permettant d'utiliser un Zynq-7020 de Xilinx.
Zynq fait partie des FPGA de la série 7.
La famille Zynq est à cheval entre la famille Artix (7010, 7015 et 7020)
et la famille Kintex (7030, 7045 et 7100) :
M. FEKI - Conception des systèmes embarqués 2

Présentation

Vue d’ensemble
a : xilinx JTAG connector
b : Power input and switch
c : USB-JTAG (programming)
d : Audio ports
e : Ethernet port
f : HDMI port (output)
G : VGA port
h: XADC header port
i : configuration jumpers
j : FMC connector
k : SD card (underside)
l : User push buttons
m : LEDs
n :switches
o : OLED display
p : prog & reset push buttons
q : 5x Pmod connector ports
r : USB-OTG peripheral port
s : USB-UART port
t : DDR3 memory
u : FPGA Zynq 7020 M. FEKI - Conception des systèmes embarqués 4
Le FPGA zynq XC7Z020
PL et PS
Zynq est composé de deux parties principales : la logique
programmable (PL) et un système à microprocesseur ARM complet
avec ses contrôleurs mémoire et ses périphériques (PS).
Architecture simplifiée de la famille Zynq
Le bus AXI (Advanced eXtensible Interface) permet de connecter la

partie PS avec la partie PL.
Le FPGA zynq
XC7Z020
Périphériques

La logique programme (PL)
Présentation

RAM et DSP slices
Des blocs RAM de 36k.
DSP Slices DSP48E1s : Le multiplieur de la Spartan 3 a évolué en un bloc

MAC (Multiply and ACcumulate) qui est la brique de base d’un Digital
Signal Processor (DSP). la multiplication-accumulation permet de
calculer un produit de convolution. C’est l’opération de base du filtrage
numérique. Il est conçu pour être cascadé avec d’autres DSP slices afin
de réaliser des filtres numériques rapides (500 MHz à comparer avec
les 250 MHz de la logique programmable usuelle.

XADC et GTX transceivers
XADC : Le bloc XADC permet soit de surveiller les alimentations et la

température du FPGA via des capteurs sur la puce, soit d’acquérir
jusqu’à 17 signaux analogiques externes via un multiplexeur. Il
comporte deux convertisseurs analogique/numérique (ADC). On peut
l’utiliser directement en VHDL ou avec le processeur ARM via le bus
AXI.
GTX transceiveurs : Les liaisons séries rapides (>> 1Gbits/s) sont de plus
en plus utilisées (USB, SATA, PCI Express, …). De plus, les interfaces
réseau Ethernet ne cessent de monter en débit (100 Gbit/s). Les GTX
transceiveurs arrivent jusqu’à 12.5 Gbps (PCI Express 1/2/3, 10 Gigabit
Ethernet, …).

Processing System (PS)
Présentation
Le PS inclut:
- deux cœurs ARM cortex A9,
- des bus AMBA et AXI,
- le DMA,
- les GPIOs,
- I2C, UART, CAN, SPI,
- le contrôleur des mémoires
QuadSPI, NAND et NOR,
- et le contrôleur de mémoire
vive.
10
Présentation
L’architecture du FPGA Zynq est centrée sur le PS car le processeur

démarre en premier, puis charge le fichier de configuration de la PL. La
logique programmable est alors utilisée pour réaliser des accélérateurs
matériels connectés au PS.
C’est le PS qui configure la PL. La PL seule n’est donc pas supportée sauf
si vous télécharger la configuration par le JTAG.

Cortex-A9
L’ARM Cortex-A9 est un processeur performant de type tablette

fonctionnant jusqu’à 800 MHz. Il possède un cache L1 de 32 kilo octets
sur les données et sur les adresses. Il y a deux cœurs A9 dans la Zynq.
Le PS est nécessaire pour configurer la logique programmable.
A.KHERIJI- Conception des systèmes embarqués 12

La SCU
La Snoop Control Unit (SCU) connecte les deux Cortex-A9 à la mémoire
système et au cache L2. Il maintient la cohérence entre les deux
caches L1 données. Il arbitre entre les deux processeurs pour
l’accès au cache L2. Il fournit un accès à la ROM/RAM interne. Il fournit
aussi un accès à l’ACP (Accelerator Coherence Port) pour la logique
programmable.

ACP(Administration Control Panel)

Méthodes de Debug
Il existe plusieurs solutions pour debugger le programme dans la
partie ARM ainsi que la logique programmable avec Vivado. Nous
utiliserons la solution mono câble JTAG avec le ARM Debug Access
Port (DAP) placé en tête dans la chaine JTAG Xilinx. Cela nous
permettra aussi de télécharger le bitstream dans la PL.

Les interconnexions
L’Advanced Microcontroller Bus Architecture (AMBA) est utilisé comme bus interne
dans les system-on-a-chip (SoC) basés sur les processeurs ARM depuis 1996.
L’Advanced eXtensible Interface (AXI) est une extension de l’AMBA (version 4.0) pour
Xilinx.
La logique programmable peut utiliser 4 ports AXI haute performance pour un accès
direct (DMA) à la mémoire du PS. Les AXI FIFO Interfaces (AFI) ont une capacité
suffisamment élevée (FIFO 128 x 64-bit) pour transférer avec régularité de grandes
quantités de données entre PL et PS.
Interfaces du PS
Le bus AXI
L’Advanced Microcontroller Bus Architecture (AMBA) est utilisé

comme bus interne dans les system-on-a-chip (SoC) basés sur les
processeurs ARM depuis 1996. L’Advanced eXtensible Interface (AXI)
est une extension de l’AMBA (version 4.0) pour Xilinx.
Le bus industriel AXI permet de connecter le PS avec la PL.
Un bloc IP n’est pas limité qu’à une seule interface AXI mais peut
disposer de plusieurs.

Interfaces du PS
Le bus AXI
L’interface entre le PS et le PL s’effectue via neuf types d’interfaces AXI,
chacune composée de multiples canaux.
S pour esclave (slave) et

M pour maitre (master)

Interfaces du PS
Le bus AXI

Interfaces du PS
Interfaces externes du PS : les MIO
La communication entre le PS et les périphériques externes est assurée

par un bus d’entrée/sortie multiplexé (Multiplexed Input/Output
(MIO)). .

Interfaces du PS
Les différents périphériques d’interfaces du PS vers le monde extérieur:
21
Interfaces du PS
Les MIO sont dîtes multiplexées car toutes

les entrées/sorties des périphériques ne
peuvent être utilisées en même temps.
54 MIO connectées aux broches externes du

FPGA.
Certains périphériques sont connectés

seulement aux MIO (représenés en noir):
USB(x2), QSPI, NAND Flash, SRAM/NOR
Flash.
22
Interfaces du PS
Interfaces avec la PL : les EMIO
64 Extended MIO (EMIO) qui sont reliées à la logique programmable PL.
Les EMIO peuvent être utilisés lorsque les 54 broches du MIO ne

suffisent plus ou pour interfacer le PS avec des IP blocks implémentés
dans la partie PL sans utiliser l’interconnexion plus complexe du bus AXI.
23
Interfaces du PS
Interfaces avec la PL : les EMIO
Certains périphériques sont connectées aux

MIO et aux EMIO (représentés en bleu) :
Ethernet (RGMII,MDIO), SD(x2), CAN, I2C,
UART, SPI, GPIO et Trace Port.
Certaines périphériques sont connectés

seulement aux EMIO (représentés en rouge):
Ethernet(MII, GMII, SGMII).
.
24
Flot de dévelopement
Introduction
Xilinx a abandonné son outil historique ISE pour passer à Vivado. ISE
s’est arrêté en 2013 avec la version 14.7 et permet de concevoir des
FPGA Xilinx jusqu’à la série 7 incluse, y compris la famille Zynq. Vivado
démarre à partir de la série 7 et donc ne peut être utilisé avec les FPGA
Xilinx plus anciens.
Vivado est utlisé pour paramétrer le PS et pour gérer le projet global et

pour créer le design en VHDL. Pour simuler, le simulateur interne de
Vivado Xsim est utilisé.
Pour développer l’application logicielle ARM exécutée par le PS, nous

utiliserons le SDK (Software Development Kit).
Ce flot de développement est aussi utilisé pour le processeur softocre

de xilinx Microblaze.
Implémentation matérielle
Côté PS, Vivado vous permet de :

- créer le PS et de le configurer
- définir les périphériques ARM utilisés via les MIO
- connecter les EMIO avec la PL
- rajouter des périphériques AXI génériques depuis un catalogue de
fonctions (IP core) pour s’interfacer avec la PL. Ces périphériques sont
réalisés avec de la logique programmable
- créer avec un assistant des périphériques AXI spécifiques réalisés avec
de la logique programmable.

Côté design, Vivado vous permet de :

- créer un projet VHDL avec la partie PL en utilisant éventuellement des
blocs IP
- générer les fichiers du PS créé précédemment
- simuler avec Xsim
- synthétiser puis d’implémenter l’ensemble PS + PL.
- configurer la PL
- exporter le projet à destination du SDK.

Introduction
Dans les systèmes embarqués, un BSP (Board Support Package) est un

ensemble de fichiers contenant du code spécifique à votre système
matériel afin de pouvoir développer l’application logicielle. Par exemple,
le BSP permet de dire au SDK quelles sont les ressources matérielles
disponibles ainsi que leur adresse. Il s’agit en général de fichiers source
en C, de fichiers d’entête .h, de fichiers d’initialisation, …
Le SDK vous permet principalement de :

- importer les spécifications matérielles fournies par Vivado
- créer le BSP
- créer le projet d’application logicielle
- exécuter le programme ARM et de le debugger

Le block design
Le processseur embarqué hardcore est modélisé par le blok design
suivant: Electrique
Le block présente un certain nombre d’E/S: interface mémoire DDR3,

des E/S fixées (Fixed_IO), clocks, resets, sortie de timers et bus
d’interfaces (AXI) qui permettent la connection avec d’autres block IP.
Les connections de l’interface mémoire DDR3 et des Fixed_IO sont

réalisées automatiquement. 29
Le block design
Il faut assurer une liaison d’horloge entre FCLK_CLK0 (output: horloge
générée par le PS) et M_AXI_GP0_ACLK (input: horloge du bus AXI). Il
est à noter que le bus AXI fonctionne à 100MHz et par conséquent il
faut configurer l’horloge FCLK_CLK0 à cette valeur.
C’est le design basique utilisant le processeur embarqué pour

implémenter une application la-dessus.
Création du Wrapper
Le Wrapper est le top level design en VHDL et dont le rôle est
d’instancier le Processing System (PS).
Signaux de
l’interface DDR3
Les MIO
L’horloge 33.33 MHz
et les PowerOnReset
et SystemReset du PS
31
Ces E/S n’ont pas à être déclarées dans un fichier de contraintes XCF car
il s’agit d’une liaison directe avec le PS. Seules les E/S passant par la
logique programmable PL doivent être placées dans le fichier de
contraintes.
La création du top level design est obligatoire. C’est là que nous

placerons notre code VHDL .



Implémentation logicielle
Les entêtes à utiliser
#include<stdio.h> : bibliothèque standard du C.
#include "platform.h" : contient les prototypes des fonctions

init_platform() Et cleanup_platform(). Init_platform() est la fonction
de configuration de base pour l’UART.
Les entêtes spécifiques Xilinx commencent tous par la lettre x.
include “xgpiops.h” : bibliothèque pour pouvoir utiliser les GPIO du

PS.
#include “ xparameters.h" : contient des macros utiles pour piloter

les périphériques.

Structures de données utilisées
Rappel : Une structure rassemble des variables, qui peuvent être de
types différents, sous un seul nom ce qui permet de les manipuler
facilement. Elle permet de simplifier l’écriture d’un programme en
regroupant des données liées entre elles.
La structure qui contrôle les GPIO dans le Processing System (PS) du

Zynq est la suivante:
Elle peut être appelée de la manière suivante :

XGpioPs my_Gpio Instance de la structure qu’on a nommé my_GPIO
La seconde structure (qui est une sous structure de XGpioPs) permet
de configurer l’instance my_GPIO et elle est définie comme suit:
XGpioPs_Config *GPIO_Config;
Pour configurer toutes les variables à l’intérieur de la structure

XGpioPs, une fonction C existe car toutes les variables internes ne sont
pas initialisées lorsque la structure est déclarée:
int XGpioPs_CfgInitialize(XGpioPs *InstancePtr, XGpioPs_Config
*ConfigPtr, u32 EffectiveAddr)
Fonction : initialise toutes les variables de la structure utilisée.
Paramètres :
-InstancePtr est un pointeur pour l’instance XGpioPs_Config
-EffectiveAddr est l’adresse qui est extraite de la structure
XGpioPs_Config
Retour : la valeur de l’état qui nous permet de savoir si l'initialisation a
été réussie. M. FEKI - Conception des systèmes embarqués 37
Pour initialiser la structure XGioPs_Config, on fait appel à la fonction

suivante :
XGpioPs_Config* XGpioPs_LookupConfig(u16 DeviceId)
Fonction : cette fonction cherche la configuration du dispositif basé sur

son unique ID. La table XGpioPs_ConfigTable[] contient les informations
sur chaque dispositif dans le système.
Paramètres :
-DeviceId est l'identifiant unique du dispositif utilisé.
Retour : Un pointeur vers l'entrée de la table de configuration
correspondant à l'ID du périphérique donné, ou NULL si aucune
correspondance n'est trouvée

Le code résultant est le suivant :

// déclaration des deux structures
XGpioPs_Config *GPIO_Config;
XGpioPs my_Gpio;
// déclaration d’un entier pour la vérification d’erreur
int Status;
//Initialisation de la structure XGioPs_Config
// DeviceId=0, valeur trouvée dans le fichier xparameters.h
GPIO_Config = XGpioPs_LookupConfig(0);
//Initialisation de la strucutre XGpioPs
Status = XGpioPs_CfgInitialize(&my_Gpio, GPIO_Config,
GPIO_Config->BaseAddr);
// vérifier la reussite de l’initialisation de XFpioPs
if (Status != XST_SUCCESS) { return XST_FAILURE; }

Les functions d’E/S de XGpioPs
void XGpioPs_SetDirectionPin(XGpioPs *InstancePtr, int Pin, int

Direction)
Fonction : Spécifier la direction du pin.

Paramètres :
-InstancePtr est un pointeur pour l’instance XGpioPs
-Pin est le numéro de pin pour lequel on va spécifier la direction. Le numéro
de pin varie de 0 à XGPIOPS_DEVICE_MAX_PIN_NUM - 1.
- Direction est la direction à accorder au pin spécifié. 0 pour une entrée et 1
pour une sortie
Retour : Rien.

void XGpioPs_SetOutputEnablePin(XGpioPs *InstancePtr, int Pin, int

opEnable)
Fonction : activer la sortie du pin spécifié.

Paramètres :
-Pin est le numéro de pin où la donnée va etre écrite. Le numéro de pin
varie de 0 à XGPIOPS_DEVICE_MAX_PIN_NUM - 1.
- OpEnable spécifie si la sortie du pin spécifié doit être activée. 0 pour la
désactivation de la sortie et 1 pour l'activation de la sortie.
Retour : Rien.

void XGpioPs_SetDirection(XGpioPs * InstancePtr, u8 Bank, u32

Direction )
Fonction : spécifier la direction du bank (ensemble de pins)
Paramètres :
Parameters:
-Bank est le numéro de bank. Le numéro de bank varie de 0 à
XGPIOPS_MAX_BANKS - 1.
- direction est la direction à définir pour les pin de la bank. Les bits avec 0
sont définis sur le mode d'entrée, les bits avec 1 sont définis sur le mode de
sortie.
Retour : Rien.

void XGpioPs_SetOutputEnable (XGpioPs *InstancePtr, u8 Bank, u32

Enable)
Fonction : activer la sortie du bank spécifié.

Paramètres :
-Bank est le numéro de bank en question. Le numéro de bank varie de 0 à
- Enable est le masque de 32 bits de la validation de sortie à définir pour
toutes les broches dans le bank
-OpEnable est le masque de 32 bits de la validation de sortie à définir pour
tous les broches dans le bank. Les bits avec 0 sont désactivés en sortie et les
bits avec 1 sont activées en sortie.
Retour : Rien.

int XGpioPs_ReadPin(XGpioPs *InstancePtr, int Pin)
Fonction : lire la donnée du pin spécifié.

Paramètres :
-Pin est le numéro de pin à partir du quel la donnée va être lue. Les
numéros de pin varie (pour la zedboard) de 0 à
XGPIOPS_DEVICE_MAX_PIN_NUM - 1.
Retours : la valeur courante dans le pin (0 ou 1).

u32 XGpioPs_Read(XGpioPs *InstancePtr, u8 bank)
Fonction : lire les données sur le bank spécifié.

Paramètres :
-Bank est le numéro de bank en question. Le numéro de bank varie de 0 à
Retour : la valeur courante sur le bank.

void XGpioPs_WritePin(XGpioPs *InstancePtr, int Pin, int Data)
Fonction Fonction : Ecrire la donnée dans le pin spécifié.

Paramètres :
Parameters:
-Pin est le numéro de pin dans lequel la donnée va être écrite. Les numéros
de pin varie (pour la zedboard) de 0 à XGPIOPS_DEVICE_MAX_PIN_NUM -
1.
- Data est la donnée à écrire dans le pin spécifié (0 ou 1)
Retour : Rien

Les functions de XGpioPs
Bien évidemment, il existe d’autres fonctions que celles évoquées dans

ce cours. Pour plus de détails voir:
http://xilinx.eetrend.com/files-eetrend-xilinx/forum/201509/9239-
20459-xilinx_driver_gpiops_v1_02_a_xgpiops.pdf

Port AXI : les functions de XGpio
Pour utiliser le port AXI, il faut rajouter la bibliothèque
#include "xgpio.h"
Puis faire l’instanciation de la strucutre XGPIO:

XGpio Gpio;
Pour configurer et initialiser toutes les variables à l’intérieur de la

structure XGpio:
int XGpio_Initialize(XGpio *InstancePtr, u16 DeviceId)
Fonction : initialise toutes les variables de la structure utilisée.
Paramètres :
-InstancePtr est un pointeur pour l’instance XGpio
-DeviceId est l'identifiant unique du dispositif utilisé
Retour : la valeur de l’état qui nous permet de savoir si l'initialisation a
été réussie.
void XGpio_SetDataDirection(XGpio * InstancePtr, unseigned Channel,

u32 DirectionMask )
Fonction : spécifier la direction de toutes les E/S du channel spécifié
Paramètres:
-InstancePtr est un pointeur pour l’instance Xgpio
-Channel : channel (1 ou 2) du GPIO
-DirectionMask : est un masque pour spécifier les entrées et les sorites. Les
bits mis à 0 sont des sorties et les bits mis à 1 sont des entrées
Retour : Rien.

Void XGpio_DiscreteWrite(XGpio *InstancePtr, unsigned Channel, u32
data)
Fonction : Ecrire la donnée sur le channel spécifié.
Paramètres :
-Channel est le numéro du channel utilisé (1 ou 2)
- Data : la donnée à écrire
Retour : Rien
u32 XGpio_DiscreteRead(XGpio *InstancePtr, unsigned Channel)

Fonction : Lire la donnée sur le channel spécifié.
Paramètres :
-Channel est le numéro du channel utilisé (1 ou 2)
Retour : une variable de type u32

Exercices
Exercice 1 : Clignoter la LED9
On souhaite faire clignoter la LED9. La LED9 est l’unique LED connecté au

PS comme le montre le tableau suivant:
Compléter le code C correspondant.

Exercices
Exercice 1 : Clignoter la LED9
#include<stdio.h>
#include "xgpiops.h"
#include "xparameters.h"
⁞
Int main(void)
{
La fonction printf() du C est fortement
XGpioPs_Config *GPIO_Config; déconseillée car elle occupe beaucoup de
XGpioPs my_Gpio; place en mémoire. La fonction xil_printf() a
int Status; la même syntaxe et est beaucoup plus
légère. Sa seule restriction, c’est qu’elle ne
traite pas les types float et double.
xil_printf("essai MIO\n");
⁞
Return 0;
}
Exercices
Exercice 2 : Contrôler la LED9 avec un bouton poussoir
Reprendre l’exercice 1 mais on suppose que la LED9 est contrôlée par un

bouton poussoir (connecté directement au PS). La LED9 est éteinte si le
bouton poussoir est enfoncé. Le tableau suivant présente l’ensemble des
boutons poussoirs présents sur la carte:
Modifier le code C de l’exercice 1 afin de répondre au nouveau cahier des

charges.

Exercices
Exercice 3 : Accéder aux GPIO via les EMIO
On souhaite accéder aux 2 switches et aux 8 LEDs connectés sur la PL via

les EMIO. On lira la valeur des switches SW0 et SW1 et on allumera les
leds LED0 à LED7 via le programme en C, à travers la logique
programmable.
Les MIO sont numérotées de 0 à 53 (bank 0 et 1), et les 64 EMIO (bank 2

et 3) se trouvent à la suite de 54 à 118. Les EMIO peuvent être utilisées
broche par broche (ça sera le cas dans cet exercice), ou bien par bank 32
bits (voir exercice du TD). Le tableau suivant indique les connexions à
respecter :
Numéro d’ EMIO Branché sur sens
54 à 61 LED0 à LED7 sortie
62 SW0 entrée
63 SW1 entrée
Exercices
Configuration nécessaire

Exercices
EMIO GPIO (Width) : Sélectionner une largeur égale à 10
Il apparait sur le composant

Zynq un nouveau port nommé
GPIO_0
56
Exercices
Ce nouveau port représente des bus 10 bits constituant le port (Input,

Output et Tristate)

Exercices
Le bloc design :

Exercices
On note que les GPIO apparaissent

maintenant dans les E/S du
composant design_1 (le composant
design_1, c’est le PS).
59
Exercices
Ces E/S ont été automatiquement

reliées aux E/S du top level design
design_1_wrapper. Par défaut,
toutes les E/S du composant
design_1 sont connectées aux E/S
de design_1_wrapper, ce qui n’est
pas toujours correct et il est
souvent nécessaire de les
supprimer.
60
Exercices

Exercices
Nous désirons réaliser le design suivant :
1. Modifier le code VHDL du Wrapper afin de répondre au cahier des charges.

Exercices
2. Ecrire le code C qui permet de:
- lire l’état des deux swiches,
- faire compter les leds LED0 à LED7 en binaire sur 8 bits de 0 à 255 si SW0 est au niveau
haut et si SW1 est au niveau bas; faire décompter les leds si SW0 est au niveau bas et si SW1
est au niveau haut.

CHAP3 CSE Exercices

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CHAP3 CSE Exercices

Hochgeladen von

Copyright:

Verfügbare Formate

Chapitre 3

Etude de cas d’un

Année Universitaire 2019-2020

La ZedBoard est une carte de développement conçue par Digilent

Zynq fait partie des FPGA de la série 7.

M. FEKI - Conception des systèmes embarqués 2

M. FEKI - Conception des systèmes embarqués 3

Architecture simplifiée de la famille Zynq

Le bus AXI (Advanced eXtensible Interface) permet de connecter la

M. FEKI - Conception des systèmes embarqués 6

M. FEKI - Conception des systèmes embarqués 7

Des blocs RAM de 36k.

DSP Slices DSP48E1s : Le multiplieur de la Spartan 3 a évolué en un bloc

M. FEKI - Conception des systèmes embarqués 8

XADC : Le bloc XADC permet soit de surveiller les alimentations et la

M. FEKI - Conception des systèmes embarqués 9

L’architecture du FPGA Zynq est centrée sur le PS car le processeur

M. FEKI - Conception des systèmes embarqués 11

L’ARM Cortex-A9 est un processeur performant de type tablette

A.KHERIJI- Conception des systèmes embarqués 12

A.KHERIJI- Conception des systèmes embarqués 13

A.KHERIJI- Conception des systèmes embarqués 14

A.KHERIJI- Conception des systèmes embarqués 15

L’Advanced Microcontroller Bus Architecture (AMBA) est utilisé

Le bus industriel AXI permet de connecter le PS avec la PL.

M. FEKI - Conception des systèmes embarqués 17

S pour esclave (slave) et

M. FEKI - Conception des systèmes embarqués 18

M. FEKI - Conception des systèmes embarqués 19

La communication entre le PS et les périphériques externes est assurée

M. FEKI - Conception des systèmes embarqués 20

Les MIO sont dîtes multiplexées car toutes

54 MIO connectées aux broches externes du

Certains périphériques sont connectés

64 Extended MIO (EMIO) qui sont reliées à la logique programmable PL.

Les EMIO peuvent être utilisés lorsque les 54 broches du MIO ne

Certains périphériques sont connectées aux

Certaines périphériques sont connectés

Vivado est utlisé pour paramétrer le PS et pour gérer le projet global et

Pour développer l’application logicielle ARM exécutée par le PS, nous

Ce flot de développement est aussi utilisé pour le processeur softocre

Côté PS, Vivado vous permet de :

M. FEKI - Conception des systèmes embarqués 26

Côté design, Vivado vous permet de :

M. FEKI - Conception des systèmes embarqués 27

Dans les systèmes embarqués, un BSP (Board Support Package) est un

Le SDK vous permet principalement de :

M. FEKI - Conception des systèmes embarqués 28

Le block présente un certain nombre d’E/S: interface mémoire DDR3,

Les connections de l’interface mémoire DDR3 et des Fixed_IO sont

C’est le design basique utilisant le processeur embarqué pour

La création du top level design est obligatoire. C’est là que nous

M. FEKI - Conception des systèmes embarqués 32

M. FEKI - Conception des systèmes embarqués 33

M. FEKI - Conception des systèmes embarqués 34

#include<stdio.h> : bibliothèque standard du C.

#include "platform.h" : contient les prototypes des fonctions

Les entêtes spécifiques Xilinx commencent tous par la lettre x.

include “xgpiops.h” : bibliothèque pour pouvoir utiliser les GPIO du

#include “ xparameters.h" : contient des macros utiles pour piloter

M. FEKI - Conception des systèmes embarqués 35

La structure qui contrôle les GPIO dans le Processing System (PS) du

Elle peut être appelée de la manière suivante :