Hallo, vielleicht nützt der I2C-Slave im Anhang dem einen oder anderen, ist noch nicht komplett getestet und auch nicht ganz fertig, Kritik und Bug-Reports sind erwünscht. Wenn jemanden was auffällt, das irgendwas nicht I2C-Spec-konform ist -> Meldung. ein paar Features: - Master kann schreiben und lesen - praktisch keine Einschränkung der Frequenz - Error-Code nach Transfer - freie Slave-Adresswahl - Sniffer-Mode
Danke FPGA-User, dein Source hat mich im besonderen bei der richtigen Erstellung von Test Benches weitergebracht. Gruß Hagen
42 Downloads und nur eine Meldung von Hagen Leute, Leute ... mit kopieren seid ihr ja immer schnell aber mal selbst mitarbeiten ???
Leider musste ich feststellen, das der Hersteller des Expansion Modules für mein Evaluation Board die Pins für i2c Schnittstelle nicht verdrahtet hat. So konnte ich auch dein Design @FPGA_USER nicht austesten. Bulk out habe ich aber trotzdem schon geschafft. Jetzt kommt noch Bulk in und dann beides zusammen. Trotzdem Danke für die Mühe die du dir gemacht hast @FPGA_USER. Ist schon traurig das einige (viele ?) Hersteller, alles raufpacken was möglich ist, und dann ist nur ein Bruchteil davon nutzbar, da alle IC's über dieselbe Busleitung durchgeschliffen werden und die einzelnen Komponenten nur über Tristate Treiber getrennt sind Grr....
@FPGA-User "Leute, Leute ... mit kopieren seid ihr ja immer schnell aber mal selbst mitarbeiten ???" Was beschwerst du Dich und was meinst Du mit "mitarbeiten" ? Die meisten werden wohl I2C lieber mit einem µC machen, die sind billiger und lassen sich auch einfacher löten (viel viel weniger Pins). D.h. die gucken nur mal wie VHDL denn so aussieht. Ich guck da auch nur rein, wie ein Schwein ins Uhrwerk. Ne Anregung hätte ich vielleicht (wenns nicht schon drin ist): FPGAs sind ja sauschnell und können deshalb leicht fehltriggern. Deshalb würde ich alle Flankenwechsel 4-fach abtasten mit nachfolgender Entprell-Logik. Das dürfte die Störsicherheit drastisch verbessern. Alle richtigen I2C-Chips haben ja auch sowas drin, um Impulse unter einer Mindestdauer zu unterdrücken, die machen das in der Regel mit einem profanen RC-Tiefpaß. Peter
@peter dannegger Ich bin mit dem was du da geschrieben hast nicht ganz einverstanden. Mit "mitarbeiten" versteht FPGA-User auch mal seinen Code in einem FPGA oder CPLD auszutesten, und dann einen Eintrag zu schreiben und mitzuteilen ob der Code auch funktioniert hat oder nicht, wenn nicht vermutungen anzustellen warum nicht. Solch ein Forum ist doch dazu da gegenseitig Erfahrungen auszutauschen. VHDL Programme zu schreiben ist mit einem größeren Zeitaufwand verbunden als nur mal schnell ein C Programm einzuhacken. Das verhalten eines synthetisierten Design stimmt nicht immer mit dem was man erwartet hat überein, deshalb ist Feedback in solchen Sachen wichtig, da wird mir jeder recht geben der schon mal damit etwas zu tun hatte. Mit der Beschwerde hat FPGA-User vollkommen recht und mal eine kleine Kritik da anzubringen ist nicht verboten. Niemand ist gezwungen sich mit programmierbarer Logik zu beschäftigen. Ich finde programmierbare Logik allerdings interessanter, da man alles anstöpseln und ansteuern kann was es gibt. G. Tobias
@Tobias "Ich bin mit dem was du da geschrieben hast nicht ganz einverstanden." Ich hab doch nur begründet, warum zwar einige reingucken, aber wohl nur sehr wenige sowas auch anwenden werden. I2C ist ja doch ne langsame Sache und daher definitiv nicht die Killeranwendung für FPGAs, deshalb ja auch mein Hinweis, daß man den FPGA noch extra für die langsamen Signale sicher machen muß. Ich setzte nur CPLDs ein und programmiere die in Abel. Die Anbindung an einen MC würde ich aber nie mit I2C machen, da zu viele Macrozellen dafür draufgehen würden, sondern entweder als memory mapped IO (8Bit Latch) oder als SPI (einfaches Schieberegister). "VHDL Programme zu schreiben ist mit einem größeren Zeitaufwand verbunden als nur mal schnell ein C Programm einzuhacken." ??? Dann würde ich es mir aber erst recht doppelt und dreifach überlegen, eine Sache in nem FPGA zu machen, die auch ein MC kann. Ich hätte jetzt aber vermutet, daß VHDL für den Kundigen einfacher als Abel/Cupl/Palasm sein sollte, denn sonst würde es doch niemand benutzen. "Mit der Beschwerde hat FPGA-User vollkommen recht" Eben nicht ! Wie gesagt, mal reingucken ist doch o.k., aber nen VHDL/FPGA-Arbeitsplatz dürften die wenigsten hier haben und I2C im FPGA noch weniger benötigen. Ich hab ja auch mal reingeguckt ohne mir anmaßen zu können, da etwas zu verstehen, geschweige denn zu testen oder zu bemängeln. Schau Dir einfach mal andere Codebeispiele an, da sind durchaus 3-stellige Downloadzahlen möglich, ehe mal jemand eine Fehler entdeckt. Man kann nicht immer gleich alles ausprobieren, was man irgendwo sieht, das ist absolut normal und keine böse Absicht. Peter
@peter dannegger Das klingt alles recht vernünftig was du geschrieben hast, und stimme dir in den meisten Punkten zu. Habe deinen vorherigen Kommentar danach etwas zu krass aufgefasst und brauchte deine Richtigstellung. Ob nun VHDL leichter zu lernen ist als Abel, Verilog oder ähnliche Sprachen sei mal dahingestellt, jede hat ihre Vorzüge und Nachteile. Es geht ja nicht in erster Linie um den Syntax, sondern um die Logic dahinter die man sich ausdenken muss. Je komplexer das Design ist, desto mehr Abhängigkeiten in der Logic entstehen, die man alle berücksichtigen muss. Das ist in jeder Sprache gleich schwer, und erfordert ein gehöriges Stück komplexes Denken und Abstraktionvermögen, das ist aber auch wieder meine eigene Ansicht. Mit Abel habe ich mal Gals programmiert, und muss sagen das ging ganz fluffig von der Hand, trotzdem wäre mir VHDL lieber gewesen, weil gelernt ist nun mal gelernt. G. Tobias
Hallo Peter, bitte nicht alles so verbissen sehen. Als Autor des I2C-Slaves nehme ich mir schon mal das Recht heraus, die Downloader zu bitten, einen Test zu machen oder Kritik abzugeben. Ich behaupte mal, ordentlichen VHDL-Code gibts nicht an jeder Ecke und wenn mehrere Leute mitmachen, ist die Gefahr für Bugs wesentlich kleiner. Übrigens, auch wenn I2C für ein FPGA keine wirkliche Herausforderung ist, es wird eingebaut. Stell Dir mal vor Du brauchst 2 I2C Multimaster und 3 Slaves gleichzeitig, jeder soll 128 Bytes Buffer jeweils für TX und RX haben und Dein Main-Prozessor hat so schon alle Hände voll zu tun, dann packt man das Zeug halt ins FPGA mit rein, wenn sowieso schon eins vorhanden ist.
Man sollte als "Contributer" solcher Sourcen einfach nicht erwarten das man ein Feedback bekommt. Zumindestens habe ich mir das mit der Zeit abgewöhnt. Um so mehr freue ich mich dann wenn ich denoch ein positives Feedback bekomme. Im Grunde ist es mir heutzutage auch egal ob ich ein Feedback bekomme, Hauptsache ist doch das man selber mit der eigenen Arbeit zufrieden und glücklich ist. @FPGA-User: ich gebe den Aussagen von Peter zwecks Sinnhaftigkeit eines I2C in FPGA aber Recht. Aus meiner Sicht ist dein Testbench Code viel interessanter als Lernstoff als dein I2C Source ansich ;) Gruß Hagen
@FPGA-User "Stell Dir mal vor Du brauchst 2 I2C Multimaster und 3 Slaves gleichzeitig, jeder soll 128 Bytes Buffer jeweils für TX und RX haben" Soll das ein Witz sein oder war das ernst gemeint ? Ich versuche jedenfalls immer, mich auch mit praxistauglichen Aufgabenstellungen zu beschäftigen. Was der Sinn von 5 I2C-Bussen in einem Gerät sein soll, entzieht sich aber gänzlich meinem Vorstellungsvermögen. Eine Hardware-Pufferung ist bei I2C nicht nötig, da der Bus ja immer auf den langsamsten Teilnehmer synchronisiert. Es reicht also voll aus, wenn der I2C Interrupthandler einen Software-Puffer verwaltet. Bzw. eine Hardware-Pufferung ist ja auch gar nicht möglich, da sie ja total protokollabhängig ist. Ein PCF8574 hat ein anderes Protokoll als ein 24C16 und der wieder anderes als ein 24C32 und wieder ein anderes, ob man byteweise oder pageweise zugreift usw. Ich habe mal in einem Gerät einen I2C-Multimasterbus verwendet und da war schon reichlich Protokollprogrammierung zu tun. Deshalb bin ich auch in neueren Geräten dazu übergegangen, den CAN-Bus zu verwenden, der einem schon ne Menge Protokollarbeit abnimmt. Für Neuentwicklungen würde ich daher nicht mehr den I2C als Multimaster einsetzen. Das hat auch den Vorteil, daß der CAN auch für die Verbindung von Geräten untereinander geeignet ist. Der Master-Modul hat deshalb einen µC mit 2 CAN-Controllern (internen Bus + externer Bus). Peter
Hallo I2C-user! Ich bin ein Wiedereinsteiger bei VHDL. Habe versucht den CODE auf ispLEVER Production Build 4.2.00.39.43.04 und dem LC4064V von Lattice zum laufen zu bringen. Bei der Simulation bin ich gescheidert. Folgenden Fehlerreport habe ich erhalten: # // # // THIS WORK CONTAINS TRADE SECRET AND # // PROPRIETARY INFORMATION WHICH IS THE PROPERTY # // OF MENTOR GRAPHICS CORPORATION OR ITS LICENSORS # // AND IS SUBJECT TO LICENSE TERMS. # // # Loading C:\ispTOOLS4_2\modelsim\win32loem/../std.standard # Loading C:\ispTOOLS4_2\modelsim\win32loem/../ieee.std_logic_1164(body) # Loading C:\ispTOOLS4_2\modelsim\win32loem/../ieee.std_logic_arith(body) # Loading C:\ispTOOLS4_2\modelsim\win32loem/../ieee.math_real(body) # Loading work.i2c_syn_pkg(body) # Loading work.i2c_sim_pkg(body) # Loading work.tb(tb) # Loading work.i2c_slave(behave) # ** Error: (vsim-3732) tb.vhd(238): No default binding for component at 'i2c_slave_1'. # (Port 'slv_adr' is not on the entity.) # Region: /tb/i2c_slave_1 # Error loading design # Error: Error loading design # Pausing macro execution # MACRO ./tb_vhdf.udo PAUSED at line 4 Hat jemand schon den CODE auf einen Lattice-Baustein zum laufen gebracht? Für einen Hinweis wäre ich dankbar! Gruss Helmuth
Hallo Helmuth, die Reihenfolge beim compilieren scheint nicht zu stimmen, bei Dir wird zuerst tb.vhd compiliert, danach i2c_slave.vhd, tb.vhd sollte aber zuletzt compiliert werden. Tausch mal die Reihenfolge, dann sollte es gehen. (Oder verwende das Script sim.do : einfach im ModelSim eingeben: do sim.do )
Hallo FPGA-User, Deine Annahme dürfte nicht ganz richtig sein. Das Auto-Batchfile von Lattice hat die gleiche Reihenfolge als das Altera-Batchfile: -- NOTE: Do not edit this file. -- Auto generated by VHDL Functional Simulation Models -- vlib work vcom i2c_sim_pkg.vhd vcom i2c_syn_pkg.vhd vcom i2c_slave.vhd vcom tb.vhd do tb_vhdf.udo tb -- End Die Fehlermeldung bezieht sich auf die Anweisung: i2c_slave_1 : i2c_slave im tb.vhd file. Ich kann mit dieser Anweisung nichts anfangen! Was ist der i2c_slave_1? Wo ist diese Funktion deffiniert? Gruss Helmuth
Hallo Helmut, i2c_slave_1 : i2c_slave ... bedeutet, dass hier die Funktion i2c_slave instanziiert wird, danach kommt das Port-Mapping. i2c_slave_1 ist der Name für die Instanz des Slaves, der dann z.B. auch wieder im Modelsim auftaucht. Die Fehlermeldung "No default binding for component..." sagt mir eigentlich, dass der i2c_slave.vhd nicht (erfolgreich?) in die Library WORK compiliert wurde. Bekommst Du eine Fehlermeldung wenn Du i2c_slave.vhd einzeln compilierst ?
Hallo FPGA-User, nachdem ich ein paar Wochen passiv das Forum genutzt habe, möchte ich jetzt doch aktiv werden. Auch ich gehöre zu denjenigen, die das Projekt nur kopiert haben um daraus zu lernen. Nach genauerem Durcharbeiten des i2c_slaves sind mir 2 Dinge aufgefallen. (Na ja mir sind noch mehr aufgefallen, die sich aber nach genauerem Studium Deines Codes in wohlgefallen aufgelöst haben :-) Ich bin halt noch Anfänger auf diesem Gebiet.) Zum einen fehlt im State WR_ACK die Anweisung slv_ack_q <= '1'; wenn aus welchen Gründen auch immer die Start Kondition gesetzt wird. In diesem Fall beläßt der Slave die Datenleitung auf Low-Pegel und es kann keine Adresse empfangen werden. Der andere Punkt betrifft den Fehlerfall TX_UNFLW. Du fragst den Underflow in den States CHECK_STS_FOR_ACK und MSTR_RD ab. Im letztgenannten setzt Du das Fehlerflag. Allerdings kann dieser State nur erreicht werden, wenn schon ein Wert im TX Register steht (vgl. Abfrage im State CHECK_STS_FOR_ACK). Demzufolge kann das Fehlerflag niemals gesetzt werden. Ich werde das Projekt noch etwas genauer studieren vorallem auch wie man eine Testbench aufsetzt (Kann man eine Testbench mit einer grafischen Timinganalyse, -ausgabe verbinden? Ich habe meine Stimuli bisher nur grafisch definiert.). Leider habe ich es noch nicht geschafft das Projekt zum laufen zu bringen. Ich nutze Quartus II in der Version 4.2 SP1 (aus Kompatibilitätsgründen zu meinen Amerikanischen Kollegen!) und diese Version scheint keine Unit math_real zu kennen: Error: VHDL Use Clause error at i2c_sim_pkg.vhd(23): design library "ieee" does not contain primary unit "math_real" Nach testweisem Auskommentieren dieser Unit wundere ich mich über folgende kuriose Fehlermeldung: Error: VHDL Wait Statement error at tb.vhd(107): Wait Statement must contain condition clause with UNTIL keyword bzgl. der Zeile: sniffer_on <= false; wait until reset ='0'; => wait for 100 ns; Na ja ich werde mich weiter mit diesen Problemen befassen und evtl. die neueste Version von Quartus II installieren. Gruß Timo
Hallo FPGA-User, habe die von Timo vorgeschlagene Aenderung durchgeführt und die Datei i2c_slave.vhd erneut kompiliert und erhalte folgenden Fehlereport: ispLEVER Auto-Make Log File --------------------------- Updating: Synplify Synthesize VHDL File Start to record tcl script... Finished recording TCL script. Starting: 'C:\ispTOOLS4_2\ispcpld\bin\Synpwrap.exe -e i2c_slave -target mach' Error output EDIF file i2c_slave.edi Error executing Synplicity VHDL/Verilog HDL Synthesizer $ Start of Compile #Tue Oct 04 21:24:35 2005 Synplicity VHDL Compiler, version Compilers 2.8.1, Build 015R, built Sep 2 2004 Copyright (C) 1994-2004, Synplicity Inc. All Rights Reserved @E: File C:\ISPTOOLS4_2\SYNPBASE\lib\vhd\math_real.vhd format not supported (encrypted ?) @END Process took 0h:0m:0s realtime, 0h:0m:0s cputime Done: failed with exit code: 0100. Wo liegt hier der Hund begraben? Gruss Helmuth
@Timo Deine Bem. zur Funktion werde ich prüfen, dauert aber noch da ich momentan wenig Zeit habe. Quartus 4.2 müsste die Synthese hinbekommen, allerdings sollten dafür nur die 2 Files i2c_slave.vhd i2c_syn_pkg.vhd verwendet werden. Die restlichen Files sind nur für die Simulation notwendig. Jeder Simulator müsste das math_real-package kennen. Ich arbeite derzeit nur mit ModelSim ALTERA, V 6.0c, damit gibts kaum Probleme. @Helmuth habe Deine Tools nicht zur Verfügung, aber wie gesagt, für die Synthese wird das math_real nicht benötigt! Habe extra 2 Packages gemacht, damit es keinen Ärger damit gibt. Ich habe im Modelsim ein Projekt, wo alle Files eingebunden sind, für die Synthese mit Quartus II werden nur 2 Files ins Projekt eingebunden (s.o.), die letzte Zeile nach der Synthese im Quartus II sieht so aus: Info: Quartus II Full Compilation was successful. 0 errors, 5 warnings
Hallo FPGA-User! Vielen Dank fuer den I2C core! Er hat mir, als absoluten VHDL Anfaenger, sehr geholfen. Ich habe ihn versuchsweise auf einen Spartan II board synthetisiert und getestet. Hier meine Beobachtungen (weiss leider nicht ob die Probleme im Code sind oder bei mir liegen - dazu muss ich mich noch etwas mehr einarbeiten): * Die ersten 2-3 Zugriffe funktionieren bei mir nicht richtig (Abwechselnd lesend und schreibend). Entweder bekomme ich kein ACK vom Slave oder die Daten sind falsch (getested via mini-loopback code). * Dannach funktioniert der Core fehlerfrei (Hab ca. 1 Million R/W Zugriffe mit random Daten probiert) * Auf beim Verschachtelten Zugriff auf ein anderes I2C device am gleichen Bus traten keine Fehler auf. Was mir noch fehlt ist eine Moeglichkeit festzugestellen ob das gerade gelesen Byte das erste nach einer I2C Startsequenz war oder ein spaeteres (fuer die logische Adressierung im Device). Werd mal versuchen sowas im Code einzubauen - sozusagen als VHDL Uebung;-) Viele Gruesse Josef
Ich möchte gerne die Programme von FPGA-User verstehen, kann mir jemand die Signale beschreiben oder definieren hat jemanden eine seite wo ich mehr erfahre über I2c slave Interface,
Falscher Ansatz: Beschreibe, die Signale Du schon verstehst, stelle konkrete Fragen zu Signalen, die Du nicht verstehst, und bitte um Ergaenzung/Berichtignung.
Hi FPGA user, Thanks for the I2c_slave! I used in my project successfully! I did make some changes to make it work for me: - line 220: tx_empty default low. (not high) - line 267: I don't assert TX_empty always. Only when Master wants to read. This way I can use it as a handshake signal, to initiate a read into wr_buf_q (tx_data). - line 283: removed the check for tx_empty = '1' - line 431: I think a little bug with tx_data and wr_buf_q You can search for fho in the attachment. I didn't do any further extensive I2C testing (and have no plans to do so), but it works fine now. regards fop
hallo fpga user. hilfe, ich versteh nicht ganz wie/wo man die slave adresse eingestellt wird auf die der slave reagieren soll; bzw. mit welcher adresse der master den slave ansprechen kann ? Danke !!
@ hilfe im code steht: -- slv_adr : Slave-Adresse, frei konfigurierbar, 0 ... 127 -- : kann auch im laufenden Betrieb geaendert werden an dieser stelle solltest du so denk ich mal dein hex wert eintragen sprich die adresse unter der der fpga angesprochen werden soll. c.u commtel
danke für die antwort, aber das ist ja nur eine kommentarzeile oder ? außerdem wird slv_adr als IN vom TYPE SLV_ADR_TYPE eingelesen, also muss die adresse ja von irgendwo eingelesen werden in der ausskommentierten zeile kanns nicht sein dankeschön in voraus !
OK, inzwischen ist der Code schon alt, aber in der State-Machine fehlt definitiv ein default-Zweig...wir wollen ja keine Latches bauen!
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.