Hallo, Ich habe einen VHDL-Code geschrieben und auch schon in Quartus simuliert. Das Problem ist, dass ich jetzt eine Schaltung dazu benötige. Der RTL-Viewer gibt mir nur eine Schaltung mit Multiplexern aus, die benötigte Schaltung darf allerdings nur aus Not, And, Or, Nand und Nor Gattern bestehen. Kann mir jemand helfen, die Schaltung dazu zu zeichnen? Der Code ist als Datei angehängt (Der PWM Eingang soll übrigens eine Clock sein, was im Code nicht implementiert ist). Danke im Voraus!
Da hat mal wieder jemand keine Lust, seine Hausaufgaben zu machen, hm? Du könntest mal versuchen, dein eigenes Design zu verstehen und überlegen, was du machen würdest, wenn du ein Synthesetool wärest. Erstmal die Boole'schen Gleichgungen aufstellen, vereinfachen und dann in eine Gatternetzliste überführen. Zum Testen kannst du dann deine abgeleitete Gatterschaltung in VHDL formulieren und schauen, ob sie im Simulator das Gleiche macht wie dein ursprüngliches Design. Das nennt sich Logic Equivalence Check (LEQ). Viel Arbeit und großer Lerneffekt. Und wenn du dann noch Lust hast, kannst du in der Multiplexerschaltung aus Quartus jedem Multiplexer durch eine äquivalente Gatterschaltung ersetzen und nochmal den LEQ machen.
Felix A. schrieb: > darf allerdings nur aus Not, And, Or, Nand und Nor Gattern bestehen. https://de.m.wikipedia.org/wiki/Multiplexer#Einfach-Multiplexer
Das soll ein VHDL-Code sein? Ich habe die letzten Monate auch einiges an VHDL geschrieben, simuliert und synthetisiert. Aber das ist ja peinlich und erbärmlich. Das ist ein automatisch generierter Header von Quartus. Das bekommt jeder Erstklässler hin (Grundschule). Sorry, aber so was schwaches erlebt man selten.
Felix A. schrieb: > Ich habe einen VHDL-Code geschrieben und auch schon in Quartus > simuliert. Seit wann gibt es denn in Quartus einen Simulator? Ich dachte die greifen auf Modelsim zurück. > Der RTL-Viewer gibt mir nur eine Schaltung mit Multiplexern aus, Es gibt i.d.R. zwei Varianten vom RTL-View. Einmal den 'logical view' mit dem Multiplexer und dann den 'physical view' mit LUTs und Flipflops. Mein Quartus-VM startet gerade nicht, aber lt. Online-Hilfe findet man die beiden Ansichten unter Tools > Netlist Viewers > RTL Viewer und Tools > Netlist Viewers, and then clicking Technology Map Viewer > Der Code ist als Datei angehängt Äh, nein. VHDL Code hat als Dateiendung .vhd oder .vhdl...
Wieviel Sinn macht es denn, eine Schaltung in Text (VHDL) zu erstellen, um sie sich dann als Grafik anzeigen zu lassen? Wenn es möglich war, die Schaltung abstrakt ohne Vorbild zu bauen, braucht es keine Grafik. Wenn es ein Grafik braucht, oder sie sinnvoll ist, stünde diese wohl am Anfang, oder? VHDL-Programmierer alles Hacker?
Naja, normalerweise beschreibt man eine Schaltung mit einer HDL und dann kommt die Toolchain und bildet das auf dem ab, was es eben im FPGA an Hardware gibt. Cool wäre es, wenn es ein Tool gibt, dem man statt FPGA selber sagen kann welche Hardware vorhanden ist. Z. B. die 74xx Serie und das Tool versucht die Schaltung in so wenig wie möglich Bausteinen dieser Serie unterzubringen und gibt dann auch gleich mit aus wie diese untereinander verbunden sind. Ebenfalls cool wäre wenn man bei Quartus/Vivado nicht nur einen, sondern mehrere FPGAs gleichzeitig auswählen könnte. 1. Wenn man eben schon vorher weiß, dass die Schaltung in keinen einzelnen FPGA passt und man eine Hardware mit mehreren davon bauen wird. Dann könnte das die Toolchain routen und auch die Verbindungen zwischen den FPGAs ausgeben die man dann so als Hardware baut. 2. Wenn man ein Board mit mehreren FPGAs hat und da jetzt ein dickes Design baut. Dann wäre das vermutlich auch besser wenn man das nicht händisch aufteilen müsste, sondern wenn man der Toolchain mitteilen könnte welche FPGAs das sind und wie die untereinander verbunden sind. Edit: Peter schrieb: > Aber das ist ja peinlich und erbärmlich. Das ist ein automatisch > generierter Header von Quartus. Das bekommt jeder Erstklässler hin > (Grundschule). Ja Mensch, er hat die falsche Datei rangehängt, kann passieren. Vielleicht dachte er, dass die Datei das ganze Quartus Projekt enthält.
:
Bearbeitet durch User
🐻 Bernie - Bär schrieb: > VHDL-Programmierer alles Hacker? Vorsicht, das Wort 'Programmieren' fuehrt zu langen Threads. Gustl B. schrieb: > Cool wäre es, wenn es ein Tool gibt, dem man statt FPGA selber sagen > kann welche Hardware vorhanden ist. Z. B. die 74xx Serie und das Tool Das Tool heisst yosys, und es gab m.W. hier auch schon einen Beitrag dazu, wo jemand diskrete Logik fuer die Leiterplatte generiert hat. Mit der Python-API kann man richtig schoene prozedurale Synthese stricken, wo man mit V* laengst nicht mehr weiterkommt. Gustl B. schrieb: > Ebenfalls cool wäre wenn man bei Quartus/Vivado nicht nur einen, sondern > mehrere FPGAs gleichzeitig auswählen könnte. Dann muesste ein solches Tool Leiterbahngeometrie und Impedanzen vorgeben. Altium ging ja mal in die 'wir designen alles'-Richtung. Schien nur irgendwie nicht so recht hinzuhauen, Fazit: Just a fool thinks this tool is cool :-)
Martin S. schrieb: > Vorsicht, das Wort 'Programmieren' fuehrt zu langen Threads. Ich weiss sehr wohl, warum ich das verwendet habe. :-) Es sind ja oft genug C-Programmierer, die sich den FPGAs zuwenden und über ihr eigentliches Feld hinaus (den ARM mit zu SW bestücken) auch noch die Umgebung des FPGAs beackern. Ich nehme mich da selber nicht aus, weil ich auch aus der Controller-Ecke komme. Ich überlasse die Umsetzung in eine Schaltung aber lieber den HW-Erstellern, die sich damit auskennen. Ich sage damit nicht, dass nicht ein C-Entwickler sich das Wissen draufschaffen kann, aber oft genug schaffen die nur sequenziellen Code. Gustl B. schrieb: > Naja, normalerweise beschreibt man eine Schaltung mit einer HDL ... und wenn das aus dem Kopf möglich ist und man keine grafische Darstellung der Schaltung benötigt, wozu dann eine im Nachhinein anlagen? Die kann doch nur der Verifikation dienen. Ich benutze die Schaltungsausgabe des VHDL als Grafik (die bekanntlich automatisch erzeugt wird!) auch nur, um zu prüfen, ob er alles eingebaut hat und es ungefähr so aussieht, wie ich es erwarte. Z.B. kann man ein Signal falsch angeschlossen haben, weil man sich vertippt hat oder es fehlt eine ganze Menge, weil wegeliminiert. Manchmal kann man ein Signal durch mehrere Ebenen verfolgen, wenn es aus einem Core kommt oder einem Modul, das man selber nicht gebaut hat. Die wirkliche Schaltung sieht man aber sowieso nicht, weil solche Sachen wie wegen Zeitverhalten duplizierte Register und andere Schaltungsoptimierung nicht sichtbar sind. So einen richtigen Nutzen sehe ich darin aber nicht. Für eine Dokumentation ist es schon be kleinen FPGAs viel zu unübersichtlich.
🐻 Bernie - Bär schrieb: > Gustl B. schrieb: >> Naja, normalerweise beschreibt man eine Schaltung mit einer HDL > > ... und wenn das aus dem Kopf möglich ist und man keine grafische > Darstellung der Schaltung benötigt, wozu dann eine im Nachhinein > anlagen? Ähm ich habe hier genau nichts zu grafischen Schaltungen geschrieben. Und wenn man mich fragen würde, dann würde ich so antworten: Als Input ist das obsolet, dafür gibt es HDLs. Aber um sich die kritischen Pfade anzugucken ist eine Darstellung als Schaltung durchaus sinnvoll. Gerade weil man dann auch gut sehen kann ob die Toolchain Register verschiebt oder nicht. An dieser Stelle möchte ich auch mal Quartus loben, das Register Balancing funktioniert hervorragend! Bei Vivado deutlich schlechter.
Martin S. schrieb: > Das Tool heisst yosys, und es gab m.W. hier auch schon einen Beitrag > dazu, wo jemand diskrete Logik fuer die Leiterplatte generiert hat. Die wurde mit yosys erzeugt? Und man kann bei yosys als Zielhardware die 74xx Serie auswählen? Edith: Ja wie cool, sowas gibt es tatsächlich! Martin S. schrieb: > Dann muesste ein solches Tool Leiterbahngeometrie und Impedanzen > vorgeben. Naja, maximale Bitrate und Laufzeit sollte reichen. Man könnte das ja auch extern constrainen so in der Art "Du darfst die FPGAs untereinander verbinden aber maximal bis 200 MBit/s und die Leitungen sind gleich lang."
:
Bearbeitet durch User
Gustl B. schrieb: > das Register Balancing funktioniert hervorragend! Bei > Vivado deutlich schlechter. Ja? Wie festgestellt?
Bernie - Bär schrieb: > Wieviel Sinn macht es denn, eine Schaltung in Text (VHDL) zu erstellen, > um sie sich dann als Grafik anzeigen zu lassen? Daran kannst du ganz fluffig erkennen, ob der Synthesizer deine textuelle Beschreibung der Hardware so verstanden hat, wie du meinstest, dass sie aussehen sollte. > Wenn es ein Grafik braucht, oder sie sinnvoll ist, stünde diese wohl am > Anfang, oder? Ja, so eine "Schaltung" sollte mindestens im Kopf des VHDL-Entwicklers sein. Denn eigentlich denkt der sich eine Schaltung aus und verwendet dann die "Hardwarebeschreibungssprache" VHDL, um seine Schaltung zu beschreiben. > VHDL-Programmierer alles Hacker? Jeder, der meint, er könne ein FPGA wie einen µC programmieren, ist ein Hacker, der sich wundert, warum sein "Progamm", in dem Prozesse "aufgerufen" werden, mal läuft und mal nicht.
🐻 Bernie - Bär schrieb: > Gustl B. schrieb: >> das Register Balancing funktioniert hervorragend! Bei >> Vivado deutlich schlechter. > > Ja? Wie festgestellt? Es wurde ein kleines Beispieldesign erstellt bei dem viel Kombinatorik zwischen den Eingangs- und Ausgangsregistern sitzt. Und dann wurde per Generic ermöglicht weitere Registerstufen hinten ranzuhängen. Bei Quartus wurde das Timing mit den ersten paar zusätzlichen Registerstufen deutlich besser und blieb dann irgendwann konstant. Bei Vivado hat nur eine zusätzliche Registerstufe minimal das Timing verbessert, weitere Registerstufen verbesserten das Timing nichtmehr. Und wenn man sich das Design, also die Netzliste am Ende angeguckt hat, dann hat Quartus tatsächlich die Logik zwischen die Stufen gepackt, während bei Vivado die allermeisten Stufen am Ende schlicht hintereinander geschaltet und die Logik fast nur zwischen den ersten beiden Stufen war. Hat mich auch etwas überrascht, aber da ich jetzt weiß wie gut Quartus das macht werde ich jetzt bei meinen Komponenten einfach ein Generic einbauen mit dem man Pipelinestufen hinzufügen kann wenn das vom Design her möglich ist.
Gustl B. schrieb: > Ebenfalls cool wäre wenn man bei Quartus/Vivado nicht nur einen, sondern > mehrere FPGAs gleichzeitig auswählen könnte. Gab und gibt immer mal wieder Forschungsprojekte, Papers und Abschlussarbeiten dazu. Automatic Partitioning, automatisiertes Bauen von Netzwerken, einfügen von Brides etc. Die andere Ecke wo das im Alltag läuft ist bei den Emulatoren von Mentor oder Cadence. Also die Schrank-grossen Teile wo Kuchenbleche voll FPGAs (heute eher Mix aus ASIC mit FPGA Teil) drin sind und Tools automatisiert ein riesen ASIC/SoC Design darauf mappen damit dann der ganze Chip emuliert werden kann, was dann natürlich um Faktoren schneller ist als ein V* Simulator. Disclaimer: Das kenne ich alles nur aus Prospekten, Webseiten etc. Ich backe viel viel zu kleine Brötchen, das sowas auch nur annähernd finanzierbar wäre bei uns.
Gustl B. schrieb: > Bei Quartus wurde das Timing mit den ersten paar zusätzlichen > Registerstufen deutlich besser und blieb dann irgendwann konstant. Bei > Vivado und du hast jeweils analoge Einstellungen verwendet? Ich meine, dass man solche Sachen wie Registerumbau für Synthese und Implementierung getrennt kommandieren kann und sich dies zwischen A und X auch jeweils unterscheidet. Wenn, müsste man bei beiden alles maximal anschalten, meine ich.
🐻 Bernie - Bär schrieb: > Wenn, müsste man bei beiden alles maximal anschalten, meine ich. Ich glaube genau das getan zu haben. Aber probiere doch selber, so ein kleines Projektlein ist in wenigen Minuten aufgesetzt.
Wie haben da durchaus "große" Projektchen, aber noch nicht so detailliert verglichen. Und ich frage mich, ob man das überhaupt kann, weil die Einstellungen unterschiedlich sein dürften. Es wäre aber sicher für Viele interessant, solche Vergleiche zu haben: Z.B. zwei Chips zu ähnlichen Kosten nehmen und dann mit unterschiedlichen Extremeinstellungen AREA, Default und SPEED: * Verbrauch der Logikzellen * Verbrauch an RAM-Zellen * maximale Schaltgeschwindigkeit * Dauer der Synthesen Für mich: Verhalten bei hohen Temperaturen um 100°C.
🐻 Bernie - Bär schrieb: > Und ich frage mich, ob man das überhaupt kann, > weil die Einstellungen unterschiedlich sein dürften. Ja, so ist das. Ein Teil der Vergleichbarkeit steht und fällt dann mit dem Typen der das Design geschrieben hat und der die Einstellungen in der Toolchain macht. Weil ich selber weder Vivado noch Quartus Profi bin würde mich mal eine Art Wettbewerb interessieren an dem auch Profis teilnehmen. Und zwar in verschiedenen Stufen: 1. Es werden nur die Ports vorgegeben und was das Design machen soll und eine maximale Latenz. Und dann gewinnt der mit wenigsten Ressourcen, höchster Takt, ... herstellerabhängige IPs dürfen natürlich nicht verwendet werden. 2. Es wird ein komplettes Design vorgegeben und dann gewinnt der der die optimalen Syntheseeinstellungen findet. Mich interessiert daran was gegenüber den Standardeinstellungen herausgeholt werden kann und auch ob es Sinn macht das Design sehr kleinteilig zu beschreiben auf Ebene von Logikgattern oder ob eine abstrakte Beschreibung auf Ebene von Integern und so ähnlich gut optimierbar ist.
Gustl B. schrieb: > eine Art Wettbewerb Das ist sicher interessant, aber m.E. letztlich nur von akademischem Wert. 1. Muß man die Hardwareplattform oft schon vorm Design wählen, damit die Leiterplattenabteilung schon mal loslegen kann. Wer Zeit hat, kann natürlich auch erst das Design komplett fertig machen, nur um dann festzustellen, das es so auf der Hardware doch nicht geht. 2. Ist jedes Design anders. Das eine performt vielleicht besser auf A und das andere auf X. Und auf L ist es eh langsamer, weil ein anderer Halbleiterprozess genutzt wird, der ist dafür stromsparender. 3. Kaum ist man fertig, kommt der Kunde, das Marketing oder der verantwortliche Entwicklungsleiter mit einer Idee, die alle bisherigen Ergebnisse wertlos macht. Letztendlich wird man den FPGA-Hersteller nur wechseln, wenn sehr gute Gründe dafür vorliegen. Sicher ist ein Teil der FPGA-Erfahrungen weiterhin nutzbar, aber die ganzen gemeinen Fallstricke muß man bei jedem Hersteller neu finden :-/ Nach meiner Erfahrung spielen übrigens die Einstellungen der Toolchain nur eine untergeordnete Rolle. Damit kann man, wenn es gut läuft vielleicht noch 10% bis 15% rausholen. Aber wenn das Design schon so auf Kante ist, das man an den Defaulteinstellungen drehen muß, wird es auch recht schnell schwierig weitere Features ins FPGA-Design zu integrieren.
> Für mich: Verhalten bei hohen Temperaturen um 100°C. 100 °C ist ein Interessanter Betriebspunkt um FPGAs zu vergleichen. Da unterscheiden sich die verschiedenen Chips und Hersteller gewaltig. Z. B. bei einem AMD Kintex Ultrascale läuft die statische Stromaufnahme eher exponentiel weg zwischen 80 und 100 °C. Bei anderen habe ich das weniger extrem gesehen (Also jeweils in den power estimator Tabellen), z. B. beim PoarFire, da blieb es näher dran an linearem Zuwachs bei diesen Temperaturen.
Gustl B. schrieb: > Die wurde mit yosys erzeugt? Und man kann bei yosys als Zielhardware die > 74xx Serie auswählen? Man muss allenfalls einen Technology-Mapper fuer seinen Logikzoo schreiben. Ist aber nicht allzu schwierig. Wird im Prinzip laufend bei alternativen Chipprojekten gemacht, Google hatte da mal ein OpenSource-Synthese-Ding am laufen. Gustl B. schrieb: > Mich interessiert daran was gegenüber den Standardeinstellungen > herausgeholt werden kann und auch ob es Sinn macht das Design sehr > kleinteilig zu beschreiben auf Ebene von Logikgattern oder ob eine > abstrakte Beschreibung auf Ebene von Integern und so ähnlich gut > optimierbar ist. Ich habe bis jetzt ' etwa 4-5 verschiedene Architekturen evaluiert, davon drei mit yosys, die kochen sich etwas weg. Bei X und L schenkt sich aufgrund der aehnlichen Synthese nicht viel (modulo LSE versus Synplify). Die abstrakte Beschreibung ist erstaunlich oft gut optimierbar, es gibt aber Pitfalls. Bei Bus-Architekturen faellt mir gerade das Thema mit partieller Zuweisung ein (`v[4:0] <= x`), wo man gut daran tut, eine Abstraktion mit Umschaltung der Default-Werte ('X' oder definiert) einzufuehren. Da das Thema hochkomplex ist, und eh nicht in einen Thread passt, wuerde ich am ehesten noch auf die gaengigen Fuzzing-Techniken verweisen. Und allenfalls pytest, um eine grosse Testmatrix zu bauen. Grundsaetzlich ist es natuerlich wuenschenswert, mehr Einfluss auf das Technology-Mapping zu haben, um architekturspezifische Eigenheiten aus dem Source rauszuhalten (das gelingt VHDL und Verilog nicht).
Rick D. schrieb: > Letztendlich wird man den FPGA-Hersteller nur wechseln, wenn sehr gute > Gründe dafür vorliegen. Absolut. Sehe ich tagtäglich. Xilinx z.B. konnte sich gegen Altera jahrelang überhaupt nur deshalb behaupten, weil sie schon in der Firma drin waren. Dabei spielte auch die krüppelige ISE ein Rolle. Trotz Vorteil für Altera scheut man sich einfach für 1-2 neue Projekte einen anderen FPGA-Typen einzuführen. Und es ist ein Kostenfaktor: Nimmst du weniger Chips von der einen Sorte ab, werden die anderen teuer:-) > die ganzen gemeinen Fallstricke muß man bei jedem Hersteller neu finden ... wobei man sagen muss, dass die Fallstricke stark an die IDE und den Chip gekoppelt sind. Die Umgehungsstrategien müssen hauptsächlich für einen neuen Chip neu erlernt werden. Da kann man schon mal wechseln. Bei Firmen, die strategisch immer 2 Hersteller fahren, geht das dann recht schnell. > Nach meiner Erfahrung spielen übrigens die Einstellungen der Toolchain > nur eine untergeordnete Rolle. Damit kann man, wenn es gut läuft > vielleicht noch 10% bis 15% rausholen. Da muss ich etwas widersprechen: Wenn ich Teile meiner Audiosignalalgos, die BRAM und DISTRI-RAM benutzen und sowohl auf fabric-MUL als auch DSPs laufen, in Richtung Fläche biege, dann wird das mal schnell 30%-40% kleiner und entsprechend langsamer. Umgekehrt wächst die Schaltung enorm, wenn ich auf Zeit optimieren muss, um die Frequenz zu schaffen. Auf diese Weise ist z.B. ein Design für 100 MHz, das zwei Pfade brauchte, um die Bandbreite zu schaffen, die das globale 200M Design braucht, nur 20%-30% größer, weil das eigentliche Design auf gut 60% zusammengekürzt wird. Da fliegen viele timing-FFs raus, es werden FFs fürs Distri-RAM frei, die das wieder weniger langsam machen und es werden sogar BRAM-Zellen frei, in die langsame FFs geschoben werden können. Die Architaktur muss nur heterogen genug sein und viel von allem in unterschiedlicher Weise nutzen, dann kann man es auch mit Platz- und Zeit-Vorgaben "in die Ecke drücken".
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.