Schnittstelle CPLD <-> Atmega

[Andy M. (andz)]

Hallo,

ich arbeite derzeit an meiner Bachelorarbet und bräuchte eine kleine 
Ideen-Hilfestellung von euch.

Hat jemand eine Idee welches Protokoll am besten für den Datenaustausch 
zwischen einem CPLD (MaxII) und µC (Atmega32) wäre. Verbunden sind Sie 
über einen 8-Bit Breiten Bus (gehen am Atmega auf PortD), der PortPin 
PC7 (CLK0) geht zusätlich an einen CLK-Eingang des CPLD, also synchrone 
Datenübertragung möglich. Am PB4 (PCINT4) ist vorgesehen das der CPLD 
einen Interrupt auslösen kann.

Standardmäßig soll die kommunikation vom Atmega als Master ausgehen, 
also er Sendet Daten an den CPLD um z.B das Steuerwerk zu setzen, der 
CPLD soll dann z.b  Daten aus einem angeschlossenen RAM oder aus 
internen Registern bzw. UFM an den Atmega zurückschicken. Auch soll der 
CPLD den Atmega zum Auslesen eines Statusregisters anstoßen (quasi 
"Hallo, ich schick dir nen Interrupt guck mal in meinem Statusregister 
was los is").

Meine Frage nun: Kennt jemand ein Protokoll welches auf diese Weise 
arbeitet? Mein Hauptproblem ist momentan die Bidirektionalität, also 
woher weis z.B. der CPLD das er seinen Tristate auf Senden stellen darf 
ohne eine ENABLE vom µC Leitung...

Danke

Gruß
AndZ

[Schrotty (Gast)]

SPI

[Andy M. (andz)]

Schrotty schrieb:
> SPI

SPI vom Atmega ist schon belegt...
Oder meinst du eine art Parallele Version davon? Also quasi PPI?

[Schrotty (Gast)]

Falls dein SPI-Port mit einem SPI-Slave belegt ist, kannst du auch 
mehrere SPI-Slaves in "Reihe" schalten.
Alternativ kannst du natürlich auch einen SPI-Port in SW mit ganz 
normalen IO-Pins "nachbilden"

[Andy M. (andz)]

Schrotty schrieb:
> Falls dein SPI-Port mit einem SPI-Slave belegt ist, kannst du auch
> mehrere SPI-Slaves in "Reihe" schalten.
> Alternativ kannst du natürlich auch einen SPI-Port in SW mit ganz
> normalen IO-Pins "nachbilden"

OK, danke...also wenn dann "nachbilden", weil die Verdrahtung zwischen 
den beiden ist Fix, also ich hab nur die oben genannten Verbindungen. 
Zwar ne Verschwendung der schönen 8 Datenleitungen, aber vermutlich 
erstmal die einfachste möglichkeit.

[Klaus F. (kfalser)]

Einfachere Alternative : Paralleler Bus 4 Bit breit

1 x Clock (optional)
1 x Read/Write
1 x high/low Nibble selektor
1 x Data/Address Selektor
4 x Data

Dazu überlegst Du dir ein einfaches Timing, z.B. Datenübername bei 
abfallender oder steigender Flanke Clock.

Mit Data/Address = '1' wird ein Address-Register beschrieben, mit dem 
man das zu lesende/schreibende Register selektiert.
Danach wird mit Data/Address = 0 auf das Register selbst zugegriffen.

Ist auf einem CPLD vielleicht einfacher zu implementieren als ein SPI 
Interface. Du musst ja nicht nur das SPI interface implementieren, 
sondern danach die Daten in die entsprechenden Register bringen.

[Schrotty (Gast)]

@Klaus:

Auch ne schöne Lösung :-)

[Andy M. (andz)]

Danke Klaus...sehr gute idee...werd ich mich gleich mal ranmachen...die 
idee mit dem getrennten Daten/Adresselektor is echt gut...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> SPI vom Atmega ist schon belegt...
Häh, du kannst an den SPI mehrere Slaves anschliessen, das weißt du 
schon?
Du brauchst dazu nur 1 zusätzliches Slave-Select: 
http://www.lothar-miller.de/s9y/categories/17-SPI

