FPGA I2C ohne Taktgeber?

I2C hat doch einen Takt. Nimm halt SCL als Takt, damit sollte es gehen.

Gruß
Marius

Bei I²C wird für jedes Bit im Byte SCL einmal getaktet (und dann noch 
ein 9. Mal um das ACK vom Slave zu kriegen).
Man dürfte also rel. einfach die Daten einlesen können (ich könnte mir 
sogar vorstellen, dass das irgendein gelangweilter Jemand schonmal 
diskret mit Schieberegs gebaut hat (ich kenn zwar akut nix, es ist aber 
einfach genug dafür).
Man hat so etwa den Flow:
Start-bedingung (SDA fällt während SCL high ist, sehr einfach zu 
detektieren); hier kann man ja einen Reset rausholen -> Slave Adresse 
ins Schiebereg rattern lassen, nach 8 takten (3 bit-Zähler ist da dein 
freund) vergleichen (XOR und (N)OR), Status anpassen (lesen , schreiben 
oder nicht angesprochen, du hast ja nur schreiben oder garnix)) -> 
ersten datenbyte reinrattern lassen und wenn fertig in das Zielreg 
schieben (ich denk mal du hast nur eins) -> ACK oder NAK senden (je 
nachdem was du vorhast legst du halt den SDA low oder nicht) -> 
Stop-Befehl vom Master -> alles tristate

Ich hab grade gelesen, dass du ein LED-Disp hast, wenn du das muxxen 
willst brauchst du eh einen dauerhaften Takt.....

Wenn du für jedes Digit einen Pin hast, dann ja.
Nur wenn man z.b. eine Uhr mit 4 Stellen hat würdest du so 7*4 = 28 I/Os 
brauchen.
Deswegen multiplext man das (man zeigt die einzelnen Zeichen so schnell 
hintereinander an, dass es für einen Mensch statisch aussieht). Das 
braucht dann 7(Segemente)+4(Digits) = 11 I/Os und halt einen Takt. Und 
das Gefälle wird noch größer wenn man mehr Stellen hat. Für alles was 
mehr als zwei Stellen hat ist die statische Ansteuerung eigtl. 
daneben...

@ Martin (Gast)

>Ich habe mir ein paar Beispiele angesehen, die hatten aber alle einen
>Systemtakt vorausgesetzt, ich denke das war jetzt nicht SCL wenn es mich
>nicht täuscht.

das wird wohl so sein.

>Hat denn schon jemand I2C (I2C write) ohne weiteren Taktgeber
>implementiert?

Kann man machen, ist aber nicht so günstig und ggf. gefährlich. Denn I2C 
benötigt einen ROBUTEN Glitchfilter am Takteingang, sonst läuft das 
nicht stabil. Ein heutiges FPGA ist mehr als hundertmal schneller als 
I2C, darum ist der Takt SCL als Takt für ein FPGA nur mit Bauchschmerzen 
zu verwenden. Siehe Taktung FPGA/CPLD.

Darum nimmt man für I2C im FPGA besser einen hochfrequenten Takt, so 10 
MHz oder so, sampelt damit SCL und SDA und macht dann eine Auswertung 
der Signale. Dabei kann man noch sehr gut filtern und kann Fehler besser 
abfangen. Denn was machst du, wenn SCL aus einen bestimmten Grund nicht 
mehr taktet? Dann steht alles!

@ Martin (Gast)

>Wenn SCL nicht mehr taktet dann kann ich den FPGA in so einen Fall
>sowieso nicht mehr ansprechen denn dann wäre ja die Master -> Slave
>Kommunikation hinüber?

Sicher, aber darum allein geht es nicht. Wenn man etwas komplexere Logik 
als nur ein paar statische LED-Ausgänge hat, will man ja meist bei 
Fehlern auf dem I2C Bus was machen, dafür braucht es einen dauerhaften 
Takt.

Vlt. sagt der OP mal was er plant zu tun :D
Wenn das nur eine "Machbarkeitsstudie" ist, dann ist das was anderes als 
ein Produktiv-System.
Ich denk mal dass das mehr als Experiment gedacht ist, da man an jeder 
Ecke I²C-Displaytreiber für <5€ hinterher geworfen bekommt :D

Wenn es dir um's Verständniss geht, dann setzt dich hin und überlege, 
wie du das Problem mit normalen Logikgattern lösen würdest. Das sollte 
dann auch so mit einem FPGA möglich sein. Du musst es halt passend in 
VHDL beschreiben.
Der Grundgedanke bei FPGAs ist aber sequentielle Logik und das geht nur 
mit Takt. Im Endeffekt ist das wohl auch einfacher.

Gruß,
  SIGINT