vhdl synthetisiarbar machen

[Zitty Z. (Firma: ZATT) (zitierer)]

hi möchte einen code synthetesierbar machen.
Original tb:

   p_config_status_vector : process
   begin
     configuration_vector <= (others => '0');
     wait for 1 us;
     assert false report "Clearing status vector outputs" severity note;
     while status_vector /= "11111100" loop
       wait until clk156 = '1';
       configuration_vector(2) <= '1';
       configuration_vector(3) <= '1';
       wait until clk156 = '0';
       wait until clk156 = '1';
       configuration_vector <= (others => '0');
     end loop;
     assert false report "DUT Ready" severity note;
     dut_ready <= '1';
     wait;
   end process p_config_status_vector;

Mein äußerst kleverer Ansatz:
Scheint aber nicht mal zu simulieren.
Oder irgendwas scheint da sehr lange zu dauern.
Muss ich die ganzen wait untils umschreiben als if anweisung oder so?

      p_config_status_vector : process 
   begin
    -- configuration_vector <= (others => '0');
  
    if  dut_ready = '0' then
      
         if status_vector /= "11111100" then
           wait until refclk_p = '1';
           configuration_vector(2) <= '1';
           configuration_vector(3) <= '1';
           wait until refclk_p = '0';
           wait until refclk_p = '1';
           configuration_vector <= (others => '0');
        else              
         dut_ready <= '1';
          end if;
     end if;
   
   end process p_config_status_vector;

würde jetzt einfach mal die Logik herausarbeiten. und dann muss das Ding 
einfach nur toggeln... sollte eigentlich machbar sein.

glaub ich brauch noch nen zähler. dann zählt der hoch und dann wird 
getogglt. - aso der togglet ja jeden takt! dann brauch man doch keinen 
zähler xD


oh jetz scheint es wenigstens mal die Simulation auf zu machen:

 p_config_status_vector2 : process (refclk_p)
   begin
  --   configuration_vector <= (others => '0');
      if  dut_ready = '0' and status_vector /= "11111100" then
            if ( refclk_p = '1') then
                configuration_vector(2) <= '1';
                configuration_vector(3) <= '1';
            else 
configuration_vector <= (others => '0');
            end if;
       end if;
   end process p_config_status_vector2;

und jetzt sehe ich hier noch
.. da ist ja ne while-schleife drin.
wie soll man das ganze synthesefähig machen xD
ist die ganze prozedur etwa komplett zu ersetzen?

procedure send_frame (
             constant frame : in frame_typ) is
             variable column_index : integer;
          begin  -- send_frame
             column_index := 0;
    
             while column_index < frame.length loop
                send_column(frame.stim(column_index));
                column_index := column_index + 1;
             end loop;    
    
          end send_frame;

[RuckZuckFresseDick (Gast)]

Vergiss es!

Man schreibt von Anfang realisierbaren Code, nicht irgendwelchen 
akademixen Pseudogedröhns.

Und das kann man erst, wenn man verstanden hat:
-was überhaupt gemacht werden soll?
-welche Werkzeuge man dazu zu Verfügung hat!

[Zitty Z. (Firma: ZATT) (zitierer)]

RuckZuckFresseDick schrieb:
> Man schreibt von Anfang realisierbaren Code, nicht irgendwelchen
> akademixen Pseudogedröhns.

Der Code stammt von einer Testbench. Habe gedacht man kann den 
synthetisierbar machen.

Kann man daraus nicht ableiten wie eine synthesefähige Logik dazu 
aussieht?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Zitty Z. schrieb:
> wie soll man das ganze synthesefähig machen xD
Du musst dir erst mal eine Hardware ausdenken. Und die beschreibst du 
dann mit der HardwareBESCHREIBUNGSsprache VHDL.

> ist die ganze prozedur etwa komplett zu ersetzen?
Du musst eine komplett andere Strategie auflegen (mein Tipp: fang mit 
einem Blinklicht und einem Lauflicht an) und auch mal den Userguide zum 
Synthesizer lesen. Da steht drin, wie du was schreiben musst, dass er es 
versteht und Hardware draus machen kann.
Im Mengenlehre-Unterricht hätte man das nämlich etwa so gezeichnet:

     ________________________________________________________________
    |                                                                |
    | gesamter                                                       |
    | VHDL-Sprachumfang                                              |
    |                                                                |
    |                                                                |
    |                                                                |
    |                                                                |
    |                                                                |
    |                                                                |
    |                                                                |
    |                                                                |
    |                                                                |
    |                                ___________________             |
    |                               |  davon            |            |
    |                               |  synthetisierbar  |            |
    |                               |___________________|            |
    |                                                                |
    |                                                                |
    |________________________________________________________________|

