[F] Xilinx Tutorial, das was bringt oder ein *Buch*

Hallo!=20

Ich "muss" mich mit Xilinx Spartan3 und vor allem der ISE=20 auseinandersetzen. Allerdings komme ich mir vor wie vor einem=20 F=FChlkasten. Das Tutorial taugt nichts (es funktioniert ja nicht mal,=20 weil die Beispiel-Dateien f=FCr die VorVorVorg=E4nger-Version sind.). Und= =20 die als pdf verf=FCgbare Doku beseitigt alle Klarheiten. Gibt es ein Buch= =20 Spartan3 f=FCr Dummies?

Falk =20

--=20 "Rechtzeitig Pedalwartung kann auch Ihr Wohlbefinden erh=F6hen!" #fahrrad - der Chat zu d.r.f im IrcNet.

snipped-for-privacy@zeitgleiter.de

Reply to
Falk Dübbert
Loading thread data ...

"Falk Dübbert":

Also für mich war's möglich, nach relativ kurzer Zeit verilog-definitionen zu einer Spartan3-Konfigurationsdatei zu compilieren. Ich glaube, das funktionierte in 2 Schritten (verilog nach Xilinx-format compilieren, dann ins .hex-format convertieren). Sollte mit vhdl exakt genauso funktionieren. Dann kann man sich die Makros u.ä. zur Benutzung der Multiplier, Blockram und so aus dem passenden lib-pdf raussuchen. So kann man Teile auch absolut oder relativ positionieren.

Also jedenfalls, als Mensch der nun auch noch so gut wie nix mit FPGA-Design gemacht hat, würd' ich vorschlagen Du schaust Dir erstmal an, was es mit dem Dateiformatdschugel auf sich hat (Vorsicht, da werden auch viele Dateiformate erwähnt, die nur in Verbindung mit Drittanbietertools auftauchen), dann, welche Kommandozielentools es zu diesen Dateien gibt, um dann letzlich zu schauen, ob das ein oder andere GUI-Tool Dir tatsächlich die Arbeit erleichtern kann, oder nicht.

Gruss

Jan Bruns

Reply to
Jan Bruns

Hallo Falk,

Du schreibst leider nicht, ob Du "nur" in die Xilinx Reihe einsteigst, oder in die Welt der programmierbaren Logik ueberhaupt.

Im ersteren Fall empfehle ich Dir einfach etwas mehr Geduld und ein Beispielprojekt. Bei ISE werden ja einige mitgeliefert. Kompilier einfach eines davon und versuche es auf Deiner Platine zum Laufen zu bekommen. Dazu wirst Du wohl die "Constraints" bzw die UCF Datei anpassen muessen, in der die Pinbelegung der Platine definiert ist.

Falls Du noch gar nichts mit FPGAs gemacht hast, brauchst Du wohl erstmal eine gute Einleitung in VHDL oder Verilog. VHDL ist eindeutig auf dem Vormarsch, deshalb rate ich von Verilog ab. Fuer VHDL habe ich zwei Buecher: "The designers guide to VHDL" von Peter J Ashenden, sowie "A VHDL synthesis primer (2nd ed)" von J Bhasker.

Letztlich umfasst die Sprache aber viel mehr als fuer ein Projekt tatsaechlich gebraucht wird. VHDL ist sehr akademisch. Deshalb wirst Du eigentlich gar keine Buecher brauchen, wenn Du kein VHDL Professor werden willst. Lerne und nutze einfach nur die 5 Syntax-Konstrukte, die Du auch in den ISE Beispiel-Projekten findest. Dazu reicht eine kurze Recherche mit Google.

Der Tipp ist also der gleiche wie immer: Probieren geht ueber Studieren.

Marc

Reply to
Marc Jet

Hi,

Falk D=FCbbert schrieb:

Nein, so ein spezielles Buch w=FCrde auch keinen Sinn machen. Du solltest dir klarer machen, was du willst, was du bereits kannst und was dir fehlt, um dort hin zu kommen. Fehlt es dir an der Methodik oder an der Werkzeugbenutzung?

