Frequenzteiler geteilt durch 2.5

Welchen FPGA/CPLD setzt du ein? Oder soll es ein TTL-Grab werden?

MfG,

Aber nur bei einer 5er LUT, manche FPGA#s haben aber nur LUTS mit 4 
Eingängen.

MfG,

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?

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 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.

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)