Hallo liebes Forum, Ich bin gerade an der Speicherung von Zählerdaten. Diese werden vom Xilinx FPGA auf einen BRAM und dann über BRAM Controller auf die SD Karte des Boards gespeichert. Dies funktioniert soweit ganz gut, nur bricht die Speicherung auf den BRAM nach max ca 1630 Zyklen und damit ca 6,5KB ab. Der BRAM wäre aber größer (zb 32KB in Vivado konfiguriert), also warum schreibt dieser nicht mehr Daten hinein? Ich habe noch kein Abbruchkriterium drinnen, wollte mal sehen, wie der Ablauf so hinhaut. Hat wer Ideen, wieso die Speicherung stoppt? Manchmal stoppt diese auch bereits früher. Kann es sein das das auslesen der Daten aus dem DualPort RAM über den PS das schreiben blockiert? Anbei das Blockschaltbild. LED und SW sind mal als Dummy ohne wirklichem Sinn drinnen. Vielen Dank für die jede Art von Hilfe.
Angehängte Dateien:
-
Block_Design.PNG
56 KB
Geza E. schrieb: > nur bricht die Speicherung auf den BRAM nach max ca 1630 Zyklen und > damit ca 6,5KB ab. Wie stellst du das fest? > Der BRAM wäre aber größer (zb 32KB in Vivado konfiguriert), also warum > schreibt dieser nicht mehr Daten hinein? Das BRAM ist sicher nicht dein Problem, denn das wird nur gesteuert und wenn was schiefgeht, dann steht da halt einfach Müll drin. > also warum schreibt dieser nicht mehr Welcher "dieser" schreibt da überhaupt?
Lothar M. schrieb: > Geza E. schrieb: >> nur bricht die Speicherung auf den BRAM nach max ca 1630 Zyklen und >> damit ca 6,5KB ab. > Wie stellst du das fest? > Ich lese die BRAM Adressen in SDK im Memory View aus und auf der SD Karte sind ebenfalls die Werte in der Bit Datei drinnen. > >> also warum schreibt dieser nicht mehr > Welcher "dieser" schreibt da überhaupt? Ah entschuldigung, das erwähnte ich nicht. Die Werte kommen aus dem Counter, als 32Bit Zahlen samt der Adressen und den für den BRAM notwendigen AXI Variablen (clk, wren, en). Der Counter zählt von 1-5000 mit seiner verlangsamten Clock clka, mit 400kS/S. Aber ich glaub das Problem könnte darin liegen, dass der PS beim RUN des C-Codes den PL stoppt? Wenn ich die Clock für den Zähler verlangsame (40kS/S), kommen 1/10 der Werte in den BRAM. Könnte das sein?
Geza E. schrieb: > dem Counter Code? Geza E. schrieb: > AXI Variablen (clk, wren, en) Das sind Signale! Geza E. schrieb: > kS/S Kilosiemens je Siemens? Geza E. schrieb: > Aber ich glaub das Problem könnte darin liegen, dass der PS beim RUN des > C-Codes den PL stoppt? Nicht glauben, messen oder herzeigen. Messen geht prima mit dem ILA, herzeigen kann man Code. Und noch viel besser ist erstmal simulieren. Geza E. schrieb: > Könnte das sein? Es fehlen noch fast alle Details. Bisher haben wir nur ein Bildchen und ein paar schwammige Aussagen. Wie soll man da helfen? Wo ist das Probem einfach das Projekt als .zip hochzuladen?
Also zur Simulation: Der BRAM ist in der Simulation normal gelaufen. Bis 5000 aber nicht, da dies so langsam war, aber zu geringeren Maxwerten hat das Abbruchkriterium funktioniert. Ob 300 oder 5000 Cycles sollte sich hier in Vivado wohl nichts mehr ändern oder? Sonst mach ich morgen eine ausgedehnte Pause und lass es mal durchlaufen. kS/s - Kilosamples pro Sekunde meinte ich Mein ILA hat leider noch nicht recht funktioniert, wollte damit die Daten in den BRAM Controller auslesen, da kam aber nichts, obwohl sie danach aber auf der SD waren, also da sein mussten! Ich bin erst morgen wieder im Labor, da kann ich die Datei als .zip dann raufstellen wenn das hilft. Dachte zuerst vll ist der Fehler im Design ersichtlich. Wie gesagt ich hab hier leide keine Ahnung mehr woran es liegen kann. Ob es eine Kleinigkeit ist oder der Ansatz der Falsche... Danke schonmal für die Infos und Hilfe! Bin für jeden Tipp sehr dankbar! Einstweilen der Code. Eher unspektakulär für geübte Anwender glaub ich. Ich hoffe es kommt euch nicht der graus beim Anblick Der VHDL Code: [vhdl] LIBRARY IEEE; USE IEEE.STD_LOGIC_1164.ALL; USE IEEE.STD_LOGIC_ARITH.ALL; USE IEEE.STD_LOGIC_UNSIGNED.ALL; entity CNT2 is Port ( clk : in STD_LOGIC; reset : in STD_LOGIC; SW : in STD_LOGIC; SW2 : in STD_LOGIC; LED : out STD_LOGIC_vector(1 downto 0) := "00"; --rot/grün leuchtet zu Beginn LED2 : out STD_LOGIC := '1'; --blau LED count2 : out STD_LOGIC_vector(31 downto 0); --integer :=0; wren: out STD_LOGIC := '1'; wren4: out STD_LOGIC_vector(3 downto 0) := "1111"; clock_out: out std_logic; --langsame Clock addra : out STD_LOGIC_vector(31 downto 0) ); end CNT2; architecture Behavioral of CNT2 is signal limit : INTEGER :=0; signal cnt : INTEGER RANGE 0 TO 5201 := 0; --Integer hat range von 32 Bit, durch angabe von extra range wird dieser angepasst signal count: integer :=1; signal tmp : std_logic := '0'; signal addrcnt : INTEGER RANGE 0 TO 40801 := 0; --TO 257 := 0; begin process(clk,reset,SW) begin if(reset='1' or SW = '1') then count<=1; LED <= "01"; --rot bleibt an also ist rot LED[01] 0 an höchstem Bit tmp<='0'; elsif(clk'event and clk='1') then LED2 <= SW2; count <=count+1; if (cnt = 5000) then --Aufhören zum zählen addrcnt <= 0; count2 <= conv_std_logic_vector(0,32); addra <= conv_std_logic_vector(0,32); wren <= '0'; elsif (count = 125) then tmp <= NOT tmp; cnt <= cnt + 1; addrcnt <= addrcnt +4; elsif (count = 250) then tmp <= NOT tmp; addra <= conv_std_logic_vector(addrcnt,32); count2 <= conv_std_logic_vector(cnt,32); count <= 1; end if; end if; clock_out <= tmp; end process; end Behavioral; [vhdl] Hier der C-Code in SDK. Liest im Endeffekt nur die Daten aus der BRAM Adresse und schreibt sie in den Ordner auf der SD: [c] #include <stdio.h> #include "xsdps.h" /*SD Device driver*/ #include "platform.h" #include "xil_io.h" #include "ff.h" #include "xil_cache.h" #include <stdlib.h> #include "xstatus.h" #include "xparameters.h" #include "xil_printf.h" #include "xplatform_info.h" FATFS fatfs; static int SD_Init(); static int SD_Eject(); static int WriteFile(char *FileName, u32 size, u32 SourceAddress); int word2; int addrbram; #define inputImageWidth 512 //Speicherweite #define inputImageHeight 512 //Speicherhˆhe #define size32 32000 //32000 //Speichergrˆfle //char imageBuffer[inputImageWidth*inputImageHeight*3]; uint32_t imageBuffer[32000];//[32000] int main() { int Status; Status = SD_Init(&fatfs); /* Mount/Unmount a logical drive */ if (Status != XST_SUCCESS) { print("file system init failed\n\r"); return XST_FAILURE; } /*Status = ReadFile("data.bin",(u32)imageBuffer); //Name length only 5 characters if (Status != XST_SUCCESS) { print("file read failed\n\r"); return XST_FAILURE; }*/ addrbram = XPAR_AXI_BRAM_CTRL_0_S_AXI_BASEADDR; //Hier wird //Startadresse angegeben, auf die die Speichergrˆfle angeh‰ngt wird xil_printf("Speicheraddr = 0x%08x\n\r", addrbram); Status = WriteFile("dat2.bin",size32,(u32)imageBuffer); // (inputImageWidth*inputImageHeight*3),(u32)imageBuffer); char *FileName, u32 size, u32 SourceAddress if (Status != XST_SUCCESS) { print("file write failed\n\r"); return XST_FAILURE; } Status=SD_Eject(&fatfs); if (Status != XST_SUCCESS) { print("SD card unmount failed\n\r"); return XST_FAILURE; } xil_printf("done..."); return 0; } static int SD_Init() { FRESULT rc; TCHAR *Path = "0:/"; rc = f_mount(&fatfs,Path,0); /* Mount/Unmount a logical drive */ if (rc) { xil_printf(" ERROR : f_mount returned %d\r\n", rc); return XST_FAILURE; } return XST_SUCCESS; } static int SD_Eject() { FRESULT rc; TCHAR *Path = "0:/"; rc = f_mount(0,Path,1); if (rc) { xil_printf(" ERROR : f_mount returned %d\r\n", rc); return XST_FAILURE; } return XST_SUCCESS; } static int WriteFile(char *FileName, u32 size, u32 SourceAddress){ UINT btw; static FIL fil; // File instance FRESULT rc; // FRESULT variable rc = f_open(&fil, (char *)FileName, FA_OPEN_ALWAYS | FA_WRITE); //f_open macht File "data" if (rc) { xil_printf(" ERROR : f_open returned %d\r\n", rc); return XST_FAILURE; } rc = f_write(&fil,(const void*)addrbram,size,&btw); //Schreibt Daten aus addrbram ins File //&fil [IN] Pointer to the file object structur Speicherort Daten, //(const void*)addrbram [IN] Pointer to the data to be written, Daten aus BRAM //[IN] Number of bytes to write, Datengrˆfle //[OUT] Pointer to the variable to return number of bytes written if (rc) { xil_printf(" ERROR : f_write returned %d\r\n", rc); return XST_FAILURE; } rc = f_close(&fil); if (rc) { xil_printf(" ERROR : f_write returned %d\r\n", rc); return XST_FAILURE; } return XST_SUCCESS; } [c]
Angehängte Dateien:
-
cnt2.png
14 KB
Ohweia schrieb: > Wenn ein Softwaremensch Hardwarebeschreibungen macht... Allerdings. Klare Empfehlung: Lerne die Grundlagen! Jedenfalls in der Simulation kommt das raus wie im Bildchen. Dauert auch nicht lange zu simulieren. Das Bild zeigt das "Ende", also wenn cnt die 5000 erreicht. Außerdem dabei: Etwas aufgehybschter (nein, ich habe keine Fehler korrigiert) VHDL Code samt sehr einfacher Testbench.
Angehängte Dateien:
-
SDK_Speicheradressen_BRAM.PNG
18 KB -
BRAM_config.PNG
40 KB
> Jedenfalls in der Simulation kommt das raus wie im Bildchen. Dauert auch > nicht lange zu simulieren. Das Bild zeigt das "Ende", also wenn cnt die > 5000 erreicht. Okay, also der Code würde somit den BRAM befüllen. Also liegt das Problem am BRAM? Konfiguration laut Bild. Also 32KByte Adressrange im Adress Editor, mit 131072Bits was eben zumindest 4096 32Bit Einträge zulassen würde. Warum auch immer, lässt der Memory Generator keine 32KByte zu. Hat da wer Erfahrung mit der Auslegung und maximalem Speicher? Sollte bei mir am Zynq700 140 BRAM zu je 36KB haben! Anbei die Datei als .zip neu, mit dem Code von @Gustl.B Allerdings zeigt mir nun SDK gar keine Werte mehr an. Keine Ahnung wieso das. > Außerdem dabei: > Etwas aufgehybschter (nein, ich habe keine Fehler korrigiert) VHDL Code > samt sehr einfacher Testbench. Vielen Dank fürs Drüberschaun. Sieht schon feiner aus, da fehlt mir noch die Erfahrung, mit der Testbench gehts wirklich flott! Ps: Mit den ganzen IP ist das File leider echt groß, obwohl nichts großartiges passiert.
:
Bearbeitet durch User
Geza E. schrieb: > Also 32KByte Adressrange, mit > 131072Bits was eben zumindest 4096 32Bit Einträge zulassen würde. Ähm ... laut Bildchen sind das 131072 Einträge mit je 32 Bits macht ... 512 kByte. Und das ist schon eher sehr viel. Wenn du nur 4096 Einträge haben willst, dann stelle die Depth auch auf 4096. Aber: Deine Adresse geht bis 19996. Das passt also nicht mit 4096 Adressen. Aber: Deine Adresse zählt immer um 4 hoch. Die letzten zwei Bits der Aadresse sind also konstant und du nutzt so nicht den gesamten Speicher, sondern immer nur ein Viertel, eben jede vierte Adresse. Statt von 0 bis 19996 könntest du das auch einfach durch 4 teilen, also die beiden LSBs der Adresse weglassen und dann geht das nurnoch von 0 bis 4999. Passt aber weiterhin nicht in 4096 Adressen. Aber: Was willst du überhaupt mit einem Zähler und dem BRAM? Wenn da sowieso nur einmalig Werte reingeschrieben werden, dann könnte man die auch einmalig berechnen und dann den BRAM über eine Datei vorinitialisieren. Weil die Werte berechenbar sind, könnte man sich auch im VHDL eine Funktion schreiben die den BRAM vorinitialisiert. Und weil das eine Funktion ist, ist die Frage wieso das überhaupt in einen BRAM geschrieben werden soll. Das könnte doch die CPU im Zynq direkt berechnen. ... oder machst du das mit dem Zähler nur um mal das mit dem BRAM auszuprobieren ohne tieferen Sinn?
Gustl B. schrieb: > Ähm ... laut Bildchen sind das 131072 Einträge mit je 32 Bits macht ... > 512 kByte. Und das ist schon eher sehr viel. Okay, war mir nicht sicher weil oben Bit steht, was damit gemeint war. Gut das hilft schon sehr!! Also genug Speicher vorhanden :) Vielen Dank für die Klarstellung! > Aber: ... > ... oder machst du das mit dem Zähler nur um mal das mit dem BRAM > auszuprobieren ohne tieferen Sinn? Zu dem "Aber". Ja ich mache das als Test um später 32 Bit große Daten aus einem Mikrofon auf der SD Karte speichern zu können. Die Filterung am FPGA mit 22Bit am Ausgang hätte ich schon getestet, allerdings keine Ahnung wie ich das am besten speichern kann. Dachte BRAM wäre am einfachsten zum Umsetzen. Der BRAM wäre nur der Zwischenspeicher, wo die ankommenden Daten (39Kilosample/s) für 1-3 Sekunden gepuffert werden sollten, damit ich die dann auf die SD schieben kann. Wäre das eine Möglichkeit über BRAM? Theoretisch vom Speicher machbar oder? Sonst müsste ich während dem aufnehmen der Signale immer wieder auslesen und den BRAM neu beschreiben, falls da zu wenig Platz verfügbar wäre...
:
Bearbeitet durch User
BRAM verwendet man eher für kleine Zwischenspeicher. Auf deinem FPGA Board mit Zynq hast du bestimmt auch DDR RAM drauf. Ist eben die Frage wie du das bauen möchtest. Du kannst direkt ohne CPU die Daten auf die Karte schreiben, quasi live. Du kannst aber auch über die CPU gehen und von der aus auf die Karte schreiben. Aber den BRAM brauchst du wohl nicht, die Datenrate ist niedrig. Wenn, dann würde ich da einen kleinen FIFO in BRAM einbauen um Schreibpausen der Karte zu puffern, aber da reichen ein paar wenige kBytes. Geza E. schrieb: > Der BRAM wäre nur der Zwischenspeicher, wo die > ankommenden Daten (39Kilosample/s) für 1-3 Sekunden gepuffert werden > sollten, damit ich die dann auf die SD schieben kann. Ja das geht, aber muss nicht. Vermutlich reicht es deutlich weniger als eine Sekunde zu puffern. Und das brauchst du nicht selbst über einen BRAM mit Adressen zu machen, sondern du kannst dir gleich einen FIFO generieren lassen. Der hat eine Schreibseite und eine Leseseite. Und die Bedingung ist, dass du im zeitlichen Mittel nicht schneller schreibst als du liest. Wenn du also langsamer liest als schreibst, dann läuft der voll. Wenn du den Weg über die CPU gehst kannst du den Puffer auch in Software bauen und die Daten in dem RAM der CPU/PS ablegen.
Gustl B. schrieb: > BRAM verwendet man eher für kleine Zwischenspeicher. Auf deinem FPGA > Board mit Zynq hast du bestimmt auch DDR RAM drauf. Ist eben die Frage > wie du das bauen möchtest. Du kannst direkt ohne CPU die Daten auf die > Karte schreiben, quasi live. Du kannst aber auch über die CPU gehen und > von der aus auf die Karte schreiben. Aber den BRAM brauchst du wohl > nicht, die Datenrate ist niedrig. Wenn, dann würde ich da einen kleinen > FIFO in BRAM einbauen um Schreibpausen der Karte zu puffern, aber da > reichen ein paar wenige kBytes. Wie könnte ich denn direkt vom PL auf die Karte schreiben? Dachte das muss über den PS gehen, über das AMBA Interface oder in der Art. Das Puffern wär so als Notlösung, falls ich nicht den ganzen BRAM vollschreiben kann und ich mehr Platz benötige um die paar Sekunden Signal zu speichern. Im Grunde brauche ich eine möglichst einfache Art ca 3s Sekunden Signal auf die Karte zu bekommen. Dann könnte ich die Mikrofone und den Filter den ich im PL implementierten will vergleichen. Schreibgeschwindigkeit bei den knapp 40kS/s direkt auf die SD wäre eignetlich möglich. Hatte ich aber noch nirgends was darüber gelesen :/ > > Ja das geht, aber muss nicht. Vermutlich reicht es deutlich weniger als > eine Sekunde zu puffern. Und das brauchst du nicht selbst über einen > BRAM mit Adressen zu machen, sondern du kannst dir gleich einen FIFO > generieren lassen. Der hat eine Schreibseite und eine Leseseite. Und die > Bedingung ist, dass du im zeitlichen Mittel nicht schneller schreibst > als du liest. Wenn du also langsamer liest als schreibst, dann läuft der voll. > Wenn du den Weg über die CPU gehst kannst du den Puffer auch in Software bauen und die Daten in dem RAM der CPU/PS ablegen. Also lieber FIFO statt BRAM beschreiben? Und als Trigger zum lesen ein Signal aus dem PL? Leider ist mir da nicht ganz klar wie ich da am besten den FPGA mit dem PS synchronisiere. Hätte da an ein Signal aus dem PL gedacht, mit dem ich über GPIO das lesen des Puffers in der CPU starte, wenn der voll ist? Wäre das eine Möglichkeit? Vielen Dank schonmal für die Hilfe! Ich steh da etwas im Dunklen vor den ganzen Möglichkeiten.
Geza E. schrieb: > Wie könnte ich denn direkt vom PL auf die Karte schreiben? Dachte das > muss über den PS gehen Eigentlich nein. Man muss eben das Interface für die SD Karte implementieren. Mit dem PS und einer Hochsprache geht das aber vermutlich einfacher. Geza E. schrieb: > Also lieber FIFO statt BRAM beschreiben? Vermute ich. Aber habe ich noch nicht gemacht. Aber: Wieso überhaupt SD Karte? Das ist doch lästig die reinstecken, speichern, rausziehen, auslesen, ... du könntest die Daten doch auch direkt zum PC übertragen. UART schafft diese Datenrate ganz locker.
Gustl B. schrieb: > Eigentlich nein. Man muss eben das Interface für die SD Karte > implementieren. Mit dem PS und einer Hochsprache geht das aber > vermutlich einfacher. Genau. Soweit einen Ordner erstellen und beschreiben klappt ja schon. Ich muss nur die Daten aus einer Adresse aus dem PL lesen. Da scheint mir BRAM am einfachsten. Wenn da alle Daten auf einmal gespeichert werden können wär es am besten. Einmal alle Daten rein und danach auslesen und auf die SD. Leider will eben der BRAM nur wenig Daten schreiben. Wenn er die 5000 oder später die 90000 Einträge schreiben könnte, wäre es schon perfekt. Leider aber schreibt er nur eine kurze Zeit, sodass eben nicht alle Zählerwerte auf dem BRAM sind und davon ausgelesen werden können. > > Aber: > Wieso überhaupt SD Karte? Das ist doch lästig die reinstecken, > speichern, rausziehen, auslesen, ... du könntest die Daten doch auch > direkt zum PC übertragen. UART schafft diese Datenrate ganz locker. Es ist die Umsetzung am Board als eigenständige Einheit ohne Computer geplant, sodass Daten selbstständig aufgenommen und gespeichert werden können. Falls dies aber schwer in der Umsetzung ist, ginge zur Not auch UART. Für die UART Übertragung wäre eine Speicherung in einen FIFO die erste Wahl um sie dann seriell an den Computer schicken zu können oder?
Geza E. schrieb: > Da scheint mir BRAM am einfachsten. Weiß ich nicht. Ich glaube ein FIFO wäre besser geeignet. Die gibt es auch mit AXI Anschluss. Geza E. schrieb: > Für die UART Übertragung wäre eine Speicherung in einen FIFO die erste > Wahl um sie dann seriell an den Computer schicken zu können oder? Muss nicht sein. Man kann das auch ohne FIFO über UART streamen. Man muss die Daten eben schnell genug rausschicken. Also schneller als sie ankommen.
Gustl B. schrieb: > > Weiß ich nicht. Ich glaube ein FIFO wäre besser geeignet. Die gibt es > auch mit AXI Anschluss. Ich wollte mir eben das wiederholte auslesen sparen und alles nach dem schreiben auf einmal auslesen (ca 1MB wird es werden). Scheinbar liest aber der PS schneller als der PL schreibt, deswegen kommen nicht mehr Einträge zusammen. Aber irgendwie kann ich das nicht ändern. Hab versucht den Prozessor zu beschäftigen vorm lesen und auch zweimal auszulesen. Ändert auch nicht so viel. Kann es sein, dass der FPGA über JTAG erst gestartet wird, wenn der Prozessor läuft? > Geza E. schrieb: >> Für die UART Übertragung wäre eine Speicherung in einen FIFO die erste >> Wahl um sie dann seriell an den Computer schicken zu können oder? > Muss nicht sein. Man kann das auch ohne FIFO über UART streamen. Man > muss die Daten eben schnell genug rausschicken. Also schneller als sie > ankommen. Das geschieht dann über die UART IP? Habe noch nie mit UART gearbeitet leider
Geza E. schrieb: > Ich wollte mir eben das wiederholte auslesen sparen und alles nach dem > schreiben auf einmal auslesen (ca 1MB wird es werden). Naja ein FIFO hat ein Flag. Das besagt ob Daten in ihm vorhanden sind. Man reagiert also auf dieses Flag und liest immer so lange bis der leer ist. Dann wartet man bis wieder Daten drinnen sind und liest dann wieder. Geza E. schrieb: > Das geschieht dann über die UART IP? Kann man machen. Aber ein UART ist auch einfach selber geschrieben. Man kann einen UART auch wunderbar an einen FIFO anschließen. Immer wenn im FIFO Daten vorhanden sind holt sich der UART diese und schickt die raus.
Geza E. schrieb: > Ich wollte mir eben das wiederholte auslesen sparen und alles nach dem > schreiben auf einmal auslesen (ca 1MB wird es werden). Scheinbar liest > aber der PS schneller als der PL schreibt, deswegen kommen nicht mehr > Einträge zusammen. Aber irgendwie kann ich das nicht ändern. Na irgendwie kannst und mußt Du das schon ändern! Als erstes überlegst Du Dir, wie lange es dauert, bis die gewünschte Datenmenge zusammen kommt. Als nächstes baust Du Kontrollmechanismen ein: Das Prozessorsystem erlaubt das Datensammeln und stoppt es auch wieder. Außerdem kommt ein Zähler rein, damit Du weißt, wie viele Daten schon gültig sind. > Hab > versucht den Prozessor zu beschäftigen vorm lesen und auch zweimal > auszulesen. Das klingt nach Murks. > Kann es sein, dass der FPGA über > JTAG erst gestartet wird, wenn der Prozessor läuft? Du solltest nochmal einen Schritt zurückgehen und ein paar Grundlagentutorials zum Zynq durchackern. Duke
Duke Scarring schrieb: > Na irgendwie kannst und mußt Du das schon ändern! > Als erstes überlegst Du Dir, wie lange es dauert, bis die gewünschte > Datenmenge zusammen kommt. Als nächstes baust Du Kontrollmechanismen > ein: Das Prozessorsystem erlaubt das Datensammeln und stoppt es auch > wieder. Außerdem kommt ein Zähler rein, damit Du weißt, wie viele Daten > schon gültig sind. In dem Fall habe ich die Zählerdaten vom FPGA abbrechen lassen. Also kenne ich den Endpunkt der Daten und wieviele gültig sind. Kann ich die dann danach als ganzes vom PS auslesen? Bzw meine eigentliche Frage: Muss ich dem FPGA ein Startsignal geben, damit der VHDL Code abgearbeitet wird? Beim Boot über SD passiert das ja. >> Kann es sein, dass der FPGA über >> JTAG erst gestartet wird, wenn der Prozessor läuft? > Du solltest nochmal einen Schritt zurückgehen und ein paar > Grundlagentutorials zum Zynq durchackern. Ich bin natürlich noch ein Einsteiger, aber diese Frage ist mir noch nicht untergekommen? Um es genauer auszudrücken. Lauft der PL Code sobald ich den FPGA über SDK programmiere? Mir scheint so als würde dies nicht passieren... Danke für die Hilfe. Geza
Geza E. schrieb: > In dem Fall habe ich die Zählerdaten vom FPGA abbrechen lassen. Also > kenne ich den Endpunkt der Daten und wieviele gültig sind. Gut. > Kann ich die > dann danach als ganzes vom PS auslesen? Wenn die wirklich alle in den BRAM passen, warum nicht. > Muss ich dem FPGA ein Startsignal geben, damit der VHDL Code > abgearbeitet wird? Ein FPGA - hier die PL - wird konfiguriert und rennt dann sofort los. Es schadet natürlich nicht hier noch ein Signal einzubauen, um die Zähler rückzusetzen und die Datenaufzeichnung zu starten. > Lauft der PL Code > sobald ich den FPGA über SDK programmiere? Mir scheint so als würde dies > nicht passieren... Es gibt mehrere Möglichkeiten den PL-Teil zu konfigurieren: - via JTAG - via FSBL - via uboot - via Linux
Thread beobachten
Seitenaufteilung abschaltenBitte 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.