1=2E HW beschreiben (mittels HDL) wenn du hier Probleme hast, empfehle ich alles andere erstmal zu lassen und je nach Background ein passendes Vorlesungsskript zur Hand zu nehmen. 2=2E Netzliste aus HDL synthetisieren lassen (Die meisten Probleme hierbei stammen aus Fehler in Schritt 1, so das L=F6sungen f=FCr Probleme in 2. oft in 1. liegen) 3=2E Netzliste durch Layout in Programmierfile =FCberf=FChren.

Wenn du das Prinzip kannst, kommst du damit bei eigentlich jedem Werkzeug f=FCr jeden Baustein mehr oder weniger schnell zu einer L=F6sung. Einfache Fragen zur Methodik l=F6sen sich am besten durch zahllose B=FCcher zur prinzipiellen Erstellung von ASICs mittels HDL. Spezielle Fragen passen nach comp.lang.vhdl/comp.lang.verilog/comp.arch.fpga. Letztere Gruppe beantwort auch Fragen zur Werkzeughandhabung.

bye Thomas

Reply to
Thomas Stanka

Hallo!

Wie hier schon erwähnt ist die Frage, ob Du bereits Erfahrungen im Bereich FPGA hast. Als Einsteigerliteratur kann ich

formatting link
"Das FPGA Kochbuch" empfehlen, ansonsten zum Thema VHDL:
formatting link
Verilog habe ich im Studium ausgetrieben bekommen, da unser Prof. früher bei Bosch gearbeitet hat, und zu lange nach Fehlern durch unvollständige Definitionen/Deklarationen gesucht hat ;-) Kann aber nichts aus eigener Erfahrung dazu sagen. Was noch ganz praktisch ist, ist ein fertiges Eval-Board mit Beispielen wie z.B. die von Digilent Inc.
formatting link

cu

Stef@n

[...]
Reply to
Stefan Schulte

"Jan Bruns":

Was mit gerade wieder auffällt:

Die Bedienungsanleitung zum Xilinx-"compiler" XST findet sich irgendwie nicht so wirklich in der Doku zu ISE.

Das Ding findet man, indemdem man auf der Xilinx-Seite nach XST.pdf sucht.

Gruss

Jan Bruns

Reply to
Jan Bruns

Im Gegensatz zu den anderen Antwortern möchte ich mich hier einmal für Verilog als HDL aussprechen - jedenfalls unter bestimmten Voraussetzungen.

VHDL bietet zwar manches, was Verilog nicht hat, insbesondere bessere Parametrisierbarkeit und automatische Generierung von multiplen Instanzen eines Schaltelements und außerdem die Trennung von Interface und Implementation, aber für den Einstieg ist Verilog von unüberbietbarer Einfachheit.

Der Unterschied ist wie zwischen ADA (VHDL) und C (Verilog). Aus gutem Grund läßt das DoD seine Interkontinentalraketensoftware in ADA schreiben, aber in C ist auch eine Menge guter Software entwickelt worden wie jeder Unix/Linux Nutzer bestätigen kann.

Ich würde für den Einstieg - so lange noch der Umgang mit den ISE Tools zu erlernen ist und schnelle Erfolge und flexibles Ausprobieren wichtig sind - Verilog empfehlen. Ich kann aus eigener Erfahrung sagen: Es macht nach einiger Zeit wirklich Spaß, Verilog-Code zu schreiben (ein Gefühl, das sich bei VHDL wohl nie einstellen wird). Eine Seite mit guten Anregungen ist übrigens

formatting link

Dort ist auch ein Tutorial für den ISE Workflow abgedruckt. Deine schlechte Meinung über die Dokumentation der Xilinx Tools kann ich übrigens gar nicht verstehen - ich benutze selbst den ISE WebPack 8.1i unter Windows XP und habe auf der Xilinx Seite (unter Support/Dokumentation) eine wirklich umfassende, als Hypertext mit PDF Dokumenten gestaltete Dokumentation gefunden. Darin ist auch eine sehr gute Kurzanleitung enthalten. Beide sind sogar direkt durch den Hilfe-Menüpunkt in der ISE-IDE erreichbar.

Ach ja, um Verilog schnell (und effektiv!) zu lernen geht meiner Meinung nach nichts über die Tutorials bei fpga4fun.com (externe Links), insbesondere das glänzend geschriebene von Peter M. Nyasulu.

Viele Grüße

