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