Forum: FPGA, VHDL & Co. Grundlagen zur parallelen Verarbeitung von hohen Datenmengen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bisher habe ich mit ADCs gespielt deren Sampletakt geringer als der 
maximal erreichbare Takt im FPGA war. Ich konnte im FPGA also schön 
bequem z. B. gleitende Mittelwerte oder Peakerkennung machen.

Jetzt möchte ich aber sehr kurze Impulse erkennen, so grob 20 ns lang, 
und daher schneller abtasten. Ich dachte an 500 MSps oder mehr. Die 
Auflösung ist relativ egal, daher werde ich 8 Bits verwenden. Ich dachte 
an den AD9484BCPZ-500 (500 MSps, 500 MHz LVDS SDR) oder den HMCAD1511 (1 
GSps, 500 MHz DDR LVDS).

Ich bekomme also 500 MByte/s oder mehr ins FPGA, kann die Logik aber 
vermutlich nicht mit 500 MHz takten. Möchte aber weiterhin Peakerkennung 
und gleitenden Mittelwert oder so rechnen.

Ich könnte natürlich mal ein schnelleres FPGA kaufen und verlöten. Aber 
ob das FPGA die Rechnerei schafft sehe ich ja erst wenn ich den Code 
habe. Den habe ich noch nicht und weiß auch noch gar nicht wie der final 
seien wird, das kann sich also auch verändern.

Ich bin also auf der Suche nach so üblichen Herangehensweisen für die 
parallele Verarbeitung von vielen Daten.

: Bearbeitet durch User
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Du musst deinen Datenstrom eifnach auch parallelisieren. Z.B. mit zwei 
Ringbuffern und immer die t_2n Samples werden in einen und die t_2n+1 
Samples in den anderen Buffer geschrieben. Da kann ich nur den Einsatz 
von Ringbuffern empfehlen.

Dann kommt es darauf an was du mit den Daten machen moechtest. In der 
Regel brauchst du dann eine Trigger Bedingung welche das weitere 
Processing anstoesst, z.B. im einfachsten Fall einfach einen gewissen 
Schwellwert deiner Pulse. Dein Processing hat dann prinzipiell alle Zeit 
der Welt, erhoeht halt die Totzeit zwischen zwei eintreffenden Pulsen.

Das Prinzip wird in den ganzen Teilchendetektoren angewandt, wie sie 
z.B. am CERN zu finden sind. Riesige FPGA Arrays schaufeln die ADC Daten 
an eine zentrale Trigger Einheit, welche versucht in Echtzeit eine 
Filterung der Daten vorzunehmen. Interessant Ereignisse werden 
herausgeschrieben und evtl. noch vorprozessiert. Falls da Interesse 
besteht kann ich gerne mal ein paar Arbeiten zusammen suchen, von einem 
CERN Experiment an dem ich zu Uni Zeiten selbst mitgewirkt habe.

von -gb- (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klar, die Option mit dem Abspeichern habe ich immer. Das sind je Impuls 
nur wenige Samples. Ich kann das also entweder abspeichern und im FPGA 
verrechnen oder sogar zum PC schicken und dort rechnen. Aber das will 
ich eigentlich nicht.
Ich möchte ohne Totzeit z. B. einen kurzen FIR rechnen und dann auf 
dessen Ergebnis eine Peakerkennung machen.
Oder sagen wir ich möchte nur einen Trigger machen im FPGA. Dann muss 
der ja auch mehrere Samples vergleichen die parallel reinkommen. Als 
Beispiel bei 250 MHz Frameclock bekomme ich dann jeweils 4 Sample 
gleichzeitig.
n,n+1,n+2,n+3
n+4,n+5,n+6,n+7
...
Und da will ich triggern wenn
n < Schwelle und n+1 >= Schwelle.

Klar kann man das Hinschreiben, aber das gibt mehrere Bedingungen. Ich 
dachte da gibt es vielleicht elegante Standardherangehensweisen.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Du musst deinen Datenstrom einfnach auch parallelisieren.

Das ist mal die Grundlage von allem, dass du die Datenbusbreite erhöhst. 
Also anstatt mit 8 bit breite rechnest du dann mit 16, 32, 64,... bit 
breite.

Es ist natürlich selten trivial, deine eigentliche Berechnung zu 
parallelisieren bzw. sie in einzelne kleine Rechenschritte zu zerlegen 
und aus diesen kleinen schritten eine Pipeline zu bauen.

Kommt dann auch sehr auf die FPGA Architektur / Datenrate an, ob die 
BlockRAMs noch den Sample Takt mitmachen oder ob die auch schon zu 
langsam sind. (Daten an passender Stelle in der Pipeline aus dem 
FIFO/Ringpuffer auslesen vs. Daten mit durch die Pipeline schaufeln).

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Klar kann man das Hinschreiben, aber das gibt mehrere Bedingungen.

Das generate Statement hilf beim parallelisieren ungemein :-)

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Klar kann man das Hinschreiben, aber das gibt mehrere Bedingungen. Ich
> dachte da gibt es vielleicht elegante Standardherangehensweisen.
Ich habe bisher noch keinen eleganten Weg gefunden, mit mehrere Samples 
pro Takt gleichzeitig umzugehen, zumal wenn die Berechnungen voneinander 
abhängig sind.

Bei gepulsten Signalen, wie in Deinem Fall, würde ich sehen, ob ich mit 
den schnellen Daten einen FIFO füllen kann, um diesen dann langsam Takt 
für Takt abzuarbeiten.
Die Triggerei muß natrürlich mit allen Samples parallel geschehen und 
darf daher nicht zu aufwendig werden.

Duke

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> dass du die Datenbusbreite erhöhst.
> Also anstatt mit 8 bit breite rechnest du dann mit 16, 32, 64,... bit
> breite.

Ja genau. Ich habe beim HMCAD1511 dann 8 LVDS Lanes die mir die Daten 
mit jeweils 1 GBit/s anliefern. Mit der Frameclock, 1/8 der Samplerate, 
also 125 MHz bekomme ich dann 64 Bit gleichzeitig, also einen 8 Bit 
Samplewert je LVDS Lane.