Jürgen

--
Jürgen Böhm                                            www.aviduratas.de
"At a time when so many scholars in the world are calculating, is it not
 Click to see the full signature
Reply to
Jürgen Böhm

|> Ich würde für den Einstieg - so lange noch der Umgang mit den ISE Tools |> zu erlernen ist und schnelle Erfolge und flexibles Ausprobieren wichtig |> sind - Verilog empfehlen. Ich kann aus eigener Erfahrung sagen: Es macht |> nach einiger Zeit wirklich Spaß, Verilog-Code zu schreiben (ein Gefühl, |> das sich bei VHDL wohl nie einstellen wird).

Und ich sage dasselbe über VHDL... Bei Verilog muss ich ja schon am Anfang wissen, ob es ein Register werden soll oder nicht ;-)

Mich stört an den Verilog == C-Vergleichen immer, dass es einfach nicht stimmt. Verilog ist bei den Schlüsselwörtern genauso langatmig wie VHDL. Nur weil Verilog //-Komentare erlaubt, hat es recht wenig mit C gemeinsam... Und das, was ähnlich ist, wird auch in C eher als schlechter Stil angesehen (?:-Abkürzung, etc.).

Mit dem richtigen Editor (zB. emacs mit VHDL-Mode) tippt sich VHDL auch in 0,nix.

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
 Click to see the full signature
Reply to
Georg Acher

On Sun, 03 Dec 2006 10:33:40 +0100, Jürgen Böhm wrote: . Ich kann aus eigener Erfahrung sagen: Es macht

Das stimmt allerdings. Dabei mögen die Konzepte ja ganz ok sein, das, was wirklich ärgert, sind die kleinen Nadelstiche, die einen alle paar Zeilen treffen.

Manchmal möchte man eben mal 45 Zeilen loswerden, ohne sie gleich ganz wegzuwerfen, damit man eine Rückzugslösung hat, falls die neue Idee doch nicht so gut ist. Ist das wirklich notwendig, dass man jetzt alle 45 Zeilen einzeln ausknipst, nur weil irgendein Feinschmecker Block-Comments bäh findet? Warum muss ich mir eine Utility für meinen Texteditor suchen, die das macht?

entity noise_gen is Port ( clk: in std_logic; rst: in std_logic; ce: in std_logic; noise: out signed(15 downto 0) std_logic_vector(phase_accu), SINE => ?osc -- äääh, in _der_ Richtung geht das leider nicht COSINE => ?osc90 -- da brauchen wir Zwischenvariablen );

--------------------

oder die Zwischenvariablen, die wir brauchen, damit wir einen out-port doch lesen duerfen und die dazu führen, daß die "gleichen Drähte" n verschiedene Namen haben. Das schöne Attribut bla'driving_value kennt wohl der Modelsim, nicht aber die ISE.

oder die Notwendigkeit, einen Testpunkt von ganz unten bis ganz oben durch alle entity-Deklarationen / component-Deklarationen/ component-Instantiierungen durchzufädeln, nebst temp-variablen auf jedem level. Was waeren wir ohne den Modelsim?

Warum geht nicht sowas:

-- pragma ieee_deprecated_evil_language_construct_signed_with_blood_on testpin

Reply to
Gerhard Hoffmann

Ich weiss ja nicht welches C du meinst, aber das C das ich kenne kennt kein //.

0,nix.

Und wenn es mal nicht klappt dann kann man ja noch in den eliza mode wechseln.

Olaf

Reply to
Olaf Kaluza

|> Manchmal möchte man eben mal 45 Zeilen loswerden, ohne sie gleich ganz |> wegzuwerfen, damit man eine Rückzugslösung hat, falls die neue Idee |> doch nicht so gut ist. Ist das wirklich notwendig, dass man jetzt alle 45 |> Zeilen einzeln ausknipst, nur weil irgendein Feinschmecker Block-Comments |> bäh findet? |> Warum muss ich mir eine Utility für meinen Texteditor suchen, die das macht?

Nimm Emacs.

|> entity noise_gen is Port ( |> clk: in std_logic; |> rst: in std_logic; |> ce: in std_logic; |> noise: out signed(15 downto 0) ); |> end noise_gen;

Schick mal int noise_gen(int blub,)

