Shared eMMC (FPGA als zweiter Host)

[P. K. (pek)]

Hallo zusammen

Ich möchte mein eMMC Flash, welches tipp-topp am S0-Port meines FX3S 
läuft, nun auch vom FPGA aus ansteuern (nicht funktional, sondern für 
den Boundary-Scan, welchen FX3 nicht bietet).

Die Leitungen sind dan im Y, was von der Signalintegrität zumindest 
durchdacht sein muss. Gibt es dazu Literatur, Links, Layout-Guidelines?

Hat das von Euch schon jemand mal gemacht? Dos and Don'ts?

Merci 6 Gruss
Peter

[Bernhard (Gast)]

Ich würde die eMMC an den FPGA hängen und den FX3S an den FPGA.
Damit kann der FPGA auf die eMMC zugreifen wenn die CPU das nicht tut 
(und diese ggf verzögern oder anhalten)

[P. K. (pek)]

Bernhard schrieb:
> Ich würde die eMMC an den FPGA hängen und den FX3S an den FPGA.

Das geht nicht. der FX3 bootet aus dem eMMC, das FPGA wird später vom 
FX3 über USB und SlaveFifo I/F konfiguriert.

Wie erwähnt will ich vom FPGA auch nicht funktional auf das eMMC 
zugreifen, sondern es geht um Produktionstestbarkeit des eMMC.

[Hmmhmm (Gast)]

P. K. schrieb:
> Bernhard schrieb:
>> Ich würde die eMMC an den FPGA hängen und den FX3S an den FPGA.
>
> Das geht nicht. der FX3 bootet aus dem eMMC, das FPGA wird später vom
> FX3 über USB und SlaveFifo I/F konfiguriert.
>
> Wie erwähnt will ich vom FPGA auch nicht funktional auf das eMMC
> zugreifen, sondern es geht um Produktionstestbarkeit des eMMC.

Ich halte das für nicht emfehlenswert.
Du musst nämlich sicherstellen:
- Welchen Status die EMMC-Ports des Prozessors haben
- Welchen die des FPGAs
Und das auch im und direkt nach dem Reset. Du muss genau wissen, was der 
EMMC-Block des Prozessors unter allen Betriebsbedingungen tut. Natürlich 
das gleiche für das FPGA.

Wenn du das nicht kannst, treiben die Ports von FPGA und Prozessor dann 
gegeneinander - zumindest wird das die Funktion behindern oder das EMMC 
irgendwie beeintraächtigen (undefinierte Pegel). Oder die Hardware 
zwerstören.
Das könnte man mit Serienwiderstände unterbinden, aber die 
Geschwindigkeit der Schnittstelle verbietet das eher.

Besser wäre eine Software auf deinem Prozessor. Ob das EMMC geht, 
erkennt man eh beim Programmieren des Images, oder?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

P. K. schrieb:
> Wie erwähnt will ich vom FPGA auch nicht funktional auf das eMMC
> zugreifen, sondern es geht um Produktionstestbarkeit des eMMC.
Da würde ich es bestenfalls so probieren:

    µC o-----------------o---------------o eMMC
                        FPGA

Oder schlimmstenfalls nur mit ganz kurzen Stubs (<10mm):

    µC o-----------------.---------------o eMMC
                         |
                         o
                        FPGA

Wenn das FPGA dann die Eingägne hochohmig schaltet, sollte sich die 
Busbeeinflussung in Grenzen halten.

[Hmmhmm (Gast)]

Lothar M. schrieb:
> Wenn das FPGA dann die Eingägne hochohmig schaltet, sollte sich die
> Busbeeinflussung in Grenzen halten.

Tja, nun, zum Beispiel ist die clockleitung per Default ein DO am 
Prozessor.

Da müsste man schon sicherstellen, dass das im Reset oder was auch immer 
auch NICHT der Fall ist. Wie sollte man sonst per boundary-Scan einen 
Takt ausgeben können, wenn der Prozessor dagegenhält?
Der ist ja nicht Boundary-Scan fähig, daher sind dessen internen Blöcke 
untrennbar kontaktiert.

Der Bus ist einfach so nicht für zwei Master gedacht. Eigentlich nicht 
einmal für zwei Slaves, mangels select.

Ich würde vermuten, dass man sich mit einem derartigen Test viele 
unnötige Probleme einhandelt. Daher wäre mein Vorschlag, das eher in 
einen anderen Testschritt zu verlagern. Oder eine Testsoftware auf dem 
Prozessor zu verwenden.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Hmmhmm schrieb:
> Tja, nun, zum Beispiel ist die clockleitung per Default ein DO am
> Prozessor.
Auch wenn der Prozessor im Reset ist?

[P. K. (pek)]

Lothar M. schrieb:
> Da würde ich es bestenfalls so probieren:
>   µC o-----------------o---------------o eMMC
>                         FPGA

Schaut bei mir eher so aus:

   µC o-----o---------------------------o FPGA
           eMMC

Nach all den Antworten, und dem Risiko dass ich die Signal-Integrity 
nicht auf die Reihe kriege, werde ich diese Idee wohl bleiben lassen und 
den TE mit einem Funktionstest belasten.

Merci sowieso!