Silicium HFR: blabla @ Electronique

Recherche :

Mot : Pseudo : Filtrer Aller à la page :
Page : 1 2 3 4 5 .. 376 377 378 .. 480 481 482 483 484 485 Page Suivante Page Précédente Bas de page
Auteur	Sujet : Silicium HFR: blabla @ Electronique

rat de combat

attention rongeur méchant!

Reprise du message précédent :
Plop

Y'a des gens qui bossent dans le monde des FPGA ici? Je tente (une fois de plus) de comprendre ce monde et j'ai du mal. Le Verilog au niveau syntaxe aucun soucis, mais le reste...

Publicité

zeql_

C'est-à-dire ?

Un FPGA est fait de portes logiques (pour simplifier). On ne programme pas forcément quelque chose de séquentiel comme sur un microcontrôleur mais des fonctions qui peuvent s'exécuter à la suite mais aussi en parallèle.

Pour simplifier très très grossièrement, avec un FPGA, tu peux avoir des fonctions AND, OR, XOR en parallèles qui fonctionnent indépendamment alors que sur un microcontrôleur, chaque fonction sera effectuée à la suite.

D'autre part les langages sont plus des langages de "description" (HDL = Hardware Description Language) que de "programmation". Il n'y a pas de compilateur mais un synthétiseur qui vient interpréter ton code pour le transformer en circuits internes.

rat de combat

attention rongeur méchant!

Oui merci, ça je sais.

Je vais expliquer mon soucis: J'ai un module (Verilog comme je disais) qui sort des données (reg [31:0]) et un signal "data_valid" pour dire à un autre module Verilog qui est "connecté" de lire ces données.

Le soucis c'est que je ne connais pas les bonnes pratiques: Est-ce que le signal "data_valid" doit se mettre à 1 au même moment (au même front d'horloge) où les données apparaissent sur la sortie du module ou un cycle avant pour laisser le temps à l'autre module de "remarquer" que des données vont arriver? Car les modules sont des FSM en interne et du coup il y a toujours (au moins) un cycle d'horloge de latence... Je suis un peu perdu. Je crains que ce soit pas très clair non? Je peux fournir plus de détails.

Pour info j'utilise Icarus Verilog et Gtkwave pour mes simulations (et plus tard Yosys pour synthétiser pour FPGA Lattice).

---------------
-/-

rat de combat

attention rongeur méchant!

