Hallo Freunde, ich hab einen FPGA mit einem I2C-Bus, an dem mehrere Slaves hängen. Für jeden Slave hab ich ein VHDL-Modul geschrieben, das jeweils einen SCL- und einen SDA-Port hat. SCL ist nur "out", SDA wäre "inout". Jetzt muß ich mehrere VHDL-Module an die zwei physikalischen Pins des FPGAs anschließen. Im Augenblick hab ich das so gelöst, daß ich für SCL- und SDA jeweils einen MUX habe, und jenachdem, welches Modul gerade aktiv ist, wird der MUX entsprechend umgeschaltet. SDA mußte ich dabei in "in" und "out" zerlegen, da sich "inout"-Signale nicht muxen lassen wollten. Das Ganze funktioniert einwandfrei, aber mich würde mal interessieren, ob es einen eleganteren Weg gibt. Optimal wäre es ja, wenn ich den Bus, wie er außerhalb des FPGAs läuft (als Wired-And Open-Collector-Strecke) im FPGA genauso weiterlaufen lassen könnte, aber soweit ich informiert bin, gibt es innerhalb des FPAGs (Spartan3) keine Open-Collector-Pfade, oder? Daneben wundert es mich ein wenig, daß man "inout"-Signale anscheinend nicht muxen kann, sondern in "in" und "out" zerlegen muß. Grüße, Dosmo
@ Dosmo (Gast) >ich hab einen FPGA mit einem I2C-Bus, an dem mehrere Slaves hängen. AUSSEN oder INNEN? >Für >jeden Slave hab ich ein VHDL-Modul geschrieben, das jeweils einen SCL- >und einen SDA-Port hat. Also INNEN. Sehr kreativ, aber praktisch sinnlos. >bin, gibt es innerhalb des FPAGs (Spartan3) keine Open-Collector-Pfade, >oder? Nein. >Daneben wundert es mich ein wenig, daß man "inout"-Signale anscheinend >nicht muxen kann, sondern in "in" und "out" zerlegen muß. Eben weil das oben so ist. Innerhalb eines FPGAs macht I2C keinerlei Sinn. FPGAs haben dermassen viel Routingresourcen, dass man Signale direkt an alle Komponenten führen kann. Innerhalb eines FPGAs gibt es nur unidirektionale Signale, inouts aus VHDL werdern bei der Synthese zerlegt. Also lässt man es gleich bleiben. MFG Falk
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 tatsächlich noch, aber diese Leitungen waren gefährdlich, weil ja durchaus mehrere Treiber darauf unterschiedliche Pegel treiben konnten. Und als Pullup-Leitungen war so ein Bus schon für damalige Verhältnisse einfach nur langsam. > 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. Aber es ist mir klar wie das kommt: dir gefällt der I2C Bus, du kennst dich damit aus. Stimmts? > SCL ist nur "out", SDA wäre "inout". Ähmmmm... bei I2C ist auch SCL bidirektional. > SDA mußte ich dabei in "in" und "out" zerlegen, da sich "inout"-Signale > nicht muxen lassen wollten. Es ist andersrum: der Synthesizer versucht, einen internen Tristate-Bus mit einem Multiplexer aufzulösen. Wenn er das nicht kann, gibt es einen Fehler...
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.
@Dosmo (Gast) >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. Sehr sinnvolles Konzept. Normale Menschen hätten einfach EINEN I2C BUS genommen.
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?
Dosmo schrieb: > vier identische I2C-Bausteine, die alle die gleiche Bus-Adresse haben > Wie willst Du die an einen Bus hängen? Das Problem ist bekannt. Und dafür gibts Abhilfe: http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=1650&uiTemplateId=NODE_STRY_PGE_T
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 :-)
@ Lattice User (Gast) >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. Stimmt, die 2 Euro sind schon verdammt teuer, da sollte man lieber 1-2 Monate eine FPGA-Lösung entwickeln . . . Leute gibts
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).
Thread beobachten
Seitenaufteilung abschaltenBitte 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.