Servus, bei Altera und Xilinx gibt es ja die Möglichkeit per JTAG auch auf das eigene Design zuzugreifen(Auch ohne Verwendung der jeweiligen Debugger, wie Chipscope). Altera bietet dafür sogar IP-Cores an, zum Beispiel eine JTAG/Avalon Bridge. Bei Xilinx kann man meines Wissens nur die BSCAN_xxx Instanz des jeweiligen Device verwenden und müsste die Anbindung ans Design selbst implementieren. Kann mir jemand sage, ob es etwas ähnliches auch für Lattice FPGAs gibt? Gruß Philip
Philip schrieb: > Jetzt hab ich was gefunden...nennt sich BSCAN 2. Nein, das ist ein Mehrfachprogrammer. Die Primitiven für die Einbindung von JTAG heissen je nach FPGA Familie JTAGA,JTAGB,JTAGC,JTAGD,JTAGE oder JTAGF Aber wenn man diese verwendet kann man Reveal und den Mico32 nicht mehr verwenden. Durchforsten der Mico32 Sourcen fördert eine vom Komponente zu Tage die mehrere Clients im FPGA zulässt und von der FPGA Familie unabhängig ist. Documentation lässt aber zu wünschen übrig. (Suchfunktion auf der Latticeseite ist down, den Mico32 habe ich derzeit nicht installiert, kann also den Namen der Kopmponente nicht ermitteln) Bisher hatte ich weder den Bedarf noch die Zeit mich damit ausführlicher zu befassen.
Bei Lattice hat man auch die Möglichkeit, per "Orcastra" über JTAG in das FPGA zu kommen - erfordert aber etwas Handarbeit. Dies ist eigentlich für die Kontrolle und Konfiguration der SerDes-Blöcke gedacht, aber an das SCI (Service-Client-Interface) kann man sich mit dranhängen.
Pat a Mat schrieb: > Bei Lattice hat man auch die Möglichkeit, per "Orcastra" über JTAG in > das FPGA zu kommen - erfordert aber etwas Handarbeit. Handarbeit ist im jedem Fall erforderlich. Da mich das Thema auch wieder einholen wird (Produktionstest) eine Frage: Sind irgendwo die JTAG Commands für ORCAstra documentiert?
Ich habe mir mal das von IPExpress generierten Ocrastra module angeschaut. Es wird VHDL oder Verilog Source erzeugt. Verbindung zum JTAG port erfolgt mit jtagconn16 das auch vom Mico32 Debug und Reveal verwendet wird.
In der TN1176 von Lattice steht auch etwas zu SCI (heißt richtig: SERDES-Client-Interface!) Aus dem ORCAstra-Modul kommen im Prinzip schon alle Adress-, Daten- und Steuerleitungen heraus. Bei der Dekodierung ist allerdings einiges zu beachten. So muss beim Lesen auch auf geänderte Adressen reagiert werden, ohne dass sich das Lesesignal SCIRD ändert. So werden mehrere Register in einem Rutsch gelesen. Und es tauchen auch immer (!) Adressen auf, die nichts mit dem SerDes oder dem zu lesenden Register zu tun haben. Den Lese- und Schreibzklus habe ich mal mit Reveal reverse-engineered. Das kann ich Dir auch empfehlen. Da sieht man besser als in der TN wie SCI wirklich funktioniert. Um meinen eigenen Adressraum vom SerDes abzugrenzen, benutze ich die beiden obersten Adressbits zur Selektion. Mit der Orcastra-GUI lässt sich mit VBS auch eine eigene GUI mit Buttons, LEDs, Eingabeboxen etc. erstellen. Beispiele dazu stehen im Orcastra-Verzeichnis. Ist aber zugegebenermaßen alles etwas "frickelig". Hoffe, das hilft Dir ein wenig weiter. Falls Du noch (detailierte) Fragen über ORCAstra hast - nur zu.
Weiß denn jemand wie die entsprechende Komponente bei Altera heißt? Für den Fall dass man nicht die fertigen IP cores verwenden möchte...
Moin, ich versuche grade, eine Lattice JTAGE-Primitive anzusteuern, bzw. integrieren, dabei will ich beide User-Register (ER1 und ER2) nutzen. Allerdings steckt noch der Bock drin, und die bestehende Doku ist nicht wirklich detailliert betr. Timings. Leider kann ich auch das Simulations-Modell nicht nutzen (da encrypted Verilog). Hat jemand das schon in VHDL zum Rennen bekommen? Mein momentanes Problem, je nach Flankensensitivität: (steigend) Entweder stimmen die Registerlängen beim Detektieren, dafür habe ich "weak bits" beim Auslesen der Register, d.h. der Registerwert wird zu spät gelatcht (gerade dann, wenn er ausgelesen wird). (fallend) Registerlängen ein Bit zu lang, dafür stimmen die Auslesewerte. Bei Xilinx habe ich festgestellt, dass einige BSCAN-Primitiven nicht besonders 'schlau' designt sind und Workarounds erfordern. Ist das bei Lattice ähnlich, oder bin ich nur zu doof? Grüsse, - Strubi
Nachträglich - nach etwas Scope-Debugging - geb ich mal nach erlangter Weisheit die Antwort noch selber: Die laut Dokumentation mit der Aussenwelt verbundenen TDI und TDO Signale (jtdi/jtdo) sind nicht 1:1 durchgeschleift, sondern werden intern nochmal nach steigender bzw. fallender Flanke abgetaste.. D.h. man bekommt die Daten erst nach einem FF, dadurch wird schon mal ein Bit zum Schieberegister addiert, und genau das ist das Problem bei einigen Beispiel-Implementationen, man kriegt es mit Abtasten auf die fallende zum Laufen, aber ein 32-Bit-Register zeigt z.B. 33 Bit. Beim Abtasten auf die steigende gibt es Probleme (übliche Timing-Randomness), die Tools betrachten nämlich die tck-Linie nicht als Clock und routen sie auch nicht entsprechend auf ein Clock-Net. Warum das Lattice so gemacht hat, ist mir ein Rätsel, auf jeden Fall war es nicht dokumentiert. Und scheint's auch keine einfache RTFM-Frage, denn vom "outgesourcten" Support kam bisher kein Echo.. (Grummel.)
Martin S. schrieb: > "outgesourcten" Support Hallo Strubi, was meinst Du mit outgesourcten Support. Über einen Distri- FAE? Gruß Vanilla
Hi, nee, die FAEs wollte ich nicht direkt belästigen, bin über techsupport@<...>. 'outgesourct' ist eine kleine bösartige Anspielung auf die gleichnamige TV-Serie.
Hallo Martin, Du schreibst etwas weiter oben: >Die laut Dokumentation mit der Aussenwelt verbundenen TDI und TDO >Signale (jtdi/jtdo) sind nicht 1:1 durchgeschleift, sondern werden >intern nochmal nach steigender bzw. fallender Flanke abgetaste.. D.h. >man bekommt die Daten erst nach einem FF, dadurch wird schon mal ein Bit >zum Schieberegister addiert, und genau das ist das Problem bei einigen >Beispiel-Implementationen, man kriegt es mit Abtasten auf die fallende >zum Laufen, aber ein 32-Bit-Register zeigt z.B. 33 Bit. Hier hast Du also 1 Bit zuviel. Schau mal hier bei Wikipedia: BYPASS-Register Bei diesem Datenregister handelt es sich um ein Schieberegister mit einem Bit Breite. Hintergrund ist, dass die Datenregister (DR) aller TAPs wie beim IR nur gleichzeitig gelesen und beschrieben werden können. Soll nur das Datenregister eines einzelnen TAP in der "JTAG chain" gelesen oder geschrieben werden, so wird über die IRs aller anderen TAPs die BYPASS Instruktion geladen, so dass dieses Register ausgewählt wird. Dadurch kann die Latenz der Scan-Chain, welche durch den Schiebevorgang entsteht, minimiert werden. Quelle Wikipedia: http://de.wikipedia.org/wiki/Joint_Test_Action_Group Kann es sein das der Lattice JTAG Port intern aus 2 TAPs besteht, das würde jetzt das zusätzliche Bit erklären, oder? Viele Grüße, Michael
Hi Michael, nein, mit dem Bypass hat es nichts zu tun, die Befehle funktionieren auch alle ganz nach JTAG-Standard. Nur wenn Du die JTAG-Primitive nutzen willst, musst du die Shift-Register (ER1 bzw. ER2) selbst implementieren, und dabei schlägt die Design-Eigenheit mit dem extra Abclocken zu. Beim Spartan6 ist das z.B. etwas eleganter gelöst und auch dokumentiert. Natürlich können damit mehrere TAPs realisiert werden, so macht es auch jtagconn16. Ansonsten können die ER1/ER2 erst mal nix, d.h. deren Implementation ist vollkommen dem User überlassen. Grüsse, - Strubi
Hallo Strubi >Beim Spartan6 ist das z.B. etwas eleganter gelöst und auch dokumentiert. Wie ist das beim Spartan6 mit dem DRCK? Ich habe hier folgende Info gefunden: >A mirror of the TCK input pin to the FPGA when the JTAG USER >instruction assigned by JTAG_CHAIN is loaded and the JTAG TAP >controller is in the SHIFT-DR state or in the CAPTURE-DR state. Ist das richtig das der Clock nur vorhanden ist wenn ein USER Register ausgewählt wurde? Oder ist er nur in den speziellen Fällen SHIFT-DR und CAPTURE-DR vorhanden? Eigentlich fehlt hier doch noch UPDATE-DR. Viele Grüße, Michael
Hi Michael, Ich habe direkt den TCK benutzt, um mehr Kontrolle über die Geschichte zu haben. Wenn ich mich recht erinnere, ist der DRCK in der Tat "gated", aber ob's nur so ist, wenn das USER-Register selektiert ist, bin ich mir nicht sicher. Mir ist eh nicht klar, was der DRCK für einen Nutzen bringen soll. Auch hier implementierst Du pro BSCAN_SPARTAN6 Primitive dein Shift-Register selbst und loopst es in das TDO der Primitive. Wenn UPDATE high geht, kannst du den Wert aus deinem shift-register entnehmen. Sauber (in die CPU-Clockdomain) einsynchronisieren nicht vergessen :-) Grüsse, - Strubi
Hallo Strubi, >Sauber (in die CPU-Clockdomain) einsynchronisieren nicht vergessen :-) Da der JTAG mit tck und mein System mit sys_clk läuft, würde ich jetzt das UPDATE-DR Signal über zwei FF führen welche mit sys_clk laufen. Wenn jetzt in der sys_clk Domain ein High auf UPDATE-DR erkannt wird, dann können die Daten aus dem parallel_register in die sys_clk Domain übernommen werden. Das war die Richtung JTAG => System. Für die andere Richtung fehlt mir gerade die Idee. Ich muss hier was mit dem State CAPTURE-DR machen. Ich glaube auch das eine Art Handshake für beide Richtungen benötigt wird. Viele Grüße, Michael
Bitte 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.