[Andy M. (andz)]

Lothar Miller schrieb:
>> SPI vom Atmega ist schon belegt...
> Häh, du kannst an den SPI mehrere Slaves anschliessen, das weißt du
> schon?
> Du brauchst dazu nur 1 zusätzliches Slave-Select:
> http://www.lothar-miller.de/s9y/categories/17-SPI

Jo schon klar...aber der Atmega is in dem Fall der Slave...Ausserdem ist 
wie gesagt die Verdrahtung schon Fix...

[Andy M. (andz)]

Hm...also soweit hab ich das konzept mal durchdacht, aber ein kleines 
Problem habe ich noch:

Mein System arbeitet mit 100MHz, also die Register und der Bus arbeiten 
mit diesem Takt. Wenn jetz ne Anfrage vom Atmega kommt und dieser dann 
die Register mit seinem eigenen Takt abfrägt wird es ja vermutlich 
krachen wegen der unterschiedlichen Taktdomänen...

Die einzige (auf einem CPLD ohne Blockram um einen FiFo zu bauen) 
realiserbare Möglichkeit die mir hier einfällt ist, dass der Atmega voll 
die Kontrolle über den CPLD übernimmt während der Abfrage, also der 
Globale Takt, welcher normal eben die 100MHz hat, wird auf den Takt 
welcher vom Atmega kommt umgeschaltet, so dass es immer nur eine 
Taktdomäne geben kann. Oder habe ich was übersehen.

Danke.

[Klaus F. (kfalser)]

Andy Müller schrieb:
> Die einzige (auf einem CPLD ohne Blockram um einen FiFo zu bauen)
> realiserbare Möglichkeit die mir hier einfällt ist, dass der Atmega voll
> die Kontrolle über den CPLD übernimmt während der Abfrage, also der
> Globale Takt, welcher normal eben die 100MHz hat, wird auf den Takt
> welcher vom Atmega kommt umgeschaltet, so dass es immer nur eine
> Taktdomäne geben kann. Oder habe ich was übersehen.

Nein, das solltest Du wirklich nicht.
Eine Umschaltung des Taktes ist das schlechteste, das man machen kann.
Wenn eine Anfrage vom µC kommt, dann wird das einsynchronisiert und der 
aktuelle Wert wird in ein Zwischenregister gespeichert.
Die Schnittstelle zum Atmega kann diesen Wert dann in aller Ruhe 
auslesen.

[Andy M. (andz)]

HmHmHm...einsynchronisieren ist auf jedenfall mal n guter plan...langsam 
gehn mir die FlipFlops in meinem CPLD aus ;-)
Also da Problem ist folgendermaßen:
Ich habe 2 Register (Statusregister und Steuerregister), wobei das 
Statusregister eigentlich nur lesenden zugriff braucht, das 
steuerregeister evtl nur schriebenden. Und einen 16 Bit breiten Datenbus 
auf den nur lesend zugegriffen wird.

Im "normalbetrieb", also wenn der Atmega nicht eingreift, werden daten 
im 100MHz Takt über den Datenbus zwischen einer Schnittstelle und einem 
externen RAM hin- und hergeschaufelt. Intern gibt es noch einen 
Adresszähler für den RAM und das ganze wird über ein Steuerwerk 
gesteuert.

Wenn der Atmega nun ins spiel kommt, so übernimmt er die kontrolle über 
das Steuerwerk (durch das Statusregister) und ist dann hauptsächlich 
damit beschäftigt über den Datenbus den RAM auszulesen.

Wir hatten an der Uni mal ein Projekt wo wir ein ähnliches Problem 
hatten. Da haben wir auch einen Datenbus im Fullspeed betrieben (50MHz) 
und bei bedarf konnte man über die serielle Schnittstelle "mitlauschen". 
Dazu haben wir die Kontrolle des Taktes der seriellen Schnittstelle 
überlassen. Das umstellen des Taktes hat eigentlich keine Probleme 
verursacht.

Ich dachete immer das schlimmste was man machen kann sin 2 Taktdomänen. 
Also was ist schlimm am Umschalten des Taktes (wenn man z.b. vorher die 
Flanken synchronisiert).