Christoph Z. schrieb:
> Kommt dann auch sehr auf die FPGA Architektur / Datenrate an, ob die
> BlockRAMs noch den Sample Takt mitmachen oder ob die auch schon zu
> langsam sind.

Egal ob ich 500 MHz oder 1 GHz Sampletakt nehme, weder im Spartan7 noch 
im Artix7 kann der BlockRAM dann den vollen Sampletakt. Ich werde also 
z. B. den Takt der Frameclock verwenden.
Aber eigentlich möchte ich ja komplett ohne BRAM auskommen.

Die Werte kommen rein, werden FIR gefiltert und dann wird auf den 
Ausgang des FIRs eine Peakerkennung/Trigger gemacht.

Warum mache ich das überhaupt?

Wir messen hier Radioaktivität und zwar sehr schwache Proben. Da macht 
die Umgebungsstrahlung den Großteil der gemessenen Impulse aus. Klar 
haben wir das in einer Burg aus Bleiziegeln, aber das  hilft auch nur 
bedingt. Besser wäre die Messung tief unter der Erde zu machen aber ... 
dann müsste man sich in einem Tunnel einmieten und hätte andere Probleme 
wie Radon das aus dem Gestein rauskommt.
Aber das Schöne ist, dass einige Zerfälle schön charakteristisch sind. 
Ein Isotop zerfällt zuerst in eine sehr kurzlebige Tochter und die dann 
eben nach kurzer Zeit wieder weiter in eine langlebigere Tochter.
Das kann man ausnutzen, aber weil das verschiedene Zerfälle sind muss 
man gleichzeitig an der Probe alle Zerfallsarten messen.
Wir messen also gleichzeitig mit einem Germaniumdetektor, der liefert 
eine sehr gute Energieauflösung. Und wir verwenden einen Anzeigen 
Photomultiplier. Aber da ist die Energieauflösung recht schlecht, was 
egal ist wenn man den nur für das Timing verwendet.
Die Idee ist also das Signal des PMT nur für das Timing zu verwenden und 
um zwischen Alpha und Beta zu unterscheiden. Letzteres geht recht 
einfach auch wenn man die Impulse mit nur mit wenigen Bits Auflösung 
hat. Klar, man könnte nach der Impulsform gehen, aber die unterscheiden 
sich auch so schon recht deutlich.

Das Problem ist hier das Timing. Und zwar haben PMTs typischerweise 
einen TIA der aus dem kleinen Stron eine Spannung erzeugt. Und da ist 
die Bandbreite typischerweise sehr gering. Und zwar so gering, dass zwei 
Zerfälle die kurz hintereinander in der Probe passieren dann als Signal 
hinter dem TIA wie ein Impuls aussehen.
Wenn man aber das Signal an der Anode direkt anguckt, z. B. mit dem 
Oszi, dann kann man das unterscheiden, dann sind das sehr kurze einzelne 
Impulse denen ich dann einzelne Zeitstempel geben kann. Aber die Impulse 
sind eben kurz, ich muss also schnell abtasten und zwar so genau, dass 
ich zumindest die Zerfallsarten unterscheiden kann. So 6 rauschfreie 
Bits reichen da aber.

Duke Scarring schrieb:
> Ich habe bisher noch keinen eleganten Weg gefunden, mit mehrere Samples
> pro Takt gleichzeitig umzugehen, zumal wenn die Berechnungen voneinander
> abhängig sind.

Da hatte ich gehofft, dass es schon so standard Vorgehensweisen gibt.

Duke Scarring schrieb:
> Die Triggerei muß natrürlich mit allen Samples parallel geschehen und
> darf daher nicht zu aufwendig werden.

Richtig, gut, ich schreibe auch gerne viel HDL, das ist nicht das 
Problem, ich möchte nur nicht später sehen, dass man das üblicherweise 
irgendwie viel eleganter machen kann.

von berndl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi, koennte evtl. ein Flancter hilfreich fuer dich sein?
https://www.doulos.com/knowhow/fpga/fastcounter/

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Wir messen hier Radioaktivität und zwar sehr schwache Proben. Da macht
> die Umgebungsstrahlung den Großteil der gemessenen Impulse aus. Klar
> haben wir das in einer Burg aus Bleiziegeln, aber das  hilft auch nur
> bedingt. Besser wäre die Messung tief unter der Erde zu machen aber ...
> dann müsste man sich in einem Tunnel einmieten und hätte andere Probleme
> wie Radon das aus dem Gestein rauskommt.

Und warum musst du dann unbedingt ohne Totzeit detektieren? Entweder du 
hast genug Zerfaelle pro Sekunde, dann ist es egal wenn du einzelne 
Ereignisse verlierst oder du hast so wenige, dass du eh genug Zeit 
zwischen den Ereignissen hast. Deine Anwendung ist ein ganz klassische 
Fall fuer mein beschriebenes Vorgehen, wird seit Jahrzehnten in der 
Teilchenphysik so gehandhabt.

Wenn du allerdings auf biegen und brechen das in Realtime willst, dann 
musst du deine Algorithmen so clever aufbauen, dass nunmal ein Satz an 
Datensamples parallel verarbeitet wird. Ein Pauschalrezept wie das 
auszusehen hat gibt es dafuer nicht.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Ja genau. Ich habe beim HMCAD1511 dann 8 LVDS Lanes die mir die Daten
> mit jeweils 1 GBit/s anliefern. Mit der Frameclock, 1/8 der Samplerate,
> also 125 MHz bekomme ich dann 64 Bit gleichzeitig, also einen 8 Bit
> Samplewert je LVDS Lane.

OK, ja das ist so gedacht, dass du dann deine Verarbeitung mit 125 MHz 
und 8*8 bit parallel machst. Mit 125 MHz kannst du dann wieder Register 
oder BlockRAM nehmen, wenn du Berechnungen hast, die mehr als 8 Werte 
überstreichen oder Daten aus dem vorherigen Frame benötigen.

