Ich arbeite an einem FPGA-Controller, der über PCIe verbunden ist. Die einzige Möglichkeit, die Hardware zu debuggen, ist die Verwendung von Chipscope. Also führe ich Befehle über meinen Treiber aus und überprüfe die Signale vom FPGA.
Das Problem ist, dass es viel Zeit in Anspruch nimmt, das Projekt zu erstellen und es jedes Mal in den FPGA zu laden, wenn ich ein Signal überprüfen möchte, um das Projekt zu debuggen.
Gibt es eine einfachere Möglichkeit, ein mit PCIe verbundenes FPGA zu debuggen?
Gibt es eine Möglichkeit, alle PCIe-Signale zu simulieren und das FPGA überhaupt nicht ausführen zu müssen?
Genauer gesagt hätte ich gerne eine Art Infrastruktur, in der ich einen Befehl über den Linux-Treiber (writeq) schreiben kann und TLP-Pakete an mein Verilog-Design gesendet werden.
Ja - Sie sollten in der Simulation debuggen, anstatt Chipscope auf der Hardware zu verwenden. Bei komplexen Konstruktionen sparen Sie mit ziemlicher Sicherheit auf lange Sicht Zeit, indem Sie simulieren.
Xilinx bietet einige Hilfestellungen für die Simulation von PCIe, Sie sollten zunächst versuchen, die Beispieldesigns zu simulieren (siehe hier für Virtex 7 oder diesen Antwortdatensatz für die 6er-Serie ).
Da Sie wahrscheinlich einen harten IP-Core verwenden, möchten Sie wahrscheinlich nicht den PCIe-Core selbst überprüfen, sondern nur Ihre Treibersoftware mit Ihrer RTL co-simulieren. Im Wesentlichen möchten Sie Ihren Treibercode ausführen, um TLPs in Ihrer Simulation zu erstellen, um die Interaktion zwischen Ihrem Treiber und der Hardware zu debuggen?
Wie Sie dies am besten erreichen, hängt von Ihrem Fahrer ab. Zum Beispiel habe ich etwas Ähnliches für einen Userspace- mmapbasierten Treiber gemacht: Der Quellcode ist auf Github verfügbar . Wenn Sie Kernel-Treiber co-simulieren möchten, sollten Sie QEMU oder ähnliches untersuchen . Alternativ könnten Sie die Kernel-Aufrufe verspotten.
Die beste Option hängt wirklich davon ab, was Sie erreichen möchten. Um Ihre Hardware zu validieren, bauen Sie am besten auf den Xilinx-Beispielen auf, fahren die BFMs und versuchen nicht, Ihren Treiber mitzusimulieren. Wenn Sie Software gegen Hardware entwickeln möchten, kann es von Vorteil sein, Zeit in Co-Simulation zu investieren.
Yonigo
Yonigo