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.ä.
> 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?
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.
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.
> 8 Bit parallel + Takt, mit ca. 200 MHz. und: > Das Steinchen sollte hobbymäßig verarbeitbar sein Vergiss es!
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?
> ... 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.
> 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?
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
> 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
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 :)
Naja, kann man da nicht einfach ein DDR-RAM verwenden und die Daten im Burst-Modus reinschreiben?
Mal zu den 200MHz: Sind da die Laufzeitunterschiede schon wirklich so schlimm das man beim PCB Design aufpassen muss? MFG
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?
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?
> ...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? :-/
> 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 ;)
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:
1 | package stddefs is |
2 | constant ODW : integer := 32; |
3 | constant AW : integer := 30; |
4 | end package stddefs; |
Modul-Datei:
1 | library IEEE; |
2 | library SR_STD; |
3 | use IEEE.STD_LOGIC_1164.ALL; |
4 | use IEEE.NUMERIC_STD.ALL; |
5 | use SR_STD.stddefs.all; |
6 | |
7 | entity busxpander is |
8 | Port ( pdata : in std_logic_vector(7 downto 0); |
9 | pclock : in std_logic; |
10 | cs : in std_logic; |
11 | nwe : out std_logic; |
12 | odata : out std_logic_vector((ODW - 1) downto 0); |
13 | addr : out std_logic_vector((AW - 1) downto 0) |
14 | );
|
15 | end busxpander; |
16 | |
17 | architecture Behavioral of busxpander is |
18 | signal lpm_cnt : std_logic_vector(((AW - 1) + (ODW/8 - 1)) downto 0); |
19 | signal lpm_sr : std_logic_vector((ODW - 1) downto 0); |
20 | begin
|
21 | -- der Zaehler |
22 | process (pclock, cs) begin |
23 | if (cs = '0') then |
24 | lpm_cnt <= (others => '0'); |
25 | elsif rising_edge(pclock) then |
26 | if (cs = '1') then |
27 | lpm_cnt <= std_logic_vector(unsigned(lpm_cnt) + 1); |
28 | end if; |
29 | end if; |
30 | end process; |
31 | |
32 | |
33 | -- das Schieberegister |
34 | process (pclock, cs) begin |
35 | if (rising_edge(pclock)) then |
36 | if (cs = '1') then |
37 | lpm_sr <= pdata(7 downto 0) & lpm_sr((ODW - 1) downto 8); |
38 | -- TODO: an Busbreite anpassen |
39 | if (lpm_cnt(2 downto 0) = "111") then -- wenn busbreite geschoben wurde ... |
40 | nwe <= '1'; |
41 | else
|
42 | nwe <= '0'; |
43 | end if; |
44 | end if; |
45 | end if; |
46 | end process; |
47 | |
48 | -- busbreite geschoben ? |
49 | process (pclock, cs) begin |
50 | if (rising_edge(pclock)) then |
51 | if (cs = '1') then |
52 | if (lpm_cnt(2 downto 0) = "111") then |
53 | nwe <= '1'; |
54 | else
|
55 | nwe <= '0'; |
56 | end if; |
57 | end if; |
58 | end if; |
59 | end process; |
60 | |
61 | -- daten und adresse treestated bei cs = high |
62 | process (cs) begin |
63 | if (cs = '1') then |
64 | addr <= (others => 'Z'); |
65 | odata <= (others => 'Z'); |
66 | else
|
67 | addr <= lpm_cnt(((AW - 1) + (ODW/8 - 1)) downto (ODW/8 - 1)); |
68 | odata <= lpm_sr; |
69 | end if; |
70 | end process; |
71 | end Behavioral; |
Bitte 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.