CPLD asyncron betreiben

Hallo,

ich habe vor mit einem CPLD einen SPI Multiplexer zu bauen der noch ein bisschen mehr kann. Auf jeden Fall gibt es keinen Takt und es würde alles asyncron laufen. Gibt es da größere Probleme oder muss ich mir ausser um die Gatterlaufzeiten noch größere Gedanken machen?

Danke, Martin L.

Reply to
Martin Laabs
Loading thread data ...

Martin Laabs schrieb:

Wenn "Gatterlaufzeiten" auch Hazardvermeidung & Co einschließt (ich weiß nicht, wie klug die Designsoftware da ist), fällt mir nichts anderes ein, aber da können unsere Programmable Logic-Götter sicherlich noch was zu sagen. :-)

Gruß Henning

--
henning paul home:  http://www.geocities.com/hennichodernich
PM: henningpaul@gmx.de , ICQ: 111044613
Reply to
Henning Paul

Henning Paul schrieb:

Nicht dass ich mich da jetzt angesprochen fühle ;-) Ich sag trotzdem mal was.

SPI Multiplexer ist ja nun reichlich allgemein. Ich geh mal davon aus, du meinst ein SPI (Serial Peripherial Interface) mit Takt, Daten_rein, Daten_raus und Chip_Select. Nun, eigentlich gibts da nix zu MUXen, die chip selets sollten ihre Funktion erfüllen. Wenn du nun (aus welche Gründen auch immer) die einzelnen Slaves quasi über dem MUX isolieren willst, dann sollte das wenig Probleme machen. Der MUX ist ja im Normalfall statisch durchgeschalten. Und wenn du den MUX schaltest, sollten halt die chip selects inaktiv sein.

MfG Falk

Reply to
Falk Brunner

Ja. Ist ja eine Newsgroup und kein Supportforum ;-)

Ja.

Es sind vier SPI Slaves und die Kabel sind relativ lang und verlaufen neben Leitungen mit viel Strom der via PWM geschaltet wird. Da will ich verhindern, dass ich auf einen Kanal noch die Störungen von den drei anderen bekomme. Aussderm sollen die anderen Slaves auch noch funktionieren wenn einer sich verabschiedet hat. Und dann macht der CPLD auch noch die 3.3V zu

5V Umsetzung. (Und so ein CPLD hat stärkere Treiber als so ein kleiner uC)

Das ist eine gute Idee, das werde ich noch fix implementieren.

Danke Martin L.

Reply to
Martin Laabs

Martin Laabs schrieb:

Hmm.. Klingt nicht grade danach als hätte man sich Gedanken über Störabstände gemacht. Für solche Anwendungen gibt es Feldbus-Standards, zumindest was die Hardwareebene betrifft. Ein Daten-Signal asymmeetrisch auf 5V-Pegel über lange Distanzen in gestörter Umgebung zu betreiben, halte ich für Bastelei. Wie soll denn die Masse geführt werden?

- Udo

Reply to
Udo Piechottka

Es sind 30cm mit einem Flachbandkabel. Ist nicht so schlimm, dass sich ein höherer Aufwand lohnt.

Tschüss Martin L.

Reply to
Martin Laabs

Hallo Martin,

ich weiß jetzt zwar über SPI nicht Bescheid, aber Daten über 30 cm Flachbandkabel zu schicken, könnte evtl. schon Nebensprechen und Überschwinger hervorrufen, ich erinnere mich an so einen Fall des Anschlusses eines Codec-Boards an den seriellen Anschluß eines DSP.

Einfachste Maßnahme wäre hier, die Leitungen abwechselnd mit Daten und Masse zu belegen, dann ist auch eine definierter unsymmetrischer Wellenwiderstand vorhanden.

Falls das alles nichts nützt und im CPLD genug Platz ist, so hätte ich im Falle eines asynchronen Schaltwerks noch die Möglichkeit, die Signale mit einem digitalen "Deglitcher" von Spikes und Prellen zu säubern. Bei Interesse könnte ich die Schaltung malen, sie funktioniert in der Praxis hervorragend.

mfg. Winfried

Reply to
Winfried Salomon

