I2C-Bus innerhalb des FPGAs

Dosmo schrieb:
> Für
> jeden Slave hab ich ein VHDL-Modul geschrieben, das jeweils einen SCL-
> und einen SDA-Port hat.

Ich würde da noch rs232 und CAM dazwischen setzen. Haha sowas hab ich 
echt noch nie gehört!

Falk Brunner schrieb:
>>ich hab einen FPGA mit einem I2C-Bus, an dem mehrere Slaves hängen.
>
> AUSSEN oder INNEN?
Die Slaves sind natürlich externe Bausteine (EEPROM usw). Wer käme denn 
auf die verwegene Idee, ohne Not einen I2C-Bus im FPGA zu machen ;)

Lothar Miller schrieb:
>Dosmo schrieb:
>> gibt es innerhalb des FPAGs (Spartan3) keine Open-Collector-Pfade,
>Kein aktuelles FPGA hat solche Leitungen mehr. Früher (tm) gab es das
Okay, danke.

>> Für jeden Slave hab ich ein VHDL-Modul geschrieben, das jeweils
>> einen SCL- und einen SDA-Port hat.
>Innerhalb des FPGAs? Das it ein extrem kurioses Konzept...  :-o
>Auf deine Art verbrauchst du nur für jedes Device zusätzlich noch
>Schieberegister&Co für die "Busanbindung". Ich würde Daten innerhalb
>eines FPGAs ausschließlich direkt verteilen. Und nur dort wo es nötig
>ist (Aussenwelt) den I2C implementieren.
Oh ja, das ist natürlich wesentlich besser als mein Konzept.

>Aber es ist mir klar wie das
>kommt: dir gefällt der I2C Bus, du kennst dich damit aus. Stimmts?
Nein, das Problem ist, daß ich regelmäßig VHDL-Projekte vorgesetzt 
bekomme, die schnell-schnell hingebastelt wurden und bar jeglicher 
Struktur sind. Ich selber bin aber kein VHDL-Typ, sondern ein 
objektorientierter Software-Engineering-Typ. Und ich versuche, möglichst 
schnell möglichst viel Struktur reinzubringen, damit der Code wenigstens 
halbwegs übersichtlich und wartbar wird.
Ich sehe, mein VHDL-Verständnis hat noch viel Wachstumspotential ;)

Dosmo schrieb:
> Ich selber bin aber kein VHDL-Typ, sondern ein
> objektorientierter Software-Engineering-Typ. Und ich versuche, möglichst
> schnell möglichst viel Struktur reinzubringen, damit der Code wenigstens
> halbwegs übersichtlich und wartbar wird.
> Ich sehe, mein VHDL-Verständnis hat noch viel Wachstumspotential ;)
Ja, aber mit der objektorientieren Betrachtungsweise liegt man bei 
FPGA-Designs ja gar nicht so falsch...
YMMV

Duke

Noch ein Detail zu meiner Ehrenrettung:
Insgesamt sind an dem FPGA sechs I2C-Busse vorhanden. An fünfen hängt 
jeweils nur ein einziger externer Slave. Nur an einem hängen drei 
verschiedene Slaves.
Nach meinem Verständnis brauche ich also mindestens mal sechs 
I2C-Interface-Instanzen im FPGA. Mir schien es dann sinnvoll und 
vertretbar, alle acht Slave-VHDL-Module gleich aufzubauen, d.h. jeweils 
mit einer eigenen I2C-Interface-Instanz. Zwei Instanzen hätt ich sparen 
können.

Falk Brunner schrieb:
>Sehr sinnvolles Konzept. Normale Menschen hätten einfach EINEN I2C >BUS genommen.
Sehr sinnvoller Kommentar. Normale Menschen hätten einfach darüber 
nachgedacht, daß es vielleicht einen Grund dafür gibt.
Tatsächlich haben wir vier identische I2C-Bausteine, die alle die 
gleiche Bus-Adresse haben (und keine externen Adress-Leitungen o.ä.). 
Wie willst Du die an einen Bus hängen?

Lothar Miller schrieb:
> Das Problem ist bekannt. Und dafür gibts Abhilfe:
> http://focus.ti.com/paramsearch/docs/parametricsea...

IMO zusammen mit einem FPGA nur sinnvoll wenn einem sonst die Pins 
ausgehen und man deswegen auf das nächst grössere Gehäuse wechseln muss. 
Die erwähnten NXP Bauteile sind ausserdem nicht gerade billig (1-2€ bei 
Mouser). Auch ein Grund warum man das oft mit FETs (z.B. 2N7002) macht.

Falk Brunner schrieb:
>>bin, gibt es innerhalb des FPAGs (Spartan3) keine Open-Collector-Pfade,
>>oder?
Das gabe es früher mal, als man noch davon träumte, ganze Schaltungen 
programmierbar zu bekommen. Es hats ich aber gezeigt, dass das 
unermesslich viel Aufwand bedeutet und resourcen bindet. Ausserdem ist 
es ein ständiger Quell von Defekten und kaputtprogrammierten FPGAs 
gewesen, weil man das nie 100% durchsimulieren konnte.

Heute ist das Zusammendrahten von Treibern im FPGA generell verboten und 
wird durch die Synthese genrell verhindert.

Du musst, wie du es beschrieben hast, die Physik aus dem design 
rauswerfen und die Verbindung logisch aufbauen. Dann kannst du dir noch 
überlegen, ob es bidirektional gehen können soll und muss. Bei vielen 
Verbindungen und Teilnehmern, wo nur ein Endlunkt vorliegt, entfällt der 
Rückpfad.

Diese Verbindungsproblematik führt übrigens bei den ach so beliebten 
SOC-Systemen zu einem ganzen Wald von Multiplexern, weil ja jeder mit 
jedem reden können muss und somit für n teilnehmer 2*n*(n-1) Pfade 
gebaut werden müssen. 2 CPUs, 4 RAMs und 2 weitere aktive Teilnehmer 
erfordern dann theoretisch 112 Kreuzverknüpfungen mit 2x8 Multiplexern, 
die jeweils 7 auf 1 Busschalten können und das möglichst nur gepuffert, 
damit hoch taktbar. Bei 16 Bit Wortbreite hast du auch beim Minisystem 
sofort x-Tausende Signale und FFs und im SOC builder sieht es so einfach 
und überschaubar aus :-)

Falk Brunner schrieb:
> Stimmt, die 2 Euro sind schon verdammt teuer, da sollte man lieber 1-2
> Monate eine FPGA-Lösung entwickeln . . .
>
> Leute gibts

2 Monate für einen einfachen Multiplexer?
Das muss aber ein extra fähiger Entwickler sein.

K. Unger schrieb:
> Diese Verbindungsproblematik führt übrigens bei den ach so beliebten
> SOC-Systemen zu einem ganzen Wald von Multiplexern, weil ja jeder mit
> jedem reden können muss und somit für n teilnehmer 2*n*(n-1) Pfade
> gebaut werden müssen.

Bei grösseren SOC hat man da schon erhebliche Probleme. Es gibt schon 
Ansätze wie NoC (Network on Chip), d.h. Packet switching statt Signal 
switching. Ich weiss aber nicht wie weit das schon gediehen ist.
Siehe dazu auch PCI Express (Packet switching) versus PCI (Signal 
switching).