Programmierung eines FPGAs durch µC

FloKath schrieb:
> Hallo Zusammen,
> ich habe eine vorhandene Hardware auf Ihr ist ein µC (Infinion) und ein
> FPGA (Lattice) installiert. Beide liegen in einer JTAG Chain.
> Ich würde nun gerne, da die Hardware verbaut ist, das FPGA über den µC
> neu Programmieren, ist dies möglich? Wenn ja wie? Über tips, tricks oder
> fertige Projekte wäre ich dankbar.
> Mfg
> Gruß,
> FloKath

Über JTAG hast du da wohl keine Chance, das dürfte schon am µC 
scheitern.

Ansonsten hängt es da die HW schon fertig ist und wie ich annehme nicht 
mehr geändert werden soll davon ab welcher Lattice FPGA und wie deine 
Schnittstelle µC - FPGA realisiert ist.

Hallo Zusammen, es sieht also so aus...
Der Infineon ist ein TriCore und die Idee ist, dass man entweder den 
FPGA durch die 4 Physikalischen Pins über JTAG oder durch einen 
Multiplexer umgeschalten eine JTAG verbindung zwischen µC und dem FPGA 
aufbauen kann, so dass der Prozessor die Programmierung übernimmt.
Wenn das so wird wie wir das wollen.
Erschwerend kommt jedoch hinzu, dass die JTAG Chain, noch 2 CPLDs 
beinhaltet.. siehe Bild.
Ich hoffe ich finde hier ein paar nützliche Tipps wie ich dieses Projekt 
lösen kann.
Da im Verbauten zustand an die harten Pins nicht mehr zu kommen ist.

Auch wenn Du das Hardwarekonzept noch nicht fertig hast, hier ein Link 
zur passenden Software von Lattice (ispVM Embedded):
http://www.latticesemi.com/products/designsoftware/ispvmsystem/ispvmembedded.cfm

Hi,
Hardware ist schon fertig. Das bei Lattice hab ich auch schon gesehen, 
damit kann man das JTAG File umkonfertieren, mir fehlt aber noch der 
Brückenschlag damit ich weiß, was ich für Methoden im µC brauche, um 
dann schließlich auch das erzeugte File ins FPGA zu bringen.
Aber schonmal danke

FloKath schrieb:
> Hardware ist schon fertig.

Also ist der MUX schon verbaut?

> Das bei Lattice hab ich auch schon gesehen,
> damit kann man das JTAG File umkonfertieren, mir fehlt aber noch der
> Brückenschlag damit ich weiß, was ich für Methoden im µC brauche, um
> dann schließlich auch das erzeugte File ins FPGA zu bringen.

Dann hast du das zwar gesehen, aber nicht genau hingeschaut. Bei ispVM 
Embedded sind C-Sourcen dabei! Man muss nur die Funktionen um an den 
JTAG Pins zu wackeln hinzufügen. Geht das überhaupt mit dem Tricore?

Um zielführender helfen zu können, müsste man aber wissen um welchen 
FPGA es denn eigentlich geht.

Ja der Multiplexer ist schon verbaut...
Es geht um ein XP2-5E bzw XP2-17E und der TriCore ist ein 1796 ich hoffe 
es geht mit diesem TriCore... ?!
Wie sehen dann diese Funktionen aus, dass ist ja mehr als Wackeln, da 
müssen ja Daten laufen, oder?
Ich bin jetzt nicht no der Embedded Programmierer, hoffe aber dass ich 
es trotzdem schaffe.
Danke
Gruß

Hi

Nur Kurz... wie kommen deine Daten auf den TriCore, bzw Streamen oder 
Buffern...

Wir reden hier von einigen MB die irgendwie "am stück" da runter 
müssen...


Gruß

Tja es wird wohl über ein CAN Interface geschickt, wobei die Zeit nicht 
so kritisch ist, wenn es mal ne halbe Stunde dauert...ist das o.k. es 
geht hautsächlich um die Machbarkeit ohne die Hardware auszubauen.
Die Nachricht enthält dann immer die Nutzdaten, die dann halt wieder 
zusammengesetzt werden müssen.
Gruß

Mach dich als erstes damit vertraut wie JTAG funktioniert.
Danach versuche die Sourcen unter 
C:\lscc\diamond\1.4\embedded_source\vmembedded in deiner 
Diamondinstallation zu verstehen. Das sind die bei denen du das Gewackle 
der JTAG Pins ergänzen musst.

