CPLD, FPGA, oder was?

[Markus T. (Gast)]

Hallo,

ich möchte einen kleinen Datenlogger bauen, der Daten von einem Sensor 
auf SD-Karte schreibt.

Der Sensor liefert kontinuierlich 8 Bit parallel + Takt, mit ca. 200 
MHz.

Jetzt dachte ich, ich nehme einen Protokollwandler, der aus den 
8Bit/200Mhz 32Bit/50Mhz macht und die in SRam (zwischen) speichert (muss 
also noch Adressen hochzählen).
Anschließend würde ich einen kleinen µC beauftragen, den Speicherinhalt 
auf eine SD-Karte zu schreiben.

Welchen Baustein würdet Ihr mir als Protokollwandler empfehlen?
Das Steinchen sollte hobbymäßig verarbeitbar sein, also bitte kein BGA, 
o.ä.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Der Sensor liefert kontinuierlich ...
>
> Anschließend ...
Wie verträgt sich kontinuierlich mit anschließend?
Erst Speicher füllen, danach auslesen und auf SD schreiben?

EDIT:
200MHz = 5ns, das wird an den Ausgangspins ganz hübsch sportlich, so 
ganz ohne Erfahrung mit programmierbarer Logik. Innerhalb eines 
Bausteins ist diese Geschwindigkeit gut erreichbar, an den IO-Pins wirds 
dann kritisch.

BTW:
Läuft der Takt immer weiter?

[ms (Gast)]

1,6Gbit/S oder auch 200Megabyte/s
das ist n ziemlicher Datendurchsatz, darf man mal was fragen was das 
fürn Sensor sein soll?

Nadelöhr ist da aufjedenfall Controller bzw. die SD Karte.

[Markus T. (Gast)]

Hallo,

> Wie verträgt sich kontinuierlich mit anschließend?
> Erst Speicher füllen, danach auslesen und auf SD schreiben?

vielleicht habe ich mich schlecht ausgedrückt.

Der Sensor sendet immer, also kontinuierlich ...
... und zwar 8-Bit parallel, also nix mit 1,6Gbit/s
Ja, Daten und Takt liefert der Sensor, ist die Frage, ob ich den 
Sensortakt im Logikbaustein verwende, oder ob ich dem einen separaten 
Takt speniere.
Ich weiß auch nicht, ob der Takt des Sensors stabil genug ist, um einen 
Logikbaustein zu treiben (irgendwo las ich, dass FPGA's da ziemlich 
empfindlich sein sollen).

Für den Datenlogger habe ich mir vorgestellt, dass ich in einem 
Logikteil jeweils 4 Byte einsammle und die 32Bit breit zum SRam schiebe. 
Dadurch hätte ich die 200 MHz nur auf Eingangsseite und könnte beim SRam 
preiswertere Bausteine verwenden (ich hoffe mal, dass 50MHz keine 
Herausforderung an der Seite bedeuten).

> Erst Speicher füllen, danach auslesen und auf SD schreiben?

Genau. Der Speicher wird gefüllt, d.h. das Logikteil schaltet bei 
Adressüberlauf ab. Anschließend übernimmt der µC das Auslesen des 
Speichers und Schreiben auf die SD-Karte. Dies ist nun völlig 
zeitunkritisch und dürfte mit den bekannten Teilen zu erreichen sein.

[Experte (Gast)]

> 8 Bit parallel + Takt, mit ca. 200 MHz.

und:

> Das Steinchen sollte hobbymäßig verarbeitbar sein

Vergiss es!

[manoh (Gast)]

Datenlogger mit 200 MHz, nicht schlecht... wie lange soll der denn 
durchhalten?

Was ist denn das für ein Sensor, der alle 5 ns einen neuen Wert liefert? 
Sind das vllt nicht 200 kHz?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> ... und zwar 8-Bit parallel, also nix mit 1,6Gbit/s
200 MByte = 1,6 GBit  (200M*8)

> ich hoffe mal, dass 50MHz keine Herausforderung an der Seite bedeuten
Wenn du dich mal mal hoffentlich nicht täuschst. Auch 20 ns für einen 
Speicherzyklus braucht ein wohldurchdachtes Layout und ein ausgereiftes 
Timing.

> irgendwo las ich, dass FPGA's da ziemlich empfindlich sein sollen
Nein, die verdauen auch Takt mit Jitter, wenn du nicht gerade 
irgendwelche DCM/PLL/... Komponenten einsetzen willst.

Du wirst das zwingend auf den Takt aufsetzen müssen. Denn mit diesem 
Takt wirst du entweder direkt ins RAM schreiben, oder wenigstens einen 
Fifo füllen müssen.

[Markus T. (Gast)]

> wie lange soll der denn durchhalten?

Hm, hängt wohl davon ab, wieviel ich in Speicher investieren will.

> Denn mit diesem Takt wirst du entweder direkt ins RAM schreiben, oder
> wenigstens einen Fifo füllen müssen.

Mit welchem Baustein sollte ich mich da anfreunden?
Die Logik hält sich ja in Grenzen - packt das noch ein CPLD?
Wenn ja, wer wäre bei diesem Takt empfehlenswert?

[ms (Gast)]

also entweder du machst dir nen wesenstlich langsameren takt der direkt 
ein wort sampled und dann auf die karte schreibt oder du hast riesige 
lücken in deiner kontunität (wasn schweres wort). Das heißt wenn dein 
Zwischenspeicher voll ist vergisst du alles was in dem zeitraum ankommt.

Und ich halte die 200Mhz immernoch für zu hoch, was is das fürn Sensor, 
und wenn du 200Megabyte die Sekunde speichern willst ist deine SD Karte 
auch schnell voll, da is nix mit Stunden oder Minuten

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> packt das noch ein CPLD?
Ja.

> Wenn ja, wer wäre bei diesem Takt empfehlenswert?
Das ist nun schon wesentlich interessanter...
Sieh dir doch mal das an:
http://www.xilinx.com/support/documentation/application_notes/xapp379.pdf


BTW:
> kontunität
Kontinuität = Durchgängigkeit, Stetigkeit

[ms (Gast)]

Ist ja auch richtig, ich meine ja die Stetigkeit. Wenn er es mit 200Mhz 
im Ram puffert dann ist sein Eingang blind in der Zeit, in der er den 
Inhalt des Rams auf die SD Karte schreibt. Das heißt er bekommt zwar 
viele Werte für einen Zeitraum, dann aber lange nichts.

Deswegen ja der Vorschlag, Sample&Hold, gleich auf die SD-Karte, und 
dann nächstes Sample&Hold. Dann sind zumindest die abstände zwischen 2 
Samples kontinuierlich. Und die SD Karte wird auch dann schnell genug 
voll :)

[Gast (Gast)]

Naja, kann man da nicht einfach ein DDR-RAM verwenden und die Daten im 
Burst-Modus reinschreiben?

[Patrick W. (seennoob)]

Mal zu den 200MHz:
Sind da die Laufzeitunterschiede schon wirklich so schlimm das man beim 
PCB Design aufpassen muss?

MFG

[Markus T. (Gast)]

Guten Morgen,

> Sieh dir doch mal das an

Danke für den Link! War sehr interessant zu lesen.
Besonders hat mir der "Double Data Rate Shifter" gefallen, auch wenn ich 
ihn vielleicht garnicht brauche.

Die negierten FFs müssten doch bei jedem CPLD funktionieren, auch wenn 
der entsprechende Designer das nicht als Element hat - zumindest wenn 
man VHDL codiert, sollte es doch überall machbar sein, oder hängt es 
auch von der Hardware ab, welche Flanke getriggert werden kann?

Bei einer Parameter-Suche sind mir Logikbausteine von Atmel aufgefallen. 
Dort soll es Teile mit 1ns Speed geben. Sind die empfehlenswert? Oder 
sind das nur Blenderangaben für die Parametersuche?
In der Logiksparte habe ich bislang noch nichts von Atmel gelesen. Hat 
jemand Erfahrung mit den Steinchen?

[Markus T. (Gast)]

Nach erstem Vergleich tendiere ich zu der ispMach 4000V Reihe von 
Lattice.
Die gibt es in TQFP und scheint alles zu bieten was ich bräuchte.

Gibt es Gegenvorschläge/Einwände?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> ...tendiere ich zu der ispMach 4000V Reihe von Lattice.
Sieht gut aus...
Beschreib das Ganze in VHDL oder Verilog, dann kannst du später mal den 
Baustein oder den Hersteller wechseln. Mit einem Schaltplan klappt da 
höchstwhrschinlich nicht.

>> Mal zu den 200MHz: Sind da die Laufzeitunterschiede schon wirklich so
>> schlimm das man beim PCB Design aufpassen muss?
Ja.
200MHz dagegen sind ausgesprochene HF, d.h. dort wird nach Millimetern 
mit kontrollierten Impedanzen gearbeitet.
Bei 200MHz mußt du schon froh sein, wenn die auf der Leiterplatte 
bleiben. Andere bauen mit solchen Frequenzen drahtlose Verbindungen auf.

Ein Tipp:
Sieh dir mal die Design Rules zum PCI-Bus an. Und der hat nur 33 MHz.

BTW:
kontrollierte Impedanz.... welcher Trottel hat eigentlich seinerzeit 
"controlled impedance" so derart falsch übersetzt?  :-/

[Markus T. (Gast)]

> Beschreib das Ganze in VHDL oder Verilog, dann kannst du später mal den
> Baustein oder den Hersteller wechseln.

Ich weiß, Du arbeitest bevorzugt mit Xilinx, wenn ich die Übersicht der 
Coolrunners richtig interpretiere, wäre nur der XCR3032 schnell genug. 
Der scheidet aber aus, weil er zuwenig IO bietet.

Lattice scheint "nur" mit Direktvertrieb zu arbeiten. Gibt es (bessere?) 
Alternativen zu meiner Wahl?
Bin am überlegen, ob ich den Weg vom SRam zur SD-Karte nicht auch mit 
CPLD mache. Dann bräuchte ich zwar einen separaten Clock, aber sollte 
doch machbar sein ...

> Bei 200MHz mußt du schon froh sein, wenn die auf der Leiterplatte
> bleiben. Andere bauen mit solchen Frequenzen drahtlose Verbindungen auf.

Das mag wohl stimmen, aber selbst dann, müssen die Signale ja auch 
irgendwie zur Antenne kommen ;)

[Markus T. (Gast)]

Hallo,

habe mal den ersten Entwurf erstellt.
Könnte von den Profis bitte jemand mal drüber schauen?
Bei dem erzeugten Schaltbild bin ich mir nicht ganz sicher ...

Dann habe ich noch eine offene Frage:
wie kann ich den Zähler abfragen, sodass ich die Konstante als Breite 
verwende? Bei der Abfrage sollten alle Bits auf '1' überprüft werden.

zu der HF auf dem PCB:
Dadurch dass ich die Pins ja selbst belegen kann, kann ich die Leitungen 
so kurz halten, dass der Stecker direkt neben dem CPLD ist. So ist der 
Rest der Platine frei für "gemütliche" Signale :)

Bibliothek:

package stddefs is
constant ODW : integer := 32; 
constant AW  : integer := 30;
end package stddefs;

Modul-Datei:

library IEEE;
library SR_STD;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL; 
use SR_STD.stddefs.all;

entity busxpander is
    Port ( pdata  :  in std_logic_vector(7 downto 0);
           pclock :  in std_logic;
           cs     :  in std_logic;
           nwe    : out std_logic;            
           odata  : out std_logic_vector((ODW - 1) downto 0);
           addr   : out std_logic_vector((AW  - 1) downto 0)
         );
end busxpander;

architecture Behavioral of busxpander is
   signal lpm_cnt  : std_logic_vector(((AW - 1) + (ODW/8 - 1)) downto 0);
   signal lpm_sr   : std_logic_vector((ODW - 1) downto 0);
begin
   -- der Zaehler
   process (pclock, cs) begin
      if (cs = '0') then
         lpm_cnt <= (others => '0');
      elsif rising_edge(pclock) then
         if (cs = '1') then
            lpm_cnt <= std_logic_vector(unsigned(lpm_cnt) + 1);
         end if;
      end if;
   end process;


   -- das Schieberegister
   process (pclock, cs) begin
      if (rising_edge(pclock)) then
         if (cs = '1') then
            lpm_sr <= pdata(7 downto 0) & lpm_sr((ODW - 1) downto 8);
            -- TODO: an Busbreite anpassen
            if (lpm_cnt(2 downto 0) = "111") then  -- wenn busbreite geschoben wurde ...
               nwe <= '1';
            else
               nwe <= '0';
            end if;
         end if; 
      end if;
   end process;

   -- busbreite geschoben ?
   process (pclock, cs) begin
      if (rising_edge(pclock)) then
         if (cs = '1') then
            if (lpm_cnt(2 downto 0) = "111") then
               nwe <= '1';
            else
               nwe <= '0';
            end if;
         end if; 
      end if;
   end process;

   -- daten und adresse treestated bei cs = high
   process (cs) begin
      if (cs = '1') then
         addr  <= (others => 'Z');
         odata <= (others => 'Z');
      else
         addr  <= lpm_cnt(((AW - 1) + (ODW/8 - 1)) downto (ODW/8 - 1));
         odata <= lpm_sr;
      end if;
   end process;
end Behavioral;