ZPU Evo(lution)

English


Le ZPU est un microprocesseur 32 bits base sur une pile, concu a l’origine par Øyvind Harboe de Zylin AS. La documentation originale se trouve sur le site web Zylin/OpenCore ou Wikipedia. C’est un microprocesseur destine aux applications embarquees FPGA avec une utilisation minimale d’elements logiques et de BRAM, au prix de la vitesse d’execution.

Zylin a produit deux conceptions en open source, a savoir les versions Small et Medium du ZPU. Des conceptions supplementaires ont ete produites par des developpeurs externes, comme les variantes Flex et ZPUino, offrant chacune des ameliorations par rapport a la conception originale telles que l’interface Wishbone, les performances, etc.

Ce document decrit une autre conception que j’appelle le modele ZPU Evo(lution), dont l’accent est mis sur la performance, la connectivite et l’extension du jeu d’instructions. Cela est ne du besoin d’une CPU pour un emulateur d’ordinateur vintage que j’ecris, qui servirait de processeur IO pour fournir des services de menu, de peripheriques et de SD.

Un exemple de la performance du ZPU Evo peut etre vu en utilisant CoreMark qui retourne une valeur de 22,2 a 100MHz sur du fabric Altera utilisant le BRAM, et pour Dhrystone 13,2 DMIPS. La connectivite se voit par l’implementation des bus systeme et Wishbone. L’extension du jeu d’instructions se voit par l’inclusion d’un cache L1 etroitement couple ou plusieurs octets d’instructions sont sources et rendus disponibles a la CPU, qui peut etre utilise pour l’optimisation (par ex. jusqu’a 5 instructions IM executees en 1 cycle) ou pour des instructions multi-octets etendues (par ex. implementation d’une instruction LoaD Increment Repeat).

La CPU

Le ZPU Evo fait suite au ZPU Medium et Flex, et des parties du code sont similaires, par exemple le decodage d’instructions. La conception differe cependant en raison du caching et de l’implementation d’un processeur de transactions memoire ou toutes les operations memoire/IO (sauf les lectures directes d’instructions si le bus d’instructions double-port est active) sont routees. Les CPUs originales géraient toutes leurs besoins en memoire sur place ou dans la machine d’etat, alors que l’Evo soumet une requete au MXP chaque fois qu’une operation memoire est necessaire.

Les sections suivantes decrivent certaines des fonctionnalites et modifications par rapport aux conceptions ZPU originales.

Structure du bus

Le ZPU possede un espace d’adressage lineaire ou tous les peripheriques memoire et IO sont directement adressables. Les conceptions ZPU existantes fournissent soit un bus systeme, soit un bus Wishbone, tandis que l’Evo fournit les deux. Le ZPU Evo cree jusqu’a deux regions distinctes dans l’espace d’adressage selon la configuration, pour fournir un bus systeme et un bus Wishbone.

Tous les modeles ont le bus systeme implemente, qui commence a l’adresse CPU 0 et s’etend jusqu’a la limite imposee par le bit d’adresse maximum configurable (par ex. 0x000000 - 0xFFFFFF pour 24 bits).

Si configure, un bus Wishbone peut etre instancie, etendant le bit d’adresse maximum de 1. Un troisieme bus peut etre configure, uniquement pour les lectures d’instructions.

Cache L1

Afin d’ameliorer les performances mais surtout pour les optimisations d’instructions et les instructions etendues, un cache L1 est implemente en utilisant des registres. L’utilisation de registres consomme de l’espace fabric et doit donc etre tres petite, mais elle permet un acces aleatoire en un seul cycle, necessaire par exemple pour compacter un chargement IM 32 bits (qui peut etre de 5 instructions) en un seul cycle.

Cache L2

Le BRAM interne n’a pas besoin de cache L2 car son temps d’acces est de 1-2 cycles. Comme le BRAM est une ressource limitee, on suppose que de la RAM externe ou du SDRAM sera utilise, qui est beaucoup plus lent et doit etre cache pour augmenter le debit. Le cache L2 est utilise a cette fin, pour lire en avance un bloc de RAM externe et alimenter le cache L1 selon les besoins.

