Hallo, ausgehend von einem Spartan 3E dev-board suche ich eine Möglichkeit, mir einen rel. krummen Takt zu erzeugen. Extern steht mir 50 MHz zur Verfügung. Per core-generator habe ich schon div. Varianten ausprobiert, aber mir fehlt noch die zündende Idee :( Ich möchte ein (externes) Taktsignal von z.B. 57,6 MHz erzeugen. Bei dem Wert meckert der core-generator, dass er das mit seinen 0-32 möglichen Werten nicht erzeugen kann. Das nehm ich ihm sogar ab, aber welche Möglichkeiten habe ich noch, um so einen Takt zu erzeugen (außer mir ein Tausenderpack von Quarzen zu kaufen von denen ich nur eines bräuchte)?
Naja, Du jubelst Dir Deinen Takt per DCM hoch und machst mit dem hohen Takt dann eine DDS: http://de.wikipedia.org/wiki/Direct_Digital_Synthesis Das geht natürlich auch digital, ohne DA-Wandler (einfach das MSB vom Phasen-Akku verwenden), hat aber bei Deinen Größenverhältnissen einen kräftigen Jitter.
> Ich möchte ein (externes) Taktsignal von z.B. 57,6 MHz erzeugen.
Die Konterfrage lautet: wozu?
Warum kommst du mit deinen 50MHz nicht aus?
Wie genau müssen die 57,6MHz erreicht werden?
> Naja, Du jubelst Dir Deinen Takt per DCM hoch und machst mit dem hohen > Takt dann eine DDS Hm, DDS hatte ich so abgelegt, dass das Verfahren zur Erzeugung einer beliebigen, konstanten Signalform ungleich dem Rechteck wäre, nicht aber für Rechtecksignale. Aber egal, selbst wenn ich den Accu auf 1 begrenze, erreiche ich damit (sofern ich das Prinzip verstanden habe) nur 2**n Teilverhältnisse. Selbst wenn ich die 50 MHz auf 200 oder 250 MHz aufpeppe, wüßte ich trotzdem nicht, wie ich zu Frequenzen komme, die nicht durch ganzzahlige Teiler erreicht werden können. >> Ich möchte ein (externes) Taktsignal von z.B. 57,6 MHz erzeugen. > Die Konterfrage lautet: wozu? Die 57,6 MHz waren nur ein Beispiel, es könnten auch 75.396 Hz sein. Zum einen geht es mir ums Verständnis und zum Anderen darum, eine gegebene Spezifikation einzuhalten. > Warum kommst du mit deinen 50MHz nicht aus? Weil ich nicht weiß, wie ... > Wie genau müssen die 57,6MHz erreicht werden? Nominell auf 2 Herz genau, aber praktisch natürlich mit den gleichen Toleranzen, die ein Quarz auch mitbringt (20-50ppm?) - Klar, je genauer desto besser. Ist natürlich auch eine Frage des Aufwandes. Wenn es einen Weg gibt, eine beliebige (einstellbare) Frequenz außerhalb des FPGAs mit vertretbarem Aufwand zu erreichen, wäre ich zu einer solchen Variante auch nicht abgeneigt. Ich könnte den Takt ja auch über die SMA-Buchse, oder LVDS-Leitungen zuführen.
mit DDS/NCO kannst du beliebig genaue frequenzen erzeugen, aber es bleibt der jitter, der dann maximal eine clk von dem NCO takt sind. mit hoch pumpten NCO clock ist es dann weniger aber immer da. fur S3E gibt es eine reference design, das den DCM in "clock dither" modus betreibt, da wird eine DCM mit NCO generated clock angespeist, und DCM macht den jitter weniger, such die S3E starter kit reference designs da ist es, der "frequency generator mit picoblaze" da drinne Antti
> aber praktisch natürlich mit den gleichen > Toleranzen, die ein Quarz auch mitbringt (20-50ppm?) Dann wirst du einen Quarz kaufen müssen. Nur ein Quraz hält genau die Specs eines Quarzes ein (Einschwingzeit, Rauschen...). Wenn du weißt, wo du nachgeben kannst, kannst du auch andere Lösungen suchen. > wie ich zu Frequenzen komme, die nicht durch ganzzahlige > Teiler erreicht werden können. Ganz einfach: Virtuelle 275 MHz aus 300 MHz erhältst du, indem du 11 Impulse mit 3,3333ns ausgibst, dann einen mit 6,6666ns. Das sind dann 12 Impulse auf 43,3ns. Also einer pro 3,6ns und damit eine Frequenz von 275 MHz. Aber >> es bleibt der jitter, der dann maximal eine clk von dem NCO takt sind. Und wenn du das FPGA auf 300 MHz hochprügelst, hast du einen Jitter bis zu 3,3ns, das sind bezogen auf z.B. 75 MHz knallharte 16%. Da fällt mir ein: Du hast die Frage nach dem Jitter noch nicht beantwortet.
> Dann wirst du einen Quarz kaufen müssen. Yepp - da wird es wohl darauf hinaus laufen. Ich habe mir mal eine Matrix mit den möglichen DCM-Werten bei gegebener Eingangsfrequenz gemacht. Da geht zwar einiges, aber so richtig befriedigend ist es nicht. > Du hast die Frage nach dem Jitter noch nicht beantwortet. War das in einem anderen Thread? Oder meinst Du die implizite Frage? Also die Antwort wird wahrscheinlich wie bei jedem Anfänger ausfallen: Ich hätte gern so wenig wie möglich :) Konkret erarbeite ich mir gerade einen Bustreiber für den SPI-Bus. Wenn ich davon ausgehe, dass jeder Busbenutzer andere Forderungen an den Bus hat, ist das (für mich) nicht ganz einfach unter einen Hut zu bekommen. Wenn ich davon ausgehe, dass der FPGA jeweils der Master ist, geht das ja noch halbwegs, weil der SPI-Takt dann mit dem Systemtakt zusammen hängt. Bleibt immer noch die Frage, wie ich eine geforderte Frequenz eines SPI-Slave-Chips erzeuge. Interessanter wird der Busmaster, wenn er den FPGA (auch) im Slave-Modus betreiben soll, oder für den SPI-Bus ein externer Takt verwendet wird, der keinen Bezug mehr zum Systemtakt hat. Wenn ich mir das jetzt unter dem Jitter-Aspekt anschaue, dann sollen die SPI-Signale und deren Verarbeitung/Weiterreichung mit SPI-Takt erfolgen, die Verwaltung des Busses und die Verarbeitung der parallisierten Daten mit Systemtakt des FPGA erfolgen. An irgendeiner Schnittstelle wird sich der Jitter sicher nicht vermeiden lassen. Bleibt für mich die Frage, ob die Integrität der Daten darunter zu leiden hat. Schließlich soll der Rest des FPGA ja mit seinem "normalen" Systemtakt laufen.
> Oder meinst Du die implizite Frage? ACK. Die war dort versteckt: >> Wie genau müssen die 57,6MHz erreicht werden? > Also die Antwort wird wahrscheinlich wie bei jedem Anfänger ausfallen: > Ich hätte gern so wenig wie möglich :) Bitte Zeit- und Toleranzangaben nicht qualitativ (schnell, klein, kurz, lang...) sondern gleich quantitativ. > Bleibt immer noch die Frage, wie ich eine geforderte Frequenz > eines SPI-Slave-Chips erzeuge. Du kannst alle mir bekannten SPI-Slaves auch langsamer als mit der maximalen Taktfrequenz anfahren. > Interessanter wird der Busmaster, wenn er den FPGA (auch) im Slave-Modus > betreiben soll, oder für den SPI-Bus ein externer Takt verwendet wird, > der keinen Bezug mehr zum Systemtakt hat. Das ist doch komfortabel: dann bekommst du den SPI-Takt von aussen angelegt. Und du musst nur die Daten mit diesem Takt in dein FPGA einschieben und dann über den Slave-Select auf deinen FPGA-Takt übernehmen. Ganz einfach: SPI sind gekoppelte Schieberegister. Zur Synchronistation auf Bitebene wird der Takt hergenommen. Und zur Synchronisation der Datenübertragung auf Byte- oder Wortebene wird der Slave-Select verwendet. > Bleibt für mich die Frage, ob die Integrität der Daten darunter zu > leiden hat. Die Integrität der Daten darf nicht leiden, schon gar nicht bei einem so simplen Bus wie SPI, der über keinerlei eigenständige Fehlerkorrektur verfügt. Also bist du selber für die Zuverlässigkeit deiner Daten verantwortlich. > oder für den SPI-Bus ein externer Takt verwendet wird Es wird nicht irgenein Takt von irgendwoher verwendet. Der Master macht den Takt. Sieh dir mal das an: http://www.lothar-miller.de/s9y/categories/17-SPI http://www.lothar-miller.de/s9y/categories/26-SPI-Slave http://www.lothar-miller.de/s9y/categories/45-SPI-Master > dass jeder Busbenutzer andere Forderungen an den Bus > hat, ist das (für mich) nicht ganz einfach unter einen Hut zu bekommen. Das wirst du sowieso niemals. Es gibt ja auch nicht den einen Mikrocontroller. Sondern jeder kann etwas besser, schwächelt dafür an einer anderen Stelle. BTW: Urig, dass du auf die wichtigste Frage keine Antwort gefunden hast: >> Warum kommst du mit deinen 50MHz nicht aus? > Weil ich nicht weiß, wie ...
>> Also die Antwort wird wahrscheinlich wie bei jedem Anfänger ausfallen: >> Ich hätte gern so wenig wie möglich :) > Bitte Zeit- und Toleranzangaben nicht qualitativ (schnell, klein, kurz, > lang...) sondern gleich quantitativ. Nun, bei der Frequenz hatte ich doch quantitativ geantwortet. Auf 2 Herz genau - wenn ich das bei 100 Mhz umsetzen würde, wäre das eine Genauigkeit von 0,00002 Promille - also völlig utopisch. Deshalb habe ich geschrieben, es sollte der Genauigkeit von Quarzen entsprechen. 100ppm dürfte dort wohl "normal" sein, 20ppm sind dann wohl die besseren. > Du kannst alle mir bekannten SPI-Slaves auch langsamer als mit der > maximalen Taktfrequenz anfahren. Logisch! - Aber wenn man gewisse Protokolle fahren will, gibt es dort spezielle Vorgaben. Nur um mal ein Beispiel zu nennen: Bei ner CD sind 44.100 KHz Standard. Ich weiß nicht, ob man hören kann, wenn eine CD mit 44.105 oder 44.095 kHz abgetastet wird - jedenfalls wäre es schon nominell nicht mehr konform. Die Fehler der ganzen Signalkette kommen ja noch dazu - es ist eher unwahrscheinlich, dass sich Fehler gegenseitig aufheben. Genauso ist es ja auch mit den 12,5 MHz von Ethernet. Keine Ahnung, wie dort die Toleranzen sind, aber wenn man nicht versucht, den nominell geforderten Wert zu erreichen, kann man seine Arbeit nicht als "standardkonform" bezeichnen. Mir ist schon klar, dass ich solange ich mich innerhalb des Entwicklungsboards befinde, mich einen feuchten um Standards kümmern kann. Das sieht aber anders aus, wenn ich Anschluss suche und/oder meine Daten anderweitig verwenden will. Allerdings ist mir auch bewusst, dass selbst wenn ich eine Frequenz auf die letzte Stelle exakt produzieren könnte immer noch die Toleranz des Quarzes reinspielt, der den Takt für den FPGA erzeugt. > Sieh dir mal das an: Im Moment mag ich nicht :) Ich will ja nicht immer nur abschreiben, sondern auch mal was verstehen, bzw. selbst hinbekommen. Da die Grundlagen noch nicht sitzen, muss ich schon genug nachschlagen. Wenn's klemmt oder ich fertsch bin, melde ich mich sowieso. > BTW: > Urig, dass du auf die wichtigste Frage keine Antwort gefunden hast: >>> Warum kommst du mit deinen 50MHz nicht aus? >> Weil ich nicht weiß, wie ... Öhm, könntest Du das bitte etwas erläutern?
>> Sieh dir mal das an: >Im Moment mag ich nicht :) solltest du aber! Wenn du nur bei SPI, deinem momentanen Projekt, Sorgen wegen krummer Takte hast: SPI ist sowieso total asynchron, ein SPI Master kann auch mal einen Moment laenger mit dem Takt aussetzen. Und damit hast du ein komplett asynchrones I/F und must es eben auch entsprechend in deiner Logik behandeln. Und wenn du Outputs generierst, die eine gewisse, krumme, Taktfrequenz benoetigen, dann brauchst du einen externen Quartz/Oszillator und musst den halt evtl. mit einem DCM hinzwiebeln. Also ich glaube auch, du verstehst dein eigentliches Problem noch nicht ganz...
@ berndl > SPI ist sowieso total asynchron SPI ist in sich absolut synchron. Deshalb kann ganz problemlos der Master mal einen Takt verzögern. Jitter ist kein Thema, solange die Specs des Slaves für den SCLK nicht verletzt werden. Du weißt das, hast es aber unvollständig weitergegeben ;-) @ Anfänger > Bei ner CD sind 44.100 KHz Standard. Ich weiß nicht, ob man hören kann, > wenn eine CD mit 44.105 oder 44.095 kHz abgetastet wird - > jedenfalls wäre es schon nominell nicht mehr konform. Und ganz definitiv ist das kein SPI :-o > ob man hören kann, wenn eine CD mit 44.105 > oder 44.095 kHz abgetastet wird Ja, man kann es hören, wenn eine CD abgetastet wird ;-) Allerdings hörst du keinen Unterschied, ob die CD mit 44.105 oder 44.100 kHz abgetastet wird. Das sind gerade mal 0,011% Abweichung. Ein Halbton hat eine Abweichung von 5,95%. Da zeigt nicht einmal ein Stimmgerät eine Verstimmung an... :-o > du verstehst dein eigentliches Problem noch nicht ganz... Da muss ich berndl recht geben: das glaube ich auch...
>@ berndl >> SPI ist sowieso total asynchron >SPI ist in sich absolut synchron. aber nur senderseitig gesehen! Am Slave musst du mit jedem Worst-Case, der unterwegs auftauchen kann, rechnen...
> Allerdings hörst du keinen Unterschied, ob die CD mit 44.105 > oder 44.100 kHz abgetastet wird. Naja, sag das nicht den Hifi-Fetischisten... Davon abgesehen: Mit einem 24 Bit Phasen-Akku bei 50 MHz Eingangsfrequenz und 44,1 kHz Ausgangsfrequenz, hat man schon eine Auflösung von unter 70 ppm, bezogen auf den 44,1 kHz, bei 32 Bits sind es in dieser Konstellation schon rund 0,25 ppm... Was bleibt, ist der Phasenjitter. Bei 50 MHz zu 44,1 kHz wären das rund 800 ppm. Darum die Eingangsfrequenz per DCM hoch jubbeln oder wie oben erwähnt, den Jitter der Ausgangsfrequenz direkt reduzieren.
> SPI ist in sich absolut synchron. Nein, auch empfängerseitig ist die SPI-Übertragung in sich synchron zum SPI-Takt. Dass der SPI-Takt natürlich vollkommen asynchron zum FPGA-Takt ist, steht auf einem anderen Blatt. Aber das Empfangsschieberegister kann durchaus mit dem SPI-Takt durchgetaktet werden. Nur müssen dann nach der Übertragung z.B. mit Hilfe des einsynchronisierten Slave-Select stabile Daten in die Taktdomäne des FPGAs übernommen werden.
> Davon abgesehen: Mit einem 24 Bit Phasen-Akku bei 50 MHz > Eingangsfrequenz und 44,1 kHz Ausgangsfrequenz Ja, zu den eingangs erwähnten 57,6 MHz sind da ja auch gute 3 Zehnerpotenzen dazwischen :-o
Schade, aber die letzten beiden Antworten finde ich eher bedauerlich. > solltest du aber! Wenn du nur bei SPI, deinem momentanen Projekt, Sorgen > wegen krummer Takte hast ... In diesem Thread schrieb ich nix davon, dass ich mir Sorgen um einen krummen Takt mache. Ich denke, ich habe einen Weg gefunden, 2 Taktdomaine unter einen Hut zu bekommen. In diesem Thread wollte ich wissen, wie ich einen krummen Takt erzeugen, bzw. definieren kann/muss. Klar weiß ich, dass die Abtastung der CD nix mit SPI zu tun hat. Ich wollte lediglich ein allgemein bekanntes Beispiel verwenden, bei dem Frequenzen vorgegeben sind. Aber sich über jemand anderen lächerlich zu machen ist ja leichter, als auf die Frage einzugehen. > SPI ist sowieso total asynchron, ein SPI Master kann auch mal einen Moment > laenger mit dem Takt aussetzen. Das mag im Audiobereich ja angehen. Schätze aber wenn ich in den Grenzbereich der IO-Frequenzen des FPGA komme, wird es schwierig werden, einen verlorenen Takt wieder einzuholen. >> du verstehst dein eigentliches Problem noch nicht ganz... > Da muss ich berndl recht geben: das glaube ich auch... Das mag wohl sein. Will ich auch überhaupt nicht in Abrede stellen. Ist das aber ein Grund, sich deshalb über die Beispiele lustig zu machen, anstatt beim Kernproblem, bzw. der eigentlichen Frage zu bleiben? Ich bezeichne mich schließlich nicht umsonst als Anfänger. Wünsche Euch noch einen schönen Sonntag
davon mal abgesehen, oben ging es im konkreten Bsp um SPI: Empfangen des SPI signals ist kein Problem, solange dein FPGA schneller laeuft als die SCK. Latenz fuer die Daten die rausgehen ist dann schonmal ein anderes Thema, verschlimmbessert durch z.B. Laufzeit auf der Uebertragungsstrecke. Da muss man evtl. schon mal tricksen... Beim Beispiel 44,1kHz fuer .wav Uebertragung: Dann baue ich mir halt einen Quartz/Oszillator dazu und clocke mit dem meine Daten raus. Ob 25ns frueher oder spaeter ist ja nicht das Problem. Hauptsache genau genug! Und bei 4Byte bei 44,1kHz, das ist ja nu auch nicht das Problem... Ich hatte nur den Eindruck, der OP dachte, er muss fuer jeden 'Slave' (SPI oder sonstwas) sich genau die passende Empfangsfrequenz zurecht biegen. Das ist Nonsens, ein FPGA ist fuer die meisten Sachen viel schneller, kann also mit '(Over)sampling' das ganze loesen. Und ja, Lothar, natuerlich hast du recht, SPI ist senderseitig synchron. Aber Empfaengerseitig halt nicht, selbst wenn du den gleichen Oszillator-Eingang am FPGA verwendendest wie der Sender. Deine Phasenlage kann eben nun mal 'worst-case' sein, darum ging es mir.
>Schade, aber die letzten beiden Antworten finde ich eher bedauerlich. Sorry wenn das so rueber kam, aber du hast weiter oben im Thread danach gefragt :o) Worum es hier geht, ist der Punkt, dass du beim FPGA Design 'genau' wissen musst, was deine Anforderungen sind. Ob du jetzt ein guter oder schlechter Logic-Designer bist, das zu beurteilen steht mir nicht zu und ich hab' auch gar keine Lust dazu! Also bitte nicht auf den Schlips getreten fuehlen, jeder von uns 'hardies' hat so seine eigenen Vorstellungen. Schilder doch dann nochmal konkret dein Problem, hier gibt's genuegend Leute, die die mit positiven/negativen Erfahrungen vlt. weiter helfen koennen.
> Ich wollte lediglich ein allgemein bekanntes Beispiel verwenden, bei dem > Frequenzen vorgegeben sind. Aber sich über jemand anderen lächerlich zu > machen ist ja leichter, als auf die Frage einzugehen. Wenn du dir lächerlich gemacht vorkommst, dann ist das evtl. deinem unduchschaulichen Beispiel zu danken. Glaub mir, ich kann meine Zeit sinnvoller verwenden, als andere lächerlich hinzustellen. Evtl. ist mir nur nicht klar, was denn jetzt dein eigentliches Problem ist :-o Ich hatte der Beschreibung entnommen, es ginge um ein konfigurierbares bzw. parametrierbares SPI-Interface. Falls ja: Wozu dann unbedingt eine SPI-Taktfrequenz von abc,xyz Mhz [a,b,c,x,y,z = E(0,1,...9)] erzeugen? > Wünsche Euch noch einen schönen Sonntag Dito, jetzt ab in den Pool ;-)
Ich versteh die ganze Diskussion um die 57,6MHz nicht. Einmal schreibt der OP, dass er sie genau einhalten muss. Ein anderes mal schreibt er, dass es nur um krumme Frequenzen geht und dass es ja auch "75.396 Hz" sein könnten. Dann heißt es, er hat SPI und vergleicht es mit Audio und 44,1kHz oder mit den 12,5MHz von Ethernet. Beides kriegt man übrigens exakt von der Frequenz hin. Das macht alles keinen Sinn ... Verrat doch einfach mal, wofür du die 57,6MHz genau brauchst. Wie andere schon angesprochen haben, kann man normalerweise SPI immer mit weniger als der maximalen Frequenz fahren. Aber Informationen will er sich auch keine Anschauen. Bei einem SPI-Analog-Digitalwandler geht das übrigens auch ... Da wird der SPI-Clock für den SAR-Converter verwendet. Was ist es denn für eine Peripherie, die exakt 57,6MHz benötigt und über SPI angebunden wird? Grüße Gast
Angehängte Dateien:
-
clock-paths.png
50 KB
Oups - gerade gemerkt, dass während des Schreibens meines letzten Beitrages hier weiter diskutiert wurde - was ich garnicht mitbekam. Insofern sind die Referenzen (letzten beiden) natürlich falsch. Ich möchte 2 Zitate loswerden: - alles ist schwierig, bevor es einfach wird - jetzt wo ich weiß, wie es geht, weiß ich auch, wie ich hätte fragen können Der Punkt ist doch, dass ich noch nicht genug weiß, um mein Problem klar umreißen zu können, ja dass ich nichtmal weiß, ob das, was ich als Problem empfinde überhaupt eines ist. Wenn ich es könnte, bräuchte ich vielleicht garnicht mehr fragen. > Sorry wenn das so rueber kam, aber du hast weiter oben im Thread danach > gefragt :o) Die ganze Diskussion um Jitter und Co hat mir einen neuen Aspekt eröffnet, über den ich mir bislang keine Gedanken gemacht habe. Deshalb hatte ich etwas weiter ausgeholt. Im Spartan-Handbuch ist ein Bild, welches die Situation recht gut veranschaulicht. Nur sind auf dem Bild alle 3 Daten-/Logikpfade isolierte Inseln. Auf dem Dev-Board hat es z.B. ein DAC, ein ADC und einen "Verstärker" für die ADC-Eingänge, wobei DAC und ADC mit 50 MHz angefahren werden dürfen, der Verstärker nur mit 1,5 MHz. Die Frequenzen sind gut aus dem Systemtakt erzeugbar. Jetzt habe ich aber auch noch externe Komponenten, die ich auch noch ansteuern möchte. Die verwenden unterschiedliche Taktraten. Deshalb habe ich über div. externe Taktquellen angefangen nachzudenken. > Verrat doch einfach mal, wofür du die 57,6MHz genau brauchst. Ich brauche die garnicht. Es war ein fiktives Beispiel um eine Zahl zu haben, die sich aus dem Systemtakt nicht erzeugen lässt. Genausowenig habe ich vor, die 44.100 kHz zu verwenden. Es waren beides nur Beispiele. > Dass der SPI-Takt natürlich vollkommen asynchron zum FPGA-Takt ist, > steht auf einem anderen Blatt. So, jetzt kommen wir auf den Punkt. Von der Voraussetzung bin ich auch ausgegangen. Ich bin davon ausgegangen, dass jedes FPGA-Modul, welches mit einem externen SPI-Baustein kommuniziert, einen völlig anderen Takt (und evtl. auch andere SPI-Modi) haben kann. Wenn ich nun eine Instanz haben will, die den Zugriff auf den SPI-Bus regelt, dann muss die mit dem FPGA-Systemtakt laufen, da sie ja keinen SPI-Takt kennt. Um die Signale vom SPI-Bus an das richtige Modul zu routen, braucht also der Busmaster einen Teil, der mit dem jeweiligen SPI-Takt läuft und einen anderen Teil, der mit dem FPGA-Systemtakt läuft. Je nach Parallelschnittstelle brauchen die FPGA-Module, die mit den SPI-Bausteinen kommunizieren nix vom FPGA-Systemtakt zu wissen. > Ich hatte nur den Eindruck, der OP dachte, er muss fuer jeden 'Slave' > (SPI oder sonstwas) sich genau die passende Empfangsfrequenz zurecht > biegen. Das ist Nonsens, ein FPGA ist fuer die meisten Sachen viel > schneller, kann also mit '(Over)sampling' das ganze loesen. Ja, berndl, damit hast Du völlig recht! Genau das habe ich auch gedacht, bzw. denke es immer noch. Das (Over)sampling funzt ja, wenn der Frequenzunterschied hinreichend ist, bzw. die Frequenzen in einem festen Verhältnis stehen. Wenn allerdings die Frequenzen durch verschiedene Taktquellen erzeugt werden, kann es doch zu Datenfehlern beim Samplen kommen - oder irre ich mich da? > Aber Informationen will er sich auch keine Anschauen. Woraus entnimmst Du das? - Weil ich die vorgefertigte Lösung von Lothar nicht verwenden will? Das eine hat mit dem anderen nix zu tun. Ich habe von allen Bausteinen, die ich ansprechen will die Datenblätter - und glaub mir, ich kann unterscheiden zwischen Maximal- und Nominalwert. Ich lese gerne, wenn es der Wissensbildung dient. Abschreiben ist für mich eher ein Akt der Faulheit. Unter lernen verstehe ich was anderes. Vom (meinem) Ansatz her habe ich ein SPI-Modul, welches die Schiebung veranstaltet, dann habe ich ein Modul zur Ansteuerung des DAC, eines für den ADC und eines für den Verstärker. Zwischen dem SPI-Modul und den anderen soll ein Busmaster den Zugriff regeln. Das SPI-Modul bezieht seinen Takt mal vom DAC-, mal vom ADC- und mal vom Verstärkermodul...
> Ich brauche die garnicht. Es war ein fiktives Beispiel um eine Zahl zu > haben, die sich aus dem Systemtakt nicht erzeugen lässt. > Genausowenig habe ich vor, die 44.100 kHz zu verwenden. Es waren beides > nur Beispiele. Vermutlich war genau das der Fehler der Fragestellung ... Oft ist es sinnvoll eine genaue Spezifikationen zu einem Problem zu haben, weil das die Bandbreite an möglichen Problemlösungen stark eingrenzt. Oft machen es sich die Anfänger einfach zu kompliziert und wollten etwas erreichen, was mit der entsprechenden Fachkenntnis überhaupt kein Thema ist, weil z.B. in einer Applikation eingebettet es evtl. garnicht so genau geht oder es andere Vereinfachungen gibt, die trotzdem zu einem richtigen Ergebnis führen. Daher auch das permanente hinterfragen nach der Anwendung, weil Anfänger aus Erfahrung eben manche Sachen anders machen, als jemand mit Fachkenntnis und jede Problemlösung auch vom Problem abhängt. Nur so eine Anmerkung ...
> Ich bin davon ausgegangen, dass jedes FPGA-Modul, welches mit einem > externen SPI-Baustein kommuniziert, einen völlig anderen Takt (und evtl. > auch andere SPI-Modi) haben kann. Richtig. Jeder externe SPI-Baustein ist in diesem Fall aber ein SPI-Slave. Der hat i.d.R. einen weiten Bereich, in dem sich sein SCLK bewegen darf. Wenn ein SPI-Slave für seine Funktion einen Takt braucht (z.B. der Netzwerk-Chip ENC28J60), dann hat er einen dedizierten Takteingang. Mit welcher Geschwindigkeit das SPI-Interface läuft, steht auf einem anderen Blatt. Es bringt daher nichts, sich mit aller Gewalt einen externen asynchronen Takt einzuhandeln, nur um die Kommunikationsschnittstelle der Bausteine an der oberen Übertragungsgrenze zu fahren. > Ich lese gerne, wenn es der Wissensbildung dient. Abschreiben ist für > mich eher ein Akt der Faulheit. Unter lernen verstehe ich was anderes. Es lag nie in meiner Absicht, dass du irgendwas abschreibst oder herkopierst. Was nicht verboten ist, und durchaus zum "Lernen" zählt, ist zu schauen, wie andere eine Aufgabenstellung angehen. Dir bleibt dann immer noch die Aufgabe, das Ganze zu verstehen und an deine Gegebenheiten anzupassen. > Das SPI-Modul bezieht seinen Takt mal vom DAC-, mal vom ADC- und mal vom > Verstärkermodul... Hier liegt der Hund begraben. Diesen Ansatz solltest du nochmal überdenken, das macht die Sache unnötig umständlich :-/ Als Gedankenanstoss und ohne Quelltext: Meine SPI-Engine sieht so aus, dass im DPRAM ein 32-Bit Konfig-Wort abgelegt ist, das die Parameter der Übertragung festlegt (Mode, Phase, Geschwindigkeit, Protokolllänge, Verzögerungszeiten, welcher Slave-Select ...). Danach folgt ein 32-Bit-Wort, das die Sende-Daten enthält, dann ein 32-Bit-Wort, das die Empfangsdaten enthält. Zum Abschluss kommt ein 32-Bit Statuswort, das bestimmte Übertragungsparameter abbildet. Dieses Muster mit 4x32 Bit wiederholt sich im DPRAM 64 mal. Dort hinein werden von einem uC die ganzen Übertragungsparameter und Daten geschrieben. Wenn das fertig ist, wird vom uC ein Start-Flag gesetzt. Jetzt kommt eine State-Machine, die ein Busy-Flag aktiviert, dann den ersten Datensatz aus dem DPRAM holt, das SPI-Interface entsprechend einstellt, den Slave-Select aktiviert, und dann die Übertragung startet. Nach dem Ende der Übertragung wird der Slave-Select deaktiviert, die empfangenen Daten ins DPRAM geschrieben und von dort der nächste Datensatz geholt und abgearbeitet. So geht das Ganze bis zu 64 mal, dann wird das Busy-Flag gelöscht und bis zum nächsten Aktivieren des Start-Flags gewartet. Dazu kommen noch ein paar Feinheiten, wie z.B. das Aktivhalten des Slave-Selects über mehrere der 64 Kanäle hinweg, das deaktivieren der einzelnen Kanäle...
Hallo zusammen, > Daher auch das permanente hinterfragen nach der Anwendung, weil > Anfänger aus Erfahrung eben manche Sachen anders machen, als jemand mit > Fachkenntnis und jede Problemlösung auch vom Problem abhängt. Das mag in vielen Fällen ja auch richtig sein. Aber nicht wenn es um das Verständnis geht. Dann ist die konkrete HW Schall und Rauch. Ich kann nur sagen - für meinen Geschmack wird nicht alles in den Büchern hinreichend erklärt, sodass ich es ohne zusätzliche Erklärung verstehen könnte. Manchmal tauchen in einer Diskussion auch neue Aspekte auf, die ich auch gerne verstehen würde. Beispiele machen anschaulich und in dem Fall ist es mir wurscht, ob sie einen konkreten HW-Bezug haben. In so einem Fall bringt mich das permanente Bohren nach konkreten Chips nicht weiter. > Wenn ein SPI-Slave für seine Funktion einen Takt braucht > (z.B. der Netzwerk-Chip ENC28J60), dann hat er einen dedizierten > Takteingang. Das ist korrekt. Mein externer ADC hat einen Systemtakt-Eingang. Dazu einige Konfigurationspins, über die man ihn als Master oder Slave betreiben kann. Einige Spielarten sind nur verfügbar, wenn man das Steinchen im Master-Modus betreibt. Master-Modus heißt für mich, dass der ADC den SPI-Takt erzeugt (deshalb habe ich ihn als gegeben eingestuft). Selbst wenn ich den ADC im Slave-Modus betreiben will, ist die Spanne, die mein SPI-Takt variieren darf nicht sehr groß, denn der Wert sollte abgeholt sein, bevor ein neuer zur Verfügung gestellt wird. Deshalb habe ich über asynchronen Takt bezogen auf den externen ADC garnicht nachgedacht. > Es bringt daher nichts, sich mit aller Gewalt einen externen asynchronen > Takt einzuhandeln, nur um die Kommunikationsschnittstelle der Bausteine > an der oberen Übertragungsgrenze zu fahren. Das war nie meine Absicht. Nur wenn ich mit dem ADC eine vorgegebene (!) Samplerate einhalten will, ergeben sich die Taktraten von alleine. Das hat nix mit ausreizen zu tun, sondern mir geht es um Einhaltung einer Spezifikation. >> Das SPI-Modul bezieht seinen Takt mal vom DAC-, mal vom ADC- und mal vom >> Verstärkermodul... > Hier liegt der Hund begraben. > Diesen Ansatz solltest du nochmal überdenken, das macht die Sache > unnötig umständlich :-/ Nun, nicht jeder Takt läßt sich aus dem Systemtakt erzeugen. Also muss ich schon mal die Möglichkeit eines externen Taktes in Betracht ziehen. Dann habe ich ein paar Versuche gemacht, mit einem eigenen "Taktmultiplexer" die unterschiedlichen Takte zu erzeugen. Selbst mit der CE-Technik komme ich nicht auf die Zeiten, die ein DCM bietet. Um jetzt 50 MHz, 12,5 MHz und 1,5 MHz gleichzeitig zur Auswahl zu haben, war das bislang beste Resultat 2 geschachtelte DCMs, wobei ich für die 1,5 MHz noch einen separaten Teiler brauche (die DCMs lassen sich nicht so langsam konfigurieren). Die ganzen Anforderungen sprengen den Rahmen dessen, was ein SPI-Master verwalten kann. Das hat mich zu dem Entwurf gebracht, dass ich den Takt entweder in den FPGA-Modulen erzeuge, oder in der Top-Entität durch Routing der entsprechenden Taktleitung. Mit meiner Variante ist das SPI-Modul so flexibel, dass es als Master und als Slave arbeiten kann, ohne das es weiß, ob es Master oder Slave ist. Die Speicherschnittstelle habe ich auch angedacht (war ein anderer Thread), wird vielleicht nicht so knackig wie Deine Variante, aber bislang bin ich mit meinem Entwurf zufrieden. Etwas was mir ganz wichtig ist (um angesichts meines eingeschränkten Könnens trotzdem was zu erreichen), ist die Reduzierung der Komplexität schon beim Entwurf. Mag sein, dass ein Profi da mehr rausholen könnte - damit kann ich im Moment gut leben. Ich habe mir einen Plan mit den zu erstellenden Modulen gemacht und da gehe ich jetzt eins nach dem anderen an. Auf den asynchronen Takt, bzw. die Grenzen zwischen Taktdomainen bin ich jetzt von verschiedenen Seiten gestoßen und deshalb ist es nach wie vor ein Thema für mich. Ich kann nicht behaupten, dass ich den Umgang mit unterschiedlichen Takten inzwischen kapiert hätte, noch kann ich mögliche Fehlerquellen im späteren Betreib ein- oder abschätzen. Kann also durchaus sein, dass ich das nochmal wieder zum Thema machen muss. > Es lag nie in meiner Absicht, dass du irgendwas abschreibst oder > herkopierst. Habe ich Dir ja auch nicht zum Vorwurf gemacht. Ich bin sehr froh und dankbar für Deine Seiten und habe schon viel von Dir gelernt und abgeschaut. Aber manchmal muss ich mich auch durchbeißen. Nur dann finde ich meine Verständnislücken. Inzwischen habe ich es mir angeschaut - und festgestellt, dass es nicht in mein Konzept passt. Wenn ich es richtig verstanden habe, ist ein Generic-Parameter ja etwas, was zum Zeitpunkt der Synthese aufgelöst wird. Lässt sich also später nimmer ändern. Ich häng mal meinen aktuellen Stand des SPI-Moduls an (der Busmaster ist noch nicht fertig).
> Inzwischen habe ich es mir angeschaut - und festgestellt, dass es nicht > in mein Konzept passt. Richtig, das hätte ich nach deiner jetzigen (konkreten) Beschreibung auch gesagt. > Wenn ich es richtig verstanden habe, ist ein Generic-Parameter ja etwas, > was zum Zeitpunkt der Synthese aufgelöst wird. Lässt sich also später > nimmer ändern. Nimm den Generic-Parameter in die Port-Liste, dann ginge das ;-) Ausgehend von http://www.lothar-miller.de/s9y/categories/45-SPI-Master z.B. sowas:
1 | entity SPI_Master is |
2 | Generic ( Quarz_Taktfrequenz : integer := 50000000; -- Hertz |
3 | SPI_Taktfrequenz : integer := 1000000; -- Hertz / zur Berechnung des Reload-Werts für Taktteiler |
4 | Pre_Delay : integer := 50; -- us / Zeit nach Aktivieren von CS bis Beginn der Übertragung |
5 | Post_Delay : integer := 10; -- us / Zeit nach Beenden der Übertragung bis Deaktivieren CS |
6 | );
|
7 | Port ( TX_Data : in STD_LOGIC_VECTOR (Laenge-1 downto 0); -- Sendedaten |
8 | RX_Data : out STD_LOGIC_VECTOR (Laenge-1 downto 0); -- Empfangsdaten |
9 | CPHA : STD_LOGIC; -- Clock Phase |
10 | CPOL : STD_LOGIC; -- Clock Polarity |
11 | MOSI : out STD_LOGIC; |
12 | MISO : in STD_LOGIC; |
13 | SCLK : out STD_LOGIC; |
14 | SS : out STD_LOGIC; |
15 | Laenge : std_logic_vector (4 downto 0) -- Anzahl der zu übertragenden Bits |
16 | Start_TX : in STD_LOGIC; |
17 | TX_Done : out STD_LOGIC; |
18 | clk : in STD_LOGIC |
19 | );
|
20 | end SPI_Master; |
Aber schon für die SPI-Taktfrequenz wäre eine deutlich größere Baustelle nötig, weil nur Divisionen durch Zweierpotenzen synthetisierbar sind :-(
> Aber schon für die SPI-Taktfrequenz wäre eine deutlich größere Baustelle > nötig, weil nur Divisionen durch Zweierpotenzen synthetisierbar sind > :-( Das ist scheinbar eine (sinnvolle) Beschränkung, die nur für Xilinx gilt. Anbei mein Versuch, mehrere Systemfrequenzen (gleichzeitig) zur Verfügung zu stellen. ClkGen-1.vhd war mein erster Entwurf - so herunter geschrieben, wie ich es für richtig hielt. Bei Altera läuft es durch, allerdings wird für sysClk eine max. Frequenz < 70 MHz ermittelt. Erst im RTL-Viewer sah ich, dass ich ein Tabu verletzt hatte, die Takte waren alle 'derived clocks'. Umgestellt auf CE-Technik war nur unwesentlich mehr drin. Also mit Xilinx probiert. Hier erfuhr ich dann, dass Modulo 134 nicht synthetisierbar ist. Ich habe dann die möglichen Werte selbst ausgerechnet und in ein Case verpackt. Mit dieser Variante brauchte Altera nur noch ein Drittel der Logikelemente und plötzlich waren die 200 MHz (bei Altera) möglich. Also ist Modulo außerhalb der Zweierpotenzen so teuer, dass ich es für richtig halte, von Xilinx hier eine Fehlermeldung zu schmeißen. Nach diesen Tests sind die DCMs natürlich doppelt wertvoll!
das clock divider von http://www.frank-buss.de/vhdl/advancedClock.html hast du naturlich schon angesehen? Antti
> Also ist Modulo außerhalb der Zweierpotenzen so teuer, dass ich es für > richtig halte, von Xilinx hier eine Fehlermeldung zu schmeißen. Hinter Modulo steckt eine Division. Wenn du keine Pipeline-Register in der Division hast, wird sie kombinatorisch synthetisiert. Und eine kombinatorische Division ist ressourcenfressend und langsam. Ein Modulo-2 Division ist einfach eine andere Verdrahtung (oder ein Multiplexer), das geht natürlich ratzfatz... > das clock divider von > http://www.frank-buss.de/vhdl/advancedClock.html > hast du naturlich schon angesehen? Naja, Kombinatorik im Taktausgang:
1 | clockOut <= latchedData(0) xor latchedData(1); |
Wird schon gutgehen... Aber auch damit können aus 50MHz keine 57,6MHz gemacht werden :-(
aber du brauchst ja keine 57.6? war ja nur ein beisbpiel? mann kann nicht allzuviel zu tricksen 1) externes chip 2) NCO in FPGA mit PLL (v5,v6,s6,altera,lattice,actel) 3) DCM clock dither Spartan3e mit allen den 3 kriegst du belibiege frequenz mit wenig jitter aber mit allen losungen den FPGA internen fixed clock benutzen kannst du zwar sehr genaue (beliebig genau!) bekommen aber mit +- clock jitter Antti
> das clock divider von > http://www.frank-buss.de/vhdl/advancedClock.html > hast du naturlich schon angesehen? Nein, kannte ich noch nicht. Aber nach überfliegen würde ich das eher als PWM-Engine oder so bezeichnen. > 2) NCO ... Sehr interessantes Stichwort. Gerade mal ergurgelt. Bei digikey fand ich dann z.B. den HPS45102 - nicht gerade ein Schnäppchen. Gibt es derlei Steine vielleicht auch ohne die analoge Endstufe, d.h. dass kein Sinus sondern ein Rechteck erzeugt wird?
wenn du gerade dabei bist, such doch mal nach fractional PLL. Der Teiler im Feedback ist nicht fix sondern wird verändert. Wenn der Teiler z.B. immer abwechselnd zwischen 5 und 6 gewechselt wird ergibt sich ein Teiler von 5.5. Das abwechselnde umschalten des Teilers würde allerdings einen Noise bei fs/2 erzeugen. Um das zu vermeiden wird ein Sigma-Delta Modulator benutzt, der den Noise zu höheren Frequenzen moduliert.
57,6 MHz / 50MHz = 144 / 125 Um ein Ausgangssignal in diesem Verhältnis zu erzeugen, brauchst Du nur 2 DCMs nacheinander zuschalten. 1. DCM: 12/5 50MHz => 120MHz 2. DCM: 12/25 120MHz => 67.5MHz fertig.
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.