durch einen C-Compiler deiner Wahl.

|> Es nervt jedesmal, wenn man nachträglich irgendwo ein Signal hinzufügt oder |> wenn man die Parameterliste umsortiert weil der Modulgenerator andere |> Vorstellungen von Ordnung hat.

Hat nix mit VHDL zu tun. | |> Oder gegeben sei ein signed(49 downto 0). Wie initialisiert man den mit dem |> Äquivalent von 4711? Die Art x"12abc" funktioniert nicht weil man 2 Bits |> zuviel/zuwenig hat. Integers funktionieren heute leider auch nicht, weil 50 |> Bits mehr als 32 sind und mehr als 32 braucht uns kein Compiler garantieren.

Eher selten lästig. "11"&x"123456789abc". Dabei kann man nicht übersehen, dass die beiden oberen Bits der Hexstelle untern Tisch fallen.

|> Oder, wir haben uns vom Core Generator eine Sinustabelle |> basteln lassen. Der ist blöde und kennt nur std_logic_vectors:

Liegt an Xilinx und nicht an VHDL...

|> oder die Zwischenvariablen, die wir brauchen, damit wir einen out-port |> doch lesen duerfen und die dazu führen, daß die "gleichen Drähte" |> n verschiedene Namen haben.

Ja, lästig. Soll in VHDL-200x behoben sein.

|> Das schöne Attribut bla'driving_value kennt wohl der Modelsim, |> nicht aber die ISE.

#warning kennt auch nur gcc und nicht WuschelPunktNetz-Studio. |> oder die Notwendigkeit, einen Testpunkt von ganz unten bis ganz oben |> durch alle entity-Deklarationen / component-Deklarationen/ |> component-Instantiierungen durchzufädeln, nebst temp-variablen |> auf jedem level.

Du kennst globale Signale nicht?

|> Was waeren wir ohne den Modelsim? |> |> Warum geht nicht sowas: |> |> -- pragma ieee_deprecated_evil_language_construct_signed_with_blood_on |> testpin -- pragma ieee_deprecated_evil_language_construct_signed_with_blood_off

Schlags vor. |> oder die Stellen, wo Werte "globally constant" sein müssen ( case labels), |> eine Eigenschaft, die aber schon von einer Typ-Konversion zerstört wird.

Weil die implizit von was anderem abhängen kann. Evtl. könnte man da was mit pure functions drehen, aber selbst da bin ich mir nicht sicher, ob es da nicht unerwünschte Effekte geben könnte.

|> Dann kommen wir auf die Idee und bringen das glorreiche Overloading-Konzept |> in Stellung um uns eine Sinustabelle zu basteln, deren Ausgänge sowohl mit |> standard_logic_vectors als auch mit signed kompatibel sind. |> Sorry, das funktioniert zwar für functions, aber nicht für entities.

Das würde wohl das Configuration-Konzept ziemlich durcheinander bringen, wenn die Architectures nicht nur durch die Konfiguration, sondern auch durch die Überladung bestimmt wird.

Ich bin mir ziemlich sicher, dass langjährige Verilog-Programmierer ähnliche Probleme haben...

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
 Click to see the full signature
Reply to
Georg Acher

Moin.

Ja, die Dokus von Xilinx sind eine wahre Freude. Wir hatten da während eines Projekts an der Uni auch so 1-n Beispiele, bei denen die Implementierung des Beispiels 'so muß das auf jeden Fall richtig gemacht werden' natürlich nicht funktionierte.

Dem kann ich nur zustimmen. ISE ist NICHT kompatibel zu Versionskontrollsystemen, da es alle Pfade (auch in Binärdaien) absolut speichert.

Einer unserer Gruppenmitglieder fand dann eine Seite mit vernünftigen Makefiles, welche wir weiterhin nutzten, die URL ist mir leider entfallen. Ich frag nocheinmal nach. Wir haben auch die ISE Tools genutzt.

Im Allgemeinen würde ich das vhdl cookbook empfehlen, zB auf [1] verlinkt. Die anderen verlinkten Sachen sind auch nicht schlecht, als Einführung in die Materie. Ansonsten gibts unter [2] eine sehr ausführliche Linksammlung.

