Hi, kann mir jemand in diesem Forum sagen, ob es eine VHDL-Testbench für PciExpress gibt, die man für die Verifikation des Lattice-IP-Cores verwenden kann ? Mir ist bekannt, dass Altera und Xilinx beim Generieren von PciExpress-IP-Cores entsprechende propietäre Testbenches mitliefern. Bei Lattice wird eine sehr rudimentäre Verilog-Testbench mitgeliefert, die lediglich eine Art Loopback-Test macht, also nichts mit dem man eigene Logik wirklich simulieren kann. Ich möchte im Prinzip, dass der IP-Core als Master und Slave simuliert werden kann, z.B. FPGA sendet via DMA Daten an einen PPC. Gibt es eine Testbench, die einfach gestrickt ist, die jedoch über die Lattice-Testbench hinausgeht ? LG, Volker
Hi Volker, meines Wissens ist der Xilinx test-bench auch nicht so toll. Da ist nicht viel Unterschied zwischen Lattice und Xilinx bzgl. der Erweiterbarkeit. Zu Deiner eigentlichen Frage, ja es gibt so etwas auch für Lattice. Ich habe die Ehre die Lattice PCIexpress Schulungen halten zu dürfen. Sie finden ca. einmal im Quartal statt bei der Firma eVision Systems http://www.evision-systems.de in der Nähe von München. Alle Schulungsteilnehmer bekommen die Simulations-Umgebung als ActiveHDL (Aldec mixed-language Simulator) Kompilat auf CD mit. Es ist immerhin gut genug, dass viele Teilnehmer der letzten zwei Jahren Ihre Produkte damit hochgezogen haben. Im wesentlichen ist es ein VHDL Transactions Model mit diverse Checks eingebaut. Du kannst sehr umfangreiche eigene Test-Cases damit bauen. Schenken kann ich es Dir leider nicht, war doch etwas zu Aufwendig zu entwickeln. Die billigste 'handelsübliche PCIe BFM', das ich kenne kostet doch so ca. €50K. Es gibt also folgende Möglichkeiten: 1) Du besuchst die Lattice PCIe Schulung (Kosten €890,00 für zwei Tage). Da bekommst Du es umsonst. 2) Wenn Du schon relativ fit in Sachen PCIe bist und keine Schulung willst, schicke mir eine SMS mit Deiner Email an +49-171-8672732. Dann können wir eine Vorgehensweise offline besprechen. Oder Du kontaktierst Lattice in Halbergmoos. Sie haben meine Kontaktdaten 3) Wenn Du noch studierst und das nur für eine Dipl. Arbeit etc brauchst, können wir u.U über eine verschlüsselte Version für ActiveHDL/Riviera reden. Grüße, Charles Gardiner
Hallo Volker123, mein Tipp: lass es den core zu simulieren Simuliere die Schnittstelle vom core und hoffe dass keine weiteren bugs im lattice core sind, hoechstwahrscheinlich triggerst du die eh nicht mit deinen tests. Spart auch ungemein Simulationszeit. Sonst gibt es PCIe BFMs z.B. von Denali oder Cadence. Fuer beide braucht man sehr viele Nerven und es gibt von Lattice auch keine Doku wie man den core vernuenftig instanziert bekommt. BTW.: falls ein neuer core released wird (>4.0) unbedingt den verwenden, Changelogs gibt es bei lattice ja nicht! Gruss Christian Leber
Hi, danke für eure Antworten, werde mir die verschiedenen Optionen durch den Kopf gehen lassen. Finde es nur seltsam, dass PciExpress als DAS Bus-Protokoll von Lattice (und vielleicht auch Xilinx) simulationstechnisch so vernachlässigt wird. So ein IpCore bringt doch ohne Sim-Umgebung nicht wirklich viel. Vielleicht ein Thema für Opencores ;O) LG, Volker
@volker123: > So ein IpCore bringt doch > ohne Sim-Umgebung nicht wirklich viel. Vielleicht ein Thema für > Opencores ;O) Naja, die IP-Cores sind dazu gedacht, um sie zu verwenden. Im Normalfall funktionieren sie halt einfach und wenn man weiß, wie man das Interface verwendet um Daten raus oder rein zu kriegen, dann passt das. Gibt ja z.B. auch keine Testbenches für z.B. die Standard-PCI-Bridge PLX9030 oder ähnliches ... Man nimmt an, sie funktionieren und baut sein Zeug dazu.
@Gast So ganz ohne ist das bei dem lattice core aber auch nicht, denn man muss sich schliesslich auch um die credits kuemmern (bei den cores von xilinx und altera nicht). Wenn immer es geht sollte man auch gekaufte cores mit simulieren, denn die haben alle bugs, nur ist es eben in dem Fall mit Schwierigkeiten verbunden. Ist natuerlich auch bei Bug reports einfacher wenn man ein waveform hat, welches den Fehler zeigt.
@ Gast
>Man nimmt an, sie funktionieren und baut sein Zeug dazu.
Das ist aber sehr naiv! Viele (nicht dokumentierte) Aspakte eines
IPcores
siehst du erst in einer Simulation oder (für meinen Geschmack schon zu
spät)
bei der Inbetriebnahme.
Volker
@ Christian Hört sich so an, als hättest du den PciExpress-Core schon mal verwendet. Du sagtest, dass du nur die IPcore-Schnittstelle simulierst ... wie hast du denn die Geschichte mit den "credits" gelöst ? LG, Volker
Hi Volker, grob skizziert, der Lattice Core hat folgende Credit Signale: Posted: ------ Angezeigte Credits (vom Link Partner) d.h. Core Ausgänge tx_ca_ph_vc0 tx_ca_pd_vco Credits, die von Deiner App wieder freigegeben werden d.h. Core Eingänge ph_processed_vc0 pd_processed_vc0 pd_num_vc0 Non-Posted ---------- (Zwischen Kommentare wie oben) tx_ca_nph_vc0 tx_ca_npd_vco nph_processed_vc0 npd_processed_vc0 npd_num_vc0 Completions ---------- tx_ca_cplh_vc0 tx_ca_cpld_vc0 Deine Logik muss tx_ca_xxxx_vc0 bewerten bevor Du ein Paket zum PCIe schickst, zu prüfen ob der Link Partner das Paket annehmen kann. Wenn Deine Logik ein ankommendes Paket abgearbeitet hat muss mit: (n)ph_processed_vc0 ein Header Credit wieder freigegeben werden und (n)pd_processed_vc0 und (n)pd_num_vc0 eine Anzahl von Payload Credits wieder freigebeben werden. Hier, entweder (n)pd_processed_vco für <num> Zyklen ziehen und (n)pd_num_vc0 auf '1' setzen oder (n)pd_processed_vco für ein Zyklus aktivieren und (n)pd_num_vc0 auf <num> setzen Genaueres steht auch in der Lattice Docu. Zugegeben, die Docu läßt sich 'sehr umweltfreundlich' ausdrucken. Sie ist aber viel besser geworden. Eine einfache Lösung wäre, mit jedem ankommenden Paket (n)ph_processed_vc0 einmal takten und mit jedem vierten Payload DWORD (n)pd_processed_vc0 takten wobei (n)pd_num_vc0 auf '1' geklemmt wird. Hängt aber von Deinem Design, ob diese einfache Lösung in Frage kommt. Auch wichtig, niemals ein non-posted Paket (e.g. MemRead) senden wenn Du das Completion Paket nicht annehmen kannst (end-point muss infinite credits anzeigen). Auch aufpassen, 'multiple completions' sind möglich, je nach Chip-Set, an einer 64-Byte oder 128-Byte Grenze. M.E. ist übrigens der Xilinx Core nicht ganz PCIe-Spec konform. Aus der Doku interpretiere ich, dass infinite completion credits nicht angezeigt werden. Hier müsste man eigentlich die trn_rfc_cplX_av Ausgänge immer bewerten bevor man ein non-posted Req. sendet. Grüße, Charles
@Volker123 Die Loesung ist einfach, es gibt immer genug credits :-) Beim xilinx core muss man sich darum nicht kuemmern. Was allerdings auch Nachteile hat, denn wenn man nicht weiss wieviele credits noch frei sind, dann kann es auch nicht entsprechend optimieren. Hinsichtlich Dokumentation, das Handbuch von lattice und altera kann nicht vergleichen.
Hallo Charles, vielen Dank für deine Ausführungen. >Alle Schulungsteilnehmer bekommen die Simulations-Umgebung als ActiveHDL >(Aldec mixed-language Simulator) Kompilat auf CD mit. Bedeutet dies im Umkehrschluss, dass die Simulation nicht mit Mentor-Modelsim durchgeführt werden kann ? Ich dachte, dass eine "handelsübliche PCIe BFM"-IP Simulator-unabhängig ist ... Ich frage, weil ich mit ModelsimSE arbeite. LG, Volker
Volker123 schrieb: >>Alle Schulungsteilnehmer bekommen die Simulations-Umgebung als ActiveHDL >>(Aldec mixed-language Simulator) Kompilat auf CD mit. > > Bedeutet dies im Umkehrschluss, dass die Simulation nicht mit > Mentor-Modelsim durchgeführt werden kann ? Ich dachte, dass eine > "handelsübliche PCIe BFM"-IP Simulator-unabhängig ist ... Zum Lattice ispLever gehört auch ein ActiveHDL. Das Problem wird in der Regel nicht dein Modelsim sein, sondern das fehlende Verilog. Denn das Simulationsmodell des Cores liegt in Verilog vor. Tom
Hallo Thomas, das ist kein Problem, da ich eine Modelsim-Mixed-Lizenz habe. LG, Volker
Hi Volker, prinzipiell hast Du natürlich recht. VHDL ist (oder sollte sein) Compiler agnostisch. Nur speziell in diesem Fall gibt es ein Paar besonderheiten teils historisch und teils weil das ganze gezielt für die Lattice Schulungen angefangen hat. Deren OEM Simulator ist nun mal Aldec: - Angefangen vor zwei Jahren hat das ganze als 'Demonstrations Vehikel' für die Lattice PCIe Schulung. Ziel war, dass die Kursteilnehemer schnell sehen könnten was die Cores im Hintergrund machen (Data-Link Layer Pakete usw.) und ausserdem was aus dem Core herauskommt wenn sie Ihre Transaction-Layer Pakete selber anlegen. Ganz am Anfang hat es nur das geschehen protokolliert und im Konsolen Fenster ausgegeben. Im Lauf der Zeit, und weil ich es selber für Projekte gebraucht habe, wurde ein ganzer VHDL BFM mit Checker und die Möglichkeit eigene Testszenarien zu bauen schliesslich mit integriert. Herz ist aber nach wie vor ein 'umgedrehter' Lattice Core (Data-Link Layer und Physical Layer) mit ein Paar Eingriffe um z.B. das Link Training bzw. Scrambling abzuschalten. D.h. es funktioniert nur mit den Lattice Zellen-Bibliotheken. Die gibt es aber natürlich auch für Modelsim. Es gibt erstaunlich viele Firmen, auch ganz grosse, die Ihre Simulationsumgebungen so aufgebaut haben. Einfach weil die 'handelsübliche BFMs' nicht gerade billig sind. Ich habe neulich mit jemand von einem 'grösseren Elektrounternehmen' gesprochen, der z.B das gleiche für einen Xilinx Core gemacht hat. Das ganze zu entwickeln hat mir jedenfalls keine €50K gekostet (ich denke eher im Bereich €10K bis €15K, wenn ich es im Auftrag gegeben hätte) und ersteres ist der Preis der mir genannt worden ist für z.B. ein BFM der Firma Avery, die angeblich oft von Intel verwendet werden. - Der Lattice Core liegt als sog. 'obfuscated Verilog Netzliste' vor. d.h. ich brauchte einen Mixed-Language Simulator. Mit Modelsim brauchst Du zwei Lizenzen, wenn Du in einem Design VHDL und Verilog simulieren willst. Bei Aldec ist das so gut wie immer dabei. - In der Schulung wird nur das Kompilat verteilt und nicht die VHDL-Quellen. Hintergrund ist einfach kommerziell. Die Schulungen halte ich über den offiziellen Lattice Training Partner. Preislich sind diese auch extrem günstig (€890,00 oder so für 2 Tage). Ziel ist natürlich, dass die Teilnehmer trotzdem alles bekommen um mit Ihren Designs erfolgreich zu sein. Aus den Feedback weiss ich auch, dass alle, die die Simulations Umgebung verwenden auch damit zufrieden sind. Die Test-Cases, die sie schreiben können sind nicht eingeschränkt. Zurück zum Thema Modelsim: Ich gehe davon aus, dass es auch mit Modelsim kompilierbar wäre. Ich selber habe aber kein Modelsim (viel zu teuer im Vergleich zu Aldec) ausser die OEM Version von Altera. Die kann aber kein Mixed Language. Ich bin aber gerade dabei zu eruieren, ob ich die nach VHDL-2008 verschlüsselte VHDL-Quellen als eigenständiges Paket anbiete. Voraussetzung wäre, dass Modelsim VHDL-2008 verschlüsselte Quellen übersetzen kann. Ich weiss es nicht, ob Mentor das schon unterstützt. Bei Aldec würde es gehen, sogar schon in der Lattice OEM Version. Preislich wäre es natürlich trotzdem nicht ganz so günstig wie die 'Schulungs Version' aber ich denke dennoch erschwinglich. Es gibt wenige FPGA Entwickler, die €50K für ein BFM als angemessen sehen. Bei ASICs mag das anders sein. Der Schulungspreis ist ein besonderes Program von Lattice. Derzeit bekommen alle Teilnehemer auch von Lattice einen Gutschein und können gegen Teilnahmebestätigung einen PCIe Core Lizenz für so ca. €800 erwerben. Deren Kalkül ist ganz einfach: wer die Schulung besucht weiss nachher, wie der Core einzusetzen ist und braucht folglich weniger bis gar kein Support. Also wird das Ersparnis an den Kunden weitergegeben. Wenn Du noch Interesse haben solltest und es unbedingt Modelsim sein muss, melde Dich einfach noch Mal. Vielleicht finden wir eine Lösung. Grüße, Charles
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.