FPGA mit ľC Takten

[Robert Brehm]

Moin Moin,

Ich arbeite mich gerade in die Welt der FPGA`s ein. Und zwar will ich
Meßdaten über einen AD Wandler wandeln und mit mit dem FPGA
bearbeiten. (Mittelwert, usw.).

Nur leider treten jetzt schon am Anfang des Projektes tausende kleiner
Probleme auf.

Ich habe um überhaupt erstmal Fuß zu fassen ein einfaches Toggle-FF in
den FPGA programmiert mit dem ich eine an den Clock Eingang des FPGA´s
angelegte Frequenz halbieren kann. So jetzt kommt der kritische Punkt.
Wenn ich nun an den Clock-Port des FPGA`s eine von einem
Frequenzgenerator erzeugte Frequenz anlegte dann läuft das System
100%ig. Sobalt ich aber mit einem Mikrocontroller eine Frequenz
erzeuge funktioniert das System nicht mehr !!!
Die Frequenz ist ungefähr 10Hz, also Pulsweiten von ca. 200ms, sowohl
beim Frequenzgenerator als auch beim Mikrocontroller erzeuge ich 5V
Signale.

Ich weiß absolut nicht mehr weiter !!

Danke im vorraus ...
Grüße Robert

 

[Georg Acher]

In article <3dc0af05.0312050607.1329bcbf@posting.google.com>,
BrehmR@gmx.de (Robert Brehm) writes:

|> Wenn ich nun an den Clock-Port des FPGA`s eine von einem
|> Frequenzgenerator erzeugte Frequenz anlegte dann läuft das System
|> 100%ig. Sobalt ich aber mit einem Mikrocontroller eine Frequenz
|> erzeuge funktioniert das System nicht mehr !!!
|> Die Frequenz ist ungefähr 10Hz, also Pulsweiten von ca. 200ms, sowohl
|> beim Frequenzgenerator als auch beim Mikrocontroller erzeuge ich 5V
|> Signale.

Wahrscheinlich ist der uC-Takt unsauber. FPGAs reagieren da wesentlich schneller
als TTLs auf versaute Flanken und Ringing. Terminiere ihn mal, entweder mit
Parallelwiderstand (100-1k) gegen GND oder mit Serienwiderstand und evtl. C gegen
GND (~10p-100p).

--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[Bertram Geiger]

Robert Brehm wrote:

Moin Moin,

Ich arbeite mich gerade in die Welt der FPGA`s ein. Und zwar will ich
Meßdaten über einen AD Wandler wandeln und mit mit dem FPGA
bearbeiten. (Mittelwert, usw.).

Nur leider treten jetzt schon am Anfang des Projektes tausende kleiner
Probleme auf.

