Snelle FPGA.

Dit is niet echt een methode, maar er is een YouTube filmpje van mikeselectristuff die bezig is geweest met een dev-bordje van Lattice, in welke serie er ook kleinere devices bestaan. Het lijkt er op dat die MachXO2 devices maximaal op 400MHz kunnen draaien, maar ik neem aan dat je met optellen voornamelijk met latency zit en niet snelheid? Je zult even moeten shoppen in de verschillende implementatietypen 'adders' om er één te kiezen met een lage latency zoals een carry-lookahead, maar ik ben daarin niet echt een expert. Wat is de snelheidsvereiste in nanoseconden? Ik vermoed dat de latency om de informatie de FPGA in en uit te krijgen waarschijnlijk groter gaat zijn (ivm 'double buffering' en synchronisatie) dat de latency van de optelling zelf, maar dat is zeker geen informatie waar je op gaat kunnen selecteren in een 'parametric table'.

Wil je je logica klokken op 1G? Da's wel heel hard hoor! Als het uberhaupt al kan. Seriele tranceivers kunnen wel zo snel, maar da's meestal maar een heel klein stukje dat nog voornamelijk in hard macros zit.
Ik werk nu aan een design dat volledig tegen de 200MHz zit en dan kan de logica maar een paar levels diep zijn anders redt je het al niet.

Heb je een 32 bit adder een miljard keer per seconde nodig?

Dan kan vrijwel iedere FPGA het, want zoiets zul je altijd moeten paralelliseren. En of je nou 10 of 20 32 bit adders in je FPGA maakt maakt niet zoveel uit, past waarschijnlijk altijd wel.

Hoe ga je je 62Gbit datastroom de FPGA in krijgen? En hoe komt de 33Gbit (carry!) er weer uit?

De 32 bit adder is een accumulator. Dus die voert zichzelf. De andere input is vrijwel constant: verandert maar een paar honderd duizend keer per seconde. De bovenste 10 o.i.d bits van de 32 heb ik glitchvrij parallel nodig om nog een paar stappen in de fpga te doorlopen. Uiteindelijk een stuk of 20 parallelle signalen de chip uit.....

Ok game over. Dat gaat hem niet worden. "Men" koopt chips waarbij dat deel nog on-chip zit en even verder wordt de bandbreedte veel lager. Ik dacht effe dat ik met alleen een fpga toe zou kunnen. Maar als ik toch die externe chip nodig heb, dan hoef ik helemaal geen snelle fpga te hebben. Misschien helemaal geen fpga, en is een microcontroller voldoende.

goeie opmerking! Het is niet de 32 bits van de accumulator die de fpga af moeten, maar een paar processing stappen verder, maar nog steeds te veel om "doen we effe met een $50 fpga" te zijn.

$50 ook nog! Hehe, dat is nog eens "voor een dubbeltje op de eerste rang zitten" Die FPGA waar ik hierboven over schreef is iets van $1000. Nou gaat het daarbij niet heel erg over snelheid, maar voor over grootte (Kintex7).

Ik weet dat het een tien vijftienjaar geleden niet kon of heel duur was. Maar de wet van moore geldt ook voor FPGAs. De goedkoopste FPGAs zijn van zeg 10 euro naar 1.50 euro gegaan. En de "met een paar duizend LUTs" zijn van 5000 voor twee tientjes naar zeg 20000 voor twee tientjes gegaan. Ook de snelheid gaat van procesverkleining omhoog. Maar goed.

Ik heb dus te veel data realiseer ik me nu om de chip af te gaan. Dus wordt het een "dedicated chip". Dit is eigenlijk een "hobby projectje": De klant heeft een "prima" leverancier die met 20+ jaar ervaring op dit product.... niet werkende spullen levert. Ik zit een beetje te hobbyen of ik het zou kunnen reproduceren zonder al te veel kosten.... Ik moet dan iets van: "en deze werkt wel" presenteren zonder dat ik (net als de anderen) de boel in het veld kan testen. Als dat succesvol zou zijn dan heb ik ineens een forse order binnen....

Even een zijspoor. Bitcoin mining doen ze op grafische cpu's dit waarschijnlijk om de vele parallelle processen. Maar GPU klokken niet zo heel erg hoog in vergelijking met PC cpu's. Ik zou dan denken kan je niet gewoon een PC cpu nemen die hebben 64 bit adders zullen wel schaalbaar zijn.

Op 18 maart 2020 04:42:36 schreef blurp:
Hoe ga je je 62Gbit datastroom de FPGA in krijgen?

Met 8 10Gb links? Oh wacht het moest goedkoop. Anyway, die 1GHz accu is het probleem hier. Jammer.

Wie zegt het dat die adder op 1GHz moet lopen?

@rew: Wat moet je werkelijke netto clock rate zijn voor de adder?

