Ich bin noch ein relativer Anfänger in der VHDL-Programmierung. Im Moment setze ich einen kleinen Spartan II von Xilinx ein und würde diesen gerne in der Hardware debuggen können, ähnlich wie es bei Mikrocontrollern eben auch möglich ist. (Keine Siimulation) Da im FPGA die ganzen Prozesse parallel ablaufen ist das bestimmt nicht ganz so einfach, aber ist es nicht auch möglich diese in der Hardware zu debuggen? Freue mich auf Eure Rückmeldungen und Erfahrungen.
Bei Xilinx gibt es den ChipScope*. Das ist ein LA der zu deinem Design hinzusynthetisiert wird und über das JTAG Interface gestartet und ausgelesen werden kann. Ansonsten Signal auf FPGA Pins legen und mit dem Oszi messen. Gruß Jörn *http://www.xilinx.com/ise/optional_prod/cspro.htm
ChipScope Pro gibts offenbar als 60-Tage Testversion, ansonsten kostet es wohl 695,- USD Es ist aber auch nicht schwer, eigene kleine Debug-Tools zu erstellen, z.B. kannst Du mit einem simplen UART (nur TX) und etwas Logik drumrum prima Registerinhalte auslesen, z.B. zyklisch und diese dann mit einem Terminal-Programm anschauen. Was sich bei mir auch bewährt hat: Testsignale generieren, die man sich mit dem Scope anschauen kann (wie von Jörn vorgeschlagen). Dabei so viel wie möglich ins FPGA packen (z.B. Vergleich ist das Signal > 0x500 usw.) und nur das Ergebnis rauslegen, damit man mit 1 - 2 -Kanal-Scope was messen kann.
Danke "Jörn" und "FPGA-User" für Eure schnellen Antworten. Das ChipScope-Programm scheint zumindest laut Xilinx recht interessant zu sein, habt Ihr oder andere hier im Forum Erfahrungen mit diesem Programm? Mich würde interessieren ob dies gut einzubinden ist, wieviel Ressourcen es im FPGA benötigt, was wirklich genau wie analysiert werden kann und ob eine Art Einzelschirttmodus möglich ist.
@Michi hab vor längerer Zeit mal mit dem Vorgänger Chip-Scope (ohne Pro) gearbeitet. Das ist praktisch nichts anderes als ein Logic-Analyzer, der im FPGA implementiert wird. Man definiert zuerst den ILA-Core (oder auch mehrere) und dann glaube ich den Core zur Kommunikation, das ganze kommt dann ins FPGA mit rein und muss zusammen mit dem Design mit compiliert werden. Wenn dann das FPGA geladen war konnte man per Windows-Oberfläche den Trigger konfigurieren, also meinetwegen Start bei fallender Flanke WE und Adresse = 0x100 und dann hat der LA einen "Schuss" gemacht und z.B. 32k Samples von den Datenleitungen ins Block-RAM geschrieben. Den Signalverlauf kann man sich so ähnlich wie im ModelSim anschauen. Das ist aber nicht vergleichbar mit dem Schrittbetrieb eines uC! Vielleich kann der Pro jetzt mehr, aber ein Schrittbetrieb würde ja voraussetzen, dass es ein globales Clock-Enable-Signal gibt oder der Clock sonst irgendwie "angehalten" werden kann, was normalerweise nicht geht. Also schau Dir mal die Features von dem Teil an, aber alles kann der auch nicht. Aus meiner Erfahrung spart man sich viel Fehlersuche, wenn man ordentlich simuliert, auch Fehlerfälle mit prüft und generell synchrone Designs verwendet. Natürlich kann die Hardware rings ums FPGA fehlerhaft sein, da ist es auch sinnvoll, wenn man schnell mal einen Block Daten in ein RAM schieben kann um sich das am PC anzuschauen, aber dafür braucht man nicht gleich einen ChipScopePro.
Hi! Ich setze selbst gerade ChipScope Pro 7.1 ein und bin damit sehr zufrieden. Zu Deinen Fragen: ChipScope Pro ist quasi ein Logik-Analyser, das stimmt. Du kannst verschiedene (beliebig breite) Signale anschauen, kannst Trigger-Funktionen (und auch Trigger-Sequenzen) bestimmen, nachher noch durch einen Filter jagen und das Ganze anschauen. Dabei werden einfach mit jedem Clock (wenn die Filter-Bedingung erfüllt ist) die Daten in die Block-Rams geschrieben und dann über das JTAG-Kabel raus-übertragen. Ein Einzelschritt-Modus ist damit nicht möglich, aber auch nicht sinnvoll. Es handelt sich eben nicht um sequentielle Software, sondern um vollparallele Logik. Und da zählt, was zu welchem Takt an welchem Knoten anliegt und ein Einzelschritt-Betrieb macht keinen Sinn. Ausserdem treten viele Probleme ja auch erst bei voller Geschwindigkeit auf und wären somit gar nicht erfassbar. Also, ich kann ChipScope Pro nur empfehlen (und ich arbeite nicht für Xilinx), weil es sehr viel Zeit erspart. Sonst müsste man sich Signale erstmal auf Pins rauslegen und mit einem LA anschauen und das ist manchmal gar nicht möglich, ausserdem: wer hat schon einen LA für 40- oder 50 bit breite Signale zu Hause stehen, der jenseits der 350MHz samplen kann? Also ich nicht. Und ChipScope ist da eine einfache Möglichkeit zum debugging. Aber man muss sich eben auch bewusst sein, dass uC-Programmierung nicht gleich VHDL-Design ist und demnach auch Debugging anders ausschaut. Ich hoffe, Dir (Euch) damit geholfen zu haben und bin für Kritik, Anregungen, Fragen usw. offen. c yas! Bernhard
Es gibt auf der Xilinxseite ein Video on demand, wo ein mitarbeiter die grundzüge von Chipscope erläutert. Sehr interessant. Die Demoversion gibt es, aber der Messadapter um es an deinen PC anzuschliessen kostet leider auch an die 100 Euro. Das ist der Nachteil :-( Selberbauen ist glaub ich nicht drin oder?
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.