Ich habe um überhaupt erstmal Fuß zu fassen ein einfaches Toggle-FF in
den FPGA programmiert mit dem ich eine an den Clock Eingang des FPGA´s
angelegte Frequenz halbieren kann. So jetzt kommt der kritische Punkt.
Wenn ich nun an den Clock-Port des FPGA`s eine von einem
Frequenzgenerator erzeugte Frequenz anlegte dann läuft das System
100%ig. Sobalt ich aber mit einem Mikrocontroller eine Frequenz
erzeuge funktioniert das System nicht mehr !!!
Die Frequenz ist ungefähr 10Hz, also Pulsweiten von ca. 200ms, sowohl
beim Frequenzgenerator als auch beim Mikrocontroller erzeuge ich 5V
Signale.

FPGA sind verdammt schnell, viel schneller als dein Oszi und ein Auge ;-)
Meist liegen solche Effekte am Aufbau, d.h. unzureichende masseführungen
oder Einstreuungen in die Verbindung zwischen uP und FPGA.
Also:
1. Stützkondensatoren konsequent einsetzen !
2. DSeine Signale sind ja wirklich langsam, also gib einen kleinen C
direkt parallel zum FPGA Input, ev. auch einen kleinen R in Serie zum uP
Ausgang. 'klein' ist natürlich relativ, da kannst du ein wenig spielen.
Wenn du zu langsam wirst, kann das durch die zu flachen Anstiegszeiten
aber auch das Gegenteil auslösen, da hilft auch ein Schmitt Trigger
_direkt_ am FPGA weiter. Wie gesagt für die Experimentalphase, bei einem
brauchbaren layout sollte sowas nicht mehr auftreten.
3. andere Variante: bau dir einen kleinen Taktgenerator (z.B. Schmitt
trigger Inverter + R + C oder den uP Takt) und synchronisiere alle
Eingangssignale mittels D-FF, dann bist du ebenfalls clean.

viel Erfolg, Bertram

--

Bertram Geiger, Graz - AUSTRIA
Private Mail: remove the letters "b a d" from my reply address

 

[Robert Brehm]

Bertram Geiger <badnews_geiger@aon.at> wrote in message news:<3fd0e413$0$24020$91cee783@newsreader02.highway.telekom.at>...

Robert Brehm wrote:

Moin Moin,

Ich arbeite mich gerade in die Welt der FPGA`s ein. Und zwar will ich
Meßdaten über einen AD Wandler wandeln und mit mit dem FPGA
bearbeiten. (Mittelwert, usw.).

Nur leider treten jetzt schon am Anfang des Projektes tausende kleiner
Probleme auf.

