Hallo,
ich führe mehrere (externe) Taktquellen zu einem Multiplexer, welcher
sich dann auf den jeweils aktiven Takt synchronisieren soll.
Die Taktumschaltung erfolgt jeweils aus dem Reset heraus, sodass
Glitches und ähnliche Dreckeffekte eher untergeordnete Bedeutung haben.
Bei Altera wird erkannt, dass ein Takt gemultiplexed wird und es werden
entsprechende Schutzkonstrukte generiert. Ich bekomme zwar eine Warnung,
dass das Design evtl. nicht funktioniert, aber das RTL sieht (soweit ich
das beurteilen kann) gut aus.
Bei Xilinx erhalte ich den Fehler, dass der Indexwert bei
rising_edge(...) nicht konstant ist (was ja beabsichtigt ist).
Wie muss ich eine Flankenerkennung für einen gemultiplexten Takt bei
Xilinx (in VHDL) formulieren, damit der Code übersetzt bzw.
synthetisiert werden kann?
Klingt so, als solltest du den Multiplexer explizit beschreiben und
nicht direkt in rising_edge angeben.
Irgendwo gab es doch von irgendeinem Hersteller eine AppNote wie man
Taktmultiplexer am sinnvollsten beschreibt, wenn sie nicht in
dedizierter Hardware laufen sollen.
Ganz nebenbei, Takte zu multiplexen ist immer nur 3. Wahl - kannst du
nicht mit Oversampling oder einem festen Takt arbeiten?
Bei Xilinx gibts BUFGMUX Elemente, die man instanziieren kann,
vielleicht hilft dir das weiter. Dein Takt-Mux muss ja aber auch einen
Ausgang haben, den kannst du doch als Bedingung für rising_edge()
nehmen? Oder wie sieht das bei dir aus? Abgesehen davon, dass man
Takt-Signale nur im äußersten Notfall muxt....
So ganz habe ich nicht verstanden, was Du mit synchronisieren meinst.
Ein Multiplexer multiplexed - der hat kein Synch sondern nur select
Eingänge.
Was heisst "Der Indexwert ist nicht konstant"? Poste mal die
entsprechende Codestelle.
Der Ausgang deines Mux sollte tunlichts per BUFG auf ein globales
Taktnetz gelegt werden (sonst versucht XST die Leitung normal zu
routen).
Für Multiplexaufgaben des Taktes gibt es den oben genannten BUFGMUX der
meine ich 4:1 auswählen kann.
> dass der Indexwert bei rising_edge(...)
Du probierst sowas:
1
signalclk:sdt_logic_vector(3downto0);
2
:
3
ifrising_edge(clk(idx))then...
Richtig?
Dann machs besser über die Instantiierung eines BUFGMUX, der als Eingang
das gemultiplexte Signal erhält, und am Ausgang auf ein Taktnetz geht.
> Bei Altera ... eine Warnung, dass das Design evtl. nicht funktioniert,> aber das RTL sieht (soweit ich das beurteilen kann) gut aus.
Der RTL-Schaltplan sagt noch gar nichts darüber aus, ob dein Design in
ein FPGA passt. Der bedeutet nur, dass die Synthese Bauteile gefunden
hat, die in etwa deiner Beschreibung entsprechen. Der RTL-Schaltplan
wird auch für ein CPLD genau gleich aussehen. Ob Translate diesen Plan
dann in "reale" FPGA-Bauteile übersetzen kann, das kommt erst später.
BTW:
Ich bin mir (immer noch) nicht sicher, ob du auf dem richtigen Weg bist
;-)
Guten Morgen und herzlichen Dank für Eure Antworten!
> Ganz nebenbei, Takte zu multiplexen ist immer nur 3. Wahl - kannst du> nicht mit Oversampling oder einem festen Takt arbeiten?
Ok, das Thema hatten wir in einem anderen Thread.
Deshalb schrieb ich externe Taktquellen. Die Taktquellen sind unabhängig
vom Systemtakt.
> Für Multiplexaufgaben des Taktes gibt es den oben genannten BUFGMUX der> meine ich 4:1 auswählen kann.
Hm, habe mal das Handbuch des Spartan durchwühlt. Da wird zwar öfters
von BUFGMUX geschrieben, aber ich fand keinen Hinweis, was ich beim
Codieren beachten muss, damit ein solcher instantiiert wird.
Ach ja, laut Handbuch (Spartan-3) wählt ein BUFGMUX "nur" einen Ausgang
aus 2 Eingängen.
> Du probierst sowas:
1
signalclk:sdt_logic_vector(3downto0);
2
:
3
ifrising_edge(clk(idx))then...
> Richtig?
Völlig korrekt.
Da ich die Breite von clk über einen generischen Parameter festlege,
weiß ich nicht, wie ich das anders formulieren soll.
Wenn der eine feste Breite hat, könnte ich ein Case-Konstrukt verwenden.
Lässt sich die Flankenabfrage über ein generate behandeln?
Mir fehlt noch der Zugang, wie ich diese Abfrage auscodieren kann und
trotzdem "dynamisch", also in Abhängigkeit von dem generischen
Parameter, bleiben kann.
> BTW:> Ich bin mir (immer noch) nicht sicher, ob du auf dem richtigen Weg bist> ;-)
Na, dann sind wir ja schon zu zweit :)
Ich musste feststellen, dass die Einarbeitung doch sehr schnell extrem
komplex wird. Jedesmal ne Testbench stricken und die Signale überprüfen
- puh - ist ein Haufen Schreibarbeit.
Allerdings entsteht so langsam auch ein Gefühl für die Materie und ich
habe zumindest schon verstanden, wie ich Signallaufzeiten und glitches
provozieren und testen kann. Also so ganz verkehrt wird der Weg nicht
sein.
Anfänger schrieb:
> Hm, habe mal das Handbuch des Spartan durchwühlt. Da wird zwar öfters> von BUFGMUX geschrieben, aber ich fand keinen Hinweis, was ich beim> Codieren beachten muss, damit ein solcher instantiiert wird.
Instanziieren machst du selber. Solche Sachen können nicht inferriert
werden.
> Ach ja, laut Handbuch (Spartan-3) wählt ein BUFGMUX "nur" einen Ausgang> aus 2 Eingängen.
Dann musst du schachteln. Aber wenn ich mich recht erinnere, hattest du
doch so schnarch-langsame Takte als Quelle, oder? Die kannst du
wahrscheinlich mit einem normalen Mux über das normale Routing schicken.
Und auch noch mit generic und variabler Anzahl Takte? Hmm...also die
eierlegende Wollmilchsau geht meistens schief....
>> Richtig?>> Völlig korrekt.> Da ich die Breite von clk über einen generischen Parameter festlege,> weiß ich nicht, wie ich das anders formulieren soll.> Wenn der eine feste Breite hat, könnte ich ein Case-Konstrukt verwenden.>
So etwas wird meiner Meinung nach für die Synthese nicht funktionieren,
da der Compiler nicht intelligent genug ist, einen Multiplexer vor den
Takt zu schalten. Außerdem muß davon stark abgeraten werden.
Wenn Du das ganze unbedingt so willst, mußt Du das ganze selbst
beschreiben:
Zuerst eine Komponente Multiplexer, diese liefert ein Signal ClkOut.
In das rising_edge statement kommt dann nur mehr ClkOut.
Die einzige saubere Variante für den Multiplexer ist die BUFGMUX
Komponente, diese kann aber nur zwischen 2 Takten umschalten.
Aber nochmals, vom Umschalten zwischen beliebig vielen Takten kann nur
abgeraten werden.
Als Anfänger und womöglich Softwerker denkt man am Anfang zu
kompliziert. Einen gewisse Flexibilität der geschriebenen Module mittels
Generics ist schon gut, aber letztendlich muß es zur verfügbaren
Hardware passen.
