mikrocontroller.net

Forum: FPGA, VHDL & Co. FPGA Coprozesser Blöcke werden wegoptimiert


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jens W. (jensw)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich arbeite mich gerade in FPGAs ein. Dazu habe ich ein Board gemacht 
mit einem Xmega und einem Spartan 6 LX9.
Das ist rein für mein Hobby und auch nicht meine Abschlussarbeit. Die 
ist schon länger her. :-)

Ich möchte das FPGA als Coprozessor für den Xmega verwenden. Hier sollen 
Berechnungen in 8,16,32 und 64bit laufen. Jeweils signed und unsigend.
Später auch noch float. Je nachdem wie schnell das FPGA voll ist.
Angebunden ist das FPGA über den EBI des Xmega.
Zusätzlich ist noch ein externes SRAM angebunden. Der Zugriff darauf 
funktioniert auch. Also die Schaltung und das Board ist ok.

Jetzt habe ich angefangen eine ALU zu bauen, die die Berechnungen 
durchführen soll.
Das Problem ist jetzt, dass alle Unterblöcke weg optimiert werden.
Ich habe auch schon gesucht und es könnte sein, dass es daran liegt, 
dass die Daten für die Berechnungen über ein Dual-Port-Ram übergeben 
werden.
Die Signale gehen eben nicht auf einen FPGA Pin direkt.
Ich finde aber leider nichts dazu wie man das Problem umgehen kann.

Kann mir da bitte jemand von euch auf die Sprünge helfen?
Wie macht man das richtig?

Vielen Dank!

Grüße, Jens