Der Code sollte sich (wenn möglich) nicht auf einzelne Typen beschränken, sprich die Features der Compiler, z.B. das Erkennen von RAM Blöcken, nutzen. (auch XST kann das)

Erst während des Mappings und mit dem UCF File wird das Projekt auf ein Bauteil festgelegt.

Schön Gruß!

Ulrich

[1]:
formatting link
[2]:
formatting link
Reply to
Ulrich Langenbach

"Ulrich Langenbach":

Naja, schön wär's ja.

Ich jedenfalls habe akuell das akute Standard-Problem, daß XST einige meiner mittel-simplen verilog Definitionen nicht synthetisieren mag.

Dabei habe ich wenig Lust, das ganze in noch kleinere Module zu verpacken, will meinen, XST's Fähigkeiten sind für meine Vorstellung von ordentlich lesbarem Code (das ist mir besonders wichtig) nicht kompatibel.

Da das nunmal die Situation ist, wär für mich eigentlich so ein "grafisches klick dir die CLBs direkt zusammen, ohne großartig die Logik zu beschreiben" eine echte Alternative, weil's dann zwar nicht mehr portabel, dafür aber schnell gemacht wäre (kein Ärger mit Tipfehlern, Compilerdetails [ie, Fehldeutungen],...).

Gibt's sowas? Also inetwa so: Zunächst Floorplaner-mässige Ansicht, Doppelklick auf ein Slice zoomt dieses auf Bildschirmformat, so daß man die verfügbaren Elemente (LUTs, Muxe, Carry-chains und sowas) durch anklicken aktivieren bzw. konfigurieren kann. Signale zu anderen CLBs dann vielleicht besser namenbasiert. Das ganze ein paar mal mit weiteren Sclices wiederholen, um dann die zusammengefasst im "Floorplaner" als instanzierbares Modul zu haben.

So furchtbar Device-spezifisch wäre so ein work-flow gar nicht; die module würden ja auf jeden Fall innerhalb einer FPGA-Familie weitergenutzt werden können (so sie denn auf das Zieldevice passen), und auch die Portierung von Modulen zwischen FPGA-Familien wäre sicherlich einigermassen zügig nachzuvollziehen.

Man sehe sich mal die Ausgabe von

xdl -ncd2xdl ein_kleines_design.ncd ergebnis.xdl

sowie die xdl-docu (/xilinx/help/data/xdl) an. Sieht original aus, als wär's für solche Tools gemacht...

Gruss

Jan Bruns

Reply to
Jan Bruns

ANSI C99 erlaubt IIRC eben dieses.

cu Michael

--
Some people have no respect of age unless it is bottled.
Reply to
Michael Schwingen

//.

Du meinst ISO C99, und hast recht.

Gruß, Felix

Reply to
Felix Opatz

Tach,

Das ist natürlich ungünstig, bei uns hatten wir denn wohl Glück. :)

Hmm, da gibt es ja so Dinge wie den HDL Designer von Mentor. Ich fand das ganz gut für die üblichen state- machines, aber ansonsten, eher ein schwerfälliges Teil.

CLBs direkt editieren macht eigentlich nicht so viel Sinn, da man sich damit ordentlich Laufzeitprobleme bei komplexeren Designs einhandeln kann und denn ja auch fluchs die Übersicht verliert. (abgesehen von der schlechteren Kommentierbarkeit)

Ich kenne nur den Floorplanner von Xilinx, aber der nützt einem auch nur, wenn man mal wissen muss welches Blockram man denn nun für bestimmte Aktionen nutzt, damit man das mit den Kommandozeilen Tools adressieren kann, ansonsten erinnere ich mich da an nicht allzu viele Möglichkeiten.

Es würde mich interessieren, wie Du so auch nur einen kleinen Prozessor implementieren möchtest, dann müsstest du ja anfangen KV-Diagramme zu machen und alles schön selber rechnen (oder ein anderes Programm dazu nutzen), platzieren und so.

Es wär aber unhandlich in Bezug auf die Benutzung in weiteren Projekten. Und es gibt ja auch schon Zellen mit gesonderten Funktionsblöcken (RAMS / DSP-Slices / Multiplizierer / I/O Pins) in deren Nähe man nicht ganz so frei mit dem Platzieren eines Moduls wäre.

