Was sind die Vorteile von nacheinander geschalteten Zählern? Ist es vorteilhafter einen 32 Bit Zähler zu nutzen oder lieber mehrere hintereinander geschaltete Zähler um eine hohen Zählerstand zu erreichen?
:
Bearbeitet durch User
This is the German forum. Pls post questions in english language on http://embdev.net/forum/fpga-vhdl-verilog furtheron. A. P. schrieb: > What are the advantages of cascading counters? If you cascade it the right way, you can reach higher countig frequencies. Because the maximum counting frequency is related to the length of the carry chain: the shorter the carry the faster the counter.
> If you cascade it the right way, you can reach higher countig > frequencies. Because the maximum counting frequency is related to the > length of the carry chain: the shorter the carry the faster the counter. @ Lothar Miller, danke für die Antwort. Ist es auch möglich, einen asynchronen Zähler hinter einen synchronen Zähler zu schalten? Also zum Beispiel einen Johnson Counter mit einem nachgeschaltetem Ripple Counter?
A. P. schrieb: > Ist es auch möglich, einen asynchronen Zähler hinter einen synchronen > Zähler zu schalten? Also zum Beispiel einen Johnson Counter mit einem > nachgeschaltetem Ripple Counter? Klar kann man das machen. Aber warum? Ich würde der Toolchain freistellen, wie sie den Counter implementiert, solange das Ergebnis schnell genug ist. Denn das effiziente und schnelle Aufbauen von Zählern wird ständig gebraucht und ist sicher vom Hersteller optimal für die jeweilige Plattform implementiert. Daran selber rumzuschrauben lohnt sich in den allermeisten Fällen nicht.
Lothar Miller schrieb:
> Klar kann man das machen. Aber warum?
Ich würde gern einen Zähler haben wollen der schnell und möglichst groß
ist. Mir stellt sich eben noch die Frage ob das sinnvoll wäre mit dem
nacheinander schalten dieser beiden Zähler.
Synchrone Zähler sind eh schneller als asynchrone.
Würde ich damit dann das Timing wieder verschlechtern? Also, wenn ich
den Johnson Counter vor den Ripple Counter schalte!
A. P. schrieb: > wenn ich den Johnson Counter vor den Ripple Counter schalte! > Würde ich damit dann das Timing wieder verschlechtern? Ausprobieren... > einen Zähler ... der schnell und möglichst groß ist. Zahlen und Plattform, bitte! Und: was willst du damit machen? Ist das nur Gehirnjogging, oder ist ein reales Problem dahinter? Am schnellsten ist ein Zähler, wenn man die unteren (2-3) Bits, die schnell zählen müssen in einem eigenen Zähler implementieren lässt, und die restlichen in einem hübschen breiten Zähler implementiert. Man kann natürlich(!) diese "unteren Bits" nirgends im FPGA weiterverwenden, denn das Rotuing zu anderen Schaltungsteilen würde die Taktfrequenz wieder reduzieren. Aber als stupider Vorteiler reicht das allemal...
:
Bearbeitet durch Moderator
Lothar Miller schrieb:
> Zahlen und Plattform, bitte! Und: was willst du damit machen?
Ich nutze Xilinx Webpack 14.7 und den Spartan6.
Ich möchte gern einen Timestamper erstellen. Ich gebe eine Taktfrequenz
rein und möchte diese dann noch auf 4 oder 5 Phasen aufteilen und
verschieben, um die Auflösung zu erhöhen.
Durch den Zähler soll dann feststellbar sein wann genau ein Signal,
welches extern angeschlossen wird, auftritt. Er läuft also parallel die
ganze Zeit mit. Dazu bekommt jede Phase ihren eigenen Zähler, wenn die
Flanke auftritt wird geschaut bei welchen Werten jeder Zähler ist und
daraus der Zeitpunkt der auftretenden Flanke bestimmt.
Ich hatte beim Zähler schon an einen 32 bit Zähler gedacht.
Sozusagen, wenn ich dich richtig verstanden habe, die ersten 3 Bits in
den ersten Zähler und die restlichen 29 in den nächsten?!
A. P. schrieb: > Sozusagen, wenn ich dich richtig verstanden habe, die ersten 3 Bits in > den ersten Zähler und die restlichen 29 in den nächsten?! Soweit schon. Aber du musst schon auch das lesen, was dir nicht gefällt: Lothar Miller schrieb: > Man kann natürlich(!) diese "unteren Bits" nirgends im FPGA > weiterverwenden A. P. schrieb: > Ich gebe eine Taktfrequenz rein Welche? > und möchte diese dann noch auf 4 oder 5 > Phasen aufteilen und verschieben, um die Auflösung zu erhöhen. Du kannst die Taktfrequenz auch mit einem Taktmanager erhöhen.
A. P. schrieb: > Ich möchte gern einen Timestamper erstellen. Ich gebe eine Taktfrequenz > rein und möchte diese dann noch auf 4 oder 5 Phasen aufteilen und > verschieben, um die Auflösung zu erhöhen. Du hast immer noch nicht geschrieben, welche Auflösung Du brauchst. 1 µs? 1 ns? 1 ps? > wann genau ein Signal, > welches extern angeschlossen wird, auftritt. Also ein TDC (Time-to-Digital Converter). Für wieviele Signale brauchst Du das Ganze? Eins? Zehn? Hundert? Tausend? Duke
Lothar Miller schrieb: >> Ich gebe eine Taktfrequenz rein > Welche? >> und möchte diese dann noch auf 4 oder 5 >> Phasen aufteilen und verschieben, um die Auflösung zu erhöhen. > Du kannst die Taktfrequenz auch mit einem Taktmanager erhöhen. Ich habe die Taktfrequenz bereits auf 400MHz mit dem DCM erhöht. Duke Scarring schrieb: > welche Auflösung Du brauchst. 1 > µs? 1 ns? 1 ps? ca. 2,5 ns Duke Scarring schrieb: > Für wieviele Signale brauchst > Du das Ganze? Eins? Zehn? Hundert? Tausend? Zwei Signale - Ein Start- und ein Stop Signal.
Ich kann immer noch keinen Sinn in der Hintereinanderschaltung von Zählern erkennen. Normalerweise gilt: 1 + 1 = 2 ... war jedenfalls früher mal so. Schaltest Du also zwei gleiche Zähler hintereinander, so sollte das Ergebnis auch entsprechend sein. Schaltest Du zwei verschiedene Zähler hintereinander, z.B. einen asynchronen und einen synchronen, so kann das Ergebnis auch mal differieren. Die Aussage: Wer hat recht ist aber praktisch unmöglich. Möglicherweise stimmen ja beide Ergebnisse. Fütterst Du zwei Zähler mit unterschiedlichen Signalen, und wenn's die Phase ist, so gilt die Aussage des Hintereinanderschaltens nicht.
A. P. schrieb: >> welche Auflösung Du brauchst. 1 >> µs? 1 ns? 1 ps? > ca. 2,5 ns Ok. Also 400 MHz. Reicht Dir das auch als Genauigkeit? Wenn ja, würde ich bei 400 MHz nur einen Zähler nehmen. Das sollte z.B. in einem Spartan6 machbar sein. Duke
Duke Scarring schrieb : > Reicht Dir das auch als Genauigkeit? > > Wenn ja, würde ich bei 400 MHz nur einen Zähler nehmen. Das sollte z.B. > in einem Spartan6 machbar sein. Für's erste sollte das reichen. Ist Größe des Zählers ist dann auch unproblematisch? Da für jede Phase ein Zähler laufen soll.
> Ist Größe des Zählers ist dann auch unproblematisch? Da für jede Phase > ein Zähler laufen soll. Was problematisch ist und was nicht, verrät Dir der Timingreport des Synthesetools. Schonmal versucht da reinzuschauen?
Holgis Mudda schrieb: > Was problematisch ist und was nicht, verrät Dir der Timingreport > des Synthesetools. > > Schonmal versucht da reinzuschauen? Ich versuche zum Großteil das noch zu verstehen. Mit dem Timing Report tue ich mich noch etwas schwer. Aber vllt kannst du mir zum Beispiel sagen was genau ich damit anfangen kann:
1 | Timing Summary: |
2 | ---------------
|
3 | Speed Grade: -3 |
4 | |
5 | Minimum period: 2.048ns (Maximum Frequency: 488.317MHz) |
6 | Minimum input arrival time before clock: 2.335ns |
7 | Maximum output required time after clock: 3.732ns |
8 | Maximum combinational path delay: No path found |
Diese "Maximum output required time after clock: 3.732ns" ist dann quasi was ich hinten am Ende noch raus bekomme? Was sagt mir dann aber "Minimum period: 2.048ns (Maximum Frequency: 488.317MHz)"?
A. P. schrieb: > Minimum period: 2.048ns (Maximum Frequency: 488.317MHz) Das ist die von Dir gesuchte Taktfrequenz. > Minimum input arrival time before clock: 2.335ns Das ist die Setupzeit für synchrone Signale, die über einen Pin reinkommen. (Für Deine Zeitmessung nicht relevant.) > Maximum output required time after clock: 3.732ns Das ist die Zeit, die synchrone Signale benötigen um vom letzen Flipflop bis durch das Ausgangspin zu propagieren. > Maximum combinational path delay: No path found Das ist ein gutes Zeichen: Es ist alles synchron. Allerdings sind die Zeiten die der Synthesizer (XST) ausgibt nur grobe Anhaltspunkte. Die Abweichung kann +-50% oder mehr betragen. Entscheidend ist, was der Timing-Rport nach Place-and-Route ausgibt. Große Designs in großen FPGAs sind eher langsamer. Duke
Duke Scarring schrieb: > Allerdings sind die Zeiten die der Synthesizer (XST) ausgibt nur grobe > Anhaltspunkte. Die Abweichung kann +-50% oder mehr betragen. > Entscheidend ist, was der Timing-Rport nach Place-and-Route ausgibt. > Große Designs in großen FPGAs sind eher langsamer. Vielen Dank für die Erklärung. :-)
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.