Op 18 maart 2020 21:14:05 schreef benleentje:
Ik zou dan denken kan je niet gewoon een PC cpu nemen die hebben 64 bit adders zullen wel schaalbaar zijn.

Het gaat om een heftig real-time proces. Er zijn kleine chipjes van < 100 euro die eea allemaal regelen. En nog veel meer. Ik dacht even dat het misschien ook in een FPGA zou kunnen, maar bij nader inzien dus niet. Deels omdat de commerciele chipjes dus 48 bits of nog meer doen, maar dat bij ons gewoon compleet overkill is.

Je maakt mij ondertussen wel erg nieuwsgierig naar dat "preprocessor" IC ...of is dat te "restricted" info?

Mwah... Plan was om het niet te vertellen omdat het niet nodig was. Maar goed. DDS: Direct digital synthesis: We moeten twee (of liever vier) outputs op 50-100MHz met een instelbare fase en een instelbare frequentie kunnen bouwen. frequentie -> Accumulator -> offset instelling -> cos tabel -> DAC. Die laatste stap naar de DAC is denk ik datgene waar de "doe het helemaal in een FPGA " op strand. Dan maar https://www.analog.com/en/parametricsearch/11018#/

AD9958 of 9959 denk ik dan. Ik vind voor 100Mhz die 5x oversampling nog wat weinig vandaar dat ik ook meteen liever naar die 1G wilde gaan.