Ich hatte hier aber eigentlich Makefiles versprochen, wir wurden fündig, bei xess:

formatting link
Lief aber wohl auch nicht direkt out-of-the-box...

Schön Abend!

Ulrich

Reply to
Ulrich Langenbach

"Ulrich Langenbach":

Ja, in der Tat, wenn ihr das Problem noch nie hattet.

Naja, sowas kann ich mir aber aim Rahmen von Hobbybastelgeschichten nicht ansehen. Kostet ja, nehme ich an.

Naja, klar. Ein Verzicht auf Autoplatzierer ist auf gar keinen Fall für jeden Einsatzzweck die Richtige vorgehensweise. Zweifelsohne wird HDL bspw. deutlich einfacher für Projektbeteiligte zu lesen sein, als 'nen schlichter Klumpen Schaltelemente.

Ob Autoplatzierer im Falle fast voll ausgenutzter Fläche nun tatsächlich so tolle Ergebnisse liefern, kann ich noch nicht beurteilen (beim CPLD-Fitter funktionierte das recht ordentlich, deutlich besser, als ich das manuell hinbekommen hätte, aber bei so kleinen Designs ist das ja auch klar).

Die Verwendung eines nächstgrösseren FPGAs (bzw. eines mit anderem Zusatzfearture pro CLB-quotienten) ist da sicherlich eine überdenkenswerte Alternative, gerade bei Kleinprojekten, wo Entwicklungszeit den grössten Anteil der Projektkosten verursacht.

Aber wo wir schon über Timingprobleme reden: Mit einem CLB-Editor liessen sich sicherlich auch viele Timingprobleme direkt vermeiden, oder andersherum: leicht beseitigen. So ist es leicht, bspw. ein Signal durch Einfügen eines zusätzlichen Logic-levels oder durch Wahl eines "langsameren Router-Anschlusses" zu verzögern.

Ausserdem lassen sich durch Hardwarenahen Desginprozess sicherlich stellenweise auch deutlich Latenzzeiten, Pipelinelevels und Bauteile einsparen, und Ausnutzungsgrade/Taktfrequenzen von kritischen Pfaden verbessern.

Zugegeben, auch bei mir schwankt der Wunsch nach direktem CLB-design ziemlich stark mit der Problemstellung. Für "uninteressante" Signale/Logiken, also solche, die -abgesehen von der Funktionstüchtigkeit- nicht sonderlich kritisch sind, ist macht das auch wohl tatsächlich wenig Sinn.

Naja aber KV-Diagramme bräuchte man für FPGAs ja nun eher nicht so viel, man programmiert ja regelmäässig die Wahrheitstabelle direkt ein. Vielleicht ist das ja von Mensch zu Mensch verschieden, aber bei mir gibt es eigentlich keinen Designschritt, in dem plötzlich die gesamte Schaltung in Form einzelner Gatter auftaucht. Vielleicht könnte ich durch einen solchen Schritt hin und wieder mal ein vereinzeltes Bauteil wegknipseln (ob das dann routing-technisch sinnvoll ist, wär' dann allerdings die nächst Frage), aber insgesamt ist es doch schon so, daß CLBs/Slices schon ein mir recht pässlich erscheinendes Grundschaltelement darstellen, welches sich einigermassen Komfortabel in die Vorstellung einer Schaltung einfügt, ohne daß man da allzuviel Unsinn macht.

Ohne das entsprechende Wissen braucht man doch mit FPGA-bezogenen Optimierungen auch gar nicht erst anzufangen. Mal ein Beispiel: Man implementiere einen 256x8 FIFO-Buffer (ohne Verwenung von Blockram). Wenn man so'n Ding einfach irgendwie in HDL zurechttüdelt, macht XST da wahrscheinlich ein schlichtes Dualport-RAM draus. Wenn das Zieldevice allerdings SRLC-Register unterstützt, kann man eigentlich besser die verwenden, da man dann mit etwa 1 LUT pro 16 Bit auskommt, während die Dualport-Variante dazu 2 LUTs benötigt (zumindest bei Spartan3 scheint das so zu sein).

Ich kann mir ohne weiteres Vorstellen, daß ein "CLB-Edit-Schema" für eure Erfordernisse schlicht gänzlich ungeeignet wäre, klar. Ich will das ja auch niemandem aufschwätzen, so nach dem Muster "macht das jetzt mal alle so", sondern habe nur den Eindruck, daß das für meine geringfügigen FPGA-Designaufgaben ganz gut wäre, so'n Editor zu haben.

Besonders komfortabel find' ich's mit HDL aber auch nicht. Mal wieder ein Beispiel dazu:

module bussampler16(sample,din,dout,doutvalid,rst); input sample; input [15:0] din; output [15:0] dout; output doutvalid; input rst; reg [15:0] dat; reg dv; always @(posedge sample or posedge rst) begin if (rst) dv = 1'b0; else begin dat = din; dv = 1'b1; end end assign doutvalid = dv; assign dout = dat; endmodule

Wie man sieht, habe ich ich hier klar definiert, daß "doutvalid" erst nachdem der Datenbus gesampelt wurde. Timingan auf's Synthesat losgelassen führte zu der Erkenntnis, daß von der gerade genannten Festlegung offensichtlich rein gar nichts beachtet wurde. Und schon tippe ich UCFs, in denen ich timing-groups definiere, und zwar nicht nur pro Modul, sondern pro Modulinstanz (also im Prinzip bei jeder Verwendung des Moduls).

Wenn ich dieses Modul in einem CLB-Editor entworfen hätte, dann hätte ich wahrscheinlich "doutvalid" sicherlich pauschal erstmal 'nen delay verpasst, und Ruhe ist.

Gruss

Jan Bruns

Reply to
Jan Bruns

Moin!

Stimmt wohl, ist halt von Mentor... ;)

