I2C Master -> Beispielimplementierung

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

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.

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"

Welchen der beiden sollte man denn nun nehmen?

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.!