Wenn das immer noch zu schnell ist, dann kannst du das auch auf 16*8 bit 
aufblasen und mit 62.5 MHz rechnen.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Und warum musst du dann unbedingt ohne Totzeit detektieren?

Weil es um das Erkennen von kurz aufeinanderfolgenden Impulsen geht. Ich 
könnte höchstens immer Impulspaare abwarten und dann verarbeiten, aber 
dann müsste ich irgendwie ohne Totzeit erkennen, dass das Paare sind. 
Und es sind natürlich nicht immer Paare, sondern auch einzelne. Es geht 
darum aus den ganzen Zerfällen die paar wenigen herauszufiltern die 
tatsächlich aus der Probe stammen. Das sind im Vergleich zu der 
natürlichen Radioaktivität und Höhenstrahlung sehr wenige, aber die 
haben charakteristische Eigenschaften wodurch man sie erkennen kann.
Ich bin aber gerade nur dabei mir das zu überlegen. Wir haben schon 
Messmethoden mit denen das auch mit langsamen ADC funktioniert, 
allerdings haben die Nachteile. Man kann dann nur anhand der Energieen 
Impulse unterscheiden und keine kurz aufeinander folgenden Doppelimpulse 
erkennen.
Das mit der gemütlichen Verarbeitung nach Speicherung werde ich mir 
jedenfalls mal merken ...

Christoph Z. schrieb:
> Mit 125 MHz kannst du dann wieder Register
> oder BlockRAM nehmen,

Exakt.

Christoph Z. schrieb:
> wenn du Berechnungen hast, die mehr als 8 Werte
> überstreichen oder Daten aus dem vorherigen Frame benötigen.

Und darum geht es mir, ob es für typische Berechnungen wie FIR und 
Trigger Herangehensweisen gibt wenn immer mehrere Samples parallel 
ankommen.

Mal gucken ob ich das wirklich baue. Wäre zwar schön auch um zu lernen, 
aber ich müsste auch das Thema Takterzeugung und Verteilung anfassen.

berndl schrieb:
> Hi, koennte evtl. ein Flancter hilfreich fuer dich sein?

Ob ich das hier brauche weiß ich noch nicht, aber das sieht trotzdem 
interessant aus, vielen Dank!

: Bearbeitet durch User
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Noch eine Nachfrage zur Takterzeugung:

Ich möchte ja den Jitter gering halten, aber auch keinen Oszillator 
fester Frequenz an den ADC anschließen, weil ich den Takt auch 
reduzieren können möchte wenn das mit dem SerDes nicht so funktioniert 
wie ich will.

Was macht da mehr Sinn:

1. Externe PLL wie die https://www.analog.com/en/products/ltc6951.html 
mit 100 MHz Referenz.

2. Einen programmierbaren Oszillator wie den 
https://www.silabs.com/documents/public/data-sheets/si544-datasheet.pdf 
und dann damit entwider direkt in den ADC oder zuerst in einen 
Taktverteiler wie den 
https://www.analog.com/media/en/technical-documentation/data-sheets/AD9508.pdf 
.
Wobei ich den Sampletakt ja sowieso nicht im FPGA brauchen kann, das 
FPGA bekommt dann vom ADC den FrameClock (1/8 Fsample) und den halben 
Sampletakt für den SerDes. Das mit dem AD9508 wäre trotzdem nett weil 
ich dann auch gleich meinen FPGA Systemtakt damit erzeugen könnte und 
weitere Takte die ich brauche.

: Bearbeitet durch User
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Weil es um das Erkennen von kurz aufeinanderfolgenden Impulsen geht. Ich
> könnte höchstens immer Impulspaare abwarten und dann verarbeiten, aber
> dann müsste ich irgendwie ohne Totzeit erkennen, dass das Paare sind.
> Und es sind natürlich nicht immer Paare, sondern auch einzelne. Es geht
> darum aus den ganzen Zerfällen die paar wenigen herauszufiltern die
> tatsächlich aus der Probe stammen. Das sind im Vergleich zu der
> natürlichen Radioaktivität und Höhenstrahlung sehr wenige, aber die
> haben charakteristische Eigenschaften wodurch man sie erkennen kann.

Das schliesst das Vorhaben immer noch nicht aus. Die stellst einen 
Trigger ein, wenn der ausloest wird dein Buffer vollgeschrieben und die 
Daten kannst du dann in Ruhe nach den Doppelpulsen untersuchen. Es gibt 
hier immer noch keinen Grund fuer eine Totzeit freie Messung.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Ja das stimmt schon, ich finde das nur eleganter wenn ich das ohne 
Zwischenspeicherei machen könnte so wie jetzt. Derzeit habe ich mehrere 
langsame ADCs, die Sample laufen durch einen FIR und dahinter wird der 
Peak erkannt.
Bei der Zwischenspeicherei ist das Problem, oder das vermute ich 
zumindest, dass das recht aufwendig wird. Die Impulse sind zwar so nah 
zusammen, dass der TIA am PMT die zu einem Impuls macht, aber sie sind 
trotzdem bei 1 GSample/s viele Samples getrennt. Ist ja Statistik, aber 
das können schon mal mehrere wenige us sein, das müssten also viele 
Samples im Speicher sein. Wenn ich die dann nachträglich verarbeitet 
kann das zu viel Totzeit führen. Oder man macht das mit mehreren 
Zwischenspeichern so round robin mäßig. Das wäre dann allerdings wieder 
schick.

Eine andere Möglichkeit wäre das mit den doppelten Impulsen zu 
ignorieren und einfach jeden Impuls mit Zeitstempel und Energiewert 
auszugeben. Dann kann man später am PC in Software schön filtern und 
dann auch Zeitfenster setzen.
Vorteil wäre, dass man bei einzelnen Impulsen nur sehr wenig 
zwischenspeichern müsste. Die sind so maximal 20 ns lang, das sind also 
nur wenige Samples.