Jo, schließlich wurde VHDL zur Doku geschaffen...

Ich habe auch keine Studie dazu zur Hand / gesehen.

Je nach Anwendung sollte man die mitgebrachte Ausstattung der FPGAs durchaus berücksichtigen.

Was meinst du mit zusätzlichem logic-level, ein Gatter, der keine logische Operation ausführt (Verzögerungsglied)?

Es fällt mir gerade nur eine Möglichkeit ein, Einfluss auf einer so niedrigen Ebene auf das Design zu nehmen, die JBits-Schnittstelle. Die wurde hin und wieder von Projekten genutzt, die ihre Schaltungen wie Software dynamisch starten und initialisieren.

Möglich, aber die nicht lesbarkeit dominiert wohl eher. Die Latenzen durch Pipelinestufen kann man mit der Beschreibung durch die HDL sehr konkret beeinflussen, allerdings habe ich auch einiges an Zeit gebraucht, bis mir klar war, wo genau latches eingebaut werden und wo nicht.

Es werden auserdem immer ungenutzte / nicht voll genutzte CLBs vorhanden sein, die aus verdrahtungstechnischen Gründen übrig bleiben oder einfach in die Verdrahtung übernommen werden.

Es gibt ja immer Zusammenhänge zwischen Anzahl der Pipeline Stufen und der maximalen Frequenz, was dann wieder mit dem Spagat zwischen Durchsatz und Latenz zusammenhängt.

Man muss halt Prioritätn setzen... ;)

Ok, mmm, wir haben da wohl unterschiedlich Herangehensweisen, ich gehe da ja einfach Hochsprachentechnisch ran, teile mein Projekt in Module auf, schau mir an, was man schön zusammenfassen kann und fange dann unten an zu 'programmieren', simulieren, synthetisieren.

Das Beispiel, das Du hier anführst mag zutreffend sein, blos, wieso kein Blockram? Gut, ausserdem gehst Du davin aus, dass das FPGA tatsächlich Zieltechnologie ist. In der Realität ist es aber oft 'nur' Test- und Entwicklungstechnologie, später wird dann ein ASIC gefertigt, mit den Bibliotheken, die der Halbleiterhersteller zur Verfügung stellt.

Wenn nun das FPGA Zieltechnologie ist und die Designziele nicht anders verwirklicht werden kann muss man wohl so vorgehen wie Du es vorschlägst. Aber selbst dann muss man nicht selber irgendwie in den CLBs rumtüdeln, sondern kann nun die entsprechenden Cores instantiieren, welche meist auch über FPGA Familien desselben Herstellers hinweg untersützt werden.

