Hallo zusammen, ich habe folgendes Problem: ich habe in einem Arry address[cnt] ==> cnt = 100, 100 Adresswerte die sich laufend parallel ändern. Jetzt möchte ich diese Adresswerte immer bei einem steigenden Clock vergleichen wenn diese Adresswer = 211 möchte ich das Signal next_p setzen. Wo ist meine Fehler? reg next_p; always@(posedge clk or negedge n_rst) begin if(!n_rst)begin next_p = 1'b0; end else begin for(j=0;j<cnt;j=j+1)begin if(address[j]==211) next_p = 1'b1; else next_p = 1'b0; end end end
Top 5 Antworten aus den letzten 100 Forenthreads treffen auch hier zu: - Ganzen Quellcode posten? (Wo wird address deklariert?) - Hast du eine Testbench? - Synthese oder Simulation? - Verilog(/VHDL) ist keine Programmiersprache! - Loops machen in HDL was anderes als in Software!
Ups und ganz vergessen, aber sehr wichtig: - Was ist deine Fehlermeldung/Fehlerindikation? Also welches Tool, welche Plattform, welche Fehleranalyse benutzt du?
Yonas schrieb: > Wo ist meine Fehler? Das Problem ist, das nur Dein letzter Vergleich für das Ergebnis (next_p) relevant ist. Vielleicht willst Du ja den Ausgang der 100 Komperatoren mit einem großen OR zusammenfassen. Dann müsste next_p auch ein Array werden. Duke
1 | always@(posedge clk or negedge n_rst) |
2 | begin
|
3 | if(!n_rst)begin |
4 | next_p <= 1'b0; |
5 | end else begin |
6 | next_p <= 1'b0; |
7 | for(j=0;j<cnt;j=j+1)begin |
8 | if(address[j]==211) |
9 | next_p <= 1'b1; |
10 | end
|
11 | end
|
12 | end
|
vielleicht sowas in der Richtung gewünscht? Natürlich extrem hardware lastig
Hi Duke, danke. Das ist ja genau meine Problem. Wire next_p; Assign next_p =( (address[0]==211) || (address[1]==211)||……(address==211)?0‘b1:0‘b0; Ich suche ein geschickte Schreibweise. Bei der forschleife bleibt next_p permanent auf 0‘b1. Da der addressed auch verschoben sein können! Danke!
Wenn auch nicht so ganz schön und wir keine anderen Infos über Tools oder kompletten Code haben, könnte das so gehen(not tested): reg next_p[cnt]; reg next_p_out; always@(posedge clk or negedge n_rst) begin if(!n_rst)begin next_p = 1'b0; end else begin for(j=0;j<cnt;j=j+1)begin if(address[j]==211) next_p[j] = 1'b1; else next_p[j] = 1'b0; end end next_p_out <= | next_p; end
Hi Cle, Danke. Der Code ist etwas aufwändig. Tool Vivado. Dank im Voraus, ich werde es heute Abend testen! Vielen Dank!
Naja, aber allein dein Code Snippet ist alleine nicht lauffähig. Wenn du alleine ein kleines Designteil testen möchtest (um natürlich zu lernen in Zukunft solche Probleme selber zu lösen) ist ein Minimalbeispiel wichtig. Das macht es auch Leuten einfacher dir zu helfen und selber direkt mehr zu sehen. Und da dem Verilog anzusehen ist das der Author damit noch nicht so viel gemacht hat sind die Verilog Werkzeuge vermutlich nicht ganz passend und daher hinterfragen die Leute hier auch gerne deine Intention, was im Endeffekt dir helfen soll das bessere Werkzeug zu nutzen (In diesem Fall ist ein sehr breiter Komparator und eine breites OR vermutlich eher Zeit- und Ressourcenteuer). Übrigens ist jeder Code aufwendig, in diesen Themen ist es hilfreich mehr Infos zu geben um den Helfenden mehr Möglichkeit zum helfen zu geben. Nur FYI: Da Vivado geht das also in ein FPGA Design, dafür ist diese Lösung recht aufwendig und könnte je nach Taktgeschwindigkeit schnell zu Timingproblemen und Routingproblemen führen. next_out_p wird übrigens ein Taktzyklus später gesetzt.
Cle schrieb: > Top 5 Antworten aus den letzten 100 Forenthreads treffen auch hier zu: > > - Ganzen Quellcode posten? (Wo wird address deklariert?) > - Hast du eine Testbench? > - Synthese oder Simulation? > - Verilog(/VHDL) ist keine Programmiersprache! > - Loops machen in HDL was anderes als in Software! Alle 5 Antworten sind hier überflüssig, man braucht nur die Frage und Codesnippet durchzulesen und sieht es wie z.B. Duke sofort, jedenfalls mit ausreichend Erfahrung.
Yonas schrieb: > ich habe in einem Arry address[cnt] ==> cnt = 100, 100 Adresswerte die > sich laufend parallel ändern. "laufend parallel" bedeutet "jeder einzelne mit jedem Takt"? Die Hardware dafür möchte ich aber mal sehen... Woher kommen diese Daten? Und woraus besteht das "Array"? Sigi schrieb: > Alle 5 Antworten sind hier überflüssig Naja, mindestens die Hälfte der Antworten enthalten neue Aspekte für Yonas.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Sigi schrieb: >> Alle 5 Antworten sind hier überflüssig > Naja, mindestens die Hälfte der Antworten enthalten neue Aspekte für > Yonas. Es sind sogar alle 5 Antworten für eine Einarbeitung wichtig (Punkt 4 ist ja dein Lieblingspunkt), dazu kommen noch Timingconstraints und der Blick auf die Resourcen und die Logiktiefe > Die Hardware dafür möchte ich aber mal sehen... Wenn man aber immer ein komplettes Szenario inkl. Testbench als TO schreibt, dann geht damit das Problem in der Menge an Infos verloren, imo. Das Problem Oben ist also vollkommen ausreichend formuliert.
Sigi schrieb: > Lothar M. schrieb: >> Sigi schrieb: >>> Alle 5 Antworten sind hier überflüssig >> Naja, mindestens die Hälfte der Antworten enthalten neue Aspekte für >> Yonas. > > Es sind sogar alle 5 Antworten für eine Einarbeitung > wichtig (Punkt 4 ist ja dein Lieblingspunkt), dazu kommen > noch Timingconstraints und der Blick auf die Resourcen > und die Logiktiefe Natürlich erkennt man was er machen will, die Frage ist auf der besseren Seite der "Hier Code - Wo Fehler"-Fragen. Trotzdem ist gerade es gerade in RTL wichtig den Kontext des Problems zu beschreiben und sinnvoller (für alle momentanen wie zukünfitgen Leser) nicht einfach eine kurze Lösung hinzukotzen. Damit ist dem TO nämlich in 99% der Fälle auch nicht geholfen. >> Die Hardware dafür möchte ich aber mal sehen... > > Wenn man aber immer ein komplettes Szenario inkl. > Testbench als TO schreibt, dann geht damit das > Problem in der Menge an Infos verloren, imo. > Das Problem Oben ist also vollkommen ausreichend > formuliert. Wie? Ein 20 Zeilen Minimalbeispiel um auf EDAPlayground das Problem wirklich zu sehen? Aber wenn man diese Testbench gebaut hat und das wirkliche Problem zeigen kann ist die Lösung schon recht nahe... und so kann man sich auch selber bei unbekannten Problemen helfen, das wäre ja aber etwas zu viel Lernerfolg. Minimalbeispiel schreiben und den Fehler eingrenzen, das hat er ja gemacht, scheinbar gemerkt das next_p nicht richtig gesetzt wird, dann aber seine Zeit sparen wollen und das Code Snippet hier gepostet. Und bei dem Hinweis Synthese vs. Simulation sind ja eventuell alle Hinweise zu Loops/Ressourcen/Timing hinfällig.
Hallo zusammen, Danke an alle, dass ihr hilfs beret seid und ihr Euch mit meinem Problem beschäftigt. Es ist lange hier, dass ich ein Verilog Code für ein CPU modul geschrieben habe. Das modul hate Parallelbus zu Compact flash converter, sowie AC97 Audi signal conditioning .....Aber wie gesagt vor gute 10 Jahre. Jetzt ist so, dass mir die Übung einfach fehlt! @ Lothar M. >> "laufend parallel" bedeutet "jeder einzelne mit jedem Takt"? >> Die Hardware dafür möchte ich aber mal sehen... Also das Sensormodul bekommt vom FPGA ein Cklock von 6 MHz und das Sensormodul schickt Bitstreams zum FPGA über die 100 Leitungen. Im FPGA findet nachdem der Bitstream in Worte umgewandelt wurde (16 Bit) werden die Daten Digitalsignal verarbeitet. Am ende werden die berechnete Datensätze mit einem Arraysatz umberechnent, dabei könnte je nach Einstellung (Kalibrierung der Sensoren) ein Adressoffset geben, daher wird die Prozedur (der Code) oben benötigt. Die berechnung läuft natürlich takt Synchron. Aber wie gesagt es können unterschiedliche offsets vorgesehen werden und die Berechnung am Ende alle Sensoren zusammen, dann muss die Berechnung unterbrochen werden wenn der offset + Array index > 211 (also das Maximum der Matrixsplate erreicht hat). Hoffentlich konnte ich Dir die HW hinreichend beschreiben. @Sigi Danke, so waren auch meine Gedanken, dass ich das Problem beschrieben habe ohne Cle in den Schlips zu treten.
Yonas schrieb: > Im FPGA > findet nachdem der Bitstream in Worte umgewandelt wurde (16 Bit) werden > die Daten Digitalsignal verarbeitet. Also hast Du mindestens 16 Takt Zeit, um das aktuelle Datum zu verarbeiten. Da könnte man die benötigte Logik ggf. etwas verkleinern, in dem man vor dem Komparator einen Multiplexer baut. Der führt dann die Werte aus den Empfangsregistern reihum dem Komparator zu. Duke
Duke Scarring schrieb: > Also hast Du mindestens 16 Takt Zeit, um das aktuelle Datum zu > verarbeiten. Und das nur, wenn das FPGA tatsächlich nur mit langsamen 6MHz getaktet ist. Yonas schrieb: > Cklock von 6 MHz und das Sensormodul schickt Bitstreams zum FPGA über > die 100 Leitungen. Im FPGA findet nachdem der Bitstream in Worte > umgewandelt wurde (16 Bit) Du hast also 100 Leitungen über die synchron zum Takt die Daten seriell eintrudeln. Ist die effektive Datenrate dann (6MHz/16Bit) / Leitung * 100 Leitungen, also 37, 5Mio Worte pro Sekunde? Denn dann würde rechnerisch 1 Vergleicher reichen, der mit 38 MHz getaktet wird.
:
Bearbeitet durch Moderator
Hallo Tim, sorry ich habe Deine Beitrag übersehen, ich habe es auch genau so implementiet, allerdings habe ich Timing probleme! Du Entschuldigst mich, dass ich das zu spät gesehen habe. Das war mein initial Implemntierung!
Yonas schrieb: > allerdings habe ich Timing probleme! Und was für welche? Welches ist der kritische Pfad?
Zugegeben etwas sehr spät, aber hab den Thread erst jetzt gesehen. Mein Verilog Vorschlag für den Arrayvergleich.
1 | always @(posedge clk) begin |
2 | next_p <= 0; |
3 | for(j=0; j<cnt; j=j+1) |
4 | next_p |= (address[j]==211); |
5 | end
|
Nur um zu zeigen dass man mit Verilog kompakt und leserlich beschreiben kann.
Andi schrieb: >
1 | > always @(posedge clk) begin |
2 | > next_p <= 0; |
3 | > for(j=0; j<cnt; j=j+1) |
4 | > next_p |= (address[j]==211); |
5 | > end |
6 | >
|
Das wird in dieser Form wohl in die Hose gehen. Die erste Zuweisung müsste ebenfalls ein blocking assignment sein.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.