Relier le code au circuit obtenu, lire une latence et corriger un chemin trop long.
La synthèse ne vérifie pas l'intention
Un outil de synthèse transforme le RTL en registres, logique et mémoires. Il peut accepter un code qui ne fait pas ce que le cahier des charges demande. La simulation, le lint, les contraintes et la lecture des rapports répondent à des questions différentes.
Avant d'optimiser, il faut vérifier :
les largeurs et le signe de chaque calcul ;
l'absence de latch involontaire ;
la présence des registres attendus ;
l'inférence des RAM et des DSP souhaités ;
les avertissements de signaux non pilotés, constants ou tronqués.
Un délai RTL ne répare pas le timing
Écrire #2 dans le RTL ne demande pas au FPGA de rendre un chemin plus rapide. Les délais de simulation ne constituent pas une architecture synthétisable portable.
Pour réduire un chemin combinatoire trop long, on peut :
ajouter un étage de pipeline ;
réorganiser un calcul en arbre ;
partager moins de logique sur le même cycle ;
utiliser une ressource dédiée ;
revoir la fréquence ou le protocole si le cahier des charges le permet.
Au premier front, les deux sommes partielles sont enregistrées. Au front suivant, leur somme est enregistrée dans o_sum et o_valid reprend le i_valid associé. Les affectations non bloquantes garantissent que le second calcul utilise les anciennes valeurs de pair_ab et pair_cd, pas celles calculées sur le même front.
Le bloc peut accepter un nouveau groupe de quatre opérandes à chaque cycle. Sa latence n'empêche donc pas un débit d'un résultat par cycle une fois la pipeline remplie.
Calculer les largeurs avant d'écrire
Deux nombres non signés de WIDTH bits demandent WIDTH + 1 bits pour conserver la retenue. La somme de quatre valeurs demande WIDTH + 2 bits. Les concaténations du module étendent explicitement les opérandes avant l'addition.
Sans cette extension, une retenue peut être perdue avant même l'affectation dans une sortie plus large.
Les contraintes décrivent l'environnement
L'analyse de timing a besoin de connaître au moins la période des horloges et, selon l'interface, les délais d'entrée et de sortie. Un rapport vert sans contrainte correcte ne prouve pas que le circuit fonctionnera sur la carte.
Une fausse route ou une route multicycle ne doit pas servir à cacher un échec. Elle doit correspondre au comportement réel du protocole et être justifiée.
Méthode de lecture d'un RTL inconnu
Pour comprendre un petit module :
relever l'interface et le sens du handshake ;
repérer chaque registre et sa condition de mise à jour ;
suivre une donnée sur plusieurs fronts ;
calculer la largeur maximale des opérations ;
noter les cas de reset, de blocage et de simultanéité ;
comparer cette lecture au testbench et au rapport de synthèse.
Sur pipelined_sum4, les bonnes questions sont simples : quand une entrée est-elle acceptée, quel o_valid lui correspond, combien de groupes peuvent être en vol et que se passe-t-il pendant le reset ?
À retenir
La synthèse traduit le code, elle ne valide pas le cahier des charges.
Un chemin trop long se corrige par l'architecture et les contraintes, pas avec #.
Le pipeline échange de la latence contre un chemin combinatoire plus court.
Les largeurs intermédiaires doivent être correctes avant l'affectation finale.
Une analyse de timing n'a de valeur qu'avec des contraintes justes.