SPI und Flachbandkabel ist heikel. Z.B. der ADS8344 sieht leicht irgendwelche Reflexionen an SCK und verhaspelt sich dann. Passiert, wenn an dem Flachbandkabel mehrere Abgriffe sind. Der Deglitcher ist da eine gute Idee.

Jetzt setzt ich die Signale auf RS422 Pegel um.

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

Hallo Uwe,

zuerst sollte man natürlich auf der analogen Seite alles tun, um Störungen zu vermeiden. Ich hatte mal anläßlich von SCSI-Problemen eine Simulation des SCSI-Busses meines Rechners hier gemacht, da ging es auch um Abstände von Geräten, Reflexionen, Einfluß der Terminierung und so. Da konnte man schon sehen, wie es auf dem Flachbandkabel zuging, recht grenzwertig. Daß es trotzdem funktioniert, ist fast ein Wunder :-).

Für alle die es interessiert, hier ist ein Deglitcher, wie er sich bei mir mehrmals bewährt hat, Zeilenumbruch bitte auf 85 umstellen, hab das jetzt nicht anders hingekriegt.

---------------------------------------------------- | ________ | | | | | --| | | | EXOR |-------- | --| | | | | |________| | | | | | | | _______ | | | | | | Out ----------------------------------------------------------|D Q|--o----o | | | | D-FF | | | | --|C | | | | | |_______| | | | | | | | | | | | ______ | | | -----| | | | | | AND |---- | | -----|______| | | | | | | | | | | | | | Delay-Line | ________ | In | _______ | | NOT | | o----o----|_______|---o--| | | | | EXOR |o------- |___________________| | |________|

Die Delay-Line besteht hier aus mehreren Buffern oder so, die gegen Wegoptimieren gesperrt sein müssen. Mit dem Delay wird die maximale Länge des Prellens oder Glitches eingestellt, sinnvollerweise kommt man da auf höchstens 100 nS. In der Praxis kann ich schon mit 4 Buffern oder Invertern Wirkung erzielen bei CPLDs, bei FPGAs sind die Gatterlaufzeiten jedoch deutlich kürzer. Man kann das auch in VHDL programmieren, wobei jedoch VHDL IMHO keine Laufzeitvorgaben erlaubt, man muß dann eben die Buffer so eingeben.

Falls man nicht grade den Takt selbst "deglitcht", kann man die Delay-Line auch durch eine Schieberegisterkette ersetzen und entsprechend die Daten synchron getaktet weitergeben. Das habe ich jedoch noch nicht ausprobiert.

Wenn ich es mir so überlege, müßte man nach dem Prinzip eigentlich sogar metastabile Zustände drastisch reduzieren können, wenn man den Delay größer als das Wahrscheinlichkeitsfenster macht. Das ist jetzt aber nur so eine Idee, über die ich nicht weiter nachgedacht habe.

Der Nachteil des Verfahrens ist, daß die Signale mit der Laufzeit der Delay-Line verzögert werden, aber mir ist keine andere Lösung bekannt bzw. bin ich fast sicher, daß es nicht anders geht.

mfg. Winfried

Reply to
Winfried Salomon

Winfried Salomon schrieb:

Jaja, so ist es mit der Weihnachtsbastelei... kurz vorm Fest geht alles dann trotzdem irgendwie doch noch.

U.P.

Reply to
Udo Piechottka

Hallo Udo,

wobei ich nur die Verhältnisse innerhalb eines handelsüblichen IBM-PCs simuliert hatte. Das Problem hier war das externe ZIP-Laufwerk, das den ganzen SCSI-Bus gestört hatte. Das lag aber am externen Rundkabel, die Weihnachtsbastelei kann man wohl eher IOMEGA zuschreiben :-).

mfg. Winfried

Reply to
Winfried Salomon

Uwe Bonnes schrieb:

Naja, es gibt auch "Experten", die normale LCDs am Flachbandkabel zum Nichtfunktionieren bringen.

Gewusst wie. Wer den Takt nicht ehrt, ist die Funktion nicht wert.

Ich würde mal einfach mir gescheiter Terminierung und Masseführung anfangen. Wirk oft Wunder. Deglitcher ist nur der Rettungsanker für Murksdesign.

MfG Falk

Reply to
Falk Brunner

Winfried Salomon schrieb:

Und was macht dich so sicher, dass deine Simulation nicht arg akademischer Firlefanz war? Will sagen, wie sah es mit dem VErgleich Simulation-Realität aus?

MfG Falk

Reply to
Falk Brunner

Hallo Falk,

liegt schon etwas zurück, es ging nur um eine Abschätzung, wie nahe ich an einem Limit liege, wenn ich die Spezifikation verletze. Das externe terminierte ZIP-Laufwerk funktionierte nur, wenn der Controller terminiert war, und auf der anderen Seite vom Controller war noch eine termimierte Festplatte. Also war 1 Terminierung am Controller zuviel und ich wollte wissen warum es trotzdem funktioniert. Wie gut das Modell war weiß ich nicht, nachmessen konnte ich das nicht. Simulation als akademischen Firlefanz zu bezeichenen finde ich auch stark überzogen, schließlich kommt man meßtechnisch an die meisten Sachen nicht ran und es soll ja möglichst auf Anhieb funktionieren.

Die Störproblematik halte ich für besonders schwierig, als die ersten Boardcomputer bei Autos aufkamen, sind diese dann in der Nähe starker Rundfunksender liegengeblieben, hab ich mal gelesen. So auf Anhieb scheint man das also nicht in den Griff zu bekommen.

mfg. Winfried

Reply to
Winfried Salomon

Winfried Salomon schrieb:

HALT!!!! DAS HABE ICH KEINEESWEG GESAGT! BITTE MAL GENAU LESEN!

Ich sagte (und meinte), dass man Simulation auch so machen kann, dass sie mit der Realität nix mehr zu tun hat. Quasi nur im Elfenbeinturm wohnt. Man kann Simulation natürlich auch gut machen, und hat dann brauchbare bis sehr gute Vorhersagen/Erklärungen für die reale Welt.

Sicher. Aber Simulation muss immer wieder mit der Realität verglichen werden. Simulation alleine ist sinnlos.

Wär ja langweilig. Und viele Entwickler arbeitslos.

MfG Falk

Reply to
Falk Brunner

Hallo Falk,

Huch, war schon etwas spät als ich das schrieb ;-).

Wenn ich an die Herstellermodelle für SPICE denke, so gibt es da große Unterschiede. Viele berücksichtigen z.B. bei OPs nur 1 dominanten Pol, sodaß man sich über einen schwingenden Aufbau wundern kann. Bei den guten Modellen wiederum hat man mit Konvergenzproblemen zu kämpfen, die manchmal sehr schwer zu beheben sind. Irgendwo hat man eben Grenzen beim Einsatz von Rechnern und wenn man glaubt, jedes Problem per Knopfdruck vom Rechner lösen lassen zu können, so wird man was anderes erleben.

Sich mit den Einflüssen von Layouts und gekoppelten Leitungen zu beschäftigen, ist glaube ich nicht so einfach, habe da schon Pferde kotzen sehen. Bei dem erwähnten seriellen DSP-Bus trat damals das Problem auf, daß beim Anschluß eines Logikanalyzers an das Flachbandkabel die Übertragung gestört wurde, soweit ich mich erinnere. Da der Takt ich glaube da mit rüberging, war auf der Empfängerseite alles gestört.

Vor einigen Tagen waren welche bei mir mit einem selbstgebauten Flasher für uCs über die parallele Schnittstelle vom Rechner, der nicht ging. Ich habe denen gesagt, wenn es nicht an der Software liegt, sollen die erstmal das Flachbandkabel vernünftig machen. Die meinen alle, es wäre so einfach, kommen mit GALs zum Brennen zu mir in der Hand ohne ESD-Verpackung transportiert und wundern sich, daß die durchgeschlagen sind.

mfg. Winfried

Reply to
Winfried Salomon

Winfried Salomon schrieb:

Sagte ich das nicht? Simulation ist gut und wichtigt (wenn sie richtig gemacht wird). Aber nicht alles.

Mag sein. Ich bin aber gegen Legendenbildung. Urban Legends gibts schon mehr als genug.

Ja und? Probing ist bei High speed problematisch, aber nicht unmöglich. Konw-How.

Shit happens.

MfG Falk

Reply to
Falk Brunner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.