Forum: FPGA, VHDL & Co. Verilog Array vergleich


von Yonas (Gast)


Lesenswert?

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

von Cle (Gast)


Lesenswert?

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!

von Cle (Gast)


Lesenswert?

Ups und ganz vergessen, aber sehr wichtig:
- Was ist deine Fehlermeldung/Fehlerindikation? Also welches Tool, 
welche Plattform, welche Fehleranalyse benutzt du?

von Duke Scarring (Gast)


Lesenswert?

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

von Tim (Gast)


Lesenswert?

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

von Yonas (Gast)


Lesenswert?

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!

von Cle (Gast)


Lesenswert?

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

von Yonas (Gast)


Lesenswert?

Hi Cle,

Danke. Der Code ist etwas aufwändig. Tool Vivado. Dank im Voraus, ich 
werde es heute Abend testen!

Vielen Dank!

von Cle (Gast)


Lesenswert?

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.

von Sigi (Gast)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von Sigi (Gast)


Lesenswert?

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.

von Cle (Gast)


Lesenswert?

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.

von Yonas (Gast)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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
von Yonas (Gast)


Lesenswert?

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!

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Yonas schrieb:
> allerdings habe ich Timing probleme!
Und was für welche? Welches ist der kritische Pfad?

von Andi (Gast)


Lesenswert?

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.

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

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
Noch kein Account? Hier anmelden.