Kennt jemand einen ASIC, der Sinus als Digitalwerte ausgibt? Mit FPGAs geht es bekanntlich nur bis 100MHz. Mit ASICs müsste sich das 10fache machen lassen.
Edgar M. schrieb: > Kennt jemand einen ASIC, der Sinus als Digitalwerte ausgibt? > > Mit FPGAs geht es bekanntlich nur bis 100MHz. Mit ASICs müsste sich das > 10fache machen lassen. Mir fällt grad kein IC ein der parallele datenworte mit 1 GHz ausgibt. Seriell geht natürlich mehr, aber das kann auch ein FPGA. In deinem fall würd ich einen schnellen standard-DSP nehmen der eine Sinustabelle ausliest, da dürfte kein ASIC schneller sein. MfG,
Die App (IQ) soll in einem FPGA laufen, daher müssen die Daten parallel rein. Klar geht das intern mit einem NCO oder extern mit einem DSP, aber eine Sinustabelle ist nicht beliebig genau und muss noch gefiltert werden, oder sie wird gigantisch gross. In jedem Fall wird immer ein grosses RAM benötigt und man kommt trozdem bei 300-400 MHz Taktfrequenz auf kaum mehr, als 3-5 MHz, wenn man etwas Anspruch an den Sinus hat. Aber auch dann nimmt der Filter viel Zeit und Platz weg. Billiger ginge es sicher mit einem DDS-Chip, aber die, die ich recherchiert habe, kommen leider nur analog raus. Von der Taktfrequenz liegen sie >Faktor5 besser und bei einem schnellen digitalen Filter liessen sich auch hohe Güten erreichen, bei vertretbarer Latenz (Reaktion auf Änderung). Ich bin nicht so der Fachmann fürs Filtern, aber bei einer Frequenzkonstellation von 300 MHz zu 30MHz habe ich mal so ca. 600 Taps veranschlagt.-> 2us Latenz, und habe angeblich überall >60dB Filterwirkung. Als Asic liesse sich ein 4 mal tieferes Filter einbauen und man kame unter 1us Latenz, zudem wäre die Abtastfrequenz viel höher. Dasselbe Filter liefert bei 1200 / 30 schon >80dB. Eine Sinustabelle in einem Chip mit 2^24 Punkten hat bei 1% Aussteuerung gerechnete >60dB SFDR, Zusammen >140dB.
> Als Asic liesse sich ein 4 mal tieferes Filter einbauen und man kame > unter 1us Latenz, zudem wäre die Abtastfrequenz viel höher. Dasselbe > Filter liefert bei 1200 / 30 schon >80dB. Eine Sinustabelle in einem > Chip mit 2^24 Punkten hat bei 1% Aussteuerung gerechnete >60dB SFDR, > Zusammen >140dB. Also wenn ich rechts verstehe willst du 24 bit parallel mit 1 GHz. Schaut mal mal grob über die IO-Specs rüber, könnte des ein GDDR3-2133 grade so erfüllen (vom Takt, von der Wortbreite bin ich grad überfragt). ASIC-Küchen arbeiten üblicherweise mit langsameren Strukturen als High-End Speicherfabrikanten. Daher bezweifle ich das einen Chip mit dieser Schnittstellenspec gibt. Intern ist 1 GHz nicht das problem, ... MfG,
Fpga Kuechle schrieb: > Also wenn ich rechts verstehe willst du 24 bit parallel mit 1 GHz. Es reichen eigentlich 300 MHz mit (analogen) 20 bit Präzision. Wie gesagt, die DDS chips produzieren eigentlich die gewünschte Genauigkeit, geben aber nur analog aus. Nur mit einem guten Filter und gutem ADC liesse sich das wieder im FPGA verwenden. Ich will es halt direkt haben.
So, habe noch ein wenig recherchiert: Der schnellste DDS Chip, den ich gefunden habe ist der 9910 von Ad, mit 1GHz bei 14 Bit. Sowas hätte ich gerne digital und dazu einen Chip mit programmierbarem Filter von 400MHz an abwärts. Momentan mache ich es mit einem FPGA, was aber sehr viel Fläche verschlingt.
Wozu soll denn das Filter gut sein? Wenn du mittels DDS die digitalen Werte einer sinusförmigen Spannung erzeugt hast, dann repräsentieren diese genau ein Sinussignal mit der gewünschten Frequenz.
Die ersten DDS-Chips hatten noch keinen DA-Wandler, aber auch nur 8 bis 10 Bit z.B. der SP2001 von Plessey/Mitel http://www.datasheetarchive.com/ -> nach SP2001 suchen 350MHz clock, max 100MHz out mit interner Sinustabelle Hier ein Artikel von 1998 mit Messungen zu verschiedenen damaligen DDS http://www.ttcla.org/vsreinhardt/Sine%20Output%20DDSs%20a%20Survey%20of%20the%20State%20of%20the%20Art.pdf z.B in GaAs-Technik der STEL-2373 1 GHz Takt, 12 Watt Leistungsaufnahme
Helmut S. schrieb: > Wozu soll denn das Filter gut sein? > Wenn du mittels DDS die digitalen Werte einer sinusförmigen Spannung > erzeugt hast, dann repräsentieren diese genau ein Sinussignal mit der > gewünschten Frequenz. Die Daten werden interpoliert und mit noch höhere Auflösung gefahren und parallel berechnet. daher brauche ich den Sinus so schnell und genau und hochaufgelöst, wie möglich. Christoph Kessler (db1uq) schrieb: > 350MHz clock, max 100MHz Ja, muss mal schauen, ob mir das eine Verbesserung bringt. Ich denke aber , eher nicht.
Hallo, bei aktuellen FPGAs kann ein Sinus-Signal mit vertretbaren Aufwand erzeugt werden. Die Genauigkeit der Erzeugung wird durch den SFDR angegeben. Basis einer DDS ist eine Tabelle mit Stützstellen des Sinus. Hierbei reicht ein Speichern des ersten Viertel einer Periode ab, da die restlichen Teile durch Spiegelung und Invertierung bestimmt werden. Werden nur Stützstellen verwendet, bringt jede Verdoppelung der Tabellengröße ein um 6 dB besseres SFDR. Besser ist die Verwendung von zwei Tabellen mit Stützstellen und Steigung des Sinus und einer anschliessenden linearen Interpolation. Dort wird mit jeder Verdoppelung der Tabellengröße das SFDR um 12 dB besser. Mit diesen Zahlen kann sehr grob die nötige Tabellengröße für ein gefordertes SFDR abgeschätzt werden: z. B. SFDR von 120 dBc gefordert -> 120/12 = 10 bit Adressen der Tabellen -> nur ein Viertel der Periode gespeichert -> Mit zwei Tabellen mit jeweils 256 Werten (Stuetz- und Steigungstabelle) kann ein Sinus mit ca. 120 dBc erzeugt werden. Es wird noch ein DSP-Slice zur Berechnung der linearen Interpolation benötigt. Eine Faustformel ist auch, dass die Stuetzstellen mit deutlicher mehr Bits quantisiert werden müssen, als die Steigungen. Mit etwas Geduld können die Fehler hergeleitet werden. Aufwand zur Erzeugung eines Sinus-Signals sind also zwei Tabellen, ein DSP-Slice (z. B. DSP48E bei Xilinx) und ein wenig Logik für das Invertieren und Spiegeln (XOR Operationen) der gespeicherten Viertelwelle. Soll die Abtastrate erhöht werden, muss diese Struktur mehrfach instanziert werden. In Virtex5-FPGAs habe ich schon diverse dieser Algorithmen mit einer Taktrate von 250 MHz realisiert. Noch mehr kann man sparen, wenn mit Dithersignalen in der Phase arbeitet, aber das ist ein etwas komplexeres Thema. Ich hoffe das hilft. Die exakte Dimensionierung (Wortbereiten) ist noch etwas aufwendiger, kann aber mit Fleiss gelöst werden. Noch eine Anmerkung: Würde man keine lineare Interpolation verwenden, müsste die Tabelle für 120 dBc 120/6 - 2 = 18 bit haben. Der Aufwand ist also ca. 500 mal größer. Das fand ich beim ersten Nachdenken darüber überraschend ;-) Gruss Markus
MJF schrieb: > Würde man keine lineare Interpolation verwenden Ist es nicht zweckmäßiger, eine quadratische Interpolation zu benutzen?
Martin K. schrieb: > MJF schrieb: >> Würde man keine lineare Interpolation verwenden > > Ist es nicht zweckmäßiger, eine quadratische Interpolation zu benutzen? Hallo Martin, bei einer abschnittsweisen Näherung einer Funktion mit Polynomen (und das ist auch die Lineare Interpolation), sinkt der Interpolationsfehler mit steigenden Grad der verwendeten Polynome. Wenn Du also statt a + b*x ein Polynom mit a + b*x + c*x^2 nimmst wirst Du genauer werden. Aber du benötigst mehr Tabellen (drei statt zwei) und zwei Multiplizierer mehr (Quadrierung und Gewichtung). Die Tabellen können aber kleiner sein. Bei der Näherung mit Polynomen gibt es eine Regel, dass der Fehlerterm immer bei Erhöhung zu einem Polynom mit ungeraden Grad am stärksten sinkt. Man spricht von der Ordnung des Fehlerterms. Der nächste wirklich gute Schritt wäre ein Polynon a + b*x + c*x^2 + d*x^3. Deshalb werden bei Splines oft diese Polynome verwendet. Aber genug Theorie. Aus HW-Sicht ist der Schritt von Interpolation 0-ter Ordung zum linearen Interpolation am lohnesten. Danach wird's kompliziert und der Gewinn ist nicht mehr so gross. In Xilinx-FPGAs (ich arbeite nicht für Xilinx!!!! aber arbeite oft mit Ihren FPGAs) sind die Block-RAMs 1k*36 bit gross. Da es Dual-Port-RAMs sind, kann in einem Block-RAM die Steigungs- und die Stuetzstellen-Tabelle abgelegt werden. Mit dieser Tabelle kann ein Sinus mit ca. 130 dBc erzeugt werden. Kleinere Tabellen bringen keinen Vorteil, da die Verwendung eines halben Block-RAMs keinen Ressourcenvorteil bringt. Viele Gruesse Markus
E. M. schrieb: > Ja, muss mal schauen, ob mir das eine Verbesserung bringt. Ich denke > > aber , eher nicht. Du kannst versuchen, bei AD nachzufragen, ob sie sowas OEM bauen. Wir aben mit TI schon einiges gemacht. Die produzieren Dir sofort einen ASIC, wenn die Abnahmemenge stimmt.
MJF schrieb: > Besser ist die Verwendung von zwei Tabellen mit > Stützstellen und Steigung des Sinus und einer anschliessenden linearen > Interpolation. So in etwa handhabe ich das bei Minianwendungen, um z.B. für Schrittmotoren einen geeigneten Sinus zu bauen. Die Tabelle hat dann 4-8 Werte für 90 Grad (ja, das reicht, wenn man linear interpoliert und mit einem Exponentialfilter nacharbeitet) und besteht quasi nur aus LUTs. Dabei zeigt sich, dass man bei wenigen Werten besser wegkommt, wenn man Stützstellen und Steigung komplett implementiert und auf die Fallunterscheidung 90 Grad <-> 360 Grad verzichtet. Wenn man es genau haben will und grosse Tabellen benutzt, würde ich nicht mehr linear arbeiten, sondern in 2 Richtungen interpolieren und dabei die benötigte Steigung direkt aus der Tabelle ziehen. Wir wollen ja Sinüsse erzeugen und deren Ableitung, die bekanntlich Cosinus heisst, steht 90 Grad weiter in der Tabelle, was zudem noch simpel ist, wenn man ohnehin nur 90 Grad abgelegt hat und somit nur umdeuten muss. Dies kostet fast keine Logik weil die zur Ansteuerung / Interpretation der 4 Viertelbereiche nötige Logik schon implementiert ist. Wer IQ-Modulation betreiben möchte, muss überdies Sin/Cos parallel zur Verfügung stellen und hat die gegenseitigen Steigungen schon parat.
MJF du hast schon recht, das geht prima in FPGAs, aber wenn sie genau sein soll, die DDS wird es flächenintensiv und in massenhaft produzierten CHIPs, ist das alles viel billiger. Du siehst doch, was die AD-Chips kosten: mit 15,- hast Du einen 1GH-Chip. Daher die Vorstellung, dort einen D-ausgang anzuzapfen. still searching ....
Hallo E. M., ich bin leider fälschlicherweise von der Annahme ausgegangen, dass ein FGPA zur Verfügung steht. Wenn nicht, hilft meine Antwort nicht weiter. Trotzdem noch eine Anmerkung: Ein DDS-Baustein wird von den Herstellungskosten immer deutlich günstiger als ein FPGA sein. Aber wenn die 15€ für eine DDS stimmen, sehe ich schon Möglichkeiten, eine SIN-Erzeugung mit 1GHz im FGPA für weniger zu realisieren. Da mir aber nicht alle Fakten bekannt sind, ist es nur eine grobe Annahme. Alles steht und fällt mit Stückzahl der FPGAs, die Du pro Jahr verbauen willst. Wenn Du im Bereich 1-5k/Jahr kommst, sind kleinere FPGAs schon für deutlich unter 10$ zu haben. Z. B. in einen Spartan-3AN (e. g. XC3S200AN) sind 16 Multiplizierer eingebaut. Es gibt auch genügend Block-RAM. Der Baustein kann auch im niedrigsten Speed-Grade mit 128 MHz getaktet werden. Somit wäre als Abtastrate der DDS 16*128 MHz = 2048 MHz denkbar. Hier ist wohl die Begrenzung, wie die Daten aus dem Chip kommen. Aber wie gesagt, das hängt extrem von den Stückzahlen und den Verhandlungen mit dem FGPA-Hersteller zusammnen. Und natürlich kostet das Entwickeln der DDS Zeit (=Geld). Für Einzelstücke ist es der falsche Ansatz und Du darfst meine Postings als Bullshit in dem Kopf vermerken ;-) Viele Grüße Markus
FPGAs stehen selbstredend zur Verfügung und werden ja verbaut. Ich dachte nur, dass man mit einem DSS Chips kleiner und billiger wird. Es ist wirklich ein Ärger, dass man an deren Digitalteil nicht dran kommt. Zu Deinem Vorschlag: Du willst 16 parallel DDS in einem so kleinen FPGa verbauen? Das Tabellellesen muss ja dann geschachtelt werden -> 128MHZ/16 -> 16 MHz.
Hallo E. M., mit Hilfe von lin. Interpolation benötigt man sehr kleine Tabellen (1k Tabelle -> SFDR>120 dBc). Die Dual-Port-RAMs in den vogeschlagenen FPGA haben eine Größe von 1k*18bit. Diese DP-RAMs können locker mit 128 MHz ausgelesen werden. Soll die Abtastrate der DDS höher als 128 MHz sein, werden mehrere dieser DDS-Blocke (und somit auch mehrere RAMs) parallel aufgebaut. Jedes DP-RAM hat den gleichen Inhalt (ist ja kein Problem, es sind ja genügend DP-RAMs im FPGA vorhanden). Somit werden mehrere Ausgangs-werte der DDS parallel berechnet, wobei in jedem DDS-Block mit der vollen Rate Ausgangswerte erzeugt werden. Somit ist die maximale Abtastrate nur dadurch begrenzt, wieviele DDS-Bloecke du in das FPGA bekommst. Da der einzelene Block sehr klein ist (1 DP-RAM, 1 Multiplizierer und ein wenig Logik für Addition und Rundung), gehen selbst in kleine FPGAs mehrere dieser Blöcke hinein (z. B. das vorgeschlagene SPARTAN-FPGA hat 16 Multiplizierer und 16 DP-RAM-Bloecke -> 16 DDS-Bloecke parallel -> bei Taktrate von 128 MHz ergibt sich eine Abtastrate von 16*128 MHz = 2048 MHz). Da es DP-RAMs sind können sich zwei DDS-Blöcke ein RAM teilen, d. h. sie teilen sich Tabellen mit den Stuetzstellen und Steigungen. Ich hoffe, ich habe es gut erklärt. Ich habe auch ein Bild dazu, muss es aber erst so wandeln, dass man es hochladen kann. Mach im am Donnerstag. Gruss Markus
Mir ist schon klar, was du schreibst, aber ich sehe immer noch nicht ein, warum ich die DDSen parallel schalten soll. Wenn, dann müsste in jeder was anderes stehen (Zwischenfrequenzen). Ich möchte ja (mindestens) sowas haben: 500MHz x 32 Bit mit jedem Takt, oder 250MHz x 2 x 32 Bit (2 Worte) oder was an eben vernünftig ins FPGA bekommt. Ein zusätzliches FPGA wäre ok, zwar Kostenfaktor aber naja - gfs auch in dasselbe rein. Gehen wir mal von einer Frequenz 300MHz ... 500 MHz aus, Auflösung 1 Hz reicht, dann würde man mit einem entsprechend genauen Akkumulator + Interpolation schon hinkommen. Aber wie liest man die Tabelle?
E. M. schrieb: > Mir ist schon klar, was du schreibst, aber ich sehe immer noch nicht > ein, warum ich die DDSen parallel schalten soll. Wenn, dann müsste in > jeder was anderes stehen (Zwischenfrequenzen). > Genau so ist es. Du hast z.B. 4 DDS. Jede addiert den gleichen Frequenzwert aber deren DDS(Akkumulator) ist jeweils um 1/4 des Frequenzwertes versetzt gestartet. Natürlich braucht jede der DDS auch seine eigene Sinus-Tabelle da auch die nur maximal mit 250MHz gelesen werden kann.
Genau so dachte ich mir das, aber das führt ja noch zu mehr Fläche.
Anders geht das halt nicht. Parallel ausführen benötigt immer N-mal die Hardware. Andere machen das übrigens auch so. Einfach ein "fettes" FPGA nehmen und gut ist.
>fettes FPGA
Ihr Verschwender :-)
Ich weiss ja nicht, wie genau Du die Frequenzinformationen brauchst,
aber es sollte möglich sein, dass Du mit einem genügend grossen
Akkumulator und einer Anzahl RAMs/Ramzugriffen zzgl Filterung jede
gewünschte Auflösung schaffst. Die DDS-Tabellen müssen in der Tat alle
dasselbe enthalten, dahinter steckt dann eine intelligente
Interpolation, z.B. "inner-outer" und abgesehen von der Latenz, würdest
Du soviele dieser Architekturen parallel instanziieren müssen, wie du
Bandbreite brauchst. Wenn z.B. die DPRAMs mit 250 MHz berieben werden
(DP für SIN/COS = Wert/Steigung) dann musst Du den Phasenakku jeweils um
4x den Inkrementalwert erhöhen, und davon abgeleitet 4 Phasenvektoren
bilden, die mit jeweils p+0, p+1, p+2 und p+3 gleichzeitig und 4
benachbarte DDS-Werte zugreifen. Für Frequenzen unterhalb der
Samplefrequenz/ Tabellenlänge, bei der nur maximal 1 Wert weitergezählt
wird, reicht es aber, 2 DDS-Tabellen zu benuzten und diese mit
Überbreite auszulesen. Beide Tabellen wären um die halbe / volle
Überbreite versetzt anzulegen, um die RAM-Grenze beim Zugriff zu
überwinden.
Wenn Du es ganz geschickt machst (Interpolationssteigung berechnen und
Werte vorsorglich aus dem Ram ziehen), reicht eine einzige Tabelle mit
einigen Pufferregistern dahinter. Für 2*fs/l benötigte man dann die
doppelte Überbreite usw. Natürlich brauchst du hernach gfs noch
parallel instanzierte Filter, die aus den 4+1 (dem alten Wert) die 4
neuen gefilterten Werte produzieren. Dann hättest Du mit quasi 1GHz
Sinus-Werte als 4fach Wort parat. Ich habe sowas mal als "200 MHz
Multiplex-DDS" in einem langsamen Cyclone II aufgebaut, weil der nicht
mehr als 50MHz konnte. Ein späteres Design läuft auf einem Virtex mit
den angebenen 250MHz.
Das funktioniert sehr gut, der Nachteil ist freilich der Resourcenbedarf
und der Umstand, dass Frequenzänderungen nicht fein aufgelöst werden,
weil diese sich nur alle 4 Werte ändern kann. Eine Erweiterung wäre die
frequency-look-ahead DDS, wie ich sie nenne, wo die Frequenzen auf der
Basis der vorherigen Änderungen extrapoliert - also geschätzt - werden,
um nichtlinear extrapolierte Werte für die Frequenzvektoren zu
generieren. Insgesamt ist das aber eine eher akademische Lösung, weil
man dann nicht mehr so einfach interpolieren kann und dazu die
Interpolatorvorschriften parallel braucht.
Wenn Du das wirklich als ASIC brauchst, solltest Du mal mit TI oder AD
reden. Viele Halbleiterhersteller bauen customized ASICs für Kunden, die
sie dann zusammenfassen und passend einhäusen, sodass sie auf genügende
Stückzahlen kommen, dass sich eine Produktion lohnt. Jeder Kunde bekommt
dann einen individuell gebondeten Chip und weiss im Prinzip nichts von
der Restapp des anderen Kunden. Diese Chips gibt es aber nicht im
Katalog der Hersteller. Wenn Du Glück hast, gibt es sowas und Du kannst
da was bekommen. Ich kann mir sehr wohl vorstellen, dass für Hersteller
von TimeToDigital-Convertern, SDR-Transceivern und Spektrumanalyzern
sowas als ASIC gebaut wird und nicht jeder Hersteller produziert seine
eigenen ASICs.
E. M. schrieb: > Genau so dachte ich mir das, aber das führt ja noch zu mehr Fläche. Der Cordic Algorithmus kann sehr schnell und zeitgleich den Sinus und Cosinus Wert berechnen. Cordic kann auch den "Wert drehen" und so als Demodulator eingesetzt werden und das ohne eine Multiplikation im FPGA zu benutzen. Das ist dann eine andere Implementation. Die Mathematiker haben auch den Fall betrachtet. Zählt auch zum Cordic Algorithmus, obwohl er etwas anders aufgezogen wird. http://www.dossmatik.de/cordic/cordic_flyer.pdf
Was unterscheidet Deinen Cordic Algo von dem z.B. von Xilinx? Ist mit sowas überhaupt Geld zu verdienen?
Es ist mir ein Rätsel warum hier ein serielles Verfahren wie Cordic vorgeschlagen wird. Wie soll man denn da mit 1GHz Rate 20bit Sinus-Werte bekommen? Da müsste man ja 100 CORDIC Generatoren parallel fahren.
Helmut S. schrieb: > Da müsste man ja 100 CORDIC Generatoren parallel fahren Nicht unbedingt. Den CORDIC kann man ja wie die meisten anderen ALgos ebenfalls als pipeline fahren, er wirft also pro Takt einen Wert aus. Man braucht nur, wie bei der Tabelle, einen Block je Kanal, also z.B: wieder 200MHz 5fach parallel für die Daten zu 1GHz. Der CORDIC hat aber gfs eine recht lange pipeline, die die Reaktion auf Änderungen einschränkt. Daher bevorzuge ich z.B. Tabellen-basierte und generische Systeme. CORDIC ist aber einfach in der Gesamtschau (Platz, Geschwindigkeit, Implementierungsaufwand, Synthetisierbarkeit, Übertragbarkeit) das Effektivste. Bei high speed DDS-Applikationen, wo moduliert werden soll, scheidet er aber schnell aus.
Mir ist immer noch ein wenig schleierhaft, warum und wozu man eine höhere Datenrate im FPGA benötigt, als das FPGa verarbeiten kann. Die nachfolgenden Stufe ist ja mithin auch nicht schneller, als die 400MHz o.ä daher reicht es doch, wenn das/ein FPGa auch mit dieser Raten sin/cos erzeugt.
FPGA-Berater schrieb im Beitrag #2393242: > Mir ist immer noch ein wenig schleierhaft, warum und wozu man eine > > höhere Datenrate im FPGA benötigt, als das FPGa verarbeiten kann. Weil man parallel arbeitet und zweitens die Chip-Elektornik auch weniger Latenz hätte.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.