[Bericht gewijzigd door rew op donderdag 19 maart 2020 12:05:27 (14%)

Tuurlijk, accumulator... had het kunnen weten Dus ook nog met een paar 100 MHz naar buiten, da's ook al niet fijn in een FPGA, tenzij het differentiele transceivers zijn.
Succes met het project!

Op 19 maart 2020 12:03:14 schreef rew:
... twee (of liever vier) outputs op 50-100MHz met een instelbare fase en een instelbare frequentie ...
AD9958 of 9959 denk ik dan.
...

Waarom alles in 1 chip?
De AD9912 doet het op 1GHz, 'gewoon' 2 of 4 stuks nemen met dezelfde kloksource...

Op 19 maart 2020 12:03:14 schreef rew:
frequentie -> Accumulator -> offset instelling -> cos tabel -> DAC. Die laatste stap naar de DAC is denk ik datgene waar de "doe het helemaal in een FPGA " op strand.

Die laatste stap is dan inderdaad wat je beperkende factor is. Sowieso zijn 1Gs DACS niet dertien in een dozijn, en daar moet je je keuze op bazeren.

Waarschijnlijk zal iedere FPGA die groot genoeg is om een 1Gs DAC aan te sturen ook wel die sinus kunnen berekenen. En anders heeft een iets groter broertje die het zeker kan.

Is het niet eenvoudiger om de golf die je wilt maken in dual-port RAM te zetten, en dat hard naar buiten te klokken? Misschien kun je de counter waarmee je dat moet indexeren sneller maken door die in gray code te laten tellen, dan heb je die worst-case carry trein niet.

De data naar buiten sturen lijkt me parallel toch het snelst, als je daar geen dedicated hardware voor hebt in een goedkope FPGA, met de datalatch op de inverse van je clock.

"grote" FPGA? In essentie heb ik twee ongeveer 32-bit adders. Verder heel weinig. 1 voor de accumulator, en 1 voor de faseverschuving van de andere uitgang. Daarnaast moet ie een faseverschuiving en een frequentiewoord aangevoerd kunnen krijgen. Dus ook nog een 64-bit schuifregister. Totaal denk ik iets van 128 luts met nog wat grut. Oh, wacht! ik moet ook de amplitude kunnen instellen. Dus dan heb ik nog iets van een multiplier nodig Daar zijn toch DSP blocks voor in de meeste FPGAs?

Voor rond de 2 tientjes kan je 500MSPS parallel DACs kopen. 1GSPS kost ongeveer 30 euro. Valt me alles mee.

Bij mouser vind ik de 12 bit DAC: DAC3161IRGCT .
Bij INtel vind ik de Cyclone 5: 5CEA2 (kleinste uit de familie) die 50 LVDS kanalen zou hebben. Precies wat er die DAC in moet.

Dus als ik met de AD9958 al compromitteer dat ik maar 500MSPS doe, dan lijkt dat haast ook te kunnen met de cyclone. Alleen, gaat die 500MSPS halen met de accumulator? Zal wel niet.

[Bericht gewijzigd door rew op vrijdag 20 maart 2020 11:08:42 (23%)

Waarschijnlijk is je FPGA groot genoeg om inefficiënte dingen uit te halen, om die snelheid te halen; je zou bijvoorbeeld 2 of 4 accumulators fase verschoven kunnen laten tellen, waarbij je die afwisselend gebruikt voor de lookup. Dit geeft natuurlijk wat extra complexiteit bij het updaten van de frequentie, maar als dat zeer zelden gebeurd, en eventueel een kleine glitch acceptabel is, hoeft dat wellicht niet eens verschrikkelijk ingewikkeld te zijn.

Maar, zoals ik al zei, kun je de hele tabel niet voorbereiden, en op die hoge snelheid alleen nog maar data uit het geheugen naar buiten klokken? Het lastige is natuurlijk dat je daarmee wel een afrondingsfout krijg in je frequentie, omdat de tabel een beperkt formaat heeft, maar je kunt de lengte van de tabel variabel maken (niet beperkt tot een macht van 2), en meerdere hele golven opnemen, dus de tabel zo groot maken als het geheugen toelaat, om die fout de minimaliseren.

Het voordeel daarvan is dat je "per ongeluk" een bloedsnelle arbitrary waveform generator hebt gemaakt...

Het vullen van die tabel zou je in de FPGA zelf kunnen doen, of met een seriële interface (QSPI of zo) vanuit een microcontroller. De grote vraag is hoe vaak en snel die parameters (frequentie, amplitude, offset) veranderd moeten worden.

Ik zou denken dat DDS altijd met een SIN-tabel werkt. Dat gaan ze echt niet live uitrekenen steeds. Maar dan nog moet je in dit geval bloedsnel je address counter incrementen met een variabel getal.

Nee, natuurlijk niet, maar je kunt veel meer werk vooraf doen; het verwerken van de gewenste frequentie en amplitude, zodat je een tabel hebt die je met een vast snelheid naar buiten kunt klokken, en zo snel mogelijk, omdat je al het moeilijke werk off-line hebt gedaan. Niet uitrekenen waar je het volgende sample moet pakken, niet interpoleren, niet vermenigvuldigen voor de amplitude, maar gewoon op elke slag van je clock een sample naar buiten sturen.

[Bericht gewijzigd door SparkyGSX op vrijdag 20 maart 2020 18:13:02 (26%)

Op 20 maart 2020 13:56:18 schreef SparkyGSX:
De grote vraag is hoe vaak en snel die parameters (frequentie, amplitude, offset) veranderd moeten worden.

Origineel iedere 42 of 44 microseconden. En dan verandert frequentie, fase en amplitude: alletdrie. En zou je er een microseconde over doen om de verandering door te voeren kan het apparaat die microseconde niet produceren. (scheelt dus 2.5% van de totale doorvoer).

Een sinus "uitrekenen" kan gewoon met digitale logica:

x = 0x8000000;
y = 0;
while (1) {
   x = x - y >> 12; 
   y = y + x >> 12;
   output (x,y);
} 

(waarbij x, y dan dus cos en sin zijn. Wil je er maar 1 dan negeer je d'r eentje. Probleem is dat dit in iets van 2^12 * 2 * pi stappen een heel rondje doet: Je kan de frequentie alleen heel grof instellen.

Het plan met de tabel-in-ram lijkt me niet zo heel tof: dan heb je een heel hoge bandbreedte naar het ram nodig. Gewoon iedere klok een adres aanbieden en dan de sinus d'r uithalen, dat lijkt me een veel beter plan. Dit kan je pipelinen. Als je het in 2ns niet haalt en 4ns er over moet doen, dan kan je inderdaad gaan interleaven.

Des noods kost het je 2 clocks extra om eea op gang te helpen.

Voor de bandbreedte naar het RAM is het niet relevant hoe groot de tabel is, en de FPGA die ik ooit heb gebruikt (Spartan 3, veel te traag voor jouw toepassing) had dual-port single-cycle RAM blokken aan boord.

Weet je lang voor de update al wat de nieuwe parameters worden? Je kunt gewoon een tweede buffer in RAM vol schrijven terwijl het vorige nog gebruikt wordt, met één adresbit kun je dan het buffer kiezen.

Als we we 4 adresbits nemen dan kan het offline: geen realtime beperkingen, we staan pas toe dat er op start gedrukt wordt als eea klaar is. Er zijn per sessie in de praktijk max 16 combinaties.

Maar de frequentie moet echt goed kloppen. 20 kHz er naast kan nog net. Hmmm tja, met een tabel van 2k entries kom je dan een eind....

[Bericht gewijzigd door rew op zaterdag 21 maart 2020 06:42:32 (26%)

Je kunt toch een parallel adder met carry-lookahead maken (of een andere variant die nog meer parallel is)?
Geen idee hoe dat ook alweer werkte, dan is voor mij ook 35 jaar geleden. Er is vast wel ergens een stuk VHDL of verilog van te vinden wat je kunt simuleren.
Waar kom je dan op uit met een gegeven clock speed?

Anders zit er niks anders op dan de boel te pipelinen zoals al gezegd is.