CPLD oder FPGA

"Stephan Mueller" schrieb im Newsbeitrag news: snipped-for-privacy@uni-berlin.de...

Klingt nach einem Problem fuer ein CPLD.

Eher geht/geht nicht. Das sagt einenm dann schon die Designsoftware.

CPLD hat meist 2 FlipFlops pro I/O-Pin. FPGA hat meist viele interne FlipFlops.

FPGA ist als Chip komplexer und damit meist teurer.

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

MaWin schrieb:

Stimme zu. FPGAs gibt's nicht unterhalb eines bestimmten Preislimits, bei dem Du für das vorliegende Problem wahrscheinlich schon 10 mal so viel Logik wie nötig bekommst. Dazu kommt noch, daß man in der Regel separaten Speicher für die Konfiguration braucht (und bezahlen muß), während ein CPLD nichtflüchtig ist.

--
Cheers
Stefan

[...]

[...]

Da die zu transferierenden Daten in einem SRAM stehen und da bei jedem einschalten auch erstmal reinmuessen kann man auch ein FPGA bei jedem einschalten Initialisieren; das FPGA hat dann den vorteil dass man nicht brennen muss und daher eventuell einen etwas kuerzeren Entwicklungszyklus hat.

--
Dr. Juergen Hannappel          http://lisa2.physik.uni-bonn.de/~hannappemailto:hannappel@physik.uni-bonn.de  Phone: +49 228 73 2447 FAX ... 7869
Physikalisches Institut der Uni Bonn Nussallee 12, D-53115 Bonn, Germany     
CERN: Phone: +412276 76461 Fax: ..77930 Bat. 892-R-A13 CH-1211 Geneve 23

Moin!

D/A-Wandler mit parallelem Port? Wenn ja, dann liegt genau im "evtl" schon ein deutlicher Unterschied in der Komplexität. Willst Du shiften, brauchst Du Datenleitungen zum SRAM und zum Wandler und belegst auch noch die entsprechende Zahl von FFs. Lässt Du das Shiften weg, brauchst Du die Daten gar nicht erst durch CPDL/FPGA zu schicken, sondern verbindest das SRAM direkt mit dem Wandler und machst bloß das Timing über die Steuerpins.

Gruß, Michael.

Hallo Stephan,

die Adressen für das SRAM kann man aber auch ganz einfach mit einem rückgekoppelten Schieberegister erzeugen. Zwei Stück ACT273 und ein ACT810 für die Rückkopplung genügen um

15 Adresssignale zu erzeugen. Es ist NICHT notwendig dass die Daten hintereinander im SRAM stehen. Die Reihenfolge ist völlig beliebig, solange du beim Reinschreiben die gleiche Reihenfolge verwendest. Hilfreich ist das Kapitel über PRBS (Pseudo Random Bit Sequence) in "Art of Electronics".

Gruss Michael

Stephan Mueller schrieb:

Hallo Stephan,

an deiner Stelle wuerde ich mir mal eine (kostenlose) Entwicklungsumgebung von Altera oder Xilinx besorgen. Damit kannst du die Schaltung, so wie du sie dir vorstellst, erstmal bausteinunabhaengig erstellen und simulieren. Bei Altera (evtl. auch Xilinx) kann die Schaltung auch als konventioneller Schaltplan unter Verwendung von 74' Logikbausteinen erstellt werden. VHDL wird man (sofern man es noch nicht kann) wohl erst als zweiten Schritt angehen wollen. Wenn einem die Schaltung dann gefaellt kann man eine Entscheidung FPGA/CPLD treffen. In der Regel wird dies durch die Anzahl der verwendeten Macrozellen = FF's bestimmt. Sollte die Entscheidung zugunsten des CPLD's ausfallen tut man gut daran eines mit genuegend Reserve auszuwaehlen, bzw darauf zu achten dass es einen pinkompatiblen Typen mit mehr Macrozellen gibt.

Gruss Markus

Danke für den Tipp! Das ist natürlich eine gute Lösung, vor allem, wenn man für den groben Aufbau nicht direkt in VHDL programmieren muß.

Danke, Stephan

Ja, parallel.

Der DAC wird wohl 10bit Breite haben. Wenn ich einen 16bit breiten Speicher nehme, kann ich den "übrigen" 6 Bit noch Informationen verstecken. Aber die Idee, den DAC über einen 10 Bit breiten Bus direkt mit dem RAM zu verbinden ist gut; die Daten müßten dann halt vorher (im PC) entsprechend bearbeitet werden..

Ja, das ganze muß zuerst mal initialisiert werden, was aber auch nicht zeitkritisch ist. Ich denke, ich werded wie von Markus vorgeschlagen, die Schaltung erstmal Simulieren und dann gucken, wie groß das Ganze geworden ist. Wenn das dann in ein CPLD paßt und noch genügent freier Platz ist, wird es wohl ein CPLD werden...

Gruß, Stephan

Hi!