: Bearbeitet durch User
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ne garnicht. Einfacher und flexibler bist du wenn du die Daten erst 
bufferst und dann ebarbeitest. Idealerweise dann via Microblaze oder 
noch besser nenn Zynq. Dann hast du da auch ordentlich Rechenpower und 
Alogirthmen auf deine Daten sind viel schneller und einfacher 
implementiert.

Je nachdem wie dein Detektor aufgebaut ist und was du dir aus der 
Messung erhoffst, koennen da zum Teil fuer einen FPGA die Algorithmen 
(z.B. eine Deconvolution) recht schnell komplex werden, auch das Testing 
ist nich zu vernachlaessigen. Bei der geringen Datenmenge bist da mit 
einem Prozessor als Auswerteeinheit deutlich effektiver unterwegs.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Da hast du vermutlich Recht. Ich habe bisher kaum was mit CPUs gemacht 
und fühle mich bei HDL eher wohl. Aber vielleicht sollte ich mich mal an 
einen Zynq herantrauen.
Da kann man ja auch ohne Linux und DDR RAM auskommen wenn ich das 
richtig sehe.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Da kann man ja auch ohne Linux und DDR RAM auskommen wenn ich das
> richtig sehe.

Ohne Linux kommst du richtig weit, fuer deine Anwendung brauchst du 
nichtmal ein RTOS. Aber ganz ohne RAM ist dann doch etwas unschoen, 
gerade bei den grossen Datenmengen. Der Zynq hat aber seinen eigenen 
Speichercontroller im Prozessor System, das macht die Sache super easy 
zum einsteigen.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Hm, welchen Zynq würdest du empfehlen? Bisher habe ich den Spartan7 mit 
1 mm Bällchenabstand verlötet. Da ist auch die Spannungsversorgung recht 
einfach machbar. DDR RAM habe ich noch nie gelayoutet.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Hm, welchen Zynq würdest du empfehlen? Bisher habe ich den
> Spartan7 mit
> 1 mm Bällchenabstand verlötet. Da ist auch die Spannungsversorgung recht
> einfach machbar. DDR RAM habe ich noch nie gelayoutet.

Fuer diese Aufgabe? Den erst besten der mit unter die Naegel kommt. Die 
ARM Cores sind innerhalb der Familien alle gleich. Idealerweise ein 
Evalboard nehmen, bei den Stueckzahlen wuerde ich mir nicht die Muehe 
machen.

Theoretisch tuts auch ein Microblaze, daher wird auch schon ein Artix 7 
ausreichen.

: Bearbeitet durch User
von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Idealerweise dann via Microblaze oder
> noch besser nenn Zynq. Dann hast du da auch ordentlich Rechenpower und
> Alogirthmen auf deine Daten sind viel schneller und einfacher
> implementiert.
Zynq und einfach? Hast Du damit schon gearbeitet oder bisher nur die 
Marketing-Slides angeschaut?

Meine Erfahrung sind nämlich anders: Da ist nix mit schnell gemacht...

Duke

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Den erst besten der mit unter die Naegel kommt. Die
> ARM Cores sind innerhalb der Familien alle gleich.

Ich frage vor allem weil ich das Marketing von Xilinx nicht so wirklich 
verstehe. Ist Ultrascale der Nachfolger von der 7 Serie und man sollte 
also Ultrascale verbauen weil irgendwann eine Software den Support 
hinten abschneidet? Oder laufen die Produkte parallel und 7 Series ist 
quasi lowend?

Tobias B. schrieb:
> bei den Stueckzahlen wuerde ich mir nicht die Muehe
> machen.

Klar, wirtschaftlich macht das alles keinen Sinn, da könnte ich das 
komplett bleiben lassen. Mir geht es drum eine Messmethode 
auszuprobieren und auch Elektronik zu lernen. Das ist für mich alles 
erstmal Hobby und macht ja auch Spaß.

Tobias B. schrieb:
> Theoretisch tuts auch ein Microblaze, daher wird auch schon ein Artix 7
> ausreichen.

Das wäre auch eine Überlegung. Dann könnte ich aber auch beim Spartan7 
bleiben. Denn wenn sowieso die CPU die Rechnerei erledigt brauche ich 
nicht viele DSP Slices oder so und für die paar Sample reicht der BRAM 
locker. Die LVDS Eingänge sind bei Artix leider auch nicht schneller als 
beim Spartan, ist aber egal, denn das ist schnell genug.

Duke Scarring schrieb:
> Zynq und einfach?

Ich kenne mich damit gar nicht aus, weiß aber, dass zusätzlich zum HDL 
dann noch Software dazu kommt die man bauen muss. Dann ist für mich 
unklar wie das mit dem JTAG läuft, also ob die ARM Kerne und das FPGA 
sich einen JTAG teilen oder ob ich dann zwei Adapter brauche und auch 
das Debugging stelle ich mir schwieriger vor. Oder kann man sich das 
einfach wie bei einem reinen FPGA simulieren lassen nur, dass beim Zynq 
auch der ARM mit der Software mitsimuliert wird?
Ich denke das wird fast einfacher, wenn ich die Rechnerei zum PC hin 
auslagere. Ein kleines FPGA sammelt die Daten ein, schickt die zum 
Rechner, dort wird dann die Peakhöhe bestimmt und in eine Aufnahme 
ausgegeben/geschrieben.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Meine Erfahrung sind nämlich anders: Da ist nix mit schnell gemacht...

Nee, schnell ist nicht. Mit keinem Prozessor dieser Leistungsklasse und 
dann noch einen FPGA dazu. Das Technical Refrence Manual ist gut, 
erschlägt einem aber im ersten Moment nur schon durch die Seitenzahl.

Gustl B. schrieb:
> Klar, wirtschaftlich macht das alles keinen Sinn, da könnte ich das
> komplett bleiben lassen. Mir geht es drum eine Messmethode
> auszuprobieren und auch Elektronik zu lernen. Das ist für mich alles
> erstmal Hobby und macht ja auch Spaß.