Bon, je tente le coup. Voici un exemple codé selon mon livre de cours (j'espère ) mais qui ne fonctionne pas à cause justement de ces fichus latences. Et là je suis perdu, car dans le monde logique programmable/Verilog je ne connais pas les bonnes pratiques et mon livre n'en parle pas vraiment ou que très peu. J'ai bien sûr regardé sur internet mais je suis toujours perdu.

L'exemple est très basique et ne fait rien d'utile, c'est juste pour montrer. Désolé c'est un peu long mais j'essaye de donner un exemple complet, en prog' on dirait "exemple qui compile".

Il y a un TX qui envoye régulièrement une série de mots (3 actuellement) le plus vite possible et un RX qui doit recevoir ça et - dans l'exemple - les mettre dans une petite mémoire.

Question: Comment décrire ça "proprement" / quelles sont les bonnes pratiques pour ce genre de situation?

fpga.v:

`timescale 1ns/1ps

module fpga(input wire clk, input wire btn);

wire btn_synced;
wire [31:0] data;
wire data_valid;

mod_sync sync_btn(.clk_i(clk), .sig_in(!btn), .sig_out(btn_synced));

mod_tx tx(.clk_i(clk), .start_i(btn_synced), .data_o(data), .data_valid_o(data_valid));

mod_rx rx(.clk_i(clk), .data_i(data), .data_valid_i(data_valid));

endmodule

sync.v:

`timescale 1ns/1ps

module mod_sync(input wire clk_i, input wire sig_in, output reg sig_out);

reg ff1, ff2, ff3;
initial ff1=1'd0;
initial ff2=1'd0;
initial ff3=1'd0;

always @(posedge clk_i) begin
ff1<=sig_in;
ff2<=ff1;
ff3<=ff2;
sig_out<=ff3;
end endmodule

test.v:

`timescale 1ns/1ps

module tb;

reg clk;
reg btn;

initial begin
$dumpfile("test.vcd" );
$dumpvars(0,tb);
clk=1;
btn=1;
#10_000 $finish;
end

always #5 clk=!clk; //100MHz

fpga _fpga(.clk(clk), .btn(btn));

initial begin
#500 btn=0;
#100 btn=1;
end

endmodule

tx.v:

`timescale 1ns/1ps

module mod_tx(

input wire clk_i,

input wire start_i,

output reg [31:0] data_o,

output reg data_valid_o
);

initial data_valid_o=0;

`define STATE_TX_IDLE 0
`define STATE_TX_WAIT 1
`define STATE_TX_SEND 2

reg [1:0] state=`STATE_TX_IDLE;
reg [1:0] state_next=`STATE_TX_IDLE;

reg [4:0] wait_counter=0;
wire wait_done=wait_counter[4];

reg [1:0] send_counter=0;
wire send_done=(send_counter==3);

reg [31:0] data=0;

always @(posedge clk_i) begin
state<=state_next;

case (state)
`STATE_TX_IDLE: if(start_i) state_next<=`STATE_TX_WAIT;
`STATE_TX_WAIT: if(wait_done) state_next<=`STATE_TX_SEND;
`STATE_TX_SEND: if(send_done) state_next<=`STATE_TX_WAIT;
endcase
end

always @(posedge clk_i) begin
case (state)
`STATE_TX_IDLE: ;
`STATE_TX_WAIT: begin wait_counter<=wait_counter+1; send_counter<=0; end
`STATE_TX_SEND: if(!send_done) begin
data_valid_o<=1;
data_o<=data;
data<=data+1;
wait_counter<=0;
send_counter<=send_counter+1;
end else
data_valid_o<=0;

endcase
end

endmodule

rx.v:

`timescale 1ns/1ps

module mod_rx(

input wire clk_i,

input wire [31:0] data_i,

input wire data_valid_i
);

`define STATE_RX_WAIT 0
`define STATE_RX_SAMPLE 1

reg state=`STATE_RX_WAIT;
reg state_next=`STATE_RX_WAIT;

reg [31:0] memory[7:0];
reg [2:0] counter=0;

//little hack to view memory content in GTKWave...
wire [31:0] memory0=memory[0];
wire [31:0] memory1=memory[1];
wire [31:0] memory2=memory[2];
wire [31:0] memory3=memory[3];
wire [31:0] memory4=memory[4];
wire [31:0] memory5=memory[5];
wire [31:0] memory6=memory[6];
wire [31:0] memory7=memory[7];

always @(posedge clk_i) begin
state<=state_next;

case (state)
`STATE_RX_WAIT: if(data_valid_i) state_next<=`STATE_RX_SAMPLE;
`STATE_RX_SAMPLE: if(!data_valid_i) state_next<=`STATE_RX_WAIT;
endcase
end

always @(posedge clk_i) begin
case (state)
`STATE_RX_WAIT: ;
`STATE_RX_SAMPLE: begin memory[counter]<=data_i; counter<=counter+1; end
endcase
end

endmodule

iverilog -Wall -o basic_test tx.v rx.v fpga.v sync.v test.v && vvp basic_test

Message cité 1 fois

---------------
-/-

zeql_

Premièrement en Europe on fait surtout du VHDL, donc partir sur du Verilog c'est trouver beaucoup moins de ressources en français.

Ensuite j'en ai fait en école d'ingé mais ça fait un moment que je n'ai plus touché. Mais en général on code avec une cible en tête. Là avoir un truc générique et juste des chronogrammes, c'est un peu déprimant et pas facile à appréhender.

Là je ne sais pas trop ce que tu veux faire.
Le mieux est de partir sur des classiques :

Pilotage d'un afficheur 7 segments
RS-232
I2C, SPI
VGA

Ce site propose des projets avec du code Verilog : https://www.fpga4fun.com/

Idéalement acheter une petite carte de développement comme la Terasic DE0 ou la Digilent Basys 2 (ou la 3) mais neuf ça coûte autour de 150-200€.

(Ca tombe bien je vends une DE0 comme neuve pour 50€ : https://forum.hardware.fr/forum2.ph [...] #t26706253 )

Message cité 2 fois

periaz

This is pure art...

rat de combat a écrit :

Bon, je tente le coup.

Salut !

Tu branches quoi sur ton entrée btn ? Si tu branches dessus un pushbutton qui vient de ta carte, c'est mieux d'utiliser un module debouncer plutôt qu'un resynchronizer à 2 ou 3 flip flops. C'est fait pour ça justement. Je te laisse regarder debouncer sur le net.

Pour répondre à ta question sur comment passer des données entre blocs, la règle générale est de mettre VALID à '1' en même temps que tu as une DATA valide.
Donc tu updates VALID et DATA au même moment, sur le même front d'horloge.
Il y a des protocoles pour faire ce que tu veux, c'est à dire de la communication inter modules (modules en Verilog, entités en VHDL). Par exemple, l'AXI-Stream est un protocole unidirectionnel pour échanger des données d'un module vers un autre.
En AXI-Stream, tu as comme signaux principaux : VALID, READY et DATA. Le signal READY te permet de gérer la backpressure, c'est à dire empêcher le module qui envoie des données d'en envoyer davantage si le module qui les reçoit n'est pas/plus prêt.

Le signal READY est optionnel en AXI Stream, donc on se retrouve dans ton cas, VALID et DATA seulement.
Le protocole indique donc qu'il faut mettre VALID à '1' quand tu as une donnée DATA qui est valide et au cycle d'après, tu dois remettre VALID à '0' pour que ton signal DATA ne soit pas lu 2 fois (-> en fait, tu peux laisser VALID à '1' mais il faut dans ce cas que ton signal DATA soit mis à jour à chaque cycle d'horloge, tu peux regarder les chnonogrammes de la spécification de l'AXI-Stream qui est disponible sur le net aussi).

Pour tes FSM, il y a des conventions que tu peux choisir de respecter ou non. Cela dépend aussi de la FSM que tu souhaites faire (Mealy ou Moore ou un mix des deux).
Mais dans l'industrie, beaucoup de personnes (je ne dis pas que c'est bien ou mauvais, je te laisse prendre ton partie) préfère utiliser 2 process / 2 always block pour coder leur FSM :
- un process combinatoire qui va driver tes signaux en fonction des états de ta FSM et mettre à jour le signal state_next
- un process clocké qui va mettre à jour l'état de ta FSM pour passer au suivant (en utilisant state_next)
Tu te retrouves avec quelque chose comme ca :

always @(posedge clk_i)
state <= state_next;

always @(*) begin
// en fonction de tes cas, tu affectes la valeur qu'il faut à state_next
end

Tu peux te demander, mais dans ce cas on ne registre que la valeur de l'état et pas les sorties de la FSM ? Et bien c'est toi qui choisit :pt1cable: as tu besoin de performance ? as tu vraiment besoin de registrer les signaux de sortie de ta FSM ?

Pour ton bloc rx.v, tu n'es pas obligé de faire une FSM. Tu peux faire quelque chose de très simple comme cela :

always @(posedge clk_i) begin
if (data_valid_i) begin
memory[counter] <= data_i;
counter <= counter + 1;
end
end

Il y a peut être quelques coquilles dans le Verilog, j'en lis pas mal au boulot mais j'en écris très rarement (je préfère le VHDL mais c'est un autre débat :jap: )

Si je peux te conseiller quelque chose, c'est de ne pas utiliser les FSM à outrance.
Je trouve, malheureusement, qu'on nous enseigne les FSM comme le nec plus ultra aussi bien dans les livres qu'en école / université.
Alors oui c'est très pratique, on a l'impression de faire un automate, c'est cool. Mais à l'usage, c'est :
- difficile à vérifier (surtout quand on a des grosses FSM avec pleins d'états différents, plein de transitions d'états)
- difficile à maintenir quand un nouvel utilisateur passe sur le code
- dans certains cas, c'est compliqué à pipeliner

Bon courage !

Message cité 1 fois

manisque

zeql_ a écrit :

Premièrement en Europe on fait surtout du VHDL, donc partir sur du Verilog c'est trouver beaucoup moins de ressources en français.

Ensuite j'en ai fait en école d'ingé mais ça fait un moment que je n'ai plus touché. Mais en général on code avec une cible en tête. Là avoir un truc générique et juste des chronogrammes, c'est un peu déprimant et pas facile à appréhender.

Je ne suis vraiment pas un expert vu que je n'ai jamais fait plus que clignoter des LEDs, mais IMO, la première phrase est incorrecte .

De ce que j'ai entendu de pas mal de numériciens Européens, le langage VHDL est plus généralement utilisé dans l'enseignement et dans la recherche académique, et le langage Verilog plus utilisé dans des projets industriels/ASIC. Et ça à l'air d'une habitude qui n'a pas vraiment de lien avec ce que ces langages permettent de faire.

Message cité 1 fois
Message édité par manisque le 21-05-2023 à 11:55:33

---------------
Si tu bois froid juste après le potage chaud, ça va faire sauter l'émail de tes dents - Monorailcat iz ohverin

zeql_

manisque a écrit :

Je ne suis vraiment pas un expert vu que je n'ai jamais fait plus que clignoter des LEDs, mais IMO, la première phrase est incorrecte .

Sur cible FPGA (et pas conception ASIC) :
J'ai fait 2 grosses boites d'aéro -> VHDL
Des anciens camarades d'écoles d'ingé qui étaient dans une autre boite d'aéro -> VHDL
Passage dans l'automobile -> VHDL
Ma boite actuelle qui fait des produits vidéo -> VHDL

Et les quelques livres que j'ai vu sur le VHDL c'est souvent écrit par des Européens.

J'ai dit qu'on faisait surtout du VHDL, ça ne veut pas dire qu'il n'y a pas de Verilog ou que c'est inexistant. Après c'est aussi à cause de l'industrie européenne qui est principalement militaire et spatiale forme donc beaucoup d'ingénieur au VHDL, donc quand ils partent dans d'autres domaines, ils gardent leur habitudes.

Message cité 1 fois
Message édité par zeql_ le 21-05-2023 à 12:35:22

rat de combat

attention rongeur méchant!

Merci à vous! :jap:

zeql_ a écrit :

Premièrement en Europe on fait surtout du VHDL, donc partir sur du Verilog c'est trouver beaucoup moins de ressources en français.

Oui je sais, mais perso je trouve le VHDL horrible et surtout Yosys (le toolchain libre) ne supporte que le Verilog. D'ailleurs ce même toolchain ne supporte pas les Cyclone, sinon on aurait fait affaire depuis longtemps concernant ta carte de dév. J'en veux pas des toolchains proprio, j'ai le souvenir que c'est des usines à gaz, sans parler des histoires de licence et que je suis sous Linux...

zeql_ a écrit :

Mais en général on code avec une cible en tête. Là avoir un truc générique et juste des chronogrammes, c'est un peu déprimant et pas facile à appréhender.

J'ai une carte de dév et des projets concrèts, mais j'en ai pas parlé pour différentes raisons. J'ai déjà fait du RS-232, clignoter des LED, chenillards etc; [EDIT: et aussi afficher quelque carrés sur un écran sans contrôleur, la petite vidéo doit être quelque part dans le forum sous forme de lien] mais tout ça c'est de la "basse vitesse" et le truc auquel je me cogne c'est comment coder proprement pour avoir une vitesse maxi correcte en sortie de synthèse. Y'a pas de -O3 pour Yosys. Merci pour le fpga4fun, j'ai déjà regardé.

periaz a écrit :

Tu branches quoi sur ton entrée btn ? Si tu branches dessus un pushbutton qui vient de ta carte, c'est mieux d'utiliser un module debouncer plutôt qu'un resynchronizer à 2 ou 3 flip flops. C'est fait pour ça justement. Je te laisse regarder debouncer sur le net.

Merci, je vais regarder ça. Je connais bien le soucis du rebond pour faire pas mal de µC. Ici le BP sert juste à lancer tout le bazar, donc le rebond on s'en fiche un peu. Mais autant bien faire puisque je demande les bonnes pratiques!

periaz a écrit :

Pour répondre à ta question sur comment passer des données entre blocs, la règle générale est de mettre VALID à '1' en même temps que tu as une DATA valide. [...]

Merci beaucoup pour ces infos fort utiles!

periaz a écrit :

Pour tes FSM, il y a des conventions que tu peux choisir de respecter ou non. Cela dépend aussi de la FSM que tu souhaites faire (Mealy ou Moore ou un mix des deux).

Mealy et Moore mon bouquin en parle, mais j'ai du mal car je pense toujours de manière séquentielle venant du monde de la programmation... Du coup mes bricolages se terminent en un affreux mélange des deux variantes souvent. Faut que je m'entraîne.

periaz a écrit :

Pour ton bloc rx.v, tu n'es pas obligé de faire une FSM.

Oui bien sûr, c'était pour l'exemple, en réalité le bloc serait beaucoup plus complexe.

periaz a écrit :

Si je peux te conseiller quelque chose, c'est de ne pas utiliser les FSM à outrance.
Je trouve, malheureusement, qu'on nous enseigne les FSM comme le nec plus ultra aussi bien dans les livres qu'en école / université.[...]

C'est pas faux... Le soucis des FSM c'est que c'est pas évident à écrire proprement surtout, rien que de bien choisir la variante (Mealy/Moore) qu'on veut et de respecter ça tout au long du "code"...

periaz a écrit :

Bon courage !

Merci, j'en ai besoin. :lol: La où ça commence à devenir vraiment "drôle" c'est le CDC (clock domain crossing) p.ex., j'avais regardé ça croyant que "ah ben ça doit être simple", je suis tombé de haut.

Message édité par rat de combat le 21-05-2023 à 13:20:40

---------------
-/-

periaz

This is pure art...

Assez d'accord avec @zeql_ concernant l'utilisation du VHDL en Europe : l'industrie (à majorité militaire, spatial, automotive) utilise quasiment que le VHDL en design, en vérification ca dépend (VHDL ou SystemVerilog).
J'ai eu des retours de personnes travaillant pour les grands EDA (Cadence, Mentor, Synopsys). Ils me disaient que le support est meilleur du Verilog (SystemVerilog) car ils ont beaucoup plus d'exemples et de codes partagés par les fabriquants d'ASIC pour améliorer leurs outils. En effet, comme le VHDL est souvent utilisé dans des projets sensibles (défense, NDA national, etc.), ils récupèrent moins de code de leurs clients

Pour les FSM, tu n'es pas obligé de respecter scrupuleusement Mealy ou Moore. Honnêtement, je pense que c'est bien de les connaitre lors des entretiens, après c'est plutôt les performances attendus qui vont te dire vers quoi tu te diriges.
Comme je le disais, on est souvent confronté à :
- est ce que je veux registrer les sorties de la FSM ? Ou bien que ce soit des chemins combinatoires qui prennent en input les états et les entrées de la FSM ?
Il ne faut pas vouloir tout registré, car parfois c'est inutile si tu n'es pas sur le chemin critique.

Pour les CDC, oui c'est une autre paire de manche.
Tout dépend si tu utilises des primitives fournies par le logiciel ou pas, ca peut te simplifier la vie.
Si tu veux le faire toi même, alors je te conseille la bible du CDC : http://www.sunburst-design.com/pap [...] on_CDC.pdf
Ca explique tout, donne les bonnes techniques. C'est un "vieux" document mais il est toujours d'actualité

Si tu voulais faire du VHDL, il me semble que GHDL supporte la conversion de VHDL en Verilog pour ensuite être utilisé par Yosys.
Idem, il existe un plugin GHDL pour Yosys pour qu'il puisse justement lire le VHDL (mais c'est en beta il me semble).

J'avais une petite carte Intel (anciennement Altera) que j'utilisais il y a 5 ans avec Quartus, honnêtement j'ai pas vraiment été limité par le logiciel même en version gratuite.

Message cité 1 fois

Publicité

manisque

zeql_ a écrit :

Sur cible FPGA (et pas conception ASIC) :
J'ai fait 2 grosses boites d'aéro -> VHDL
Des anciens camarades d'écoles d'ingé qui étaient dans une autre boite d'aéro -> VHDL
Passage dans l'automobile -> VHDL
Ma boite actuelle qui fait des produits vidéo -> VHDL

Et les quelques livres que j'ai vu sur le VHDL c'est souvent écrit par des Européens.

J'ai dit qu'on faisait surtout du VHDL, ça ne veut pas dire qu'il n'y a pas de Verilog ou que c'est inexistant. Après c'est aussi à cause de l'industrie européenne qui est principalement militaire et spatiale forme donc beaucoup d'ingénieur au VHDL, donc quand ils partent dans d'autres domaines, ils gardent leur habitudes.

Ça doit-être la différence .
Je vois surtout de la conception/vérification ASIC dans mon entourage, et par conséquence, tous les outils annexes sur cible FPGA sont en verilog .

---------------
Si tu bois froid juste après le potage chaud, ça va faire sauter l'émail de tes dents - Monorailcat iz ohverin

rat de combat

attention rongeur méchant!

periaz a écrit :

Pour les FSM, tu n'es pas obligé de respecter scrupuleusement Mealy ou Moore. Honnêtement, je pense que c'est bien de les connaitre lors des entretiens, après c'est plutôt les performances attendus qui vont te dire vers quoi tu te diriges.
Comme je le disais, on est souvent confronté à :
- est ce que je veux registrer les sorties de la FSM ? Ou bien que ce soit des chemins combinatoires qui prennent en input les états et les entrées de la FSM ?
Il ne faut pas vouloir tout registré, car parfois c'est inutile si tu n'es pas sur le chemin critique.

Je dirais que pour un rongeur débutant c'est peut-être bien de respecter un minimum les formalismes, après quand on évolue on peut être plus libéral dans ce qu'on fait (mais pas trop ).

Merci pour le lien sur les CDC, je regarderai ça le moment venu. Pour l'instant je vais me limiter à une seule horloge. :whistle:

Oui il y a une histoire de plugin pour Yosys pour le VHDL, mais comme tu dis c'est en beta je crois et de toute façon je trouve le VHDL horrible. Et je bricole dans un cadre strictement perso, j'ai pas l'intention de faire ça comme boulot (de toute façon n'étant pas ingé j'aurais franchement du mal dans l'aéronautique etc et jamais je ne bosserai pour les militaires), donc autant choisir le language qui me va mieux...

Le soucis avec les toolchains des fabriquants c'est pas d'être limité pour mes petits bricolages, mais plutôt qu'il faut probablement s'enregistrer quelque part et/ou avoir une connection internet active tout le temps et/ou c'est des gros, gros logiciels bien lourd etc. Je préfère autant que possible le FOSS.

Message cité 1 fois
Message édité par rat de combat le 21-05-2023 à 15:29:43

---------------
-/-

periaz

This is pure art...

rat de combat a écrit :

Tu ne sais pas ce que tu rates... J'arrête
Oui tu peux faire la même chose avec les deux donc si tu fais du soft déjà, normal que tu te diriges vers le Verilog, ça ressemble beaucoup au C.
Quoi que le VHDL ça vient de l'ADA

rat de combat a écrit :

Je suis bien d'accord avec toi, autant utiliser le FOSS dès qu'on peut.
Mais on est assez vite limité, c'est le problème. J'espère vraiment que cette décennie va voir se développer beaucoup plus d'outils FOSS pour tout ce qui tourne autour des HDL.

Message cité 1 fois

rat de combat

attention rongeur méchant!

periaz a écrit :

Mais on est assez vite limité, c'est le problème.

C'est sûr. Les toolchains proprio ont modules tout fait configurables, mais pas (pour l'instant) les toolchains libres.

---------------
-/-

rat de combat

attention rongeur méchant!

Encore moi.

Quelqu'un peut me conseiller un peu de lecture (pas de soucis si c'est en anglais) concernant les "critical path report"? Il y en a un exemple ici, ceux de mes bricolages ont le même format et j'y pige rien... Je comprend bien sûr l'idée, la vitesse de propagation des signaux est finie et plus on a de logique dans un chemin plus c'est lent donc f_max est basse; mais de là à comprendre ce que dit nextpnr... En prog on a des profiler qui disent clairement "fonction X prend Y temps", en logique programmable on ne peut pas faire pareil bien sûr mais il doit être possible d'avoir des infos comment optimiser son design?

(J'ai pas mal bricolé en utilisant au max la logique combinatoire, mais du coup f_max est catastrophique et je ne sais pas OÙ mettre mes registres pour arranger/améliorer ça. Malheureusement je ne pourrais/veux pas dire plus sur mon projet concret , mais la question est générale et il y a un exemple de timing report dans le lien. Il y a aussi un script pour réarranger les infos mais il ne fonctionne plus visiblement.)

:??:

periaz

This is pure art...

Hello !

Oui le timing report est bien dégueu je trouve, j'en avais jamais lu de Yosys et c'est pas joli
L'outil qui permet de clarifier le timing report dans ton lien est déjà bien meilleur pour lire ce qu'il se passe.

Là, on observe qu'il y a pas mal d'étages combinatoires, beaucoup de LUT4 impliquées sur le même chemin.

C'est dur pour un synthétiseur d'optimiser comme le ferait un compilateur en soft. Il y a bien des techniques pour grapiller par ci par là des MHz mais tu ne pourras pas avoir un changement radical de ton design opéré par le synthétiseur.

Si tu veux gagner en fréquence, tu dois casser les chemins combinatoires et mettre + de registres.
Et ça, le synthétiseur ne peut pas le deviner car s'il le faisait de lui-même, il changerait le comportement de ton design et ce ne serait plus déterministe.

Il y a bien des outils qui supportent ce qu'on appelle le register retiming mais je ne suis pas sûr que Yosys le supporte. Dans mon domaine, on ne préfère pas l'utiliser car il n'y a pas toujours que des avantages...
Mais pour faire simple, l'idée est de faire beaucoup de combinatoire sur le même chemin, puis de mettre plusieurs registres en aval (ou en amont, ça marche aussi). Ensuite, c'est l'outil qui décide de lui même parmi ces registres, est ce qu'il peut en déplacer certains pour casser des chemins combinatoires sans changer la fonctionnalité.
L'objectif est que ta logique donne le même résultat au bout du même nombre de coups d'horloge, i.e. la netlist produite avec l'option register retiming doit être équivalent formellement à ton rtl.

Pour toi, je ferais en sorte de juste rajouter des registres ici et là dans ton design.
Si tu as une seule clock, pas de backpressure entre tes entités, alors c'est assez simple à faire.
N'hésite pas à découper tes opérations en plusieurs morceaux:
d <= a + b + c;
peut devenir :
d_tmp <= a + b;
d <= d_tmp + c;
tout cela dans un process clocké.

Tu peux aussi utiliser des primitives de ton FPGA pour faire des calculs complexes au lieu d'utiliser des LUTs (si jamais le synthétiseur n'arrive pas à faire l'opération) :
d <= a * b;
très couteux en LUTs si le synthétiseur ne comprend pas que c'est une multiplication (bon j'exagère, en général il se débrouille bien), peut devenir avec instantiation de primitive :
multiplicator m0 (.x(a), .y(b), .result(d));

Parfois ce qui est problématique, c'est les comparaisons avec des résultats de calculs, suivi d'un calcul :
if ((a + 5) > (b - 3))
c <= d + 4;
C'est le genre de RTL qui coute cher

Tu peux me MP si tu veux en dire un peu plus

rat de combat

attention rongeur méchant!

Merci periaz pour ces explications. :jap:

A priori j'ai que des trucs "simples" à synthétiser, pas d'autres calculs que des additions/soustractions avec une constante, et pas de comparaisons "complexes" on va dire. Je vais m'y remettre quand je serai plus motivé et si je m'en sors pas je reviendrais peut-être sur ta proposition de MP.

---------------
-/-

froggycorp

Hello,

Question pas/peu en lien avec le topic, je sais pas trop.
Vous utilisez quoi pour faire des schémas PCB ? Je trouve que KiCad gère mal les librairies et j'ai pas les trace des composants

merki !

Message cité 2 fois

crazytiti

http://crazytiti.free.fr/

Salut, j'utilise Kicad en mode perso et eagle pour les trucs pro.
kicad a toujours été un peu "dur" à appréhender mais il fait bien le taff.
Eagle est payant et d'ailleurs c'est uniquement en abonnement maintenant.
Il y a Design spark electrical qui est dispo gratuitement (je ne connais pas ses limites)
Sinon il y a des sites qui proposent en lien avec leur service de gravure de pcb.
Par exemple https://easyeda.com/ de jlpcb

---------------
Le PC est une drogue... Mes modèles 3D qui me rapportent des points :-D https://makerworld.com/fr/@crazytiti https://www.printables.com/fr/@Crazytiti_1456354

zeql_

froggycorp a écrit :

Ca veut dire quoi "il gère mal les librairies" ?

Les traces des composants faut faire les associations. Si tu ne les a pas il faut en récupérer ou les faire toi-même.

rat de combat

attention rongeur méchant!

froggycorp a écrit :

Je trouve que KiCad gère mal les librairies et j'ai pas les trace des composants

Je pense que du moins pour un usage perso Kicad est encore le mieux et pas seulement car c'est open source et donc gratuit. Certes, il y a easyeda et Co, mais on se rend dépendant de la bonne volonté d'un fabriquant. Perso j'aime pas, surtout que j'utilise aussi Kicad (en mode "improvisation" ) pour faire des routages sur protoboard. La gestion des lib oui il faut s'y faire, mais on peut se débrouiller. Perso j'ai un dossier dans lequel je collecte toutes les empreintes etc que j'ai fabriqué/dessiné/... moi-même et je copie ce qu'il faut dans le dossier projet. Tout(?) les formats Kicad sont du texte à la base, donc facilement comparable et on pourrait même utiliser un truc genre git pour les révisions etc (y'a des gens qui font comme ça?)

Sinon si tu as des questions Kicad ou autre il y a un sujet dédié: https://forum.hardware.fr/forum2.ph [...] w=0&nojs=0

---------------
-/-

gizmo15

Bonjour,

Petite question connecteur :
j'arrive pas à trouver le modèle de ce connecteur blanc : https://norishare.com/qAMjbKXaUaR
je cherche surement pas avec les bons mots clés

Vous auriez son nom ?

c'est les petits connecteur d'alim dans les mini pc pour un disque 2.5

Merci!

rat de combat

attention rongeur méchant!

Tu peux donner les dimensions au cas où c'est pas standardisé? Car si je cherche SSD/HDD 2,5" je tombe que sur les connecteurs SATA qu'on connaît...

Message cité 1 fois
Message édité par rat de combat le 02-06-2023 à 12:15:01

---------------
-/-

pyromanu

rat de combat a écrit :

Tu peux donner les dimensions au cas où c'est pas standardisé? Car si je cherche SSD/HDD 2,5" je tombe que sur les connecteurs SATA qu'on connaît...

Ça ressemble à du JST serie XH on dirait, mais à confirmer avec les dimensions.

rat de combat

attention rongeur méchant!

Le lien a déjà dû passer par ici, m'enfin bon
Common wire-to-board, wire-to-wire connectors, and crimp tools: https://www.mattmillman.com/info/crimpconnectors/

---------------
-/-

gizmo15

le connecteur fait 10mm de large par 4mm de profondeur sur 8mm de haut

merci de votre aide!

edit : ça ressemble fortement au JST XH en effet

edit 2 : ça confirmerait les JST XH : https://fr.aliexpress.com/item/1005001432733235.html

Message édité par gizmo15 le 02-06-2023 à 13:34:53

Bersac

Pour vérifier, JST-XH = entraxe 2,5 mm

datasheet

gizmo15

j'vais couper l'adaptateur livré et y mettre une molex ou une prise fan et hop, j'aurais mon adaptateur

froggycorp

ha bah je vais regarder sur le sujet dédié à ce moment là
merki

Par exemple, je voulais installer le plugin snapeda plutot que d'aller DL puis installer manuellement, bah ca marche pas.
Quand je rajoute des symbols, je trouve que c'est la croix et la baniere

Message édité par froggycorp le 02-06-2023 à 15:21:40

M4vrick

Mad user

Hello

Est-ce qu'il y en a par ici qui sont pas trop mauvais en décodage de protocole série ?
Je suis en train de faire du reverse engineering sur un clavier de piano numérique et j'ai du mal à déterminer exactement le contenu du message envoyé par le clavier à la carte principale.

Je précise que ca a l'air extremement simple, je distingue l'idée générale et le pattern utilisé pour communiquer mais je n'arrive pas à aller au bout n'ayant aucune expérience dans le domaine je ne sais pas vraiment quoi chercher coté mise en forme.

J'ai fait des captures avec un analyseur logique, je peux vous les partager.

---------------
--== M4vr|ck ==--

Natopsi

☄️Just end it already!☄️

C'est pas bêtement du MIDI?

Message cité 1 fois

---------------
⚡ACH/VDS⚡HFRCoin◈1435mm⚡

crazytiti

http://crazytiti.free.fr/

+1, tu peux aussi nous mettre des photos du PCB avec la ref des circuits présents.

Message cité 1 fois

---------------
Le PC est une drogue... Mes modèles 3D qui me rapportent des points :-D https://makerworld.com/fr/@crazytiti https://www.printables.com/fr/@Crazytiti_1456354

M4vrick

Mad user

Natopsi a écrit :

C'est pas bêtement du MIDI?

Malheureusement non, je suis au moins certain de ce point. C'est en interne du piano et vu le montage avec 2 cartes branchées sur le même port serie du MCU ca exclut le MIDI. De plus les signaux que j'ai capturé ne correspondent pas du tout.

crazytiti a écrit :

+1, tu peux aussi nous mettre des photos du PCB avec la ref des circuits présents.

Je peux même faire mieux et vous donner la doc : https://M4vrick.quickconnect.to/d/s [...] r2gMb07fQo
mdp : HFR

Ce qui m'intéresse c'est page 7, le connecteur CN3 tout à gauche qui vient de la carte clavier. Je fais mes captures depuis la broche 3 de IC2 qui me fourni un signal bien propre.

En gros j'ai une trame en RX qui apparait à chaque fois que j'appuie sur une touche du clavier, elle est de longueur fixe et apparemment séparée en interval de 10µs, elle fourni la hauteur de la note et la vélocité. J'arrive plus ou moins à voir les 2 parties, note et vélocité. Mais je ne connais pas assez ce genre de signaux pour déterminer exactement où ils commencent et termine et comment est faite la séparation entre les deux.
Je n'ai pas les captures sous la main la, je ferais ca plus tard dans la journée.

Message édité par M4vrick le 03-06-2023 à 10:51:03

---------------
--== M4vr|ck ==--

Natopsi

☄️Just end it already!☄️

On dirais une liaison asynchrone avec les deux modules qui parlent tous les deux sur une seule entrée du maitre tout en utilisant une paire de lignes pour se synchroniser entre eux.
https://pdf1.alldatasheet.com/datas [...] /3292.html

Message cité 1 fois

---------------
⚡ACH/VDS⚡HFRCoin◈1435mm⚡

M4vrick

Mad user

Natopsi a écrit :

Ca y ressemble beaucoup en effet ! Merci pour la piste de recherche :jap:

Dans mon cas je vais tout dégager pour ne garder que le clavier avec sa carte d'interface et je veux justement pouvoir lire et interpreter les trames qu'il envoi. Donc la partie partage de ligne va disparaitre.

---------------
--== M4vr|ck ==--

M4vrick

Mad user

Voila un exemple de ce que me sort le clavier :

3 notes identiques mais vélocité différente

3 autres notes identiques et vélocité différente

On voit que la trame débute toujours de la même manière, il est structuré en interval de 10µS:
- 50µS de signal niveau bas suivi d'un niveau haut pendant 10µS puis niveau bas pendant 20µS
- des infos correspondant à la note, c'est identique à chaque fois
- Les infos correspondant à la vélocité

Et en fait en écrivant ce message j'ai fait des mesures pour décrire ce que je vois et j'ai eu une illumination.

J'ai donc l'entête:
- 50µS niveau bas, 10µS niveau haut, 20µS niveau bas
- Puis la note sur 80µS, en découpant par tranche de 10µS ca fait un octet.
- Puis 30µS niveau bas
- Puis de nouveau 80µS qui doivent correspondent à la vélocité
- Puis 10µS niveau bas pour cloturer la trame.

Est-ce que cela vous semble correct vis à vis des captures ci-dessus ?

---------------
--== M4vr|ck ==--

rat de combat

attention rongeur méchant!

Ca pourrait bien, oui, mais j'ai regardé que brièvement. J'ai pas access à la doc sur ton NAS, config trop restrictive chez moi...

A ta place je mettrais un µC pour tenter de décoder le signal et voir si le résultat à du sens, p.ex. en changeant la vélocité (ch'ais pas ce que c'est moi ) d'un seul pas. Tu peux aussi, si tu parles Python, regarder Sigrok et écrire un décodeur custom, c'est pas bien long (connaissances en Python supposés).

Puisqu'on parle RE (c'est pas contraire au règlement ça? ), j'ai passé un peu de temps à regarder les signaux qui sortent du module caméra d'un vieux tél mobile basique. C'est intéressant, mais je pense que je vais pas pousser vu la résolution ridicule (320x240 à priori) et le fait qu'on trouve des modules caméras (EDIT: documentés) à quelque Euros. C'est pas bon pour la planète mais à un moment le RE ça ne vaut plus la peine et le temps... Surtout que j'ai des signaux sinusoidaux au scope, donc trop rapides (car je suppose qu'il n'y a que du numérique qui passe entre le SoC et le module caméra), donc faudrait que je sorte l'analyseur logique "costaud" mais rien que souder les fils sur ce connecteur... Aussi à ma connaissance ces modules caméras ont un bus I2C pour la config, or là sans aucune doc concernant les registres etc... Bref. </3615>

Message édité par rat de combat le 03-06-2023 à 18:46:19

---------------
-/-

Natopsi

☄️Just end it already!☄️

UART, 1 Start, 1 Stop, pas de parité, 3 octets
D'ailleurs j'ai merdé le dernier c'est Start 0000 1101 Stop

Message cité 1 fois
Message édité par Natopsi le 03-06-2023 à 18:48:29

---------------
⚡ACH/VDS⚡HFRCoin◈1435mm⚡

rat de combat

attention rongeur méchant!

Ah oui... :jap:

---------------
-/-

M4vrick

Mad user

Natopsi a écrit :

https://i.imgur.com/0GHAyvL.png
UART, 1 Start, 1 Stop, pas de parité, 3 octets
D'ailleurs j'ai merdé le dernier c'est Start 0000 1101 Stop

Oui j'ai tenté l'UART dans l'analyseur et ça me sort bien 3 octets.
Mais le baud rate est non conventionnel et surtout le résultat sur les 3 octets est étonnant pour 2 valeurs a remonter.

---------------
--== M4vr|ck ==--

rat de combat

attention rongeur méchant!

Un baud rate non standard ça ne me choque pas, ça dépend de comment il est généré, autrement dit quelle fréquence est disponible et comment fonctionne le diviseur. Et 3 octets, faudrait voir le contenu / faire d'avantage d'analyses. Peut-être un octet sert à la synchro ou ... ?

Message édité par rat de combat le 03-06-2023 à 19:47:57

---------------
-/-

Publicité

Page : 1 2 3 4 5 .. 376 377 378 .. 480 481 482 483 484 485

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Electronique, domotique, DIY

Silicium HFR: blabla @ Electronique

Sujets relatifs
Plus de sujets relatifs à : Silicium HFR: blabla @ Electronique

Page générée en 0.069 secondes