Allerdings, an was für Pins des Tricores habt ihr den JTAG 
angeschlossen?
Wenn es GPIOs sind alles in Butter, wenn es der JTAG Debugport des 
Tricore ist habt ihr euch vermutlich ins Knie geschossen.

Der JTAG-Port geht intern auf einen TAP-Controller (Statemachine), an 
dem der normale µC-Kern nicht wackeln kann.
Du kannst normalerweise nur mit externen Tools auf den JTAG-Port 
zugreifen.

Lattice User schrieb:
> Wenn es GPIOs sind alles in Butter

Alles in Butter es sind GPIOs ;-)
Also jetzt nur noch den Code verstehen und wie JTAG geht, sehe ich das 
soweit richtig?
Ist das für jemanden ohne großes Wissen im Embedded Bereich zu lösen?
Oder kämpfe ich hier auf verlassenem Posten?

BoundaryScan schrieb:
> Der JTAG-Port geht intern auf einen TAP-Controller (Statemachine), an
> dem der normale µC-Kern nicht wackeln kann.

Was meinst du damit?

Gruß

Der JTAG-Port besteht normalerweise aus den 4 Pins TDI, TDO, TMS und 
TCK, wobei TDI der Dateneingang ist und TDO der Ausgang. TDO vom ersten 
Baustein in der Kette ist mit TDI vom nächsten Baustein verbunden usw. 
TMS und TCK werden parallel an alle Bausteine der Kette geführt.
Die 4 Signale werden mit einer externen Hardware verbunden, zum 
Debuggen, Programmieren oder Testen, was der eigentliche Sinn dieses 
Ports ist. Das heißt, völlig unbeeinflußt vom CPU-Kern kann die externe 
Hardware, gesteuert von entsprechender Software, die Anschlüsse des 
Controllers testen.

Wenn diese Signale (also TDI, TDO usw) auf normalen GPIOs liegen, sind 
sie für BoundaryScan-Anwendungen nutzlos und die Kette kann auch nicht 
funktionieren.

achso...

die MUX ist ziemlich für die Katz... einfach die Pins am µC tristaten 
langt.

Gruß

>Daher hat er ja den Mux drin. Somit kann er offenbar die JTAG Kette
>entweder auf den externen Programmierstecker oder aber auf die GPIOs
>legen

Es langt die IO am uC zu tristaten, dann die vier JTAG Signal parallel 
auf JEDEC Stecker und GPIOs führen. Hab ich schon einige mal gemacht, 
auch auch FPGA Pins damit sich der FPGA selber neu programieren kann 
(nur sollte man da nie vergessen, den Pull-Up abzuschalten...)


Die GPIOs würd ich eher nicht für andere Funktionen weiterverwenden..


Gruß

Moin Zusammen!
Freut mich zu sehen,
dass so heftig diskutiert wird, aber um auf mein ursprüngliches Problem 
zurück zu kommen.
Hat schon jemand dieses Projekt umgesetzt? Vielleicht mit einem der 
Beiden oder beiden Bausteinen?
Über Tips, Tricks, QuellCode Beispiele zum nachvollziehen wäre ich 
dankbar.

Hi,

also ich finde jetzt erst mal Butter bei die Fische.
Für ordentliches helfen musst du selber auch ein bisschen was tun.

Lies mal die Datenblätter vom Tricore und poste evtl. mal den Schaltplan 
bzw. nenne die Pins an die das beim Tricore angeschlossen ist.

Irgendwer hat was von nem Mux erzählt....Gibt es den in HW und wenn ja 
wie ist das realisiert??

Fakten bitte, dann helfe ich auch ein bisschen.
Rumraten usw. bringt hier nicht viel weiter.

Ich selbst habe mal mit einer ispVM Embedded ähnlichen Software von 
Lattice rumprobiert, wollte es auf einem atMEGA (8-bitter) laufen 
lassen, was nicht funktioniert hat. Diese Software hiess leicht anders 
und ist für den Slave SPI-Port vom Lattice XP2 gedacht.

Die Lösung war dann: Ich habe auf dem atMEGA selber eine Software 
geschrieben die den SSPI-Port vom XP2 bedient und den FPGA auf diesem 
Wege beschickt. Funktioniert auch relativ gut.