Wir verwenden hier recht gerne das MicroZed Board von Avnet. Ziemlich 
günstig und eben kein Evalboard sondern gedacht um damit eine Anwendung 
in kleinen Stückzahlen zu bauen.

Gustl B. schrieb:
> Ich kenne mich damit gar nicht aus, weiß aber, dass zusätzlich zum HDL
> dann noch Software dazu kommt die man bauen muss. Dann ist für mich
> unklar wie das mit dem JTAG läuft, also ob die ARM Kerne und das FPGA
> sich einen JTAG teilen oder ob ich dann zwei Adapter brauche und auch
> das Debugging stelle ich mir schwieriger vor.

Das läuft gleich wie mit dem Microblaze, da kommt auch Software dazu und 
in Vivado ist es gleich aufgebaut, egal ob dein Target ein Microblaze 
enthält oder einen ARM.

Du hast einen einzelnen JTAG Anschluss zum Konfigurieren und Debuggen. 
Brakepoints und ILA (Chipscope) Triggern kann man auch zusammenknüpfen.

> Oder kann man sich das
> einfach wie bei einem reinen FPGA simulieren lassen nur, dass beim Zynq
> auch der ARM mit der Software mitsimuliert wird?

Schön wärs, ja. Wir bauen die FPGA Teile wie gewohnt in HDL und mit 
Testbench bis sie laufen, dann schreiben wir Embedded Software dazu und 
Debuggen die per JTAG.

Es gibt Ansätze das auch zusammen zu simulieren, leider ist da Xilinx 
selber nicht so weit wie sie sein müssten. Es gibt so "Demos" mit Qemu 
und Icarus (SystemVerilog), Renode oder CocoTb. Strubi hier im Forum ist 
ja hier super Fit (gefühlte 10 Jahre voraus zu allen anderen die ich 
kenne oder zusammenarbeite).

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Nee, schnell ist nicht. Mit keinem Prozessor dieser Leistungsklasse und
> dann noch einen FPGA dazu.

Hm ...

Christoph Z. schrieb:
> Wir verwenden hier recht gerne das MicroZed Board von Avnet.

Sieht interessant aus.

Christoph Z. schrieb:
> Das läuft gleich wie mit dem Microblaze, da kommt auch Software dazu und
> in Vivado ist es gleich aufgebaut, egal ob dein Target ein Microblaze
> enthält oder einen ARM.

Das ist doch schonmal schön.

Christoph Z. schrieb:
> Strubi hier im Forum ist
> ja hier super Fit (gefühlte 10 Jahre voraus zu allen anderen die ich
> kenne oder zusammenarbeite).

Das stimmt allerdings.

Nun gut, mir erscheint es da tatsächlich einfacher wenn ich in einem 
kleinen FPGA einen einfachen Trigger in HDL einbaue und dann jeweils die 
Sampledaten des Impulses an den PC schicke.
Das mit dem Zynq schaue ich mir dann mal getrennt an. Das möchte ich ja 
auch mal gemacht haben weil das jetzt modern ist.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Nee, schnell ist nicht. Mit keinem Prozessor dieser Leistungsklasse und
> dann noch einen FPGA dazu. Das Technical Refrence Manual ist gut,
> erschlägt einem aber im ersten Moment nur schon durch die Seitenzahl.

Die Prozessorleistungsklasse ist doch unerheblich ob die Implementierung 
schnell oder nicht ist.

Im Vergleich zu das ganze zu 100% im FPGA machen, ist das aber definitiv 
schneller. Wenn er den HDL Code eh shcon aht fuer die ADCs, dan muss er 
nur noch einen AXI Wrapper schreiben und die Daten in einem Speicher 
ablegen. Wenn er genug BRAM hat kann er auch laessig einen dedizierten 
BRAM fuer die ADC Daten als Ringbuffer nehmen. Seinen Trigger den er in 
HDL schreibt erzeugt nenn Interrupt und wenn dieser ausloest kann er die 
Daten vom Prozessor aus aus dem BRAM holen und verarbeiten wie er 
moechte.

Eine Schleife ueber eine Speicher Offsetadresse bekommt doch wohl jeder 
von uns hin ohn das gleich als Aufwand zu bezeichnen?

Duke Scarring schrieb:
> Zynq und einfach? Hast Du damit schon gearbeitet oder bisher nur die
> Marketing-Slides angeschaut?
>
> Meine Erfahrung sind nämlich anders: Da ist nix mit schnell gemacht...

Klar, mehr als nur einmal. Dein Prblem ist nunmal das du nicht die 
Erfahrung hast, sondern dir die Erfahrung fehlt. Deshalb ist erscheint 
auch dieses Miniprojekt bei dir auch wie ein Mords Akt. Daher kann ich 
nur empfehlen: ueben, ueben, ueben. ;-)

von Frank K. (fchk)


Bewertung
0 lesenswert
nicht lesenswert
Überlege doch mal, ob Du Dein Interface nicht auf eine M.2 Typ M Karte 
oder eine normale PCIe x8 Karte bekommst und das dann mit einem NVidia 
Xavier (entweder dem großen AGX oder dem kleinen NX) koppelst. Da hast 
Du dann nämlich eine GPU, die Tausende von CUDA Kernen hat, die alle 
parallel arbeiten. Xavier hat Unified Memory, d.h. Du hast nicht wie 
beim PC separaten GPU-Speicher, sondern die 32GB auf dem AGX sind voll 
von der GPU nutzbar. Die Arms sind dann nur fürs Management da, und um 
die DMAs passend anzuwerfen.

fchk

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Im Vergleich zu das ganze zu 100% im FPGA machen, ist das aber definitiv
> schneller.