Ich habe um überhaupt erstmal Fuß zu fassen ein einfaches Toggle-FF in
den FPGA programmiert mit dem ich eine an den Clock Eingang des FPGA´s
angelegte Frequenz halbieren kann. So jetzt kommt der kritische Punkt.
Wenn ich nun an den Clock-Port des FPGA`s eine von einem
Frequenzgenerator erzeugte Frequenz anlegte dann läuft das System
100%ig. Sobalt ich aber mit einem Mikrocontroller eine Frequenz
erzeuge funktioniert das System nicht mehr !!!
Die Frequenz ist ungefähr 10Hz, also Pulsweiten von ca. 200ms, sowohl
beim Frequenzgenerator als auch beim Mikrocontroller erzeuge ich 5V
Signale.


FPGA sind verdammt schnell, viel schneller als dein Oszi und ein Auge ;-)
Meist liegen solche Effekte am Aufbau, d.h. unzureichende masseführungen
oder Einstreuungen in die Verbindung zwischen uP und FPGA.
Also:
1. Stützkondensatoren konsequent einsetzen !
2. DSeine Signale sind ja wirklich langsam, also gib einen kleinen C
direkt parallel zum FPGA Input, ev. auch einen kleinen R in Serie zum uP
Ausgang. 'klein' ist natürlich relativ, da kannst du ein wenig spielen.
Wenn du zu langsam wirst, kann das durch die zu flachen Anstiegszeiten
aber auch das Gegenteil auslösen, da hilft auch ein Schmitt Trigger
_direkt_ am FPGA weiter. Wie gesagt für die Experimentalphase, bei einem
brauchbaren layout sollte sowas nicht mehr auftreten.
3. andere Variante: bau dir einen kleinen Taktgenerator (z.B. Schmitt
trigger Inverter + R + C oder den uP Takt) und synchronisiere alle
Eingangssignale mittels D-FF, dann bist du ebenfalls clean.

viel Erfolg, Bertram

Hi ,

....Bertram
Habe die Varianten 1+2 probiert. Jetzt tut sich am FPGA Ausgang (dort
wo eigentlich die halbierte Freq. anliegen sollte) etwas, aber immer
noch nicht perfekt. es sieht so aus als würde der FPGA nicht jeden
Puls erkennen und so kommt ein undefinierbarer Müll heraus.

Ich wäre Dir sehr verbunden wenn Du mir die Variante drei nochmal
etwas genauer erklären könntest, und muß ich wenn ich den AD Wandler
in der Erprobungsphase an den FPGA hänge mit ähnlichen Problemen
rechnen ???

Ich würde den AD Wandler mit Hilfe einer Lochrasterplatine
verschalten, und diese Platine mit einem Flachbandkabel mit dem FPGA
verbinden. Auch würde ich die Daten mittels ľC vom ADC auslesen und
über UART oder LCD ausgeben. Das auslesen dürfte dann aber keine
Probleme bereiten ( ? ! ). Wenn ich das auslesen über I˛C oder SPI Bus
vornehme würde ich dann auch Probleme bekommen ?

Sorry für die tausend Fragen ...

Schöne Grüße

Robert

 

[Bertram Geiger]

FPGA sind verdammt schnell, viel schneller als dein Oszi und ein Auge ;-)
Meist liegen solche Effekte am Aufbau, d.h. unzureichende masseführungen
oder Einstreuungen in die Verbindung zwischen uP und FPGA.
Also:
1. Stützkondensatoren konsequent einsetzen !
2. DSeine Signale sind ja wirklich langsam, also gib einen kleinen C
direkt parallel zum FPGA Input, ev. auch einen kleinen R in Serie zum uP
Ausgang. 'klein' ist natürlich relativ, da kannst du ein wenig spielen.
Wenn du zu langsam wirst, kann das durch die zu flachen Anstiegszeiten
aber auch das Gegenteil auslösen, da hilft auch ein Schmitt Trigger
_direkt_ am FPGA weiter. Wie gesagt für die Experimentalphase, bei einem
brauchbaren layout sollte sowas nicht mehr auftreten.
3. andere Variante: bau dir einen kleinen Taktgenerator (z.B. Schmitt
trigger Inverter + R + C oder den uP Takt) und synchronisiere alle
Eingangssignale mittels D-FF, dann bist du ebenfalls clean.

Habe die Varianten 1+2 probiert.

Wirklich konsequent und sauber ?

Jetzt tut sich am FPGA Ausgang (dort

wo eigentlich die halbierte Freq. anliegen sollte) etwas, aber immer
noch nicht perfekt. es sieht so aus als würde der FPGA nicht jeden
Puls erkennen und so kommt ein undefinierbarer Müll heraus.

naja, ferndiagnose ist schwierig. Du wirst nicht umhin kommen,
die Signale mit dem Oszilloskop zu analysieren, wenngleich die
schlimmen kleinen Störimpiulse schwer zu erkennen sind.
Slew rate eingehalten ? (Eingangssignal darf auch nicht zu
Langsam sein ! -> Schmitt-Trigger

Ich wäre Dir sehr verbunden wenn Du mir die Variante drei nochmal
etwas genauer erklären könntest, und muß ich wenn ich den AD Wandler
in der Erprobungsphase an den FPGA hänge mit ähnlichen Problemen
rechnen ???

An den Datenleitungen wirst du weniger Probleme haben, kritisch
sind die Taktsignale.
Also ich meinte das so:
Wenn - was recht wahrscheinlich ist - das Problem von
Störimpulsen an den Taktflanken auftritt, so kannst du die
Situation durch synchronisieren deiner Signale verbessern. Hole
dir von 'irgendwo' einen sauberen und schnellen Takt (eigener
Oszillator, uP). Dessen Güte kannst du testen, indem du einen
Teiler damit ansteuerst und schaust ob er sauber arbeitet.
Nun führst du dein zu verschönerndes Signal im PLD auf ein D-FF,
welches von deinem obigen Takt getaktet wird. Ist dein Takt
deutlich langsamer als die Störungen aber deutlich schneller als
dein 'Nutzsignal', so hast du ein sauberes und synchronisiertes
Signal zur Verfügung und klare Verhältnisse für die
Weiterverarbeitung. (Metastabilitätsbetrachtungen lassen wir
hier mal noch weg)

Ich würde den AD Wandler mit Hilfe einer Lochrasterplatine
verschalten, und diese Platine mit einem Flachbandkabel mit dem FPGA
verbinden. Auch würde ich die Daten mittels ľC vom ADC auslesen und
über UART oder LCD ausgeben. Das auslesen dürfte dann aber keine
Probleme bereiten ( ? ! ). Wenn ich das auslesen über I˛C oder SPI Bus
vornehme würde ich dann auch Probleme bekommen ?

wie schon gesagt, die Takte müssen sauber sein, obige Busse bzw.
Datenströme sind für FPGA ohnedies langsam wie eine Schnecke ;-)

Ich war bei ähnlichen Anwendungen (fliegende Laboraufbauten,
Demos) mit der Kombination: RC Glied + Schmitt-Trigger
möglichst nahe eigentlich immer erfolgreich, wenns auch manchmal
abenteurlich ausschaut ;-)

Grüsse, Bertram


--

Bertram Geiger, Graz - AUSTRIA
Private Mail: remove the letters "b a d" from my reply address

 

[jetmarc]

Habe die Varianten 1+2 probiert. Jetzt tut sich am FPGA Ausgang (dort
wo eigentlich die halbierte Freq. anliegen sollte) etwas, aber immer
noch nicht perfekt. es sieht so aus als würde der FPGA nicht jeden
Puls erkennen und so kommt ein undefinierbarer Müll heraus.

Neben dem Clock Signal musst Du auch das Reset Signal mit der gleichen
Sorgfalt zum FPGA leiten. Falls Du Kabel verwendest, nimm am besten
Flachbandkabel und isoliere die Signale gegen Uebersprechen indem Du
immer abwechselnd Masse und Signal nimmst. Mit Serien-R am Mikro und
C am FPGA solltest Du es hinbekommen.

Programmiere zum Test einen Zaehler im FPGA, und leite den Zaehlerstand
auf I/O Pins. Dann siehst Du genau wieviele Clocks Dein FPGA erkannt
hat, wenn Du "einen" Impuls schickst, und auch ob manche Flops einen
asynchronen Reset gemacht haben wo gar keiner sein sollte (zB wegen
Uebersprechen).

Marc

 

[Martin Lenz]

Robert Brehm schrieb:

Moin Moin,

Ich arbeite mich gerade in die Welt der FPGA`s ein. Und zwar will ich
Meßdaten über einen AD Wandler wandeln und mit mit dem FPGA
bearbeiten. (Mittelwert, usw.).

