Vous êtes sur la page 1sur 63

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 du SoPC cible: zedbord
Présentation

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


Présentation du SoPC cible: zedbord
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.
M. FEKI - Conception des systèmes embarqués 5
Le FPGA zynq
XC7Z020
Périphériques

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


La logique programme (PL)
Présentation

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


La logique programme (PL)
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.

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


La logique programme (PL)
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, …).

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


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
Processing System (PS)
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.

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


Processing System (PS)
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


Processing System (PS)
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.

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


Processing System (PS)
ACP(Administration Control Panel)

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


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.

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


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.
A.KHERIJI- Conception des systèmes embarqués 16
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.

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


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)

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


Interfaces du PS
Le bus AXI

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


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

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


Interfaces du PS
Interfaces externes du PS : les MIO
 Les différents périphériques d’interfaces du PS vers le monde extérieur:

21
Interfaces du PS
Interfaces externes du PS : les MIO

 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.
M. FEKI - Conception des systèmes embarqués 25
Flot de dévelopement
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.

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


Flot de dévelopement
Implémentation matérielle

 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.

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


Flot de dévelopement
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

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


Implémentation matérielle
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
Implémentation matérielle
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.
M. FEKI - Conception des systèmes embarqués 30
Implémentation matérielle
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
Implémentation matérielle
Création du Wrapper

 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 .

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


Implémentation matérielle
Création du Wrapper

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


Implémentation matérielle
Création du Wrapper

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


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.

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


Implémentation logicielle
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
M. FEKI - Conception des systèmes embarqués 36
Implémentation logicielle
Structures de données utilisées
 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
Implémentation logicielle
Structures de données utilisées

 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

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


Implémentation logicielle
Structures de données utilisées

 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; }

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


Implémentation logicielle
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.

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


Implémentation logicielle
Les functions d’E/S de XGpioPs

 void XGpioPs_SetOutputEnablePin(XGpioPs *InstancePtr, int Pin, int


opEnable)

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


Paramètres :
-InstancePtr est un pointeur pour l’instance XGpioPs
-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.

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


Implémentation logicielle
Les functions d’E/S de XGpioPs

 void XGpioPs_SetDirection(XGpioPs * InstancePtr, u8 Bank, u32


Direction )
Fonction : spécifier la direction du bank (ensemble de pins)
Paramètres :
Parameters:
-InstancePtr est un pointeur pour l’instance XGpioPs
-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.

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


Implémentation logicielle
Les functions d’E/S de XGpioPs

 void XGpioPs_SetOutputEnable (XGpioPs *InstancePtr, u8 Bank, u32


Enable)

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


Paramètres :
-InstancePtr est un pointeur pour l’instance XGpioPs
-Bank est le numéro de bank en question. Le numéro de bank varie de 0 à
XGPIOPS_MAX_BANKS - 1.
- 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.

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


Implémentation logicielle
Les functions d’E/S de XGpioPs

 int XGpioPs_ReadPin(XGpioPs *InstancePtr, int Pin)

Fonction : lire la donnée du pin spécifié.


Paramètres :
-InstancePtr est un pointeur pour l’instance XGpioPs
-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).

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


Implémentation logicielle
Les functions d’E/S de XGpioPs

 u32 XGpioPs_Read(XGpioPs *InstancePtr, u8 bank)

Fonction : lire les données sur le bank spécifié.


Paramètres :
-InstancePtr est un pointeur pour l’instance XGpioPs
-Bank est le numéro de bank en question. Le numéro de bank varie de 0 à
XGPIOPS_MAX_BANKS - 1.
Retour : la valeur courante sur le bank.

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


Implémentation logicielle
Les functions d’E/S de XGpioPs

 void XGpioPs_WritePin(XGpioPs *InstancePtr, int Pin, int Data)

Fonction Fonction : Ecrire la donnée dans le pin spécifié.


Paramètres :
Parameters:
-InstancePtr est un pointeur pour l’instance XGpioPs
-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

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


Implémentation logicielle
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

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


Implémentation logicielle
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.
M. FEKI - Conception des systèmes embarqués 48
Implémentation logicielle
Port AXI : les functions de XGpio

 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.

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


Implémentation logicielle
Port AXI : les functions de XGpio
 Void XGpio_DiscreteWrite(XGpio *InstancePtr, unsigned Channel, u32
data)
Fonction : Ecrire la donnée sur le channel spécifié.
Paramètres :
-InstancePtr est un pointeur pour l’instance XGpio
-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 :
-InstancePtr est un pointeur pour l’instance XGpio
-Channel est le numéro du channel utilisé (1 ou 2)
Retour : une variable de type u32

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


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.

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


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;
}
M. FEKI - Conception des systèmes embarqués 52
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.

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


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
M. FEKI - Conception des systèmes embarqués 54
Exercices
Exercice 3 : Accéder aux GPIO via les EMIO
Configuration nécessaire

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


Exercices
Exercice 3 : Accéder aux GPIO via les EMIO
EMIO GPIO (Width) : Sélectionner une largeur égale à 10

Il apparait sur le composant


Zynq un nouveau port nommé
GPIO_0

56
Exercices
Exercice 3 : Accéder aux GPIO via les EMIO

Ce nouveau port représente des bus 10 bits constituant le port (Input,


Output et Tristate)

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


Exercices
Exercice 3 : Accéder aux GPIO via les EMIO

Le bloc design :

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


Exercices
Exercice 3 : Accéder aux GPIO via les EMIO

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
Exercice 3 : Accéder aux GPIO via les EMIO

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
Exercice 3 : Accéder aux GPIO via les EMIO

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


Exercices
Exercice 3 : Accéder aux GPIO via les EMIO

Nous désirons réaliser le design suivant :

1. Modifier le code VHDL du Wrapper afin de répondre au cahier des charges.

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


Exercices
Exercice 3 : Accéder aux GPIO via les EMIO
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.

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

Vous aimerez peut-être aussi