Hallo! Kann jemand einen einfachen I2C Master in VHDL empfehlen der Herstellerübergreifend funktioniert? Google und die Forumsuche haben mir leider nicht weitergeholfen. Viele Grüße, hhanff
Habe ich gesehen. Aber hier fehlt die Doku: http://opencores.org/project,i2c_master_slave Und der Rest ist Verilog...
Schau dir mal den hier an, der ist VHDL und auch gut dokumentiert. Hat zwar ein WB interface aber darüber kann man ruckzuck einen wrapper bauen. http://opencores.com/project,i2c
Vega schrieb: > http://opencores.com/project,i2c Das Ding ist bei mir im Einsatz und funktioniert wunderbar (bis jetzt :-)) Duke
Vega schrieb: > Schau dir mal den hier an, der ist VHDL und auch gut dokumentiert. Hat > zwar ein WB interface aber darüber kann man ruckzuck einen wrapper > bauen. > > http://opencores.com/project,i2c OK. Hatte ich nicht gesehen, weil das Projekt mit "Verilog" getaggt ist... Gucke ich mir mal an. Danke an alle und schönen Start ins WE!
Hallo, könnte vielleicht jemand die Beispielcores hier hochladen. Hab mich grad registriert, des braucht aber 1-2 Tage. Vielen Dank im vorraus !
Andi schrieb: > Hallo, > > könnte vielleicht jemand die Beispielcores hier hochladen. Hab mich grad > registriert, des braucht aber 1-2 Tage. > > Vielen Dank im vorraus ! Diese cores sind nicht umfangreich, mach einfach c&p aus der Browser Ansicht.
Schafft der auch mehr, als die 1MBit, z.b. den Ultra Fast Mode mit 5MBit?
Frank P. schrieb: > Schafft der auch mehr, als die 1MBit, z.b. den Ultra Fast Mode mit > 5MBit? UFm I2C ist im Grunde ein eigenes Protocol, es macht keinen IMO Sinn das in einem normalen I2C Core mit zu unterstützen. Genau betrachtet ist es sogar viel einfacher zu implementieren. Aus der Spec The UFm I2C-bus is a 2-wire push-pull serial bus that operates from DC to 5 MHz transmitting data in one direction. It is most useful for speeds greater than 1 MHz to drive LED controllers and other devices that do not need feedback.
Ich benötige auch einen I2C (ADC-Chip) und hatte schon angefangen, mir selber einen zu schreiben. Da stiess ich auf dieses Posting: Duke Scarring schrieb: > Vega schrieb: >> http://opencores.com/project,i2c > Das Ding ist bei mir im Einsatz und funktioniert wunderbar (bis jetzt > :-)) > Duke Das klingt ja prima. Was hast Du alles geändert, bzw von welchen Sourcen bist Du ausgegangen? In dem Repository gibt es ja eigentlich 3 Gruppen: - die Verilog (4x) - die VHDL (3x) - die VHDL für den DallasChip (2x) Meine Erfahrungen bisher: Ich habe die Source importiert und bekomme Probleme mit den .v files, weil ein include file fehlt. Woher bekomme ich das? Ist das dabei? * Bei Nutzung der VHDL files, fehlt in einem source code das include auf die Numeric.lib, er findet sonst kein unsigned. Das lief also schon mal nicht. * nach Import in ISE erscheinen 3 achitectures aus 2 files, vermulich weil in einem ein Codestück als package mitdefiniert ist. Unsauber aber es geht wohl. * Nach Compilation in XST werden mehrere Signale als in der Sensitvity liste fehlend angemeckert und mussten nachgetragen werden. Das als "stable" zu bezeichnen ist sehr gewagt, finde ich.
Bastler schrieb: > > Ich habe die Source importiert und bekomme Probleme mit den .v files, > weil ein include file fehlt. Woher bekomme ich das? Ist das dabei? > In XST den Verilog Include Pfad richtig gesetzt?
Keine Ahnung wie ich das machen muss, aber ich brauche ja erstmal das file selber. Ist zunächst auch egal, da ich mit den VHDls weiterarbeiten will. Diese habe ich nur unverändert in ModelSIM eingetragen und kann sie complieren. Beim Starten der Simulation kommt: Loading work.i2c_master_byte_ctrl(structural) # ** Failure: (vsim-3807) Types do not match between component and entity for port "clk_cnt". # Time: 0 ns Iteration: 0 Instance: /i2c_master_top/byte_ctrl File: nofile Line: UNKNOWN # Loading work.i2c_master_bit_ctrl(structural) # ** Failure: (vsim-3807) Types do not match between component and entity for port "clk_cnt". # Time: 0 ns Iteration: 0 Instance: /i2c_master_top/byte_ctrl/bit_ctrl File: nofile Line: UNKNOWN # Fatal error at a source-protected location Ich habe mir die Sourcen angesehen, finde aber ad hoc den Fehler nicht. Irgendwo meine ich mal gesehen zu haben, dass in einer entity irgendwas mit clock_cnt gemacht wird. In jedem Fall sind die sourcen so nicht i.O. und sicher nicht simuliert worden. @Duke Scarring: Hast du etwas an den Sourcen gemacht? Benutzt du Testbenches?
Bastler schrieb: > Keine Ahnung wie ich das machen muss, aber ich brauche ja erstmal das > file selber. Ist zunächst auch egal, da ich mit den VHDls weiterarbeiten > will. Die Files sind da:
1 | // synopsys translate_off |
2 | `include "timescale.v" |
3 | // synopsys translate_on |
4 | |
5 | `include "i2c_master_defines.v" |
Wo man das in XST einstellt weiss ich leider nicht. > > Diese habe ich nur unverändert in ModelSIM eingetragen und kann sie > complieren. Beim Starten der Simulation kommt: > > Loading work.i2c_master_byte_ctrl(structural) > # ** Failure: (vsim-3807) Types do not match between component and > entity for port "clk_cnt". > # Time: 0 ns Iteration: 0 Instance: /i2c_master_top/byte_ctrl File: > nofile Line: UNKNOWN > # Loading work.i2c_master_bit_ctrl(structural) > # ** Failure: (vsim-3807) Types do not match between component and > entity for port "clk_cnt". > # Time: 0 ns Iteration: 0 Instance: > /i2c_master_top/byte_ctrl/bit_ctrl File: nofile Line: UNKNOWN > # Fatal error at a source-protected location > > Ich habe mir die Sourcen angesehen, finde aber ad hoc den Fehler nicht. > Irgendwo meine ich mal gesehen zu haben, dass in einer entity irgendwas > mit clock_cnt gemacht wird. > Im readme steht dass man auf dir Reigenfolge achten muss
1 | The i2c_master core consists of three files: |
2 | |
3 | - i2c_master_top -- top level |
4 | - i2c_master_byte_ctrl -- byte controller |
5 | - i2c_master_bit_ctrl -- bit controller |
6 | |
7 | VHDL needs to be compiled in order. The files are listed |
8 | above in descending order. |
Vielleicht liegt es ja daran.
ISIM meckert auch. Der CLLK_CNT ist als unsigend definiert, verträgt sich aber nicht mit einem Komponenten-Port. Ist das so? Oder ist das gfs in einer neueren VHDL-SPEC so und deshalb nicht aufgefallen, weil es mal erlaubt war? Ich denke, ich schreibe lieber am eigenen Core weiter, WB brauche ich ohnehin nicht.
Bastler schrieb: > > Ich denke, ich schreibe lieber am eigenen Core weiter, WB brauche ich > ohnehin nicht. Wenn man den core aus einer FSM benutzen möchte, ist ein Businterface ala WB ohnehin eher hinderlich.
Den I2C Core von OpenCores hatte ich mir auch schon angetan. Da scheint wohl einiges nicht so ganz ausgegoren. Bastler schrieb: > Das als "stable" zu bezeichnen ist sehr gewagt, finde ich. Noch gewagter finde ich die Bemerkung "ASIC prooven" denn dazu gehören Testbenches. Die sind aber zumindest bei den VHDL-Sourcen dabei. Ein sauber dokumentiertes und vollständiges Projekt sieht bei uns anders aus. Da schaut die QM drauf und ich als PL auch. Wenn mir einer der Entwickler sowas abliefern würde, bekäme er die rote Karte. Bei uns werden nur vollständige Projekte mit konsitentem Stand, Dokumentation und Testbenches eingecheckt. Ich gehe hier davon aus, dass er im Wesentlichen die Verilogversionen nutzt und geprüft hat und das VHDL nur eine Dreingabe ist. Ein Blick auf die v-Sourcen offenbart aber auch nicht gerade das, was ich strukturiertes Programmieren nenne. Aber so sind halt die Amis: Schnell schnell was hingezimmert, auf OPENCORES hochgeladen und dann abgedüst. So hat man ein schönes Referenzprojekt zum Bewerben. Aber wehe, es schaut sich das jemand aus einer Branche an, in der es um sicherheitskritische Themen oder um die Anforderungen ausreichender Tests und Dokumentation geht. Solche Hurri Durri Sachen sind da nicht gefragt. Das ist eben OPENCORES: Bastelprojekte für Bastler :-)
Thomas Ulrich schrieb: > Aber so sind halt die Amis: Schnell schnell was hingezimmert, auf > OPENCORES hochgeladen und dann abgedüst. Eine solche Aussage zeugt allerdings auch nicht gerade von Kompetenz, im Gegenteil. Der Author des diskutierten Opencore-Projekts ist weder Ami, noch ist er abgedüst.
Gut ich hätte wohl schreiben wollen und sollen "angloamerikanische Projektvorgehensweise" denn ungeachtet der tatsächlichen Nationalität, entspricht es eben genau dem Muster. Zu dem Punkt des unvollständigen Projektes stehe ich nach wie vor, wenn Wesentliches fehlt und sich nichts tut. Unter anderem ist ja wohl ein Wishbone-IF implementiert, im tagging steht aber noch ausdrücklich "WishBone Compliant: No". Und warum es (nur) als Verilog getagged ist, dürfte inzwischen klar sein. Jetzt werden viele sagen "Ist doch besser, als nichts und dafür ist es kostenlos" und einem geschenkten Core schaut man nicht auf die Bits. Aber ich sehe es anders: Entweder was Richtiges oder garnicht. Und die Sachen, die nur halb sind und nicht gepflegt, muss man lieber garnicht hochladen, sondern dann, wenn sie fertig sind. Dies ist es, was ich mit abgedüst meinte.
Thomas Ulrich schrieb: > Zu dem Punkt des unvollständigen Projektes stehe ich nach wie vor, wenn > Wesentliches fehlt und sich nichts tut. Unter anderem ist ja wohl ein > Wishbone-IF implementiert, im tagging steht aber noch ausdrücklich > "WishBone Compliant: No". Ich sehe da "WishBone Compliant: Yes". Auch dass sich da nichts tut, ist falsch. Der Bugtracker wird aktiv bearbeitet.
Angehängte Dateien:
-
ic2core.gif
91 KB
Interessant. Sprechen wir etwas von 2 verschiedenen Projekten: Bei "meinem" steht "NO".
Thomas Ulrich schrieb: > Interessant. Sprechen wir etwas von 2 verschiedenen Projekten: Bei > "meinem" steht "NO". Bei deinem steht aber auch VHDL! und es ist auch nur VHDL enthalten. Die ganze Diskussion ging um diesen hier: http://opencores.com/project,i2c Verlinkt zuerst von Vega Beitrag "Re: I2C Master -> Beispielimplementierung"
Heinrich H. schrieb: > Kann jemand einen einfachen I2C Master in VHDL empfehlen der > Herstellerübergreifend funktioniert? Ich muss zugeben das ich auch lange gesucht habe um einen Core zu finden. Die Opencores waren mir deutlich zu komplex für meine Anwendungen. Momentan nutze ich diesen hier: http://www.eewiki.net/display/LOGIC/I2C+Master+%28VHDL%29 Gruß
Der ist aber gegenüber dem anderen eingeschränkt, kann z.B. keine 10 bit und ist auch nicht MM-fähig. Trotzdem Danke für den link. Die Seite enthält im Übrigen noch einen SPI2I2C den ich gut gebrauchen kann.
Das Ding habe Ich auch im Gebrauch gehabt, letztlich kann man sich die paar Zeilen aber auch selber schreiben. Das Aufwändige ist ohnehin die übergeordnete Steuerung, die das Ding bedient.
Hat sich schon einmal mit den Bedingungen bei OC auseinandergesetzt, um dort solche COREs für den industriellen professionellen Einsatz zu verwenden? Viele stellen aufgrund der "Bedingungen", die dort inzwischen gelten, schon nicht mal mehr was ein.!
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.