Das weiß ich nicht. Ich müsste mich erst in dieses ganze Zynq Ökosystem 
einarbeiten (was ich sowieso mal machen sollte).
Schneller/einfacher wäre es das am PC zu rechnen. Also wie du 
beschrieben hast, kleiner Speicher im FPGA, Trigger im FPGA und dann 
wird der Speicher nach jedem Trigger zum PC geschickt. Die Datenraten 
sind auch eher sehr gemütlich. Sagen wir maximal 1k Impule/s (ist 
wahrscheinlich deutlich zu hoch gegriffen, aber über 100 gibt es schon 
manchmal). Dann ist jeder Impuls so 20 ns lang, macht bei 1 GSample/s 
also 20 Samples, da würde ich vorher und nachher noch was dazu nehmen, 
also so 64 Samples insgesammt. Und dann noch ein Zeitstempel. Also < 100 
Bytes/Impuls und < 100 kByte/s. Das kann man locker sogar über UART an 
den PC schicken.

Frank K. schrieb:
> Überlege doch mal, ob Du Dein Interface nicht auf eine M.2 Typ M Karte
> oder eine normale PCIe x8 Karte bekommst und das dann mit einem NVidia
> Xavier (entweder dem großen AGX oder dem kleinen NX) koppelst.

Äh ... nun, man warf mir schon overengeneering vor, das möchte ich 
ungerne wiederholen.

Ein anderes Problem habe ich noch und frage das hier einfach auch noch:

Und zwar geht es ja drum von den Impulsen die Höhe zu messen. Jetzt 
bekomme ich aber von jedem Impuls nur wenige Abtastpunkte und es ist 
unwahrscheinlich, dass da immer einer der Abtastpunkte das Maximum 
getroffen hat.
Wie bekommt man denn die Höhe die der Impuls hatte wenn man nur so 
wenige Stützpunkte hat? Das Signal würde ich natürlich in der Bandbreite 
begrenzen, man kann also aus den Abtastpunkten das tatsächliche Signal 
rekonstruieren. Mir geht es um eine einfache Methode wie man das macht.
Danz primitiv würde ich virtuell die Samplerate deutlich erhöhen und 
dann mit einer schönen Tiefpass filtern. Dann hätte ich eine glatte 
Kurve mit vielen Stützstellen und könnte davon dann die höchste nehmen.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Also wenn du ein PC zur Verfuegung hast, dann wuerde ich die Auswertung 
acuh am PC machen. ROOT ist da das absolute Mittel der Wahl:

https://de.wikipedia.org/wiki/ROOT

Aber selbst fuer diese Aufgabe wuerde ich noch einen Prozessor nehmen. 
In diesem Fall einen Microblaze (ohne DDR Speicher). UART Protokolle 
sind in Software einfach schneller entwickelt als in Hardware. Gerade 
fuer UART verwende ich gern eine Eigenentwicklung welches ein Handshake 
Verfahren verwendet, angelehnt an TCP.

ICh wuerde diesen Schritt wirklich mal wagen, der Einstieg ist bei 
Weitem nicht so schwierig, wie hier im Forum suggeriert wird. Am besten 
mit einem Hello World UART Beispiel anfangen und dann Schrittweise BRAM 
und Interrupts hinzufuegen (das letzte ist als Neuling wahrscheinlich 
das schwierigste, aber auch nix weltbewegendes - ausserdem ist die Menge 
an Leuten die Helfen koennen noch groesser, weils nicht mehr FPGA 
sondern Mikrocontroller ist ;-)).

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Die Prozessorleistungsklasse ist doch unerheblich ob die Implementierung
> schnell oder nicht ist.

Die Anzahl Seiten an Dokumentation steigt halt mit der Leistungsklasse 
und entsprechend auch die Einarbeitungszeit. Merkt man nur schon wenn 
man vom AVR zum STM32 wechselt, weil sie ja gleich wenig kosten aber nun 
kommt z. B. noch eine DMA Einheit mit etc.

Tobias B. schrieb:
> Seinen Trigger den er in
> HDL schreibt erzeugt nenn Interrupt und wenn dieser ausloest kann er die
> Daten vom Prozessor aus aus dem BRAM holen und verarbeiten wie er
> moechte.
>
> Eine Schleife ueber eine Speicher Offsetadresse bekommt doch wohl jeder
> von uns hin ohn das gleich als Aufwand zu bezeichnen?

Nee, ein Aufwand ist diese Aufgabe nicht, nach dem man sich x Tage in 
Vivado & Vivado SDK eingearbeitet hat, endlich weiss, wo welche Häckchen 
zu setzen sind, damit da auch eine Interrupt Leitung ist und nach 
weiteren Tagen hat man es geschafft, das die Triggereinheit ein Xilinx 
IP core ist, bei dem die Offset Adresse automatisch in der Header Datei 
landet und der Softwaretreiber automatisch ins SDK Projekt kopiert wird.

Die Tutorials vom MicroZed waren für mich ziemlich hilfreich: 
http://zedboard.org/support/design/1519/10

Beim zweiten Mal gehts dann ganz fix.

Tobias B. schrieb:
> Daher kann ich
> nur empfehlen: ueben, ueben, ueben. ;-)

Definitiv. Diese FPGA-SoCs machen generell schon Spass, weil mit denen 
kaum etwas unmöglich ist und wenn die Prozessor Peripherie nicht passt, 
dann hat man viel FPGA Platz um da alles rein zu bauen in einer 
Kombination die man so sicher nie kaufen könnte.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Aber selbst fuer diese Aufgabe wuerde ich noch einen Prozessor nehmen.
> In diesem Fall einen Microblaze (ohne DDR Speicher). UART Protokolle
> sind in Software einfach schneller entwickelt als in Hardware.

Ja, das kann gut sein. Bisher habe ich das alles in HDL gemacht. Und was 
Protokolle angehet, das muss ja nicht irre komplex werden. Da definiert 
man ein Paket mit fester Länge und schon kann man da Daten an den PC 
schicken. Geht mit FT2232H/FT600 auch schnell. Aber ja, man ist in 
Software natürlich deutlich flexibler, das wäre ein Vorteil.