Bzw. man macht beides und instantiiert je nach Wunsch und Aufgabenstellung / Platz / Gutdünken das was angebracht ist.

Wie schonmal gesagt, es mag dafür Anwendungen geben, ein Tool ist mir nicht wirklich bekannt, bis auf JBits, Doku gibts, wo auch immer, hab ich nicht gefunden, für mein Referat...

Ich muss dazu mal sagen, in verilog, was das oben wohl sein soll, bin ich nicht so fit, so wollte ich deine Code fetzen in VHDL abbilden, aber das ist nun nicht mehr nötig, mir ist aufgefallen wo der Fehler vermutlich steckt...

Register können nur mit Clockdomains gebildet werden, falls sample nicht als Takt zählt fällt es somit raus, es sollte ein entsprechendes (wenn auch kryptisches) Warning geschmissen werden. Weiterhin fehlt hier dann ein Takt. Ich vermute, dass verilog, wie VHDL die beiden letzten Zuweisungen konkurrent interpretiert und damit wird dann gleichzeitig der Datenbus gesampelt und das doutvalid gesetzt, da mag ich mich aber irren. Man sollte dazu eine mini state-machine benutzen, aus lese und valid zyklus oder wenns in ner pipeline ist, einfach ein enable, was das sample vielleicht sein soll... (wird der Takt bei verilog als implizit vorhanden angenommen?

*grübel*)

Joa, vermutlich, siehe oben.

Schöne Grüße!

Ulrich

Reply to
Ulrich Langenbach

"Ulrich Langenbach":

Ja, klar.

Protest! Auch Hobbymässig ausgeführte Tätigkeiten sind real.

Hm, ich habe mich den IP-generatoren von xilinx noch nicht wirklich befasst, aber jedenfalls existiert anscheinend zumindest für verilog im webPack ISE kein template für SR-Fifos. Für normal würd' man dann wohl, wie gesagt, das ganze als distibuted Dualport RAM implementieren.

"sample" ist ein Taktsignal, daß allerdings nicht notwenigerweise synchron zu einem regelmässigen, periodischen Takt ist, so daß die Verwendung eines CE nicht machbar ist. Den FlipFlops ist's wohl egal, die enthalten ja keine DLLs, oder sowas.

Der wesentlich Punkt bei dem Codeschnipsel ist, daß die Zuweisungen innerhalb des always-blocks mit "=" erfolgten. "=" ist da in verilog ein "blocking assignment", während man "nonblocking assignments" mit "

Reply to
Jan Bruns

Hallo, Jan Bruns schrieb:

as

Kostet, ja :=3D). Und soweit ich das verstanden habe liegt der Vorteil des HDL Designer nicht im erstellen, sondern verstehen von Code. F=FCr schematic entry sind die Werkzeuge immer mehr verschwunden, gibt es aber wohl nocht, da besonderes bei CPLD wohl noch verwendet.

jeden

tlich

pen

Platzier mal ein komplexes Modul nur von Hand, da drehst du doch durch, wenn Timing auch noch wichtig ist. Ich habe hier Designs, bei denen ich beim Platzieren nachhelfen musste, das ist frustrierend ohne Ende, wenn du nicht einen klaren linearen kritischen Pfad hast, sondern 30 FF die stark voneinander abh=E4ngen.

er

Definiere uninteressant? Mach mal einen 64 Bit Datenpfad von Hand. So ein Addierer ist ja schnell mal zeitkritisch, trotzdem eine Ochsentour und im Ergebnis nicht besser wie signal a,b, c : std_ulogic_vector(63 downto 0); a module bussampler16(sample,din,dout,doutvalid,rst); [=2E.]

[=2E.]

Schonmal die Netzliste =FCberpr=FCft? Ich tippe hier eher auf einen Fehler der Timinganalyse, ohne die Feinheiten von Verilog zu kennen, scheinst du hier klar ein FF zu definieren, dass bei Reset 0 und sonst (nach der ersten Taktflanke) 1 ist. Nachdem allerdings sample vermutlich nicht der Haupttakt ist, musst du aufpassen, wie du das Signal weiterverwendest, da du schnell Taktdomains verwurstelst.=20

bye Thomas

Reply to
Thomas Stanka

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.