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
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