Zitty Z. schrieb:
> Der Code stammt von einer Testbench.
> Habe gedacht man kann den synthetisierbar machen.
Wozu sollte man eine Testbench synthetisierbar machen und in ein FPGA 
packen? Eine Testbench hat ein völlig anderes Ziel und natürlich auch 
eine ganz andere Designstrategie.

Das ist, wie wenn du aus einem Fußballfeld einen Fußball machen 
wolltest. Es hat zwar beides mit Fußball zu tun, aber der Ball wird auf 
dem Feld gespielt.

[Duke Scarring (Gast)]

Zitty Z. schrieb:
> Kann man daraus nicht ableiten wie eine synthesefähige Logik dazu
> aussieht?
Nein. Wir wissen ja noch nichtmal, was für Signale rein und rausgehen...

Bisher ist ja nur das hier bekannt:

library ieee;
use ieee.std_logic_1164.all;

entity unknown_dut is
port
( 
   configuration_vector : in  std_logic_vector( 3 downto 0);
   status_vector        : out std_logic_vector( 7 downto 0)
};
end entity dunknown_dut;

Duke

[Zitty Z. (Firma: ZATT) (zitierer)]

Lothar M. schrieb:
> Userguide zum
> Synthesizer

ja mache ich!

nur noch vollständigkeitshalber:

send_frame soll aus einem Prozess 4 mal aufgerufen werden, um 4 Frames 
zu senden.
Allerdings beinhaltet send_frame einen weiteren procedure-Aufruf, bei 
dem send_column "sehr oft" aufgerufen wird.

Könnt ihr  ungefähr sagen, ob die while-Schleife komplett 
unsynthetisierbar ist? Oder wäre das doch möglich, da die Grenzwerte 
statisch sind?

Habe gerade nur send_frame betreffendes auskommentiert und die Synthese 
wurd schonmal von Vivado durchgeführt.

hier noch mal das betreffende:

