Hallo Zusammen, ich suche einen Frequenzteiler mit dem eine entsprechendes Rechtecksignal in seiner Frequenz durch 2.5 geteilt werden kann. Die bevorzugte Lösung ist eine Kombination aus zwei bis drei D-Flip-Flops und zwei bis 4 Logikgattern. Wichtig ist mir die Minimierung des Hardwareaufwands. Das Tastverhältnis darf asymetrisch sein. Ich kenne den folgenden Artikel: http://www.mikrocontroller.net/attachment/177198/Clock_Dividers_Made_Easy.pdf Die Schaltung darin ist mir aber zu aufwändig. Ich bedanke mich für eure Mithilfe. Gruß Flo
Flo schrieb: > ich suche einen Frequenzteiler mit dem eine entsprechendes > Rechtecksignal in seiner Frequenz durch 2.5 geteilt werden kann. Wofür brauchst du dieses Signal? Woher kommt das "Rechtecksignal", wohin geht das geteilte Signal?
Flo schrieb: > Ich kenne den folgenden Artikel: > http://www.mikrocontroller.net/attachment/177198/Clock_Dividers_Made_Easy.pdf > Die Schaltung darin ist mir aber zu aufwändig. Meinst Du die Schaltung Nr. 14? Ich glaube kaum, das Du da was einfacheres finden wirst. Es sei denn, Du nimmst einen passend programmierten µC. Gruss Harald
Angehängte Dateien:
-
Divider25.png
13 KB -
Divide5.png
10 KB
Harald Wilhelms schrieb: > Ich glaube kaum, das Du da was einfacheres finden wirst. Wobei diese Schaltung allein nicht die ganze Wahrheit ist. Denn man braucht ja noch die Flipflopschaltung aus dem Bild 12 dazu...
:
Bearbeitet durch Moderator
OK, es braucht sogar 6 Eingänge also 6 er LUT für einen ein LUT-Lösung
Lothar Miller schrieb: > Ich bin mir auch sicher, denn das passt in 1 einzige LUT. das ist aber gemogelt. Denn Schaltung 14 braucht als Eingänge die Signale von Schaltung 12 (A, B und C), den Aufwand muss man noch dazurechnen ;-)
Sorry, verzählt, doch nur 5 Eingänge... meine Augen werden alt.
Der Schaltkreis hat einen Nacheil:
>duty cycle output not 50%
Wie liesse sich ein Takt generieren, der echte 50% d.h. hat?
Markus Wagner schrieb: > Wie liesse sich ein Takt generieren, der echte 50% d.h. hat? Wofür? Welche Frequenz?
Folgender 2.5 Teiler ist sicherlich zuverlässiger als der Vorschlag im
Paper mit combi loop. Er ist definitiv glitch frei.
rFF=rising-FF
fFF=falling-FF
(x)=init/reset x
__
|------------------------------------------*-------------------->| |
| | | OR |->div
|->rFF(0)->rFF(0)->rFF(0)->rFF(0)->rFF(1)--*--->fFF(0)->fFF(0)-->|____|
Markus Wagner schrieb: > Der Schaltkreis hat einen Nacheil: >>duty cycle output not 50% > Wie liesse sich ein Takt generieren, der echte 50% d.h. hat? Mit digitaler Schaltungstechnik laut dem Paper gar nicht, also PLL. Ich habe keinen Grund das anzuzweifelen, aber wer es tut kann es gerne widerlegen und eine Lösung vorstellen. Eine solche Lösung muss natürlich glitchfrei sein. Ottmar schrieb: > Folgender 2.5 Teiler ist sicherlich zuverlässiger als der Vorschlag im > Paper mit combi loop. Er ist definitiv glitch frei. > Warum sollte der Vorschlag im Paper nicht glitchfrei sein? Eine combiloop muss keinen Glich als Folge haben, sonst könnte man auch keine FFs bauen, denn die bestehen intern aus einigen Combiloops. Die Analyse auf Glitchfreiheit ist sicher schwieriger, aber trotzdem keine Rocketscience.
@ Lattice User (Gast) >Warum sollte der Vorschlag im Paper nicht glitchfrei sein? Eine >combiloop muss keinen Glich als Folge haben, sonst könnte man auch keine >FFs bauen, denn die bestehen intern aus einigen Combiloops. >Die Analyse auf Glitchfreiheit ist sicher schwieriger, aber trotzdem >keine Rocketscience. Eben, siehe Glitch. Der Trick ist, dass sich immer nur EIN Eingangssignal ändern darf, ähnlich wie Gray-Code.
Lattice User schrieb: > Warum sollte der Vorschlag im Paper nicht glitchfrei sein? Eine > combiloop muss keinen Glich als Folge haben, sonst könnte man auch keine > FFs bauen, denn die bestehen intern aus einigen Combiloops. Wo habe ich behauptet das der Teiler aus dem Paper glitcht, oder das combi loops glitchen? Zuverlässiges Design heist das sich eine Schaltung auf verschieden Techonolgien gleich verhält ohne große Analysen. Erklär doch bitte wie du das Timing einer combi loop mit FPGA tools reproduzierbar Verifizierst?
Falk Brunner schrieb: > Eben, siehe Glitch. Der Trick ist, dass sich immer nur EIN > Eingangssignal ändern darf, ähnlich wie Gray-Code. Das ist nur für einfache Gatter gültig. Eine komplexe kombinatorische Logik kann bedingt durch race conditions auch beim Wechsel eines Eingangssignals glitchen.
Falk Brunner schrieb: > @ Lattice User (Gast) > >>Warum sollte der Vorschlag im Paper nicht glitchfrei sein? Eine >>combiloop muss keinen Glich als Folge haben, sonst könnte man auch keine >>FFs bauen, denn die bestehen intern aus einigen Combiloops. >>Die Analyse auf Glitchfreiheit ist sicher schwieriger, aber trotzdem >>keine Rocketscience. > > Eben, siehe Glitch. Der Trick ist, dass sich immer nur EIN > Eingangssignal ändern darf, ähnlich wie Gray-Code. Das ist eine hinreichende aber keine notwendige Bedingung. z.B. 3 Fach-AND, solange einer der Inputs 0 ist, können sich die beiden anderen ändern wie sie wollen. Auch bei einem 2 Fach-AND sind nur 2 der 4 möglichen Übergänge anfällig. Ottmar schrieb: > > Wo habe ich behauptet das der Teiler aus dem Paper glitcht, oder das > combi loops glitchen? Implizit dadurch dass du als alternative die viel aufwändigere FF Lösung vorgeschlagen hat. Ist in dem Paper übrigens auch beschrieben (als 4.5 Teiler) > > Zuverlässiges Design heist das sich eine Schaltung auf verschieden > Techonolgien gleich verhält ohne große Analysen. > > Erklär doch bitte wie du das Timing einer combi loop mit FPGA tools > reproduzierbar Verifizierst? Wo war von FPGA die Rede? Davon abgesehen kann das Diamond Analyse Tool den Delay der Loop reporten. Reicht wharscheinlich das für beliebige Combiloops, im vorliegenden Fall wo es um ein einfaches Latch geht schon.
Lattice User schrieb: Korrektur: > Wo war von FPGA die Rede? > Davon abgesehen kann das Diamond Analyse Tool den Delay der Loop > reporten. Reicht wharscheinlich nicht für beliebige Combiloops, im > vorliegenden Fall wo es um ein einfaches Latch geht schon.
Das "TTL-Grab" bestünde aus einem einzigen 74xx90 oder 74xx390. Der hat einen Fünferteiler und an zwei Ausgängen kommen zwei Impulse pro fünf Eingangsimpulsen heraus. Ein synchroner Zähler 74xx162/192 kann sogar synchron durch fünf teilen und hat die 2,5er-Ausgänge. Aber es soll wohl in ein CPLD oder FPGA passen. Auch da gibt es vorkonfektionierte Teiler. Das werden aber mehr als die gesuchten drei Flipflops sein.
Christoph Kessler (db1uq) schrieb: > > Aber es soll wohl in ein CPLD oder FPGA passen. Auch da gibt es > vorkonfektionierte Teiler. Das werden aber mehr als die gesuchten drei > Flipflops sein. In einem FPGA wegen ein paar Gatter/FF zu sparen macht nur extrem selten Sinn. Und auch beim CPLD sehe ich das auch nicht. Übrigens kann man die Schaltung 14 aus dem Paper mit nur einem weiteren auf der negativen Flanke getriggertem FF von der Combiloop befreien.
Lattice User schrieb: > Ist in dem Paper übrigens auch beschrieben (als 4.5 > Teiler) Die Schaltung ist ja für jedes x.5 Teilerverhältnis adaptierbar. Lattice User schrieb: > Davon abgesehen kann das Diamond Analyse Tool den Delay der Loop > reporten. Man kann es reporten aber nicht constrainen. Sowohl P&R als auch STA brechen loops an einer meist beliebigen Stelle auf. Dadurch wird ein Teil der Pfade nicht berücksichtigt/analysiert. Der diskrete Aufbau aus dem Paper muss ganz klar im Zusammenhang mit ASIC Design gesehen werden. Dort gibt es teilweise keine neg. edge FF. Leider gibt der Autor auch keine Hinweise auf die Fallstricke seiner Schaltung. Fig. 14: Die Signale CLK und B stehen z.B. in einer race condition am AND gate. Und da es keine relativen constraints gibt um race condititions zu constrainen sollten solche Sachen einfach vermieden werden.
Ottmar schrieb: > Der diskrete Aufbau aus dem Paper muss ganz klar im Zusammenhang mit > ASIC Design gesehen werden. Dort gibt es teilweise keine neg. edge FF. > Leider gibt der Autor auch keine Hinweise auf die Fallstricke seiner > Schaltung. Aus dem Paper: Proper functioning of such asynchronous sequential circuits depends on the fact that the transition of the CLK input to the LUT will always occur before the other inputs. Zwischen CLK und B gibt es übrigens kein Problem (wird durch C maskiert), und zwischen CLK und C führt es zum Jitter der outputclock, aber nicht zu Glitches. Übrigens habe ich auch dafür ein Constraint gefunden, das zumindseten eine Erkennung per Script zulässt:
1 | ================================================================================ |
2 | Preference: MAXSKEW PORT "clk" 1.000000 nS ; |
3 | 1 item scored, 0 timing errors detected. |
4 | -------------------------------------------------------------------------------- |
5 | |
6 | Report: 0.781ns skew on clk_c meets |
7 | 1.000ns skew constraint by 0.219ns |
8 | |
9 | Delays Connection(s) |
10 | 1.205ns 38.PADDI to R10C11B.C0 |
11 | 1.986ns 38.PADDI to R10C11A.CLK |
12 | 1.986ns 38.PADDI to R10C11C.CLK |
13 | 1.986ns 38.PADDI to R10C11D.CLK |
14 | |
15 | Report: 0.781ns is the maximum skew for this preference. |
Wenn das Delay der resten Zeile (Eingang des AND) grösser ist als die anderen, dann jittert die Clock. Ich stimmer dir allerdinmgs zu, bei einem FPGA ist es sinnfrei, mit nur einem zusätzlichen auf der negativen Flanke getriggert FF für O' geht es auch ohne die Combiloop. (O' <= B & C)
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.