Synthèse efficace d'une fonction 4-à-1 dans Verilog

Question

Je dois mettre en œuvre une fonction 4-to-1 dans Veriog. L'entrée est 4 bits, un nombre compris entre 0 et 15. La sortie est un seul bit, 0 ou 1. Chaque entrée donne une sortie différente et la correspondance entre les entrées et les sorties est connue, mais les entrées et les sorties ne le sont pas. Je veux que vcs optimise le code avec succès et qu'il soit aussi court/soigné que possible. Ma solution à ce jour:

wire [3:0] a; 
wire b; 
wire [15:0] c; 

assign c = 16'b0100110010111010; //for example but could be any constant 
assign b = c[a]; 

avoir à déclarer c est laid et je ne sais pas si VCS reconnaîtra la K-carte là. Est-ce que cela fonctionnera aussi bien qu'une déclaration de cas ou une affectation sous forme normale conjonctive?

Answer 1

Ce que vous avez est bon. Une déclaration de cas fonctionnerait également bien. C'est juste une question d'expressivité que vous souhaitez être.

Votre solution, l'indexation, fonctionne correctement si les encodages sélectionnés n'ont pas de signification particulière (un sélecteur d'adresse mémoire par exemple). Si les encodages sélectionnés ont une signification sémantique particulière pour vous, le concepteur (et ils ne sont pas nombreux), alors allez avec une instruction case et enums.

Synthèse sage, peu importe celle que vous utilisez. Tout outil de synthèse décent produira le même résultat.

Answer 2

Ma préférence - si cela a du sens pour votre problème - est pour une déclaration de cas qui utilise des énumérations ou `définit. Tout pour faciliter l'examen du code, la maintenance et la vérification.

Answer 3

Je suis totalement d'accord avec Dallas. Utilisez une déclaration de cas - cela rend votre intention plus claire. L'outil de synthèse le construira comme une table de correspondance (s'il est parallèle) et optimisera tout ce qu'il peut.

En outre, je ne m'inquiéterais pas tellement de garder votre code RTL court. Je tirerais pour la clarté d'abord. Les outils de synthèse sont plus intelligents que vous ne le pensez ...

Answer 4

Pour des choses comme ça, la clarté RTL l'emporte de loin. SystemVerilog a toujours des directives spéciales de blocage pour indiquer clairement quand le bloc doit être synthétisé en logique combinatoire, verrous ou flops (et votre outil de synthèse devrait renvoyer une erreur si vous avez écrit RTL qui est en conflit avec cela (par ex. liste de sensibilité d'un bloc toujours). Sachez également que l'outil remplacera probablement l'encodage le plus efficace du point de vue matériel (celui qui minimise la surface totale de votre dessin), sauf si le codage lui-même se propage aux broches

Ce conseil va en général aussi, rendre votre code facile à comprendre par l'homme, et il sera probablement plus compréhensible à l'outil de synthèse, ce qui lui permet d'apporter plus efficacement littéralement milliers d'homme-années de recherche d'algorithmes à supporter sur votre RTL.

Vous pouvez coder également à l'aide d'opérateurs ternaires si vous voulez, mais je préférerais quelque chose comme:

always_comb //or "always @*" if you don't have an SV-enabled tool flow 
begin 
    case(a) 
    begin 
    4'b0000: b = 1'b0; 
    4'b0001: b = 1'b1; 
    ... 
    4'b1111: b = 1'b0; 
    //If you don't specify a "default" clause, your synthesis tool 
    //Should scream at you if you didn't specify all cases, 
    //Which is a good thing (tm) 
    endcase //a 
end //always 

Answer 5

Apparemment, je me sers d'un outil de synthèse moche. :-) Je viens de synthétiser les deux versions (juste le module en utilisant un modèle basé sur des ventilateurs pour les retards de fils) et la version d'indexation de la question donnait de meilleurs résultats de timing et de surface que les instructions de cas. Utilisation de Synopsys DC Z-2007.03-SP.