VHDL-méthode plus rapide?

[indri]

Bonjour,

Je me demandais si c'est deux facon de programmer une sorte de démultiplexeur, laquelle est la plus rapide (utilise la moins de ressource du fpga?).

Peut importe le nombre de LEs, c'est surtout la transition que je veux optimiser.

out_re<= 	out_re1 when modulation="01" else
			out_re2 when modulation="10" else
			out_re3 when modulation="11";
			
out_im<= 	out_im1 when modulation="01" else
			out_im2 when modulation="10" else
			out_im3 when modulation="11";

Ou:

process(out_re1,out_re2,out_re3,out_im1,out_im2,out_im3,modulation)
begin
	case modulation is
			when "01" =>
				out_re<=out_re1;
				out_im<=out_im1;
			when "10"=>
				out_re<=out_re2;
				out_im<=out_im2;
			when "11"=>
				out_re<=out_re3;
				out_im<=out_im3;
			when others =>
				out_re<="0000";
				out_im<="0000";
	end case;
end process;

D'abords est-ce que ca fait bien la même chose (en sachant que je me fou royalement de ce qui se passe dans les autres config que ces 3 là)? J'avais jamais utilisé la première facon donc pas trop sur que ca marche bien.
Sinon comment voir la différence du temps que ca prend? (me dite pas l'oscillo, à 5ns de différence ca va pas le faire^^) sur quartus?

Bav!
-----

[invite71a6c60d]

j'aurais tendance a penser que la deuxieme est plus rapide mais honetement sur une expression aussi courte ca va pas jouer des masse


Pour verifier je sais que sous Xilinx tu peux visualiser le hardware que tu crée avec ton code

[indri]

Oui mais y'a pas que ca...Dans le process global j'ai des erreurs de timing et nottament tout un bloc de logique combinatoire (3 "case" imbriqué) non clocké qui est trop lente pour le reste du disign qui lui est clocké...

Et donc voir quelle méthode serait la plus efficace pour voir si je dois tout changé ou pas ^^

[invite71a6c60d]

je crois que le mieux (si tu le peux) c'est que tu nous montre tout ton code qu'on puisse y voir plus clair

[A voir en vidéo sur Futura]

[indri]

Oui bon apparement pour cet exemple là, le compilateur le fait de la même facon (x démultiplexeur) d'après ce que j'ai vu sur RTL viewer...merci de m'avoir fait penser à ca!

Pour le code ca va pas être trop possible, pas envie de flooder ^^

[jiherve]

Bonjour,
au niveau synthèse c'est la même chose à un détail près :
la première écriture infère un latch, le cas "00" n'étant pas décrit, c'est un péché mortel pour quelqu'un voulant se lancer dans le VHDL!
Je pense que si le compilo ne sortait pas une erreur lorsqu'il manque le 'when others' il y aurait eu la même erreur dans le case.
JR

[jiherve]

Re
pour la vitesse attention au nombre de signaux/variaibles nécessaire à l'élaboration d'une sortie, en fonction de la famille cible au dela de 4,6,8 termes alors il y a cascadage/chainage de LCELL/ALUT et la fréquence tombe.
la solution c'est le pipeline.
N'oublie pas non plus que l'analyse de timing est incapable de détecter les branches logiques ne devant pas fonctionner à la fréquence d'horloge.
Ces branches doivent être identifiées par la propriété multiclock cycle.
JR

[indri]

péché mortel carrement ^^.
Arf dommage qu'on sache pas "mesurer" des process non clocké. Pourtant c'est jamais que des temps de réponses des portes logiques à additioner non?
On m'avait déjà parlé aussi du pipelining mais encore jamais mis en oeuvre.

[jiherve]

Re
oui péché mortel car un latch suppose une réaction de la sortie sur l'entrée et l'absence de glitch dans la logique combinatoire or ce n'est pas garanti sauf cas bien spécifiques.
Donc un design qui contient un latch est un design peu sur, il est d'ailleurs détecté par le design assistant de Quartus.
Pour estimer le temps d'un processus combinatoire comme il n'est guère possible maintenant de faire la calcul à la main car tout ou partie du routage est inaccessible la solution la plus simple c'est de placer le bout de logique entre deux FF et regarder ce que donne l'analyse de timing.
Ceci dit avec Timequest c'est faisable mais nettement moins immédiat!
JR

[stefjm]

péché mortel carrement ^^.

Oui.
Aussi bien du point de vue théorique, que pratique. (Pour une fois que la théorie sert à quelque chose...)