FPGA Schaltplaneditor

Hat schonmal einer den Schaltplaneditor von den diversen FPGA-Synthesizerprogrammen verwendet? Ich habe letztens den von Quartus ausprobiert, hauptsächlich da ich mir dachte, daß man damit besser die Struktur eines Systems visualisieren und dokumentieren kann, als per reinem VHDL. Erstmal nur für Hauptebene und nur bei einigen größeren Entities auch für die Ebene darunter. In dieser Kombination ist das eine gute Idee, denke ich: Die Entities mit vielen und komplexen Prozessen schreibt man weiterhin in VHDL, da das als Diagramm recht unübersichtlich werden würde, erzeugt ein Symbol daraus und die in VHDL redundante und umständliche Verdrahtungsarbeit der Entities untereinander macht man grafisch im Schaltplaneditor. Kleinere Dinge, wie Inverter usw., kann man aber direkt mit ins Diagramm einbauen.

Was haltet ihr davon? Ich finde es von der Idee her gut, aber der Schaltplaneditor von Quartus ist noch schlimmer als Eagle. Hierarchisches Arbeiten ist zwar möglich, aber wenn man z.B. mal einen Pin mehr oder weniger an einem Symbol haben will, muß man eine Textdatei manuell editieren, denn es gibt keine forward/backward Anpassung zwischen VHDL und Symbol. Man könnte das Symbol zwar neu generieren, aber dann sind natürlich alle manuell gemachten Verschiebungen für Gruppierungen oder andere Positionen der Pins weg. Also noch verbesserungswürdig. Sind die Editoren von Xilinx, Actel, Lattice usw. besser?

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss
Loading thread data ...

Der HDL Designer von Mentor macht genau sowas. Ist leider teuer. In Grosskonzernen arbeiten die Leute damit, um besser dokumentieren zu können. Mit dessen Hilfe hab ich mich schon in so einige fremde Designs reingearbeitet, und bilde mir ein damit schnell klargekommen zu sein. (Allerdings waren da immer die Core-Entwickler auch greifbar, und Rückfragen gibts da immer...)

Also kein schlechtes Tool, aber massenweise Programmierfehler, die Xilinx SW EDK oder gar ISE sind eine Erholung dagegen.

Und die verschiedenen Versionen sind auch nicht gerade kompatibel, wenn man Designs über viele Jahre aufheben und vielleicht sogar pflegen soll, ist reines VHDL oder Verilog wohl am einfachsten.

Eine gute Doku zum Design (und im Design) brauchts allemal, sodass andere da was ändern können.

MIKE

--
www.oho-elektronik.de
OHO-Elektronik
Michael Randelzhofer
FPGA und CPLD Mini Module
Klein aber oho !
Kontakt:
Tel: 08131 339230
mr@oho-elektronik.de
Usst.ID: DE130097310
Reply to
M.Randelzhofer

Ja, stimmt. Ist nicht schlecht um mal eben Übersicht in einen legacy chip zu bringen.

Du musst ISE 7, 8, 9.1 übersprungen haben.

Ich glaube, wir kennen uns von E..., aber emails zu Dir sind letztes Jahr immer gebounced. (Du bist mindestens so groß wie ich, was was heissen will :-) ?

Reply to
Gerhard Hoffmann

"Gerhard Hoffmann" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

Oh yes, siehe PM

MIKE

Reply to
M.Randelzhofer

Ich hab' die alle mitgemacht, und sie waren durchaus benutzbar. Keine Offenbarung natürlich, aber immerhin.

Gruß Henning

Reply to
Henning Paul

Finde ich auch, die Kommandozeilentools sind alle tauglich. Wer die GUI benutzt (oder benutzen muss) ist natürlich selber schuld. Ich sehe keinerlei Vorteil die zu starten, ausser einmal die Kommandozeilenparameter rauszufinden.

Ich weiss auch nicht, warum immer so über die vermeintlichen Synthesebugs von xst gelästert wird. Alle Bugs, die ich anfangs auf xst geschoben habe, haben sich im Endeffekt als meine eigene Blödheit entpuppt. Evtl. code ich auch zu defensiv ;-)

Mit Synopsis DC/FC oder FPGA-Express habe ich mich wesentlich mehr rumgeärgert. Mir war immer schleierhaft, wie man damit professionell entwickeln können soll...

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias
Reply to
Georg Acher

Nicht ganz. Das kann durchaus passieren, daß man von der Shell aufgefordert wird, jetzt doch mal mit der GUI manuell Probleme zu lösen. Bspw. wenn PAR aus irgendeinem Grund denn doch mal aufgibt. Ich habe das Problem zwar noch nicht gehabt, wohl aber eine entsprechende Meldung schonmal irgendwo gesehen. Da kann man nicht so viel für können, wenn der Router nicht mehr weiter weiss.

