Re: Neue Farnell-Website :-(

On Mon, 1 Jun 2009 19:30:50 +0200, Frank Buss <fb@xxxxxxxxxxxxx>
wrote:
Einen DSP in VHDL zu programmieren hatte ich mir auch mal überlegt. Deine
Implementierung klingt sehr speziell, kann der auch beliebige Programme
abarbeiten?

Im Prinzip ja.
Es ist sogar eine Sonderbehandlung für schnelle Branches
eingerichtet.

Du setzt für deine Anwendungen ja die fetten FPGAs ein, meinst
du sowas würde auch für einen Cyclone oder Spartan funktionieren?

Mit einem Spartan 3A DSP würde er funktionieren, die hiesigen
Vertreter von Xilinx liegen mir auch ziemlich in den Ohren, dass
ich den verwenden möge. Die von Lattice allerdings auch ;-)

Wir nutzen momentan einen ECP2M-70 für unser CIFDM
Basisband-Board, weil der auch SERDES Links hat, über die
sowohl das optische GigE als auch optionale High Speed
ADC geführt sind.

Preislich liegen die ECP2M etwas höher als die Spartan,
aber nicht so viel.

Heißt: Es ist absolut vorstellbar, dass das Ding irgendwann
mal ein Standardteil so wie ein WLAN Chip wird und
Ihr dann mit so einem Stick ins Internet kommt ;-)
Technisch passt es da locker rein.

Momentan befinden sich in dem FPGA zwei CIFDM Engines
(vollduplex) mit je (!) zwei Polyphasenfilterbänken (FIR) gemäß
meiner neuartigen Architektur einschließlich je zwei Hardware
FFT je Engine und eben einem Vektorprozessor für so Dinge
wie Synchronisation, Equalization und Encoding/Decoding.
Außerdem sind da noch Gemeinschaftsfunktionen
(GigE, Unterstützung FEC, ADC Downsampling usw.)
untergebracht.

Damit Du einen Eindruck hast: Wir unterhalten uns um
rund 12000 Zeilen VHDL, allerdings mit doch einigen
Kommentaren im Programmcode. Das passt alles in ein
FPGA der Kategorie ECP2M.

Die Engines haben einen vollen Befehlssatz, allerdings keinen
beliebig großen Speicher, dafür können sie sehr effizient
mit komplexen Zahlen rechnen und eben mit Feldern aus
diesen. Es geht z.B. darum, dass pro Engine eine CORDIC-
Pipeline vorhanden ist, die eben ein I/Q Paar pro Zyklus
umsetzen kann. Ein klassischer DSP kann das auch, aber
eben nicht als

Einen richtigen Dual Core DSP haben wir auch auf dem
Board, und genau da zeigen sich die Unterschiede:

Grundsätzlich kann sowohl so ein FPGA als auch ein DSP
alles, es grüßt die Touring Maschine.

Aber: Das FPGA ist bezüglich des Befehlssatzes unheimlich
flexibel, dafür ist der DSP mit klassischen Befehlen und
mit dem Cache unheimlich schnell.

Der Grund sind primär die Routing Delays auf dem FPGA,
nicht die Logik, das Routing kostet rund 70 bis 80% der
Zykluszeit. Genau das entfällt beim festverdrahteten DSP,
der Cache ist optimal angepasst usw. Und man kann halt
nicht alles beliebig per Pipeline regeln, irgendwann wird
auch vorne ein Ergebnis von hinten benötigt oder es
kommt ein bedingter Sprungbefehl.

Bei letzterem tun sich übrigens selbst große Prozessoren
unheimlich schwer, wenn er nicht vorhersagbar ist (eben
weil da echt was entschieden wird, CORDIC ist ein ganz
klassischer Fall für derlei CPU-Unbill, die Sprünge sind nur
vom Ergebnis abhängig), da haut es jedesmal die ganze
Pipeline weg.

Ohnehin ist so ein CPU-Design im FPGA unheimlich lehrreich,
da merkt man schnell, wo die Tücken bei einer klassischen
CPU

400 MHz Takt, wie es schon die einfachen DSPs können, würde man aber
zumindest mit den kleineren FPGAs wohl schonmal nicht hinbekommen, daher
müsste man sich wohl einen ausgefallenen und auf die Anwendung angepassten
Befehlssatz ausdenken.