procedure send_frame (

             constant frame : in frame_typ) is
             variable column_index : integer;
          begin  -- send_frame
             column_index := 0;
             while column_index < frame.length loop
                send_column(frame.stim(column_index));
                column_index := column_index + 1;
             end loop;        
          end send_frame;

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Zitty Z. schrieb:
> send_frame soll aus einem Prozess 4 mal aufgerufen werden
> procedure send_frame (
Nur zur Einschätzung der Lage: du bist ein Programmierer, der Hardware 
machen muss. Stimmts?

[Zitty Z. (Firma: ZATT) (zitierer)]

ja

[Zitty Z. (Firma: ZATT) (zitierer)]

aber die procedure wird von der original testbench wirklich 4 mal 
aufgerufen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Zitty Z. schrieb:
> ja
Und deshalb willst du VHDL "programieren" und findest sogar noch ein 
paar "false friends", die du aus deiner Programmiersprache kennst.

Zum Prozess: ein Prozess wird in der Hardware in der (theoretischen) 
Zeit 0 abgearbeitet. Wenn in dem Prozess eine Schleife ist, wird die zu 
paralleler Hardware ausgerollt und gleichzeitig bearbeitet. Wenn du in 
einem Prozess etwas nacheinander machen willst, dann brauchst du einen 
Zustandsautomaten.

> send_frame soll aus einem Prozess 4 mal aufgerufen werden

Zeichne das als Schaltplan und beschreibe die Funktion dann mit VHDL.

Zitty Z. schrieb:
> aber die procedure wird von der original testbench wirklich 4 mal
> aufgerufen.
Ja, aber das geht eben nur in der Testbench. Und die Testbench ist von 
Anfang an nicht darauf ausgelegt, dass man sie synthetisieren könnte.


Wie gesagt: Blinklicht simulieren, synthetisieren. Lauflicht simulieren, 
synthetisieren. VGA-Schnitte simulieren, synthetisieren. Serielle 
Schnitte simulieren, synthetisieren. Und danach stellst du viele Fragen 
nicht mehr, die dich grade so plagen.
Dort gehts los:
http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html

[Zitty Z. (Firma: ZATT) (zitierer)]

Lothar M. schrieb:
> Ja, aber das geht eben nur in der Testbench. Und die Testbench ist von
> Anfang an nicht darauf ausgelegt, dass man sie synthetisieren könnte.

Ja möchte aus dem Konzept aber synthesefähige Logik machen.
Wollte nur wissen inwiefern man schon vorhandenen Code nehmen kann.
Bevor ich unnötig alles kompliziert umschreibe..

[Cle (Gast)]

Zitty Z. schrieb:
> Lothar M. schrieb:
>> Ja, aber das geht eben nur in der Testbench. Und die Testbench ist von
>> Anfang an nicht darauf ausgelegt, dass man sie synthetisieren könnte.
>
> Ja möchte aus dem Konzept aber synthesefähige Logik machen.
> Wollte nur wissen inwiefern man schon vorhandenen Code nehmen kann.
> Bevor ich unnötig alles kompliziert umschreibe..

Das Problem jetzt ist  das du eine gewisse "Uneinsichtigkeit" in 
Hardwarebeschreibungssprachen und die Schritte in der FPGA Entwicklung 
gezeigt hast. Hier liegen einige Probleme die es schwierig machen dir zu 
helfen.

Nochmal ganz klar: Testbenches sind schier unmöglich direkt in 
synthetisierbaren Code umzuwandeln.

Entweder ein Designer entwickelt eine Schaltung für die Realität, dann 
schreibt er direkt synthesefähigen Code, oder ein Verifikateur schreibt 
eine Testbench die nur für das Testen genutzt wird. Das kann durchaus in 
der selben Sprachen passieren, aber sind oft absolut unterschiedliche 
Sprachkonstruke und Paradigmen.

Du kannst du das "Verhalten" (die äußere Ansicht, also wie Signale 
togglen) anschauen und das ganze von Testbench zu Design übertragen 
(oder andersrum).

[Gustl B. (-gb-)]

Cle schrieb:
> Testbenches sind schier unmöglich direkt in
> synthetisierbaren Code umzuwandeln.

Naja, auch eine Testbench kann durchaus in synthetisierbarem Code 
geschrieben sein. Muss aber eben nicht.

Hier wäre es hilfreich, wenn wir mal die komplette Testbench sehen 
würden. Vielleicht sind die Stimulussignale nicht von Ausgängen der UUT 
abhängig und können quasi starr durchgefahren werden mit der Zeit.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Zitty Z. schrieb:
> möchte aus dem Konzept aber synthesefähige Logik machen.
Was soll das bringen? Willst du zwei FPGAs vetbinden und mit dem einen 
FPGA (="synthetisierte Testbench") ein anderes (=DUT device under test) 
stimulieren?

[Zitty Z. (Firma: ZATT) (zitierer)]

Cle schrieb:
> Du kannst du das "Verhalten" (die äußere Ansicht, also wie Signale
> togglen) anschauen und das ganze von Testbench zu Design übertragen
> (oder andersrum).

Ja das wäre interessant. Ich möchte 4 Ethernetframes immer wieder senden 
lassen.
Bzw. es wäre mir fast schon egal ob es nur 1 Ethernetframe ist xD

Lothar M. schrieb:
> Was soll das bringen? Willst du zwei FPGAs vetbinden und mit dem einen
> FPGA (="synthetisierte Testbench") ein anderes (=DUT device under test)
> stimulieren?

Ein FPGA soll Frames aussenden über seine Transceiver. Diese sind am 
Ende mit einer Netzwerkkarte verbunden.
FPGA(->Transceiver) ->HW-> NIC

Werde einfach mal schauen ob ich die Frames mit Zählern senden kann xD

Cle schrieb:
> gewisse "Uneinsichtigkeit"
Ich hoffe das ändert sich schnell.
Man muss mir mal ordentlich mit nem FPGA auf den Kopf schlagen.

[Zitty Z. (Firma: ZATT) (zitierer)]

ahhhh
Habe mich vertan.
Diese Testbench sendet gar nicht ganze Ethernet frames.. .

Nacheinander Ethernet-frames  auf den xgmii bus legen, müsste aber 
irgendwie klappen.

Also eigentlich brauche ich nur einen Testframe. Der immer wieder 
gesendet wird.

Sind aber etwa 1500 Bit. Also muss ich die korrekt nacheinander auf den 
Bus 64+8 Bit - Bus legen lassen.

Laut Datenblatt kommen kurz nach clk-high neue 64 Bit xgmii + 8 Bit 
Kontroll-Daten auf den Bus.

Ca. 23 mal muss was auf den Bus ...
Wie würdet ihr das machen?

Ich könnte das ganze in Excel machen und dann einfügen
oder vorsichtig mit einer Schleife ein Array auslesen xD
haha

[Duke Scarring (Gast)]

Ich würde einen RAM als ROM verwenden und mit einer FSM zyklisch 
auslesen.
Eine Schleife bringt Dir hier gar nix.

Duke

[Zitty Z. (Firma: ZATT) (zitierer)]

Duke Scarring schrieb:
> RAM als ROM

Das ist auch gut.

Vielen Dank für den Tipp!

Dann kann man nach einander immer die benötigten Daten aus dem RAM 
lesen?

[Achim S. (Gast)]

Zitty Z. schrieb:
> Dann kann man nach einander immer die benötigten Daten aus dem RAM
> lesen?

Ja. Und zwar indem du zusätzlich einen Adresszähler implementierst, der 
jeweils auf die Adresse der gerade benötigten Daten im RAM zeigt. Der 
muss im wesentlichen bei jeder Taktflanke, bei der du einen Wert aus dem 
RAM ausliest und versendest, um 1 erhöht werden und am Ende des 
Datenpakets wieder auf den Anfangswert zurückspringen.

[Zitty Z. (Firma: ZATT) (zitierer)]

ok RAM mit Address-Pointer hört sich vernünftig an.
Was passiert wenn man das so macht wie "sendethernet.txt"?

es wird zwar synthetisiert, aber ich kann nicht abschätzen was ich da 
wirklich rauskommt.

[Achim S. (Gast)]

Zitty Z. schrieb:
> es wird zwar synthetisiert,

Ehrlich? Bekommst du keine Warnung wegen einer kombinatorischen Schleife 
oder sowas in der Art? Wie sieht denn der vollständige Code aus, hier 
sieht man ja nur ein Schnippsel...

An dieser Stelle
    if refclk_p = '1' then --- please  check for rising clock!
machst du nicht, was im Kommentar steht (und was notwendig wäre). Du 
prüfst nicht auf eine steigende Taktflanke. Sondern du prüfst, ob der 
Taktpegel high ist.

Zitty Z. schrieb:
> aber ich kann nicht abschätzen was ich da
> wirklich rauskommt.

Dafür gibt es einen Simulator...

[Zitty Z. (Firma: ZATT) (zitierer)]

Achim S. schrieb:
> Ehrlich? Bekommst du keine Warnung wegen einer kombinatorischen Schleife
> oder sowas in der Art?

Im Anhang habe ich einen Screenshot davon.

Aber wenn du schon meinst, dass da etwas schlechtes entsteht, muss ich 
mir Gedanken machen!

Ich schaue mir gerade
http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife
an.

Achim S. schrieb:
> if refclk_p = '1' then --- please  check for rising clock!

War mein eigener Kommentar, damit ich das noch ändere.

Achim S. schrieb:
> Dafür gibt es einen Simulator...

Bei jedem Takt (high) werden Daten auf den Bus gelegt. Das gesamte Frame 
wird immer wieder gesendet.
Werde auch gleich mal schauen, ob der Core das korrekt übersetzt - tu 
diesen Code in ein "example-design", wo auch ein Monitor drin ist.

[Achim S. (Gast)]

Zitty Z. schrieb:
> Bei jedem Takt (high) werden Daten auf den Bus gelegt. Das gesamte Frame
> wird immer wieder gesendet.

Bei jeder Taktflanke sollte etwas passieren. Nicht dauernd, solange die 
Taktflanke auf high ist.

Was die Warnungen angeht:  du hast über 100 von denen nur ein Teil auf 
deinem Screenshot zu sehen ist. Und vieles von den erkennbaren Warnungen 
bezieht sich auf Teile des Codes, die du nicht gezeigt hast und die ich 
nicht erraten kann.

Zitty Z. schrieb:
> Ich schaue mir gerade
> http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife
> an.

Oben wurde dir schon vorgeschlagen, mit einem einfachen Design zu 
starten um zumindest die "grundlegensten Grundlagen" zu kennen, bevor du 
an Ethernet-Pakete gehst.

Lothar M. schrieb:
> Dort gehts los:
> http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html

Mach dir an einem einfachen Design klar, wie man die Taktflanke abfrägt, 
ehe du dich an komplexere Projekte setzt.