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

Question

Je dois implémenter une fonction 4 pour 1 dans Veriog.L'entrée est de 4 bits, un nombre de 0 à 15.La sortie est un seul bit, 0 ou 1.Chaque entrée donne une sortie différente et le mappage des entrées aux sorties est connu, mais les entrées et sorties elles-mêmes ne le sont pas.Je veux que VCS réussisse à optimiser le code et qu'il soit aussi court/précis que possible.Ma solution jusqu'à présent:

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

Devoir déclarer c est moche et je ne sais pas si vcs y reconnaîtra la K-map.Cela fonctionnera-t-il aussi bien qu'un énoncé de cas ou une mission sous forme normale conjonctive ?

Answer 1

Ce que tu as est bien.Une déclaration de cas fonctionnerait également bien.C'est juste une question de savoir à quel point vous souhaitez être expressif.

Votre solution, l'indexation, fonctionne bien 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 qu'ils ne sont pas nombreux), utilisez une instruction case et des énumérations.

Du point de vue de la synthèse, peu importe celui que vous utilisez.Tout outil de synthèse décent produira le même résultat.

Answer 2

Je suis entièrement d'accord avec Dallas.Utilisez une déclaration de cas - cela rend votre intention plus claire.L'outil de synthèse le construira sous forme de table de recherche (si elle est parallèle) et optimisera tout ce qu'il peut.

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

Answer 3

Ma préférence - si cela a du sens pour votre problème - va à une instruction case qui utilise des énumérations ou des définitions.Tout pour faciliter la révision, la maintenance et la vérification du code.

Answer 4

Pour des choses comme celle-ci, la clarté RTL l’emporte largement.SystemVerilog a des directives spéciales Always Block pour indiquer clairement quand le bloc doit synthétiser en logique combinatoire, en verrous ou en échecs (et votre outil de synthèse doit générer une erreur si vous avez écrit un RTL qui entre en conflit avec cela (par ex.n'incluant pas tous les signaux dans la liste de sensibilité d'un bloc Always).Sachez également que l'outil remplacera probablement tout encodage dont vous disposez par l'encodage le plus efficace sur le plan matériel (celui qui minimise la surface de votre conception totale), à ​​moins que l'encodage lui-même ne se propage aux broches de votre module de niveau supérieur.

Ce conseil s’applique également en général.Rendez votre code facile à comprendre par les humains, et il sera probablement également plus compréhensible pour l'outil de synthèse, ce qui lui permettra de traduire plus efficacement littéralement milliers d'années-homme de recherche d'algorithmes à porter sur votre RTL.

Vous pouvez également le coder en utilisant des opérateurs ternaires si vous le souhaitez, 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, j'utilise un mauvais outil de synthèse.:-) Je viens de synthétiser les deux versions (juste le module utilisant un modèle basé sur des sortances pour les retards de fil) et la version d'indexation de la question a donné de meilleurs résultats en termes de timing et de zone que les déclarations de cas.Utilisation de Synopsys DC Z-2007.03-SP.