Tobias B. schrieb:
> ICh wuerde diesen Schritt wirklich mal wagen, der Einstieg ist bei
> Weitem nicht so schwierig, wie hier im Forum suggeriert wird. Am besten
> mit einem Hello World UART Beispiel anfangen [...]

Das hatte iich schon mal gemacht, aber den Vorteil nicht gesehen. Ich 
hatte damals versucht die Daten von Blockram zum FT2232H durch den 
Microblaze zu schieben. Also im BRAM lagen die ADC Samples, der 
Mikroblaze sollte daraus dann Pakete bauen (jeweils n Samples 
aufsummieren) und ausgeben. Aber das war schnarchlangsam. In reinem HDL 
konnte ich USB2 fast voll auslasten.

Christoph Z. schrieb:
> nach dem man sich x Tage in
> Vivado & Vivado SDK eingearbeitet hat, endlich weiss, wo welche Häckchen
> zu setzen sind, damit da auch eine Interrupt Leitung ist und nach
> weiteren Tagen hat man es geschafft, das die Triggereinheit ein Xilinx
> IP core ist, bei dem die Offset Adresse automatisch in der Header Datei
> landet und der Softwaretreiber automatisch ins SDK Projekt kopiert wird.

Und das will ich mir gerne erstmal sparen. Wenn Zynq, dann würde ich 
auch gleich Ethernet verwenden wollen, aber dann muss ich auf der PC 
Seite meine Software deutlich umschreiben. Da müsste ich mich wirklich 
erstmal einarbeiten. Aber das ist ja nicht schlimm. Werde ich machen, 
aber nicht bei diesem Projekt wobei ich mir jetzt noch etwas über Zynq 
einlesen werde. Vielleicht kann man den Artix ja einfach durch einen 
Zynq ersetzen und muss nicht alles neu machen. Man könnte ja auch zuerst 
den Zynq nur wie einen FPGA verwenden.

Nachtrag:
Ist der Zynq Ultrascale der Nachfolger vom der 7k Serie oder existieren 
die nebeneinander?
Und dann haben die alle deutlich mehr BGA Bällchen als so ein kleiner 
Spartan. Da würde eine Platine mit vielen Lagen teuer werden. Aber ich 
kann doch weiterhin nur wenige IOs routen (auf wenigen Lagen) und die 
restlichen Bällchen unverbunden lassen?
Die Zynq sehen schick aus weil die schon ziemlich viel BRAM und DSPs 
drinnen haben. Vielleicht könnte ich da den Datenstrom sogar in Echtzeit 
filtern.

: Bearbeitet durch User
von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Die Anzahl Seiten an Dokumentation steigt halt mit der Leistungsklasse
> und entsprechend auch die Einarbeitungszeit. Merkt man nur schon wenn
> man vom AVR zum STM32 wechselt, weil sie ja gleich wenig kosten aber nun
> kommt z. B. noch eine DMA Einheit mit etc.

Die Doku steigt aber nicht mit der Leistungsklasse sondern mit den 
Features die auf dem Chip sind. Und wenn ich 98% der Features nicht 
brauche, dann brauch ich auch 98% der Doku nicht lesen.

Gustl B. schrieb:
> Das hatte iich schon mal gemacht, aber den Vorteil nicht gesehen. Ich
> hatte damals versucht die Daten von Blockram zum FT2232H durch den
> Microblaze zu schieben. Also im BRAM lagen die ADC Samples, der
> Mikroblaze sollte daraus dann Pakete bauen (jeweils n Samples
> aufsummieren) und ausgeben. Aber das war schnarchlangsam. In reinem HDL
> konnte ich USB2 fast voll auslasten.

Das ist auch nochmal ein anderer Anwendungsfall und da muss man auch 
schauen wie man die Anbindung an den FT2232 ordentlich macht. Da geht es 
dann Richtung DMA damit man auch die volle Performance ausschoepfen 
kann. Eben wie bei einem Mikrocontroller auch.

Nur weil man die Technologie nicht richtig beherscht, sollte man sie 
nicht gleich verteufeln. Vielleicht einfach ordentlicher einarbeiten. 
;-)

Gustl B. schrieb:
> Nachtrag:
> Ist der Zynq Ultrascale der Nachfolger vom der 7k Serie oder existieren
> die nebeneinander?

Die Ultrascale(+) sind die Nachfolger, beide Familien existieren aber 
parallel. Genauso wie die anderen Familien eben auch.

Und wie schon gesagt, wenn du das Processing am PC machst reicht fuer 
diese Anwendung auch ein Microblaze ohne DDR RAM auf einem Spartan 7.

: Bearbeitet durch User
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Nur weil man die Technologie nicht richtig beherscht, sollte man sie
> nicht gleich verteufeln. Vielleicht einfach ordentlicher einarbeiten.
> ;-)

Vollkommen richtig, ich verteufel hier aber auch nix. Ich habe mit HDL 
bisher recht gut das erreicht was ich erreichen wollte und sehe auch 
jetzt oft keinen Grund einen Prozessor zu verbauen.

Tobias B. schrieb:
> Die Ultrascale(+) sind die Nachfolger, beide Familien existieren aber
> parallel. Genauso wie die anderen Familien eben auch.

OK, danke. Ich finde das doch irgendwie seltsam von Xilinx und weiß dann 
nicht was ich machen soll. Es droht eben immer die Gefahr, dass man dann 
wie beim Spartan6 abgehängt ist und nicht mit der neuen Software 
arbeiten kann.

Tobias B. schrieb:
> Und wie schon gesagt, wenn du das Processing am PC machst reicht fuer
> diese Anwendung auch ein Microblaze ohne DDR RAM auf einem Spartan 7.

Dann bleibe ich dabei. Denn da habe ich schon Versorgung und alles 
wunderbar im Griff.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> OK, danke. Ich finde das doch irgendwie seltsam von Xilinx und weiß dann
> nicht was ich machen soll. Es droht eben immer die Gefahr, dass man dann
> wie beim Spartan6 abgehängt ist und nicht mit der neuen Software
> arbeiten kann.