Weiters will man ja vielleicht auch hin und wieder mal sehen, was die Tools so produzieren. Das ist in der GUI, finde ich, auch übersichtlicher anzuschauen, als irgend'ne ASCII-Datei mit abertausenden signälchen aus einem völlig geplättetem Design.

xst

im

;-)

Wieso, wie kann denn ein Enduser Programmabstürze verursachen?

Aber stimmt andererseits, insgesamt funktioniert's ja, soweit ich das mitbekomme. Und für kostenlos kann man da nun wirklich nicht meckern, das ist ja abgesehen davon auch überall in der Softwarebrachne so, daß grottig fehlerbehaftete Dinger selbst für teuerstes Geld rausgehen.

Gruss

Jan Bruns

Reply to
Jan Bruns

esser die

inem

eren Entities auch

ee, denke

rhin

de, erzeugt

kt

Im Prinzip ja, aber ...

... mit `diff' mal eben die letzte =C3=84nderung eingrenzen ist nicht meh= r so einfach, obwohl das Datenformat (bei Quartus) nicht einmal bin=C3=A4r ist= .

Gru=C3=9F, Enrik

Reply to
Enrik Berkhan

Kann man scheinbar eine Evaluierungsversion beantragen. Habe das gestern mal gemacht, aber noch nichts gehört.

Ja, das mache ich sowieso immer. Als Ergänzung ist auch der Timing Font hier sehr gut, da man grafisch viel schneller sieht, wie z.B. ein Protokoll aussieht, oder ob die Daten nur mit fallender oder steigender Flanke eingelesen werden sollen, als wenn man es mit vielen Worten beschreibt:

formatting link

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

|> > Finde ich auch, die Kommandozeilentools sind alle tauglich. Wer die GUI |> > benutzt (oder benutzen muss) ist natürlich selber schuld. Ich sehe |> > keinerlei Vorteil die zu starten, ausser einmal die Kommandozeilenparameter |> > rauszufinden. |> |> Nicht ganz. Das kann durchaus passieren, daß man von der Shell aufgefordert |> wird, jetzt doch mal mit der GUI manuell Probleme zu lösen. Bspw. wenn |> PAR aus irgendeinem Grund denn doch mal aufgibt. Ich habe das Problem zwar

Das kannst du mit der GUI auch nicht direkt lösen, schon gar nicht mit dem ISE-Monster. Ab und zu ist der fpga_editor praktisch, um einen Eindruck der Plazierung zu bekommen und um die Constraints anzupassen. Aber Routen will ich damit nichts, da schiesse ich mir lieber gleich ins Knie...

|> noch nicht gehabt, wohl aber eine entsprechende Meldung schonmal |> irgendwo gesehen. Da kann man nicht so viel für können, wenn der Router |> nicht mehr weiter weiss.

Dann muss man dem Router einfach ein paar sinnvolle Plazierungsconstraints als Kristallisationspunkt geben. Es hilft bei "knappen" Ausgängen auch mal immer wieder, die zu langen Pfade im Timinganalyzer/trce-Output anzuschauen. Da merkt man dann meistens erst, was man da eigentlich an Bandwurmlogik beschrieben hat.

|> Weiters will man ja vielleicht auch hin und wieder mal sehen, was die Tools |> so produzieren. Das ist in der GUI, finde ich, auch übersichtlicher |> anzuschauen, als irgend'ne ASCII-Datei mit abertausenden signälchen aus |> einem völlig geplättetem Design.

Naja, ausser dem erwähnten fpga_editor ist alles andere auch nur ASCII ;-) Es gibt noch einen anderen Vorteil, es nur mit den Kommandozeilentools zu machen: Die haben sich bei Xilinx seit ~10 Jahren (seit M1) nicht mehr in der Bedienung verändert. D.h. alle Settings der damaligen Projekte sind im Skript offensichtlich. Ich verwende seit 1996 ein im wesentlichen unverändertes Skript zum Routen... Erst sein einem Projekt mit dem EDK gibt es ein kleines Makefile.

Die ISE-GUI dagegen ändert sich und ihr Projektformat ungefähr jedes Jahr, inzwischen ist es AFAIK binär und damit ungeeignet für vernünftiges Arbeiten mit CVS/SVN.

|> > Ich weiss auch nicht, warum immer so über die vermeintlichen Synthesebugs |> > von xst gelästert wird. Alle Bugs, die ich anfangs auf xst geschoben habe, |> > haben sich im Endeffekt als meine eigene Blödheit entpuppt. Evtl. code |> >ich auch zu defensiv ;-) |> |> Wieso, wie kann denn ein Enduser Programmabstürze verursachen?

Nein, aber evtl. durch zu "offensiv" genutzes VHDL kaputte oder kaputt-optimierte Logik. An sich kenne ich das aber nur von Synopsys. Das ist auch gelegentlich bei bestimmten (völlig legalen...) Konstrukten reproduzierbar abgeschmiert.

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias
Reply to
Georg Acher

"Georg Acher":

Naja, was anders als den FPGA-Editor verwende ich auch nicht mit GUI. Halt, doch, ModelSim, da habe ich mich noch nicht zur Gänze reingefuchst.

BTW, was ist eigentlich bei Xilinx aus diesem hardwarespezifischen ASCII Netlist Format geworden? In älteren ISEs gab's im Unterverzweichnis /xilinx/help (anstatt unter /doc) so eine Beschreibung von dem Format (das war wohl ziemlich vergleichbar mit .ncd). Weiss da jemand was drüber?

Um mal wieder zum Thema zurückzukehren: Also ich habe neulich mal die ISE-IDE gestartet. Und zwar deshalb, weil mich das total genervt hat, überall was davon zu lesen, daß ISE doch einen Schematic Editor enthalten solle, aber nirgends erwähnt wurde, wo man den findet. Und tatsächlich war der über die IDE aufzufinden.

Ich könnt mir vorstellen, daß der für einige Module sinnvoller zu verwenden ist, als HDL.

Jüngst habe ich zum Beispiel einen Zufallsgenerator benötigt, ohne grosse Ansprüche aber eben doch etwas besser als 'nen grosses Shiftregister, aber hauptsächlich sollte das Ding eben "keinen" Platz brauchen. Herausgekommen ist dabei so eine Konstruktion mit SRL16, die gleichmässig mit 0/1 initialisiert sind, und abhängig vom zuvor erzeugten Zufallsmuster adressiert+geshiftet werden, und zudem am Ausgang über Carry teilweise kippen. So braucht das Ding nur genau eine viertel Spartan3 CLB pro Bit "Zufall". Gerne hätte ich auch noch MUX-F5/FX mitverwendet, aber das war mit HDL schlicht überhaupt nicht mehr sinnvoll zu bewerkstelligen.

Kannst Dir ja mal ansehen, was ich meine (für spartan3, top: prng64):

formatting link

Gruss

Jan Bruns

Reply to
Jan Bruns

Also ModelSim kann man glaube ich auch gut scripten, bräuchte man nicht unbedingt das GUI, außer vielleicht für's debuggen, aber wenn man gute Testbenches schreibt, braucht man sowas ja auch kaum.

Wirklich gut gemacht ist übrigens die Integration in Quartus: Man braucht nur bei den Settings unter EDA Tool Settings->Simulation als Tool "ModelSim-Altera" einzustellen, dann im selben Menü bei NativeLink Settings ein Testbench hinzufügen und kann fortan unter Tools->Run EDA Simulation Tool->EDA RTL Simulation das ModelSim Programm per Live-Link starten: Es werden automatisch alle Entities des aktuellen Projektes reingeladen, der Testbench compiliert, die Wave-Anzeige usw. passend aufgebaut und der Testbench gestartet. In ModelSim selbst braucht man dann hauptsächlich zwei Buttons, wenn es nicht bis zum Ende durchläuft und man debuggen will: Den Restart-Button in der Toolbar und den Run-All-Button, zwischendurch passend Breakpoints setzen. Kann man teilweise auch im Einzelschrittmodus, ähnlich wie ein C-Programm, debuggen (zumindest innerhalb eines Prozesses). In meinen Testbenches schreibe ich am Ende dann immer sowas in der Art:

assert false report "No failure, simulation successful." severity failure;

Das hält jede Simulation zuverlässig an, ohne das man die Zeit genau angeben braucht, wie lange es laufen soll, sodaß man Run-All verwenden kann. ModelSim kann auch mit "wait for "-Anweisungen umgehen, anders als der integrierte Simulator in Quartus, sodaß die Testbenches schon fast wie C aussehen vom Implementierungskonzept (Variablen, Funktionen, Prozeduren und Schleifen gibt es in VHDL ja auch).

Ganz makellos ist es natürlich mal wieder nicht: In VHDL kann man normalerweise direkt eine Entity erzeugen, wenn man per "USE work.all;" in der verwendenden Entity am Anfang alles andere bekannt macht (nur in Quartus notwenig, bei Xilinx ISE scheint das implizit bekannt zu sein). ModelSim compiliert sowas leider nicht und man muß für jede verwendete Entity redundant die component-Deklarationen nochmal mit aufschreiben, wie es auch für ältere Quartus-Versionen notwendig war (vor Version 7 oder so). Ist aber die Frage, ob das wirklich ein Bug ist, oder ob VHDL an dieser Stelle zu ungenau definiert ist. Ist manchmal ja recht abstrakt und einige gültige VHDL-Konstrukte kann man sowieso nicht synthetisieren, oder nur je nach verwendetem Programm.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.