Unsere Engine läuft mit 125 bis 150 MHz je nach FPGA Typ
( und Preis ;-/

Das reicht völlig, selbst für breite Funkkanäle.

Das kostet aber wieder LEs, wenn's schnell laufen
soll. Ich hatte mal spaßeshalber einen FIR-Filter mit dem Megawizard
ausprobiert und je nach Anzahl taps ist der Cyclone dann schnell voll :-(

Sowas sollte man auch sauber codieren, wenn man weiß, was
man macht, kann man unheimlich viel aus den FPGA rausholen.

Unser CODEC ist jedenfalls ein Baustein, den man sich so vor
5 Jahren nicht hätte vorstellen können. Ich nehme mal an,
dass das auch einer der Gründe ist, warum in Richtung unseres
neuen Modulationsverfahrens kaum geforscht wurde, außerdem
war damals noch nicht klar, wie man derlei Signal mit krummen
Abständen wirtschaftlich synthetisieren kann.

Aber er ist keine Vaporware, das Ding spielt und wir testen zur Zeit
real im UHF Funkfeld (wir haben eine Versuchsfunklizenz)
ebenso wie auf langen Kabeln, wie dicht man z.B. die beiden
Kämme aneinander ranführen kann, sprich wieviel Daten da
reinpassen, auch wenn der Funk mal nicht so gut ist.
Bisher sieht es sehr gut aus, mit dem richtigen (!) Sendesignal
trennen sich die beiden Kämme tatsächlich so, wie wir uns das
theoretisch gedacht haben, d.h. das kommt fast an ein
orthogonales Schema ran, nur eben mit endlich gescheiten
Filtern statt mit dem sin(x)/x Krempel.

Und wir haben momentan sogar noch einigen Platz im FPGA,
allerdings relativiert sich das etwas durch die steigenden
Routing Delays, sprich: Will man das FPGA ausquetschen,
dann wird es lahm,

@Jörg: Du siehst, das ist echt nicht sooo schwer, einen DSP
zu bauen, es ist wirklich eine Frage der NRE (Maskenkosten)
und des Absatzmarktes. Im Grunde braucht man eine ganze
DSP Familie und eine Grundauslastung der Fab, dafür war
z.B. in der Vergangenheit Automotive sehr gut (daher z.B.
die Grundausrichtung Infineon dorthin).
Es gibt im internationalen Bereich (ich rede nicht vom US
Chaos) auch nicht sooo viele relevante Patente, Du weißt
vielleicht, dass ich sogar selber in dem Segment noch eines
geholt habe.

Sprich: Man braucht Abnehmer, man braucht Kapital, man
braucht wenige extrem gute Entwickler, die das gewisse
Extra erfinden, damit der werte Durchschnittsingenieur
das Risiko eingeht, auf diesen Typ zu schwenken.

Genau wegen dem Kapital sind z.B. die Scheichs bei AMD
(jetzt Globalfoundries) eingestiegen, inzwischen kann in
Dresden übrigens jeder fertigen lassen, der die NRE und
ein Design mitbringt.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@xxxxxxxxxx
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
.

Relevant Pages

  • FPGAs (was: Neue Farnell-Website :-()
    ... 18x18 Multiplier und PLLs findet man heutzutage eigentlich überall. ... FPGA der Kategorie ECP2M. ... die eben ein I/Q Paar pro Zyklus ... Ein klassischer DSP kann das auch, ...
    (de.sci.electronics)
  • Re: [OT?] whats a FPGA?
    ... [My desires would be better met by a 'discrete speech' rather than the ... How many analog simulation blocks can I stuff in a FPGA? ... an FPGA or a DSP is an implementation decision. ... algorithm that requires more processing than this from an 8 kHz sampled ...
    (comp.dsp)
  • Re: DSP or FPGA for high-speed image processing??
    ... I am going to start a project of onboard high-speed CMOS image ... DSP or FPGA? ... Are FPGA development tools readily available in Zhejiang, ...
    (sci.electronics.design)
  • Re: low-power-cons, low-cost, uP+DSP combo for H.264 video encoding & control/monit
    ... but are lack horsepower on DSP end ... An FPGA _may_ be a viable alternative. ... Power will be a concern, but my experience with video processing in FPGA vs. DSP was that you can't just consider the processor -- the memory for frame buffers is a big "everything hog", and using an FPGA gives you tons more flexibility to interface to memory. ...
    (comp.arch.embedded)
  • Re: DSP or FPGA for high-speed image processing??
    ... I am going to start a project of onboard high-speed CMOS image ... DSP or FPGA? ... Are FPGA development tools readily available in Zhejiang, ...
    (sci.electronics.design)