von FPGAzumSpass (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hab leider kein ISE hier drauf, deswegen kann ich jetzt nicht das 
Projekt bauen.

Prinzipiell wird das wegoptimiert was du eh nicht benutzt hättest. Das 
kann an nicht angeschlossenen Pins liegen oder aber auch an Bedingungen 
die nicht eintreten können, z.b. ein Vergleich mit unterschiedlichen 
Bitbreiten.

Oft kann man was in den Reports finden. So auch hier in der Datei 
xst.xmsg im _xmsg Unterordner:

ALU_CTRL.vhd:
line 73
"All outputs of instance My_ALU_CONSTANTS are unconnected - Underlying 
logic will be removed."

Das Gleiche gilt für alle andere ALU_SX Blöcke genauso.



Der Grund dafür liegt mMn in Zeile 168:
internal_ALU_INPUTS(135-i*8 downto 136-i*8-8) <= di_ram after 5ns;

Du nimmst hier das 8 Bit di_ram und schreibst es 17 mal in einen 
breiteren Vektor und zwar als Kopie, nicht etwa zu Unterschiedlichen 
Zeiten.
(Das "after" dort ist eh eine schlechte Idee, weil es in der Logik dort 
keine Verzögerung gibt solange du das hinterher wieder eintaktest, deine 
Simulation wird sich damit eventuell anders Verhalten wie die Hardware, 
die das "after" einfach ignoriert)

Dadurch das dort z.b. Bit 0-7 und 128-135 immer den gleichen Inhalt 
haben, lässt sich warscheinlich jede Menge wegoptimieren.

Das ist aber jetzt erstmal nur eine Vermutung, könnte auch woanders 
liegen.

Allgemein ist der komplette "next_state_proc" sehr ungünstig formuliert, 
weil du dort viel zu viel ungetaktet machst, u.a. Pins für das Dualport 
ram treiben.


Mein Tip für sowas: Simulation. Die Logik ist doch nun wirklich komplex 
genug um dort Fehler einzubauen, die man nicht aufwändig mit 
Logikanalyzer oder Scope finden will, d.h. es lohnt sich in jedem Fall.

Und um Anderen vorzukommen:
verwende nicht STD_LOGIC_UNSIGNED und STD_LOGIC_ARITH und NUMERIC_STD. 
Wirf einfach die ersten beiden raus, die brauchst du nicht wenn du 
richtig castest/konvertierst.

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielen Dank schonmal.
Da scheint noch mehr im Argen zu liegen. Macht es dann wirklich Sinn 
schon zu schauen, warum das weg optimiert wird, oder sollte ich nicht 
nochmal über die Architektur nachdenken.

Du schreibst ja, dass auch bei dem Zustandsautomat wenig getaktet ist 
und das zu Problemen führen kann/wird.

Das ist genau das was ich eigentlich verstehen und lernen will, wie man 
so etwas richtig macht.

Ich lade heute Abend das Blockschaltbild hoch und schreib ein bisschen 
mehr, was ich mir dabei gedacht habe.
Ich bin auf deine Meinung gespannt.

Grüße, Jens

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jens W. schrieb:
> Die Signale gehen eben nicht auf einen FPGA Pin direkt.
> Ich finde aber leider nichts dazu wie man das Problem umgehen kann.
Alle Ausgänge die nicht verwendet werden, werden von der Synthese 
wegoptimiert.
Ein großes AND, OR oder XOR und dann alles auf einen unbenutzten 
Ausgangspin gegeben hilft hier erstmal weiter.

Ich hätte übrigens nicht mit der ALU angefangen, sondern mit der 
Kommunikation über das EIB-Interface: schreiben und zurücklesen.

Duke

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Duke,

das habe ich auch so gemacht. Das Schreiben und Lesen über EBI in 
externe Ram und auf die eine Seite des Dual Port Rams funktioniert. Das 
habe ich schon getestet.

Und da ist das Problem. Ich kann die Werte, die ich übergebe, nicht auf 
Pins legen. Die Schnittstelle ist ja das RAM.

Unter dem Strich wird das ein speichergekoppeltes System werden.
Dual Port Rams sind ja auch Standard in Designs. Es muss also einen Weg 
geben, das auch dem Synthesewerkzeug beizubringen.
Da hänge ich halt gerade dran.

Wie gesagt, ich lade heute Abend noch ein paar Infos mehr hoch, damit 
sich jeder ein genaueres Bild machen kann.
Sonst macht die Diskussion keinen Sinn.

Und vermutlich bleibt mir dann nichts anderes übrig, als wieder ein paar 
Schritte zurück zu gehen und das System in der Architektur nochmal zu 
überdenken. Wahrscheinlich habe ich mich da schon verrannt.
Aber da freue ich mich drauf. Schließlich will ich das ja verstehen und 
lernen wie das richtig gemacht wird.

Grüße, Jens

von FPGAzumSpass (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn du ins Dual Port Ram schreiben und wieder lesen kannst, dann ist es 
die andere Seite die keine Funktion hat.

Mal ein Beispiel bei dir:

In state decode_op wird internal_ALU_RESULT etwas zugewiesen und zwar 
rein ungetaktet.
Einen Takt später benutzt du es aber bei execute_op um do_ram zu füllen.

Weil internal_ALU_RESULT nie getaktet wird baut er daraus im "besten" 
Fall ein Latch, kann aber auch sein das es ganz wegoptimiert wird. In 
diesem State gibt es einfach keinen Treiber für das Signal.


Versuche mal als erstes jede nichttriviale Zuweisung getaktet zu machen 
und nur jede triviale Zuweisung ungetaktet, dann aber auch stetig.


In dem Beispiel würden bei mir alle Zuweisungen zu internal_ALU_RESULT 
getaktet stattfinden.
Die Zuweisung zu do_ram wiederrum wäre gar nicht in dem process sondern 
als dauerhafte Zuweisung die immer aktiv ist zu finden.
Lediglich das we_ram wäre wiederrum getaktet.

von berndl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jens W. schrieb:
> Das Schreiben und Lesen über EBI in
> externe Ram und auf die eine Seite des Dual Port Rams funktioniert. Das
> habe ich schon getestet.

wie genau hast du das getestet? Eine Adresse geschrieben und dann 
zurueck gelesen? Oder das ganze RAM geschrieben und dann das ganze RAM 
wieder zurueck gelesen? Ich frage fuer einen Freund...

Spaessle. Wie ist denn dein EBI Timing eingestellt beim lesen? Passt 
das, wenn du ein BRAM verwendest? Hast du das mal simuliert? So mit 
realistischen Timings?

von Jens W. (jensw)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Berndl:
Ich habe eine RAM Test Funktion, die das gesamte externe RAM (SRAM) mit 
Daten füllt. Und zwar rechne ich mit den Laufvariablen, den aktuellen 
Ergebnissen und so weiter eine CRC Prüfsumme und schreibe diese.
Das gibt ganz gut "zufällige" Werte.
Ich schreibe das gesamte RAM voll und dann lese ich zurück und berechne 
nochmal die gleichen Werte, die ich beim Schreiben schon gerechnet habe. 
Diese vergleiche ich. Wenn die gleich sind, dann ist das RAM richtig 
geschrieben und gelesen.
Zusätzlich habe ich die Möglichkeit über den JTAG Debugger mir die Werte 
anzuschauen, die ich Schreibe und Lese.
Das ist also im echten System getestet.
Mit dem EBI Timing hat das nichts zu tun. Das hat mich auch schon Nerven 
gekostet. Aber das habe ich hin bekommen. ;-)

Ich habe mal ein Screenshot von der Top Entity angehängt. Auf der linken 
Seite sieht man wie die einzelnen Module zusammen gehören. Im Schematic 
wird klar, wie ich mir das gedacht habe.
Memory Interface ist der Block, der das Timing für den EBI inne hat. 
Daran ist die Schnittstelle zum externen RAM dran (das geht direkt auf 
die Pins des FPGA über Adresse, Daten, CE, OE und WE).
Wenn man nun in die ersten 256 Byte der Speichermap schreibt gelangen 
die Daten nicht ins externe RAM, sondern ins Dual Port RAM.

Und das ist auch die einzige Schnittstelle für ALU_CTRL. Hier sollen die 
Berechnungen laufen und das Ergebnis wieder über das Dual Port Ram 
ausgetauscht werden.

Ich hoffe so wird klar, wie ich mir das gedacht hatte.

@FPGAzumSpass:
Wenn ich die Zuweisung der Signale getaktet machen soll, das verstehe 
ich. Aber wenn ich versuche das in den Zustandsautomaten zu integrieren 
wird es wohl doch sehr unübersichtlich. Wie trennt man das denn sinnvoll 
auf?
Gibt es da was ähnliches wo ich mir das vorher mal anschauen kann wie 
das aussehen muss? Hast du da eine Quelle?

Vielen Dank euch schonmal!

Grüße, Jens

von FPGAzumSpass (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ob das übersichtlicher ist oder nicht, da scheiden sich wohl die 
Geister.

Ich persönlich bevorzuge die 1-Prozess schreibweise, manche benutzen 
aber sogar die 3-Prozess Schreibweise.

Hier mal eine sehr gute Erklärung von Lothar:
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html


Habe mal dein Modul umgeschrieben und angehangen. Ohne Anspruch auf 
Korrektheit, aber sollte zumindest zeigen wie ich mir das vorstellen 
würde.

Habe mir erlaubt die Abfolge der Signale in der FSM umzustellen, so wie 
ich glaube das es richtig(er) ist und eine Anmerkungen an die Steps 
geschrieben, die aktuell nicht funktionieren können.


Überleg dir unbedingt wie dein DualPort Ram Zugriff aussehen soll.
An deiner Stelle würde ich den Zugriff auch nicht mit 8 Bit machen, weil 
das sehr lange dauern wird. Wenn du genug Blockrams hast bietet sich ein 
136 Bit Zugriff an. Das braucht dann zwar 4 Blockrams, gibt dir aber 
einen Request mit einem Zugriff statt mit 17!

Blockrams können beide Seiten mit unterschiedlicher Bitbreite behandeln 
und auch ein Byteenable ist möglich.


Wenn das übrigens so aussieht wie ich es im Moment vermute, nämlich das 
du immer nur die gleichen 136 Bit benutzen willst, dann würde ich 
überhaupt kein Blockram dafür verwenden, sondern gleich 136 Flipflops, 
also ein getaktetes Signal. Das macht es nicht nur viel einfacher, 
sondern auch schneller und braucht weniger Ressourcen!

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

vielen Dank für die Infos soweit. Das schaue ich mir an.
Die Seite von Lothar hilft mir sehr denke ich.

Auch den Zugriff über das RAM werden ich anders gestalten. Die 
Implementierung für das Dual Port Ram ist aus dem XST User Guide. Da ist 
kann ich die Seite B ohne Problem mit einem breiten Vector machen.
Ich werde zuerst versuchen hier die Daten richtig austauschen zu können 
und dann weiter in die einzelnen ALU Blöcke gehen.

Ich halte euch auf dem Laufenden. Aber ich werde sicher ein paar Tage 
brauchen.

Grüße, Jens

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich gebe euch ein kurzes Update.
Die Tipps haben mir schon sehr weiter geholfen! Vielen Dank!

Ich habe nun erstmal alle Unterblöcke raus genommen und konzentriere 
mich auf den Zustandsautomat und den Datenaustausch. Ich rechne im 
ersten Schritt nur Operant_A + Operant_B.
Beim synthetisieren sieht man auch, dass jetzt deutlich Ressourcen 
verbraucht werden. Da tut sich also was.

Ich mach am Wochenende eine Testbench dazu und kontrolliere die 
Ergebnisse. Erst wenn das richtig tut, gehe ich einen Schritt tiefer in 
die einzelnen Blöcke.
Vermutlich komme ich da auch mit weniger aus. Das sieht zumindest für 
mich danach aus. Aber das wird sich zeigen.

Eine Frage habe ich nun jetzt schon. Ich will eine Multiplikation 
machen. Da kann man einfach a * b schreiben und da kommt auch irgendwas 
raus, aber sollte man das auch so machen?
Bei der Division habe ich schon gesehen, dass es besser ist, dass 
richtig zu machen so wie von der Seite von Lothar Miller. Aber wie sieht 
es bei der Multiplikation aus? Sollte man das auch "zu Fuß" machen?

Grüße, Jens

von FPGAzumSpass (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Multiplikation kannst du ruhig mit * machen. Wenn die Operation das 
Timing nicht schafft, dann musst du eventuell einen Multicycle Path 
daraus machen. Immer noch besser als die Multiplikation per Code in 
mehrere Cycles zu zerteilen.

Die Frage die du dir eher stellen musst, ist was du mit den Ergebnisbits 
machst.
Bsp: 32bit * 32Bit sind 64Bit.

Möglichkeiten das Umzusetzen sind:
- volle 64 Bit als Ergebnis -> muss deine Architektur hergeben
- 2*32 Bit als Ergebnis -> 2 verschiedene Opcodes für High und Low
- nur die unteren 32 Bit als Ergebnis, eventuell mit Überlaufcheck

Bisher hattest du die dritte Variante ohne Überlaufcheck.

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
So ein kleines Update von mir:

Ich habe das Design überarbeitet. Das läuft auch soweit.
Die einzelnen ALU-Blöcke für die verschiedenen Rechenoperationen 
funktionieren für sich.
Ich verwende aber den Core Generator. Ich erhoffe mir dadurch, dass die 
Blöcke effizienter sind als meine, da die Entwickler von Xilinx das 
sicher besser drauf haben als ich.
Ergänzt habe ich auch Float, sin, cos und so weiter. Das FPGA ist damit 
auch gut zur Hälfte gefüllt und das Mapping dauert jetzt schon eine 
Stunde.
Der einzige Core der Probleme macht ist der integer Dividierer. Hier 
verwende ich den div_gen_3.0 aus dem IP Catalogue. Den kann ich nicht 
über
my_xxx: entity work.xxx instanziieren. Da muss ich vorher die componente 
mit definieren. Im Verzeichnisbaum erscheint der Core richtig, aber ich 
kann dafür keine Test bench erstellen. Da bleibt im File ein "?".
Ich habe keine Ahnung woran das liegt. Es scheint aber Cores zu geben, 
die buggy sind. Diese Baustelle bleibt erstmal.

Was mir jetzt Probleme bereitet ist die Testbench für die ALU.
Nachdem ich die Daten über ein Dual Port Ram übergebe, habe ich keine 
Ahnung, wie ich die Daten aus dem RAM für die Simulation übergeben kann.
Am Port habe ich ja nur Adresse, Data_in und Data_out. Da wird zyklisch 
gelesen. Einfach einen Wert an Data_in anlegen geht zwar, aber ich 
bekomme keine Infos was intern läuft. Es werden in der Simulation nur 
die Signale aus der Port map angezeigt. Wie komme ich an die internen 
Signale ran?
Wie macht man das richtig? Da finde ich auch nichts im Netz.
Kann mir jemand von euch da auf die Sprünge helfen?

Grüße, Jens

von Duke Scarring (Gast)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Jens W. schrieb:
> Ich verwende aber den Core Generator. Ich erhoffe mir dadurch, dass die
> Blöcke effizienter sind als meine, da die Entwickler von Xilinx das
> sicher besser drauf haben als ich.
Naja. Meine Erfahrung sind da etwas anders. Zum Einen sind einige Cores 
recht flexibel in der Parametrierung und benötigen dann auch im FPGA 
etwas mehr Fläche. Zum Anderen, warum sollte Xilinx die Cores 
optimieren, wenn man doch so ggf. ein größeres FPGA (mit mehr Marge) 
verkaufen kann.

Was mich aber regelmäßig stört, ist das Xilinx die Interfaces von 
Version zu Version ändert und das sie auf Xilinx limitiert sind.

Jens W. schrieb:
> Es werden in der Simulation nur
> die Signale aus der Port map angezeigt.
Welchen Simulator verwendest Du?

> Wie komme ich an die internen
> Signale ran?
> Wie macht man das richtig? Da finde ich auch nichts im Netz.
> Kann mir jemand von euch da auf die Sprünge helfen?
Üblicherweise kann man sich die im Simulator einfach reinziehen. Siehe 
Anhang.

Duke

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Duke,

mit der Fläche habe ich leider noch keine Erfahrung. Das glaube ich dir 
einfach mal.
Das mit den Interfaces habe ich auch schon gemerkt.
Nachdem der IP Core div_gen V3 Probleme macht, habe ich gedacht, ach, 
dann nimm den neueren Core, da wird das dann sicher besser sein. Von 
wegen! Das Interface ist anders und ich müsste alle anderen Cores drauf 
anpassen, damit es in der gesamten Struktur wieder passt.

Der Plan ist nun, dass wenn überhaupt mal was geht und die Anwendung mit 
dem Controller erstmal funktioniert, dass man dann schaut was man 
optimieren kann. Und wie. Ich will ja eigentlich in erster Linie die 
Architektur von meiner Elektronik anschauen und lernen, wie das geht.

Das Problem mit dem div_gen IP Core werde ich wohl so lösen, dass ich 
den komplett raus schmeiße und die Division von Lothars Seite verwende. 
Die muss ich nur so erweitern, dass sie auch mit signed Variablen 
umgehen kann. Ich will das so machen, dass man sich das Vorzeichen 
merkt, dann die Werte in unsigned wandle, die Division durchführe und 
dann, je nach Vorzeichen, das Ergebnis wieder nach unsigned wandeln und 
ausgeben.

Ich verwende ISIM.
Das mit den Signalen habe ich gefunden. Funktioniert. Da kann ich sehen, 
was ich gesucht habe.

Eine Frage habe ich noch (und ich werde es auch gleich ausprobieren):
Ich übergebe Daten über ein Dual Port Ram. In der Simulation wäre es 
gut, wenn das Ram schon mit den Daten gefüllt wäre, die im richtigen 
Betrieb der Mikrocontroller an das FPGA übergibt. Kann ich für die 
Simulation einfach ein RAM in der Test Bench instanziieren und hier die 
Werte, mit denen ich arbeiten will, als Default Wert reinschreiben? Die 
Idee kam mir heute morgen. Macht man das so, oder gibt es da einen 
eleganteren Weg?
Weil direkt über den Port geht nicht. Da gibt es kein Signal mit dem ich 
neue Daten lese. Daher kann ich darüber die Werte auch nicht zur 
richtigen Zeit übergeben.

Vielen Dank dir!
Bleibt gesund!

Grüße, Jens

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jens W. schrieb:
> Ich will das so machen, dass man sich das Vorzeichen
> merkt, dann die Werte in unsigned wandle, die Division durchführe und
> dann, je nach Vorzeichen, das Ergebnis wieder nach unsigned wandeln und
> ausgeben.
Genau so habe ich das auch schon gemacht.


> Ich übergebe Daten über ein Dual Port Ram. In der Simulation wäre es
> gut, wenn das Ram schon mit den Daten gefüllt wäre, die im richtigen
> Betrieb der Mikrocontroller an das FPGA übergibt.
Ja, der RAM kann schon mit initialen Werten gefüllt sein. Bei FPGA (im 
Gegensatz zu ASIC) klappt das zum Großteil sogar für die Synthese, da 
beim Startup auch die (Block)RAM-Zellen mit initialisiert werden.

Beispiele wie man das in VHDL hinschreibt finden sich im XST user guide 
U627 bzw. UG687.

Duke

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
wenn dein FPGA-RAM vom µC aus befüllt wird, wäre es m.E. sinnvoll, das 
auch in der Testbench entsprechend nachzuvollziehen (dabei kann auch 
einiges schief gehen)?

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Duke: Danke für die Dokumente. Die schau ich mir an.

@Markus: Das stimmt. Habe ich auch schon gemacht.
Das ist sogar schon auf der HW getestet. An der Stelle hängt es jetzt. 
Das RAM wird befüllt und das FPGA muss mit den Daten was machen. Jetzt 
will ich den Teil simulieren, was als Rechenoperation ausgeführt werden 
soll (mit einem simulierten RAM in der Test Bench) und danach versuche 
ich das gesamte Design auf der HW zum Laufen zu kriegen.

Das dauert leider alles etwas, da ich das ja nur nebenbei mache. Und ich 
arbeite mich auch erst in die Materie ein.
Ich habe schon gemerkt, dass das deutlich länger dauert, als wenn ich 
für einen Controller in C einfach eine Funktion hin stelle und das 
laufen lasse (zumindest ist das bei mir so).

Danke euch allen!

Grüße, Jens

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
Jens W. schrieb:
> Ich habe schon gemerkt, dass das deutlich länger dauert, als wenn ich
> für einen Controller in C einfach eine Funktion hin stelle und das
> laufen lasse (zumindest ist das bei mir so).

Das ist so (und wird sich auch nur unwesentlich ändern).

Ist halt ein Unterschied, ob man Hardware macht oder nur fertige 
Hardware nutzt.

von FPGAzumSpass (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich würds so machen:

- Controller Code, sofern tatsächlich nur C, direkt für den PC 
übersetzen.
- Per Define die Schreibroutine zum FPGA ersetzen durch Schreiben in 
eine Datei
- In der Testbench die Datei parsen auf neue Requests und dann mit dem 
normalen Protokoll über die Pins ins FPGA geben
- Berechnen lassen und auf normalem Weg über Pins in die Testbench 
zurück
- Ergebnis in eine andere Datei schreiben
- im C Programm diese Datei parsen und normal den Controller Code weiter 
ausführen


Wenn das Controller Programm auf dem PC nicht oder nur mit immensem 
Aufwand lauffähig ist, dann das gleiche Konzept benutzen, aber die 
Dateien mit einem Script füllen/prüfen.

Eine statische Testbench zu benutzen geht auch, aber spätestens wenn man 
die 5 mal geändert hat, weil man das Nächste probieren will oder die 
Testbench immer komplizierter wird, hat sich der Aufwand locker gelohnt.

Mal ganz davon abgesehen, das sich so ein File-IO Interface für das 
nächste Projekt recyclen lässt.

von Jens W. (jensw)


Bewertung
1 lesenswert
nicht lesenswert
Hallo,

das klingt ein bisschen kompliziert. Also zumindest für mich. Ich komme 
aus der HW Ecke. Skripte schreiben und in Files die Ergebnisse und so 
weiter. Das klingt gut. Aber das tu ich mir im Moment noch nicht an. Da 
versenke ich zu viel Zeit. Da sind meine Lücken zu groß.

@Duke:
Zurück zum Dividieren. Du hast geschrieben du hast das schon gemacht. 
Gibt es da einen Trick sich das Vorzeichen zu merken? Damit man nicht zu 
viel Zeit verliert. Ich hätte da den Zustandsautomat erweitert um einen 
oder zwei Zustände.
Kann man da einen Trick anwenden und sich das erweitern des 
Zustandsautomaten sparen?

Zur Simulation:
Da komme ich weiter! Lasst mich euch an dieser Stelle danken!
Ich bin so begeistert! Ich habe heute früh die ersten Durchläufe laufen 
lassen. Ein paar Fehler waren tatsächlich drin. Klar, hätte mich 
gewundert wenn nicht. ;-)
Addition, Subtraktion und Multiplikation funktionieren. Dividieren noch 
nicht. Aber das ist sicher der Punkt, den ich schon geschrieben hatte, 
dass der IP Core irgendwie Probleme macht. Und da will ich den Code von 
Lothar verwenden.
Float, Sinus und Cosinus fehlen noch. Ich mache erst die Integer 
Operationen fertig. Aber es geht gut voran!

Grüße, Jens

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.