DFT/FFT in Spartan 3 A

Martin S. schrieb:
> Die wohl am besten serialisierbare Loesung (nach der reinen SW-Routine)
> mit geringstem HDL-Overhead
Das dürfte aber mehr HDL-overhead erzeugen, als eine einfache DFT in 
hardware. Prozessor mit Ladefunktion, serielle Speicherung, möglichst 
noch in externen RAMs .... naja ....

Martin S. schrieb:
> Gegenfrage: Lernen oder schnelle Loesung?
> Mein Favorit betr. Literatur sind die "Algorithms" von Robert Sedgewick.
> Ansonsten: Bei opencores.org nichts gefunden?
> Die wohl am besten serialisierbare Loesung (nach der reinen SW-Routine)
> mit geringstem HDL-Overhead ist der Microcode-Ansatz per Softcore zur
> Konfiguration und einem FFT-'Coprozessor'. Da spulst du dann einfach
> quasi ein Programm durch. Da gibt's aber m.W. kaum aktuelle Literatur zu
> und man muss das bestehende SoC-Design gut auf den BRAM-Bedarf
> abklopfen.

Vorerst lernen aber wäre auch gut wenn das nicht 2 Jahre braucht.

Könnte man eigentlich 2 Punkt DFT Blöcke irgendwie zusammenschalten?

Wie eine DFT funktioniert, ist eigentlich klar definiert. Sie in HW 
umzusetzen, hat zwar einige Freiheitsgrade in Sachen Parallelisierung 
und Sequentialisierung, bietet aber IMO weniger Anforderung an das 
Denken, wie bei einer SW-Implementierung für einen ARM oder einen DSP 
oder einen Intel-Prozessor mit CoPro-Funktionen, bei denen man sehr viel 
Optimieren kann.

Bei der FFT ist es noch klarer, weil Butterfly-bildung direkt mit dem 
Willen zusammenhängt, Multiplier zu spendieren oder nicht.

Wer da nicht große Spezialanforderungen hat, nimmt einfach den 
mitgelieferten Core und baut ihn ein. In der SW habe ich zuletzt vor 12 
Jahren eine FFT angefasst, um sie auf einen Virtex mit Power-PC 
anzupassen. (Ja, da haben die PPC die FFT gemacht, weil 
"Stromsparzwang").