Was hast denn überhaupt vor? Klingt so nach Funktionsgenerator.. Und eine "Information" könnte ein Trigger sein.

Eben, in Deinem Fall spart es schonmal 20 Pins (10x Daten rein, 10x Daten raus). Da Du sicher einiges an Adressleitungen hast, die ganzen Steuerleitungen zum RAM und DAC, und evtl noch die eine oder andere sonstige Hardware (Taster/Schalter/Anzeigen/Controller?) können diese

20 Pins schnell den Unterschied machen zwischen "geht noch in einem einfachen CPLD mit PLCC84 in normal lötbarer Fassung" und "soviele Anschlüsse gibts nur noch im FPGA mit 0,5mm SMD-Pin-Raster".

Gruß, Michael.

Hmmmz. Wie wäre es mit diesen MaxII-Dingern von Altera? Soweit ich das mitgekriegt hatte, haben die 'n FPGA genommen, von der Zellen-Anzahl extrem verkleinert und intern noch ein wenig Flash und den Konfigurationcontroller untergebracht. Jetzt nennen sie das ganze CPLD.

Mir fällt jetzt nur beim besten Willen nicht mehr ein, wie teuer die Teile sein sollten. Hielt sich AFAIK aber in Grenzen. Vermutlich 2EUR, wenn man gleich 5Mio. Stück abnimmt oder so ;)

MfG, Maik Schmidt

Hallo Stephan,

| ich möchte folgendes Projekt verwirklichen: Um ein Signal zu generieren | sollen Daten aus einem SRAM auf einen D/A Wandler gegeben werden. Da das | recht schnell sein soll (50 - 100 MHz) dachte ich mir, daß da am besten ein | FPGA oder einem CPLD zum Einsatz kommt. Im Prinzip muß der Baustein nur den | SRAM auslesen, evtl. die Daten shiften und dann auf den D/A Wandler geben. | Die Steuerung des RAMs und des DACs soll natürlich auch vom CPLD/FPGA | übernommen werden.

So was hab ich in meiner Diplomarbeit aufgebaut, mit noch ein paar Randbedingungen drumherum. Ich hab seinerzeit zwei CPLDs von Lattice verwendet, die auch einfach zu bekommen sind. Heute würde ich wohl gleich auf 3V3 Teile von z.B. Xilinx gehen, gabs damals noch nicht, bzw wir hatten eben die Umgebung für die Lattice-Teile...

| Ein CPLD wäre wohl billiger, hat aber auch weniger "Platz".

Reicht aus...

| Außerdem soll | die Verknüpfung der Zellen im CPLD anders als im FPGA sein, so das gewisse | Signalverknüpfungen nicht (oder nur mit größerem Aufwand) möglich sind und | deshalb die Programmierung zeitaufwändiger ist. Stimmt das?

FPGAs haben noch weitere Möglichkeiten was falsch zu machen ;-) CPLDS sind recht einfach in der Handhabung. Meine Meinung zu ABEL kontra VHDL hab ich jüngst schon von mir gegeben.

MArtin

Wenn sowohl CPLD als auch FPGA in VHDL programmiert werden, was kann man bei FPGAs mehr falsch machen als bei CPLDs?

Gruß

Thomas

Wieviel S-RAM Speicher brauchst du denn ? Wenn du mit 100kByte auskommst sind ADSP219x oder Blackfin schnell genug um die Daten vom internen SRAM rauszuschaufeln.

Markus Greim

| Wenn sowohl CPLD als auch FPGA in VHDL programmiert werden, was kann man bei | FPGAs mehr falsch machen als bei CPLDs?

Beim CPLD geht intern alles weitgehend mit einigermaßen gleichmäßigen Laufzeiten, was beim FPGA eher weniger der Fall sein wird. Inwieweit Diene Syntheseroutine das abfängt, kann ich nicht sagen. Mir hat man nur damals (ca 5 Jahre) nahe gelegt, wenn irgend möglich mit CPLD auszukommen, um mich nicht auch noch mit internen Timings zu stressen. Praktisch ausprobiert hab ich das aber nie, weil ich mich dann auf CPLDs gestürzt habe und die bisher immer ausgereicht hatten ;-)

MArtin

Wenn man sich beim FPGA auf einen Takt beschränken kann, alles wichtige IO nach aussen synchron dazu ist und damit alles denselben Setup/Holdzeiten gehorchen muss, kann man bei einem FPGA auch mit drei Zeitangaben für den Router auskommen. Wenn er die schafft, kann einem das genaue interne Timing recht egal sein.

Natürlich kann es einem in der VHDL-Coding-Wut ("ach, alles so schön abstrakt hier...") passieren, dass die synthetisierte Logik erschreckend langsam ist. Aber nach einiger Zeit bekommt schon ein Gespür dafür, wo man vorsichtig sein sollte. Dafür geht in FPGAs halt so unwahrscheinlich viel mehr als in CPLDs...

--
         Georg Acher, acher@in.tum.de
         http://wwwbode.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias