controller mit >= 100 MHz clock

Wed Aug 11, 2010 9:30 am   

Hallo Mark,


Sehr wohl und das hat auch gar nichts mit der internen Clockrate zu tun. Wir
hatten ARM7-µC im Einsatz, die intern mit >40 MHz laufen, aber an den Pins
bei 2 MHz schlapp machen. Speziell bei den SPIs hätten die Chipdesigner
wirklich ein bischen mehr Speed spendieren können.

Marte

Wed Aug 11, 2010 9:30 am   

Mark schrieb:


Hallo,

wenn es keinen dafür passenden Controller gibt kann der auch nicht am
geeignetsten sein. Wenn Du schon ein FPGA hast wäre es doch am besten
das Problem in diesem zu lösen, ohne ein zusätzliches FPGA. Falls in dem
vorhanden FPGA dafür nicht mehr genug Resourcen frei sind muß es wohl
das nächstgrössere sein.

Bye

Wed Aug 11, 2010 9:34 am   

Mark schrieb:


Hallo,

der Controller soll ja schnell mit konstanter Verzögerungszeit auf den
triggernden Eingang reagieren, da liegt das Problem. Wenn dabei ein
Jitter von etlichen 10 ns dazukommt nützt Dir das doch nichts.

Bye

Wed Aug 11, 2010 10:08 am   

Am 10.08.2010 15:51, schrieb Mark:

Ich hatte mal nach Timer-ICs für das Takten mehrerer ADC mit 1Gs/s
gesucht. Vielleicht gibt es da was für Dich Geeignetes. Ich meine, TI
und Analog hätten solche Dinger im Programm.

Ein genügend schnelles FIFO könnte auch funktionieren.

In beiden Fällen könntest Du das Timing mit dem Controller vorgeben und
dann laufen lassen.

Gruß,
Falk
--
Suche SD/MMC-Karten mit 64MB-512MB

Wed Aug 11, 2010 10:19 am   

Michael Koch wrote:

Ack. Es kommt dann aber auch noch darauf an, wie gross das Jitter beim
Erkennen des Triggersignals sein darf. 10ns sind da schon beim Erkennen
mit dieser CPU gar nicht moeglich, denn es gibt keinen Sprungbefehl der
nur 1 Cycle benoetigt. Dazu kommt, dass diese CPU bereits recht modern
ist und einen Branch Target Cache hat (weil die Fetch-unit sonst nicht
hinterherkommt und die Pipeline leerlaeufen wuerde). Bei einem Cache
miss wird die Pipeline daher fuer Zitat "bis zu 4 Cycles" angehalten und
der Sprung selbst dauert einen Cycle laenger. D.h. man kriegt gleich
nochmal bis zu 50ns Jitter drauf wenn man die relevanten Sprungziele
nicht im Cache halten kann. Wenn es dumm laeuft koennte das
Gesamt-Jitter also mit dieser CPU am Ende groesser werden wie die
angepeilte Pulsdauer.


Micha

Wed Aug 11, 2010 11:30 am   

Marte Schwarz wrote:

2MHz SPI ist natuerlich schon arg lahm, da hat der Student beim
"Zusammenklicken der Fremd-IP" wohl ueberall die gleichen Makrozellen
genommen Alle Treiber schnell ist auch nicht der Hit. Umschaltbare
Slew rate ist eigentlich das was man will, also schnell nur da wo es
auch noetig ist.


Micha

Wed Aug 11, 2010 12:38 pm   

Hallo Michael,



Man kann die CPU aber so konfigurieren dass bestimmte Code-Bereiche
immer im Cache gehalten werden.

Gruss
Michael

Wed Aug 11, 2010 12:44 pm   

Hallo Mark,


Zwei Zyklen für "SETB bit" und zwei Zyklen für "CLR bit". Die Pulsdauer
kannst du mit NOPs verlängern, die brauchen einen Zyklus.

Gruss
Michael

Wed Aug 11, 2010 12:57 pm   

Hallo Michael,


Doch, das geht wenn man ein paar Tricks anwendet. Lege das Triggersignal
auf einen Eingang, der einen Interrupt auslöst und gleichzeitig einen
100MHz Timer startet. In der Interrupt-Routine liest du als erstes den
Zählerstand des Timers aus. In dieser Zahl ist die Information
enthalten, wie lang die Reaktionszeit auf den Interrupt war. Verwende
dann diese Zahl, um an der richtigen Stelle in ein NOP-Array
reinzuspringen. Auf diese Weise wird eine variable Verzögerungszeit mit
10ns Auflösung generiert, wodurch die Interrupt-Reaktionszeit
ausgeglichen werden kann. Das Ergebnis ist 10ns Jitter.

Gruss
Michael

Wed Aug 11, 2010 1:31 pm   

Michael Koch wrote:


Jepp, das ist das übliche Verfahren, um variable Interruptlatenzen zu
kompensieren. Prinzipiell ähnlich funktioniert es auch mit freilaufendem
Zähler und Captureeinheit.

Allerdings kostet das Verfahren selber einiges an Zeit und der Interrupt
natürlich sowieso. D.h: Du bekommst eine nicht ganz unerhebliche
Mindestlatenz.

Wed Aug 11, 2010 1:59 pm   

Michael Koch wrote:

Ja, der Cache scheint auch ziemlich gross zu sein.

Einen Pin toggeln geht in einem Takt, d.h. die minimale Pulsdauer von
10ns wie gefordert sollte moeglich sein (sofern die Pin-Treiber das
ausgeben koennen). Allerdings kann man am Ende hoechstens an 20ns Jitter
herankommen. Mehr ist aus der CPU nicht zu holen wenn ich das Datasheet
richtig lese.


Micha

Wed Aug 11, 2010 2:36 pm   

Heiko Nocon wrote:

"nicht ganz unerheblich" wird noch untertrieben sein im Vergleich zu
direkt abgefragt. Aber gut, vielleicht ist das hier ja akzeptabel bzw.
kann sogar an der Triggerquelle kompensiert werden.


Micha

Wed Aug 11, 2010 2:39 pm   

Hallo Michael,


Mit welchem Befehl soll das gehen? Ich meine die schnellste Möglichkeit
ist ein "SETB bit", aber der braucht 2 Taktzyklen.

Gruss
Michael

Wed Aug 11, 2010 4:13 pm   

Michael Koch wrote:

Du hast Recht. Ich dachte "Rn" duerfte auch ein SFR sein, das ist aber
nicht so. Das Toggeln haette man sonst mit MOV oder XCH machen koennen
(die restlichen Pins des Ports kann man reservieren, sind hier ja im
Ueberfluss vorhanden). Aber diese Befehle brauchen dann auch alle 2
Cycles wenn ein SFR beteiligt ist.

Ein (D)J(N)Z-Sprung geht aber in 2 Cycles, d.h. damit koennte man die
Schleife vom Interrupt unterbrechen lassen mit <=20ns Jitter. Wenn man
das Jitter auf Kosten der Latenz rausrechnet wie an anderer Stelle
beschrieben, kaeme man auf >=20ns Pulsdauer und <=10ns Jitter.

Will man minimale Latenz, dann stoert der Interrupt:
----------------------------------------------------------------------
JNB Trigger, 0
[Pulserzeugung]
----------------------------------------------------------------------
Das braucht nur max. 3 Cycles um aus der Poll-Schleife rauszukommen und
nochmal 2 um den Pin zu setzen, d.h. <=50ns Latenz waeren moeglich, am
Jitter von <=30ns kann man dann aber natuerlich nichts rausrechnen.

J(N)B ist allerdings nicht unter den Branch-Instructions gefuehrt die
angeblich einen Cycle schneller sind wenn sie nicht springen muessen.
D.h. so muesste man doch eigentlich auch mit max. 2 Cycles aus der
Poll-Schleife kommen koennen:
----------------------------------------------------------------------
[Restliche Pins von Port auf festem Potential]
MOV A, Trigger
CJNE A, Port, 0
[Pulserzeugung]
----------------------------------------------------------------------


Micha