So dann mal Butter bei die Fische,
also der Mux ist in ein Baustein auf der Platine, der durch anlegen 
einer Bootstrap Spannung entweder auf auf physikalische Pins schaltet, 
dann kann das FPGA durch einen Programmer geflasht werden, klappt aber 
nur, wenn die Platine nicht verbaut ist.
Wenn die Platine Verbaut ist, wird durch anlegen der Bootstrap spannung 
der Mux umgeschaltet und die TriCore Pins bedienen dann die JTAG 
Schnittstelle der FPGAs (so soll es werden). Die Hardware ist schon 
komplett fertig, Bisher haben wir die mühe, dass die Platine jedesmal 
beim neu flashen ausgebaut werden muss, dann geflasht, isolationstest 
und wieder verbaut.
Soll sich aber ja durch das Projekt ändern.
Zu den TriCore Pins die Signale sind folgenden Pins zugewiesen...
TDI -> P7.0
TDO -> P7.1
TCK -> P7.2
TMS -> P7.3

So ich hoffe, ich bin Bernds ansprüchen gerecht geworden.
Ich komme selber mehr aus der Hardware / FPGA Schiene, bin also Embedded 
nicht so bewandert, würde es aber trotzdem gerne schaffen.

Grüße und schon mal Danke und frohe Ostern!

FloKath schrieb:
> Ich komme selber mehr aus der Hardware / FPGA Schiene, bin also Embedded
> nicht so bewandert, würde es aber trotzdem gerne schaffen.

Ich habe das Gefühl du lässt dich durch da Buzzwort Embedded zu sehr ins 
Bockshorn jagen. Jede noch so kleine ATiny Anwendung fällt unter diesen 
Begriff.

In dem oben von mir genannten Verzeichnis findest du die Variante der 
Software für den JTAG Port und nicht die Variante für den von Bernd 
erwähnten SSPI Port. Anzupassen ist hardware.c

Da ihr in der gleichen Chain auch 2 weitere PLDs habt, muss das im svf 
File berücksichtigt werden.

Wenn der Platz im tricore nicht mehr reicht, könnt ihr auch einen ganz 
simplen Player implememtieren, einfach über CAN ein Datenpacket 
empfangen und Byte für Byte auf den GPIOs für den JTAG ausgeben. Der 
Aufwand liegt dann auf der anderen Seite um einen passenden Stream bzw 
File zu erzeugen. Dazu muss man sich aber etws genauer mit JTAG 
befassen. Hat ausserdem den Nachteil dass Fehlererkennung nicht mehr 
einfach ist.

Hi,

nen Schaltplan hab ich jetzt zwar noch nicht gesehen, habe aber jetzt 
verstanden, dass die Pins vom Tricore ordentlich angesteuert werden 
können.

Die von LatticeUser genannte Lattice-Software solltest du dir jetzt mal 
vornehmen und in die (bereits vorhandene?) Tricore-Software einbinden.

Ich bin mir (fast) sicher, dass Lattice sehr gut beschreibt wo überall 
Änderungen vorgenommen werden müssen, LatticeUser hat ja auch schon 
gesagt wo man was machen muss.

Compiliert dat Dingens ordentlich? Habt ihr evtl. die Möglichkeit 
in-circuit zu debuggen? Single-Step usw. kann sehr nützlich sein.

Außerdem brauchst du nun ein SVF oder embedded SVF-File. Da ihr eh 
Lattice benutzt bietet es sich an ein solches File mit dem 
ispVM-Programm vom Lattice zu erstellen. Habe gehört es gibt nun auch 
noch ein neueres Programmierprogramm von Lattice, kenne dieses 
persönlich aber noch nicht. In ispVM benötigst du BSDL-Files von allen 
Devices die zwar in der JTAG-Chain sind, die du aber NICHT ansprechen 
möchtest. Mit diesen BSDL-Files und dem zu programmierenden FPGA Bitfile 
(JEDEC-format) solltest du (habs selber noch nicht bei ispVM 
ausprobiert) ispVM mittteilen können wie die JTAG-Chain aussieht. Dann 
SVF-File erstellen.

Und dieses SVF muss jetzt auch noch in dein Device kommen. Du wolltest 
das ja über CAN machen. In die Tricode-Software muss also noch ein 
entsprechender Puffer rein der das SVF-File aufnimmt. Wenn es nicht ganz 
rein passt, dann ein Ringpuffer, der immer nur einen Teil aufnimmt und 
dann Stück für Stück Teile nachlädt. Vielleicht kannst du das in einer 
SD-Card ablegen? Ist eure HW schon komplett fertig?