Jeu d'instructions

Une caracteristique du ZPU est son utilisation d’un ensemble fixe minimal d’instructions implementees en materiel et d’un ensemble souple d’instructions supplementaires implementees en pseudo-microcode. Le ZPU Evo implemente toutes les instructions en materiel, mais cela peut etre ajuste dans la configuration pour utiliser des instructions souples si necessaire pour economiser les ressources FPGA.

Le format d’extension du jeu d’instructions est:

Extend Instruction,<new insn[7:2]+ParamSize[1:0]>,[byte],[byte],[byte],[byte]

Jeu d'instructions implemente

La table complete du jeu d’instructions est identique a la version anglaise et y est documentee.

Table de comparaison des instructions implementees

alt text

Hardware Variable Byte Write

Dans les conceptions ZPU originales, il y avait de la marge mais pas d’implementation pour permettre au ZPU d’effectuer des ecritures octet/demi-mot/mot complet. Dans l’Evo, du materiel a ete implemente (selectionnable au moment du build) pour permettre les ecritures octet et demi-mot.

Hardware Debug Serializer

Afin de deboguer la CPU ou simplement fournir des informations de fonctionnement interne de bas niveau, un module de debogage UART avec tampon est implemente.

Contraintes de timing

C’est un travail en cours. Le design est progressivement mis a jour pour que le timing soit pleinement respecte.

System On a Chip

Afin de fournir un cadre de travail fonctionnel dans lequel le ZPU Evo peut etre utilise, un wrapper System On a Chip a ete cree qui permet l’instanciation de divers peripheriques (par ex. UART/carte SD).

Le SoC implemente actuellement: CPU (Small/Medium/Flex/Evo/Evo Minimal), Wishbone Bus, BRAM, RAM, SDRAM, I2C, Timers, UARTs, Interrupt Controller, PS2, SPI, SD, IOCTL et SOCCFG. La table complete des composants est identique a la version anglaise.

SDRAM

Le SoC supporte le SDRAM via deux chemins independants: un controleur bus systeme (SB) et un controleur bus Wishbone (WB). Les deux sont desactives par defaut et peuvent etre actives independamment.

Logiciel

Le logiciel fourni comprend:

  1. Un bootloader, I/O Control Program (IOCP).
  2. Une application, ZPUTA (ZPU Test Application).
  3. Un systeme d’exploitation, zOS (ZPU Operating System).
  4. Des fonctions de bibliotheque en C, y compris des bibliotheques tierces comme FatFS.

21/04/2020: Le logiciel pour le ZPU a ete fusionne avec le tranZPUter et est maintenu dans le depot zSoft.

Configuration

Cette section montre comment configurer le ZPU et le SoC. Les tables de configuration completes pour la CPU et le SoC sont identiques a la version anglaise.

Build

Cette section montre comment effectuer un build de base et suppose que la carte de developpement cible est le QMTECH Cyclone V board.

La methode recommandee pour construire le ZPU est le script de configuration automatise correspondant a votre plateforme (voir Configuration et build automatises juste en dessous) — il installe toute la chaine d’outils (Intel Quartus Prime Lite 17.1 et, si necessaire, Docker), clone le depot, vous laisse choisir la carte cible et la variante de CPU, et construit le bitstream FPGA jusqu’a son terme, sans connaissance approfondie des outils. Les etapes manuelles Build logiciel et Build du bitstream RTL ci-dessous s’adressent aux utilisateurs avances et aux builds partiels.

Configuration et build automatises (recommande)

Si vous souhaitez simplement recuperer le depot et produire un bitstream FPGA sans apprendre toute la chaine d’outils, utilisez les scripts de configuration fournis. Ils installent tout le necessaire (Intel Quartus Prime Lite 17.1 et, si requis, Docker), clonent le depot, vous laissent choisir la carte cible et le CPU, et construisent le bitstream jusqu’a son terme. Chaque script est autonome: copiez uniquement le fichier correspondant a votre plateforme et executez-le. Ils ont ete verifies de bout en bout sur Windows (natif), macOS (Intel, via Docker) et Linux.