Du produzierst hier doch Einzelstuecke? Die Softwrae ist verfuegbar und 
die Chips auch noch viele Jahre. Da wuerde ich nicht eine Sekunden fuer 
verschwenden, ist doch alles nicht-kommerziell?

Und die Spartan6 bekommst du heute auch noch, die werden sogar noch 
produziert und auch die Tools sind noch verfuegbar.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Stimmt auch wieder.

Wie macht man das eigentlich bei der Versorgung von so FPGAs, welchen 
Wert nimmt man da für den Strom? Ja, ich kenne dieses XPE Teil, da 
fallen auch Werte raus je nach Verwendung im FPGA, aber wie geht man da 
typischerweise heran und wie viel mehr Strom sollte die Versorgung 
können?

Als Beispiel sagt mir das XPE jetzt mal 2,5 A auf 1.0 V. Reicht dann ein 
DCDC der 3 A liefern kann oder würde man als Profi mehr Sicherheit 
drauflegen?
Bisher verwende ich den https://www.ti.com/lit/ds/symlink/tps65266.pdf 
und bin sehr zufrieden. Der hab jetzt bei mehreren verschiedenen Layouts 
nie Probleme gemacht und hat auch immer genug Strom geliefert. Aber 
jetzt kommt eben ein schneller ADC, ein langsamerer ADC, USB ICs und 
Analogschaltung vor den ADCs dazu.

Vieler der Bausteine speziell für FPGAs sehen irre kompliziert aus und 
wollen programmiert werden. Wenn dann dachte ich an den ADP5054 oder so.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Wie macht man das eigentlich bei der Versorgung von so FPGAs, welchen
> Wert nimmt man da für den Strom? Ja, ich kenne dieses XPE Teil, da
> fallen auch Werte raus je nach Verwendung im FPGA, aber wie geht man da
> typischerweise heran und wie viel mehr Strom sollte die Versorgung
> können?

Du schaust auf entsprechendem Evalboard nach wie da die Stromverorgung 
aufgebaut ist. Am einfachsten ist es spezielle Regler zu verwenden die 
fuer den FPGA Typ entwickelt wurden, da ist dann auch die Ein- und 
Abschaltsequenz geregelt.

Das ist aber wirklich ein Thema fuer sich, vll ist es besser dafuer ein 
extra Thread aufzumachen?

: Bearbeitet durch User
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Ja stimmt, werde ich machen. Zu der Eingangsbeschaltung von schnellen 
ADCs habe ich auch noch Fragen. Aber ich mache ja gerne Threads auf^^. 
Jedenfalls vielen Dank!

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
So, ich habe mich jetzt für einen Artix entschieden.
Aber ich brauche bei weitem nicht alle IOs. Kann ich ungenutze IOs 
unverbunden lassen? Ich würde sagen Ja.
Und wie sieht es bei einer Bank aus die ich nicht verwende, muss da 
trotzdem VCCO angeschlossen sein?
Und dann brauchen LVDS Eingänge scheinbar nur minimal Strom über VCCO, 
da sollte also ein kleiner LDO für die 2,5 V genügen.
BRAM und DSP brauchen auch erstaunlich wenig Strom.

von Klakx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Aber ich brauche bei weitem nicht alle IOs. Kann ich ungenutze IOs
> unverbunden lassen? Ich würde sagen Ja.

jep. man könnte sogar noch im bitfile "unused pulldown" oder "unused 
pullup" einstellen. Das ist natürlich erst nach dem Programmieren 
gültig. In der Regel muss man nichts machen.

Gustl B. schrieb:
> Und wie sieht es bei einer Bank aus die ich nicht verwende, muss da
> trotzdem VCCO angeschlossen sein?

Diesen Fall hatte ich noch nicht überlegt, da meist immer irgendwas 
dranhängt. Eigentlich könnte man die ungenutze Bank auslassen, aber wehe 
da ist etwas angeschlossen (reverse biasing of bank). Ansonsten einfach 
die Spannung von der Nachbarbank anschließen. Die statische Leistung ist 
in der 7er Generation ganz angenehm gering.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Wunderbar, Danke! Hach wenn man nur wenige IOs verwendet lässt sich 
sogar ein BGA stressfrei auf wenigen Lagen routen (-:

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Fuer solche Falle wuerde ich immer in den entsprechenden PCB Design 
Guide schauen. Den bietet so ziemlich jeder FPGA Hersteller zu seinem 
FPGA an. Die sind meistens unter 100 Seiten und laessig an einem 
Nachmittag durchgearbeitet.

Beim Artix 7 ist das UG483 und da gibt es ein kompletten Abschnitt zu 
dem Thema:

https://www.xilinx.com/support/documentation/user_guides/ug483_7Series_PCB.pdf

Seite 36.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank! Das Dokument kannte ich schon weil da auch drinnen steht 
wie viele und welche Kondensatoren an welche Versorgung sollen, aber 
diesen Teil kannte ich noch nicht. Ich werde einfach das VCCO 
anschließen und unbenutzte Pins dann im Bitstream auf Pullup/Pulldown 
legen.

von René D. (Firma: www.dossmatik.de) (dose)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Gustl,

ich hatte mal so eine ähnlichen Fall für einen Laser.
Das Projekt nannte sich Multistop.

Da gab es noch keinen High-speed ADC. Die Lösung war ein schneller free 
running Zähler.
Am Eingang war ein Komperator und immer wenn ein Übergang von Low zu 
High kam, wurde der Zählerwert in einen Fifo abgelegt. Auf der 
Ausgangsseite war an dem Fifo ein geringerer Takt.

Jetzt der Bringer. Intern war ein zweiter Takt der 180° Phasen 
verschoben war.
Mit diesen zweiten Takt wurde das Gleiche auf gebaut.
So hatte man die doppelte Taktrate genutzt.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Das stimmt, mit verschobenen Takten und mehrfacher Logik kann man höhere 
Datenraten erreichen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.