Nur leider treten jetzt schon am Anfang des Projektes tausende kleiner
Probleme auf.

Ich habe um überhaupt erstmal Fuß zu fassen ein einfaches Toggle-FF in
den FPGA programmiert mit dem ich eine an den Clock Eingang des FPGA´s
angelegte Frequenz halbieren kann. So jetzt kommt der kritische Punkt.
Wenn ich nun an den Clock-Port des FPGA`s eine von einem
Frequenzgenerator erzeugte Frequenz anlegte dann läuft das System
100%ig. Sobalt ich aber mit einem Mikrocontroller eine Frequenz
erzeuge funktioniert das System nicht mehr !!!
Die Frequenz ist ungefähr 10Hz, also Pulsweiten von ca. 200ms, sowohl
beim Frequenzgenerator als auch beim Mikrocontroller erzeuge ich 5V
Signale.

Ich weiß absolut nicht mehr weiter !!

FPGAs (Altera) reagieren teilweise extrem allergisch auf _zu_langsame_

Flanken. Also die im Thread teilweise propagierten RC Tiefpäße haben bei
mir meist mehr Probleme erzeugt als gelöst. Wichtiger als die RCs sind
schnelle Schmitt-Trigger (HC-MOS ist da teilwesie schon fast zu
langsam)direkt an den Eingängen, da kann man dann vorher bei Bedarf noch
mit RCs arbeiten. Bei flachen Flanken ergeben sich fast immer
Zusatzpulse durch Schwingungen an der Flanke.

Martin