Script Plateforme Notes
setup_ZPU_windows.cmd Windows 10 / 11 Recommande sous Windows — lanceur a double-clic. Execute la configuration PowerShell, garde la fenetre ouverte et journalise tout dans setup_ZPU_log.txt. Installation native, sans WSL.
setup_ZPU_windows_native.ps1 Windows 10 / 11 Le script PowerShell sous-jacent (executez-le directement depuis une fenetre PowerShell si vous preferez). Installe Git for Windows + Quartus 17.1 via winget / l’installateur Intel.
setup_ZPU.sh Linux / macOS Quartus natif sous Linux (par defaut); une image Docker Quartus headless autonome sous macOS (aucun Quartus natif macOS n’existe — Mac Intel uniquement, car Quartus est x86-64).
build_zpu.sh tous Wrapper de build portable utilise par les scripts de configuration. Relancez-le a tout moment pour reconstruire: ./build_zpu.sh [BOARD] [CPU].

Windows 10 / 11 (natif, sans WSL) — double-cliquez sur setup_ZPU_windows.cmd, ou depuis une fenetre PowerShell ouverte:

# optionnel: construire un depot specifique (par defaut le depot public https://git.eaw.app/eaw/zpu.git)
$env:ZPU_REPO_URL = "https://git.eaw.app/eaw/zpu.git"
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\setup_ZPU_windows_native.ps1

macOS / Linux — depuis un terminal:

chmod +x setup_ZPU.sh
./setup_ZPU.sh

Sous Linux, Quartus est installe nativement dans ~/altera/17.1. Sur un Mac Intel, une image Docker Quartus headless est construite (Docker Desktop doit etre installe et en cours d’execution) car Intel ne fournit aucun Quartus natif macOS.

Cartes et variantes de CPU
Cartes CPUs
QMV (par defaut, QMTECH Cyclone V), DE10_nano, DE0_nano, E115 (Cyclone IV E EP4CE115), CYC1000 (Cyclone 10 LP) EVO (par defaut), EVO_MINIMAL, FLEX, MEDIUM, SMALL
Reconstruire ensuite (sans relancer la configuration)

Une fois Quartus installe, relancez directement le wrapper portable. Sous Git Bash Windows, placez d’abord les outils Quartus dans le PATH:

# Sous Windows Git-Bash uniquement:
export PATH="/c/altera/17.1/quartus/bin64":$PATH

./build_zpu.sh                    # par defaut -> QMV_EVO
./build_zpu.sh E115 EVO           # carte + CPU
./build_zpu.sh QMV_EVO            # forme combinee BOARD_CPU
./build_zpu.sh --list             # lister toutes les cartes / CPUs
Variables d'environnement utiles (toutes optionnelles)
Variable Objet Par defaut
ZPU_REPO_URL Depot a cloner https://git.eaw.app/eaw/zpu.git (public)
ZPU_BOARD / ZPU_CPU Ignorer les invites carte / CPU (invites)
ZPU_RTL_METHOD Forcer la methode Quartus: native ou docker native sous Linux/Windows, docker sous macOS
ZPU_DIR Construire dans un checkout existant au lieu de cloner (clone)
ZPU_QUARTUS_BIN Pointer vers un bin / bin64 Quartus existant auto-detection

Le reste de cette section documente le build manuel sous-jacent pour ceux qui preferent lancer les outils a la main.


Build logiciel

  1. Telecharger et installer la ZPU GCC ToolChain. Installer dans /opt ou un repertoire commun similaire.
  2. Configurer le chemin de la variable d’environnement. 
     export PATH=$PATH:/opt/zpu/bin
  3. Cloner le depot ZPU Evo.
  4. Editer le fichier zputa.h et selectionner les fonctions a integrer dans l’image core ZPUTA.
  5. Lancer la commande de build. 
     cd <zpu evo dir>/software
 ./build.sh -I 3 -O zputa -o 2 -B 0x1000 -A 0xC000

Build du bitstream RTL

Les instructions de build pour le bitstream RTL et les builds specifiques aux CPU (Small, Medium, Flex, Evo) sont identiques a la version anglaise.