www.mikrocontroller.net

Forum: FPGA, VHDL & Co. CPLD und AVR Kombo (Logic Analyzer)


Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

sicher haben einige schon von dem "Logic Analyzer bauen" Thread im
Forum "µC & Elektronik" gehört. Ansonsten ist im Wiki ein ungefährer
"Stand der Erkenntnisse/Dinge" festgehalten. Momentan ist leider noch
vieles im Fluss.

Also: ATMega8 sei per UART/USB Chip mit dem PC verbunden. Weiterhin
exisitiert eine Verbindung zwischen AVR und dem Xilinx XC95144XL zur
Kommunikation - wahrscheinlich SPI (oder Parallelport Lösung), aber
egal.

Der AVR wird per Bootloader vom PC aus programmiert werden (oder
umständlich per Kabel über ATMEL/ISP Stecker).
Der Xilinx kann mit dem JTAG ISP programmiert werden, also konkret über
angeschlossen Xilinx JTAG/Parallel Download Cable
(http://www.xilinx.com/support/programr/jtag_cable.pdf) und Xilinx/ISE
impact(?).

Existiert eine fertige Lösung, wo ich mir das Kabel/Pinleiste am CPLD
sparen kann, also den CPLD über PC->ATMega8 programmieren kann?

Es soll es mal einen erthernut-thread gegeben haben, wo es wegen des
Aufwandes verworfen wurde.

Viele Grüße
Olaf

Autor: Konstantin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine fertige Lösung ist mir nicht bekannt. Aber die Pins, die Du für
Programmierung benutzt kannst Du, meiner Meinung nach, nicht als I/Os
verwenden. Also sparst Du nichts.

Ich fürchte, PC->ATMega8->CPLD klappt so nicht :-(

Noch eine Frage (ich möchte jetzt nicht den ganzen Logic Analyzer
Thread noch mal durchlesen), aber wozu noch AVR? Mann kann doch
genausogut uart im CPLD implementieren :-o



Konstantin

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Konstantin:
Vielen Dank! Ich hatte so etwas schon befürchtet. Die verfügbaren I/O
waren auch der Grund zum Sprung vom XC9572 auf den CX95144.

Momentan ist der Stand:

* 2Stck 256k x 16 SRAM (synch/asnych steht noch nicht konkret fest
wegen Preis/Verfügbarkeit). Dies benötigt ggf. 2 Adresszähler
(odd/even) mit jeweils 18 Macrozellen. Die beiden Bänke werden entweder
im Interleave betrieben für maximale Performance oder zur Speicherung
zB. einer 18Bit Timestampadresse und 14bit Bit Pattern zum Transitional
Timing Analysis Mode (einer wohl künftigen VHDL Implementation, aber wer
weiss schon) um den Speicher effizient zu nutzen.
* 2x 8 Eingänge für den LA, weitere 16 MC für's Latch
* Hinzu kommt die (komplexe) Trigger Logik mit
* Zähler für interne Clocks (einstellbare Samplerate)

Die Schwellen sollen per Analog Comperator einstellbar sein, d.h. des
muss ein 2Channel DAC mit ran, per SPI programmierbar. Wenn alle
Stränge reißen mit dieser Eingangsbeschaltung, muss halt 74HCxxx
genommen werden.

Zur Generierung des Clocks soll ein Chip mit PLL eingesetzt werden,
dessen Multiplier per SPI ebenfalls programmierbar sein soll.

Leider existiert bisher kein konkretes Design in VHDL, so dass man
abschätzen kann, ob ein XC95144TQ144 (ca 12,-€) seitens der Macrozellen
ausreichen würde (die I/O reichen zumindest endlich).

Daher wurde der ClockMultiplierChip, der DAC und das UART
(Ansteuerlogik) in den Atmel verlegt - dieser soll per USB an den
Rechner ran, konfigurieren (Trigger Cond. etc.) und den SRAM
anschließend über den CPLD auslesen. Auch kann dort im AVR-EEPROM der
maximale Multiplier des Taktchips gespeichert werden, da der maximale
Takt vom PCB (wohl zweiseitig aus Kostengründen), vom löten u.a.
abhängig ist und derzeit vollkommen unbekannt ist - wir sind da alle
voller Hoffnung die möglichen 100MHz zu erreichen :)

Es gibt irgendwo eine Reference Impl. von xilinx eines uart, habe sie
mir aber noch nicht angesehen. Wieviel MC braucht denn ein uart ca?
Kann man dann darüber den CPLD programmieren? Wäre ein CP2102 oder FTDI
daran möglich?

Natürlich passt alles in ein FPGA, aber die sind teuer und das Ende des
LA ist (noch) ungewiss - da möchte keiner viel Geld investieren in
mögliche Fehlschläge. Wir sind froh, wenn alles unter 100€ bleibt
(Alleine ein FPGA DevKit sind schon über >100€ - wenn auch kein
rausgeworfenes Geld i.A.).

Das Problem das ich habe (und sicher auch viele andere aus dem uC
Forum): ich habe zwar viel über CPLD gelesen, aber kann (noch) kein
VHDL bzw. habe praktische Erfahrungen damit - insofern ein (imo
lohnenswertes) CPLD Einstiegsprojekt.

Viele Grüße
Olaf

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS: Es war auch die Rede davon, im AVR eine kleine Kompression
einzusetzten um die Datenübertragung zu beschleunigen.

Autor: Konstantin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Zusammenfassung! :-)

Habe jetzt mal Uart in ein CPLD gefittet. Zwar in 9572, aber die sind
ja ähnlich. Und es werden 26 MC gebraucht, nicht sehr viel.
Aber wenn viel Zeug drin ist, ist das sehr schwer abzuschätzen.

Ob man CP2102 oder FTDI dranhängen könnte, weis ich erstmal nicht. Ich
meine jetzt, was MC angeht. Aber ich vermute stark, dass ja. So viel
Logik steckt da nicht drin.

Das Projekt interessiert mich sehr. Nur leider verliere ich die
Übersicht dabei :-/ ICh meine, ich würde wirklich bei "Null"
anfangen.  Nach meinem Geschmack sind das zu viele ICs drin, zu viele
Unsicherheiten.

Sonst, viel spaß bei dem Projekt, und falls was ist - fragen! :-)

Konstantin

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

mal ganz doof gefragt wieso nehmt ihr kein AT94k ????

Gruß,

Dirk

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nach meinem Geschmack sind das zu viele ICs drin, zu viele
> Unsicherheiten.

Yep, das stimmt. Deshalb bin ich sehr froh, das wir von der 3x CPLD
Lösung weg sind :)

Ziel ist es, ein <100€ Proof-on-Concept hinzubekommen, mit wenig
Mitteln viel zu erreichen. Daher für die Komparator Schwellenspannung
Erzeugung keine PWM etc. sondern gleich einen erprobten IC. Dies
verringert die Fehlerquellen. Solche Überlegungen ziehen sich durch den
gesamten Thread und machen ihn auch so lang und unübersichtlich  - man
findet zB. nichts wieder ;-)

Momentan:
- 1 CPLD
- 2 SRAM
- 1 uC
- 1 DAC
- 1 Clockgen
- 1 oder 2 Quarze
- 1 USB Chip
- 4 Quad-Komparatoren oder die Nx 74HCxxx
- Stützkond. obligat :-)

und

- SPI untereinander weil einfach.

Ich versuche das Wiki auf
http://www.mikrocontroller.net/articles/Logic_Analyzer halbwegs aktuell
zu halten um den Quer- und Neueinsteigern eine kurze Zusammenfassung der
Egebnisse zu geben - mir hilft es, die Gedankengänge, URL etc.
übersichtlich zu behalten.

Viele Grüße
Olaf

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wiki updated

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Olaf:

>> * 2Stck 256k x 16 SRAM (synch/asnych steht noch nicht konkret fest
>> wegen Preis/Verfügbarkeit). Dies benötigt ggf. 2 Adresszähler
>> (odd/even) mit jeweils 18 Macrozellen. Die beiden Bänke werden

Warum so ?
Du benötigst nur einen 18 Bit Addresszähler, aber dafür für den einen
SRAM im CPLD einen 16 Bit Latch für die Daten.
Also man versucht interlaved beide SRAM's zu schreiben. Immer
abwechselnd SRAM A und B und A und B, aber zeitlich überlappend. Dabei
entsteht das Problem das man 2 Addresszähler benötigen würde. Wenn aber
SRAM A zeiltich um exakt 1 Sampletakt später angesprochen wird benötigt
man nur noch 1 Addresszähler für beide SRAM's. Dazu muß man aber die
gesampelten Daten für SRAM A exakt 1 Takt lang im CPLD
zwischenspeichern, also in einem Latch.
Diese Technik kann man so auch weiter ausbauen. Angenommen mit 4 SRAMs.
Dann benötigt man 3 Latches. Der 1. Latch hält seine Daten exakt 3 Takte
lang, der 2. 2 Takte und der 3. Latch 1 Takt. Die kompletten Daten der 4
SRAM's werden dann synchron mit gleichem Addresszähler gespeichert.

Vorteile ?
Der Addressbus ist der Bus mit den meisten Leitungen. Nach obigem
Konzept können nun alle SRAM's am gleichen Addressbus parallel
angeschlossen werden. Man spart also Pins am CPLD und Leitungen im
Layout.

Geht man aber weiter und benutzt "synchrone" SRAM's so kann man
sogar die internen Daten-Latches im CPLD einsparen. Dazu muß der CPLD
in Halbtakt-Schritten den Addresscounter erhöhen. Die SRAM's werden
nun durch den CPLD so getaktet das sie exakt zum Sampletakt die Daten
am Datenbus übernehmen. Synchrone SRAM's speichern ihre Daten ja auf
eine Taktflanke hin, nicht so wie bei asynchronen SRAM's. Elektronisch
würde das also dann so aussehen:

- SRAM's mit gemeinsammen Addressbus am CPLD.
- gemeinsammer Datenbus der SRAM's zu den Eingangstreibern
- vom CPLD zu den SRAM's separate Taktleitungen
- CPLD enthält 18 Bit Addresscounter für gem. Addresbus
- CPLD taktet im Smapletakt abwechselnd die SRAM's, die übernehmen zur
Taktflanke die Daten auf dem gemeinsammen Datenbus

Der CPLD hat also folgende Pinbelegung:
- 18 Bit Addressbus
- 2 Taktleitungen für SRAM's
- 1 Takteingang für die Sample-Clock
- 1 Resetleitung zum AVR
- 1 Enable Leitung zum AVR


Fertig. Der CPLD halbiert den Sampleclock und erhöht in diesem Halben
Takt den internen Addresszähler. Mit dem Sampleclock synchon wird nun
abwechselnd SRAM A und SRAM B getaktet.

So, fehlt nun nur noch das Auslesen der SRAM's über den AVR. Auch das
kann man fast über die gleiche Logik im CPLD erreichen. Nur diesesmal
taktet der AVR den CPLD und somit dessen Addresscounter. Der AVR muß
nur die Eingangslogik auf HighZ setzen, den CPLD Takten, die SRAM OE/WR
Leitungen korrekt setzen und kann dann ebenfalls über einen 16 Bit Port
die Daten sequentiell aus den SRAM's lesen.

Ich würde also empfehlen mit synchronen SRAM's zu arbeiten.

Gruß Hagen

Autor: C. Lechner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann IMHO das CPLD über den Microcontroller durchaus programmieren.
Siehe dazu http://www.xilinx.com/bvdocs/appnotes/xapp058.pdf

Man könnte also (bei Bedarf) das SVF File über UART an den uC liefern,
der es dann ins CPLD schießt. Viel Eigenintelligenz des uCs scheint
dazu nicht erforderlich zu sein. Hätte den Vorteil, dass der
Nachbauende sich den Xilinx Programmierer sparen kann und man schnell
(im Feld) den Inhalt des CPLDs austauschen kann.

CU
- C. Lechner

Autor: C. Lechner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nochwas: Das SVF File erzeugt man mit dem Xilinx Impact Tool. Für den
XC95144XL würde man ca. 150kB Speicher brauchen.

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:
Vielen Dank für die Auführung, allerdings habe ich ein Problem
(Verständnis) bei der Darstellung mit asynchronen SRAM. Müssen die
Adressen nicht auch einige Zeit stabil anliegen, bevor die Daten
gelesen/geschrieben werden können, exemplarisch Timing auf
http://rocky.digikey.com/WebLib/ST%20Micro/Web%20D...?

Daher die Idee mit 2 Adresszählern, ansonsten müßte ein Adresszähler
und 2 Adresslatches (neben den 2x 16-Bit Data-Latches) verwendet
werden, welche durch das LSB angesprochen werden - genaugenommen
benötigte man für die 2x (256k x 16) einen 19 Bit Adresszähler. Daher
kann der Addressbus der asynch SRAM nicht gleichzeitig an allen SRAMs
anliegen. Liege ich richtig/falsch?

Ansonsten muss ich es mir erstmal aufmalen (asynch/synch) was Du
beschrieben hats. Das Problem mit den synchrones ist die
Verfügbarkeit/Preis bisher gewesen.

Viele Grüße
Olaf

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@C. Lechner:
Angeblich wurde http://www.xilinx.com/bvdocs/appnotes/xapp058.pdf im
ethernut Thread
http://www.mikrocontroller.net/forum/read-1-138024... als
softwaretechnisch zu aufwendig verworfen. Es ist aber auch so'n langer
Thread wie der des LA und schwer zu lesen. Weiss jemand genauers?

Viele Grüße
Olaf

Autor: C. Lechner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab jetzt die URL des Beitrages, wo steht dass es ziemlich übel ist
(10k SRAM für den uC)

http://www.mikrocontroller.net/forum/read-1-138024...

Ist dann wohl nix, sollte man allerdings auch ins Wiki einfügen.

-cl

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Olaf:

am besten du malst dir mal das Timing auf einem Blatt Papier auf.
Wir haben zb. alle 40ns einen Sampleimpuls und müssen diese Daten in 2
SRAM's a 70ns speichern. Die geraden Sampleimpulse landen im SRAM A
und die ungeraden im SRAM B. Auf deinem Blatt Papier müsste man also
abwechselnd alle 40ns den Sampletakt für A,B,A,B,A,B.. zu sehen sein.
Bei einem gemeinsammen Addresscounter würde dieser mitten im
Schreibzyklus des SRAM's B aber schon inkrementiert werden damit für
SRAM A die nächste Addresse anliegt. Der Zeitpunkt des Inkrementierens
des Addresscounters liegt also mit 40ns in der Hälte der 80ns beim
Schreiben von SRAM A. Deshalb meinst du auch das man 2 Addresscounter
benötigen würde.
Aber, auf deinem Blatt Papier verschieben wir nun einfach die Zeitachse
für SRAM A um exakt 40ns nach rechts. D.h. wir samplen alle 40ns, aber
diesesmal abwechselnd in 2 Latches A und B. Die Speicherung dieser
Latches wird aber erst ausgeführt wenn Latch B gefüllt wurde. Somit ist
der Addresscounter und der Datenbus für beide SRAM's synchon für 80ns
stabil. Die SRAM's benutzen den gleichen Addressbus aber eben
getrennte Datenbusse.

18 Bit Addressbus + 2*16 Bit Datenbus, statt eben 2*18 Bit Addressbus +
2*16 Bit Datenbus. Die beiden internen Latches zur Zwischenspeicherung
der LA Eingänge benötigst du sowieso !

Allerdings meine ich eben das synchrone SRAM's viel besser geeignet
wären. Die Kosten für solche Teile schlagen sich in den Gesamtkosten
nicht so stark nieder als das man an dieser Baustelle sparsam sein
sollte. Immerhin vermute ich mal das die Eingangselektronik, also
schnelle Komparatoren + gute HighZ Eingangsbuffer usw. viel teurer
wird.


Gruß Hagen

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen,

yep - jetzt hab ich das Prinzip begriffen (denk' ich zumindest), der
Adresszähler wird ja mit fs/2 getaktet! Das Prinzip selbst ist klever!

Morgen komme ich an einen Scanner, dann stelle ich meine Timing Skizze
rein.

Zum Thema CPLD proggen:
Im ethernut Thread wird auch
http://www.ethernut.de/en/xsvfexec/index.html XSVF Executor erwähnt,
hat den schon mal jemand ausprobiert? Immerhin steht da ja: "The XSVF
Executor emerged from a complete re-design of the original Xilinx
code". Und steht da noch: "XSVF Executor has been successfully tested
with the Ethernut 2 board, programming the on-board XC9536XL". Also
muss es doch letzlich doch gehen, oder übersehe ich das was?

Viele Grüße
Olaf

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
es geht sicher... die frage ist nur wie viel arbeit wirds das ganze zu
portieren... man bedenke nur das am ethernut2 die immerhin 512kb ram
dran haben ;)

aber ich denke eher an einen programmer-emu... sprich man booten in den
loader und sagt ihm bitte werde zum cpld jtag programmer...

dann wirft man die programmer-soft seiner wahl an und fertig... das
dürfte am wenigsten aufwand sein... sonnst darf man sich überlegen wie
man stück für stück die daten reinbekommt usw.. komplizierte protokolle
können nix find ich... und wenn man dem pc die arbeit machen lassen kann
... warum nicht ;)

73

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anscheinend bin ich einer von der langsamen Sorte - dieses hattest Du ja
schon mal erwähnt. Sprich den AVR in 2 Modi, zB per Bootloader, arbeiten
lassen, richtig? Ist wohl zu heiss für meine BrainWare :)

Imo hat Ethernut aber auch ein Henne-Ei Problem lösen müssen, da das
Ram paging ja per CPLD gemacht wird. Oder wird im AVR RAM der CPLD
programmiert und anschließend im paged RAM des CPLD weiter gearbeitet?
Sprich ohne groß "reboot".

Viele Grüße
Olaf

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
WiKi updated.
Neues Highlight:  Datenblätter, Bezugsquellen und Preise

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vergiss doch erstmal den Bootloader und das autom. Programmieren des
CPLDs/FPGAs. Als erstes einfach davon ausgehen das der CPLD nicht
ständig reprogrammiert wird und im fertigen Betrieb wird man ihn eh
nicht mehr umprogrammieren. D.h. also das ein simpler JTAG für den AVR
und für den CPLD vollkommen ausreichend sein sollten. Erst später würde
ich mich auf solche Details konzentieren.


Gruß Hagen

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das sehe ich auch so und so wird es wohl auch umgesetzt werden.

Die Frage dahinter ist allerdings, welche "Strippen" muß ich in den
Schematics vorsehen, dass diese Option für künftige
AVR-Firm-/Software bei unveränderter Hardware besteht.

Ob sich dann letzlich jemand daran setzt und realisiert ist freilich
eine andere Sache. Sinnvoll wäre es das Problem zu lösen, da dieses
Problem ständig wieder auftritt und die AVR/CPLD Kombo imo ein gutes
Gespann ist, wo FPGA Overkill/zu schwierig ist.

Momentan sieht es so aus, also ob der CPLD und AVR diese 4 I/O frei
hat, warum also dann nicht ranknippern? Ggf. per Lötpad scharf machen
oder garantieren, dass der angeschlossene AVR Port HighZ ist, solange
es softwaretechnisch nicht unterstützt ist.

Per JTAG Stöpsel ist auf jeden Fall die "Sichere und Schnelle
Ergebnisse" Methode, schon um Frust zu vermeiden.

Viele Grüße
Olaf

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich bin für folgendes.. leg einfach die jtag pins des cpld auf einen
eigenen port... fertig.. wenn wir das mal machen wird das in software
gepollt...

falls zuwenig platz am avr sein sollte...mega16 statt mega8 hin ;)

aja jedes nicht anders initialisierte port am avr ist von natur aus
highZ ;)

73

Autor: Clemens Helfmeier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

ich schlage vor, den CPLD-Jtag-port auf den AVR zu legen und die
Firmware nicht in den AVR zu verlagern sondern in den PC (da ist ja
bekanntlich vieel Platz ;)). Der AVR macht dann nichts weitere als die
Befehle an den JTAG-Port weiterzuleiten ... den genauen Ablauf /
Protokoll kann man auch später noch festlegen.

Jetzt ist erstmal das Layout gefragt und dort ist wichtig:
JTAG-Verbindungen zum AVR.

Clemens

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
üm übrigen bin ich der meinung, dass jtag header mit aufs board
müssen...

73

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Clemens:
>ich schlage vor, den CPLD-Jtag-port auf den AVR zu legen und die
>Firmware nicht in den AVR zu verlagern sondern in den PC (da ist ja
>bekanntlich vieel Platz ;)). Der AVR macht dann nichts weitere als
>die Befehle an den JTAG-Port weiterzuleiten ... den genauen Ablauf /
>Protokoll kann man auch später noch festlegen.

So wie ich das verstanden habe, ist genau das das Problem - JTAG ist
ein Protokoll und muss vom AVR interpretiert werden, was
verhältnismäßig viel RAM frisst.

Zumindest herrscht Einigkeit über den JTAG Stecker am CPLD, der für die
Programmierung über den AVR vorbereitet wird. Meine Frage: Kann jemand
mit Bestimmtheit sagen, das 4 Portpins ausreichen?

Viele Grüße
Olaf

Autor: Clemens Helfmeier (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Olaf,

ich denke, solange die eigentliche Verbindung nur 4 Leitungen hat,
braucht der AVR auch nur 4 Leitungen zu reservieren. Beim AVR geht ja
alles (Abfragen & Setzen) auf jeder Leitung einzeln. Es würde die Sache
eben nur verlangsamen und den Code vergrößern.

Gibt es beim JTAG eine Mindestgeschwindigkeit? Ich denke das wäre der
einzige Grund, woran dies scheitern könnte.

Schöne Grüße, Clemens

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen
Hier das Timing des interleaved RAM, wie ich es verstanden habe.

Viele Grüße
Olaf

Autor: ope (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
verflucht, warum vergißt das Forum ständig meine Anhänge?

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Olaf,

ja, so hast du zumindestens beide Kanäle synchron. Alledings müssen die
SRAMs trotzdem so schnell wie der Sampletakt sein und man verschenkt die
halbe Samplingtime ohne das die SRAMs was zu arbeiten hätten. In dieser
Konfiguration sind die SRAMs also so schnell wie der Samplingtakt, ergo
köntest du auch gleich die SRAMs immer sequientiell für Kanal A dann B,
A, B usw. ansprechen. Du würdest dann also nur noch 18 Addressleitungen
+ 16 Datenleitungen, alle gemeinsam für beide SRAM's benötigen. Es gibt
asynchone statisch SRAMs für ca. 3-5 Euro das Stück die 10ns
Zugriffszeiten haben = 100Mhz. Würde man aber solche Teile benutzen,
und 100Mhz wären ausreichend, ja dann benötigst du garnicht mehr das
interleaved Speichern, sprich eine Trennung von Kanal A und B. Ergo:
dein Timingdiagram bringt im Grunde keine Vorteile, man kann immer noch
nur so schnell samplen wie die SRAM's das aushalten.

Man würde nun für Kanal A einen zweiten Latch benötigen. Kanal A hat
also 2 Latches. Jedes dieser Latches speichert für den Kanal A immer
nur den 2. Sample. So wie im Attachment. Daraus sollte ersichtlich
werden das die Datenbusse für A und B nun synchron zum gem. Addresbus
komplett die Daten halten können. Ergo könnte man nun mit zwei 10ns
SRAMs einen Sampletakt von 200Mhz fahren.

Ich weis nicht so recht. Wenn es für 3-6 Euro große asynchrone SRAM's
mit 512Kb zu kaufen gibt -> Kessler Electronics, die zudem noch mit
10-15ns sehr schnell sind, warum diese nicht benutzen ?
Oder wenn es günstig synchrone SRAMs gibt, die nun auch noch die
internen Latches ersetzen könnten, warum diese nicht benutzen ?

Man kann mit CPLDs/FPGAs ja wunderschöne Sachen machen, und ja für die
Profis ist das meistens nach deren Aussagen ein Klacks, aber ICH als
"Anfänger mit 20 Jahren professioneller Programmierererfahrung"
bastle zB. schon 3 Tage an einem simplen SPI Slave für den CPLD. Damit
möchte ich zum Ausdruck bringen das man den CPLD nicht unterschätzen
sollte und es am cleversten ist die Logik im CPLD nicht zu
verkomplizieren. Wenn es also schon günstig die passende Hardware gibt,
in Form von schnellen asynch. SRAMs oder eben synchronen und getakteten
SRAMs, warum diese dann nicht benutzen ?

Gruß Hagen

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:
Jetzt habe' ich es - vielen Dank. Es in VHDL umzusetzten ist aber ein
anderes Thema als Neuling :-)

> Ich weis nicht so recht. Wenn es für 3-6 Euro große asynchrone
> SRAM's mit 512Kb zu kaufen gibt -> Kessler Electronics, die zudem
> noch mit 10-15ns sehr schnell sind, warum diese nicht benutzen ?
> Oder wenn es günstig synchrone SRAMs gibt, die nun auch noch die
> internen Latches ersetzen könnten, warum diese nicht benutzen ?

Richtig, Kessler gibt's ja auch noch!

Leider hat Kessler keine genaueren Bezeichnung in der SRAM Abteilung,
womit dann auch ein entsprechendes Datenblatt findet (oder zu alt und
abgekündigt).

Immerhin ca. 10€ für Statisches RAM 256K x 16 55ns LLPower TSOP44, über
synchron/asynchron steht leider nichts da.

In der Asynchron SRAM Abteilung gibt's zumindest Highspeed-RAM 256Kx16
12ns 3,3V asynchron TSOP44 oder SOJ44 für 8,00/8,50.

Ich stimme Dir zu, dass es so einfach wie möglich gehen soll;
persönlich gebe ich lieber 3-5 Euro mehr für synchrone SRAM aus und
erspare mit mehrere Stunden/Tage bei der Umsetzung - nur erstmal die
synchronen mit Datenblatt preiswert finden.

Viele Grüße
Olaf

Autor: Jörn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ope:

Ich bin grad dabei die Ansteuerung für asynchrones SRAM auf dem Xilinx
Board zu machen. Werds posten, wenn es mal tuten sollte.

@Hagen:
Ich kann dir eine komplette SPI Schnittstelle (Master/Slave) anbieten.
Ist komplett konfigurierbar. Wurde für ein FPGA umgesetzt (Spartan2).
Etwas abgespeckt wüßte sie auch in ein CPLD passen. Wenn du Interesse
hast einfach ne Mail schreiben.

Gruß Jörn

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Jörn

das wäre echt nett, an HaReddmann bei T-Online punkt de.

Mein derzeitiges Problem ist garnichtmal der SPI Slave sondern wie
immer das leidige Thema mit der Synchronität zu den anderen Elementen
im Design. Ich bekomme sowas immer nie richtig hin. Leider stösst man
mit CPLD's dann allzuleicht an deren Resourcegrenzen.

Gruß Hagen

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

>Leider stösst man mit CPLD's dann allzuleicht an deren
>Resourcegrenzen.

Also steigen wir doch um auf FPGA?

Gruß,

Dirk

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
XC9572 -> XC95144XLTQ144 -> XC95288XLTQ144 Evolution?

XC95288XL10TQ144 288Macro 117I/O 10ns TQFP144  18,618€ bei Darius.de

Allerdings kommen wir langsam in FPGA Preis Regionen.

Oder die synchronen SRAM stärker avisieren?

Viele Grüße
Olaf

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich muss euch leider unterbrechen. Ich hatte jetzt schon mehrmals den
AT94k angesprochen, aber keine Positive- und Negativeresonanz gehoert.

Wir wissen immer noch nicht wieviele Gatter & Makrozellen benoetigt
werden. Preislich kostet der AT94k mit 5k Gattern + 256 Corezellen bei
Digikey 20 Dollar. Der Preis bei Digikey ist ueberzogen. Diesen FPGAAVR
Typ kriegt man fuer knapp 10 Euro.

Der AVR Part laeuft auch mit 25Mhz.

Gruß,

Dirk

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hatten wir glaubich schon im anderen forum....

wie ist das mit beschaffen über digikey ??? wenn das vernünftig
geht...

gibts da zufällig auch welche die usb haben ??? ;)

bei 10e klingt das auf jeden fall interessant...


73

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

direkt mit USB nicht, aber der FTDI245 sollte doch problemlos am FPGA
Part laufen koennen.

Die 10E wurden mir von einem Händler genannt. Wie es mit der
Verfuegbarkeit aussieht kann ich leider noch nix zusagen.

Schaut euch doch mal selber die Datasheet's an....

Gruß,

Dirk

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dirk,

Vergiss den AT94k von Atmel. Das hört sich auf den ersten Blick sehr
gut an und auch ich habe mal einen ganzen Tag mit Recherchen
verplempert. Das Problem -> Software und Synthese. Schaue dir mal die
Lizensbedingungen und die für den AT94k benötigte Software genauer an.

Ok, ich bastel nicht an eurem projekt mit, meine aber das Xilinx/Altera
CPLDs/FPGAs bei weitem günstiger und flexibler sind und deren Software
samt verfügbaren Sourcecode viel praktikabler sind.
Für sinnvolle Erweiterung des AVR Cores enthält der AT94k viel zu wenig
Resourcen. Desweiteren muß man eben die teure Spezialsoftware von Atmel
dazu benutzen. Ich bin nun nicht der Profi, meine aber das dem AT94k
keine große Zukunft beschieden ist.

Gruß Hagen

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen:
Vielen Dank für die Mühe und vor allem Weitsicht!

Aus  FPSLIC (AVR with FPGA) - FAQs:

After the 4-month period customers will need to purchase a new software
license. There are two options...

A 12-month license including 12 months maintenance (ATDS94KSW1) is
available for a suggested resale of $995.

A perpetual license, which includes 12 months maintenance (ATDS94KSW2),
is available for a suggested resale of $2,495. Additional 12-month
maintenance contracts (ATDM94KSW2) is available for a suggested resale
of $495.

Viele Grüße
Olaf

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

also ihr meint das die Software mehr als 4 Monate braucht?
Oder wegen spaeterer Updatefaehigkeit?

Oder wollt Ihr ein fertiges Geraet bauen und an Endkunden verkaufen?

Gruß,

Dirk

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Preis ist doch nur ein Punkt der vielen "Unzulänglichkeiten".
Schaue dir mal an was ein "normaler" Xilinx/Altera FPGA für Resourcen
enthält. Die haben um ein Vielfaches mehr an LEs, haben BlockRAMs,
DualPort RAMs, meistens mehrere DCMs bzw, PLLs oder DLLs. Zudem ist
deren Software frei erhältlich und im WEB gibt es fast ausschließlich
nur Seiten für Xilinx/Altera Steine.
Nun schauen wir ins Datenblatt des AT94k und sehen
- der FGPA Core ist lächerlich unterdimensioniert, 5k ? heutzutage sind
50-250k Gatter angesagt.
- der FPGA Core ist vergleichweise arsch langsam
- die Kommunikation zwischen FPGA Core und AVR Core ist saumäßig schwer
und man muß komplizierte Regeln beachten
- an der Dokumentation happert es gewaltig und viele Fragen bleiben
ungeklärt
- man kann den AT94k nicht mit Standard VHDL/Verilog/Abel Sourcen
programmieren sondern muß mit der Atmel Software arbeiten, zumindestens
interpretiere ich das aus den Unterlagen
- auf der Atmel Seite habe ich kein einzigstes IP Core für den AT94k
gefunden
- an eine spätere Portierung der programmierbaren Logik in
Xilinx/Altera Steine ist somit nicht zu denken, im Gegenatz dazu ist
eine Portierung eines VHDLs von zb. einem XC95?? auf einen MAX7??? im
Grunde absolut problemlos möglich

Naja, tut nichts zu Sache da ich sowieso nicht an dem Projekt arbeiten
werde. Ich wollte es nur erwähnt haben da ich nach meiner Recherche bei
Atmel, anfangs hyperoptimistisch, so ziemlich enttäuscht wurde.
Eventuell solltest du mal bei AVRFreaks suchen, dort hatte ich ähnliche
Meinungen zum AT94k gelesen.

Gruß Hagen

Autor: Hagen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso ein nicht unwichtiger Punkt fehlt noch:

Warum? zum teufel soll man ein Unternehmen aktiv unterstützen das den
Hobbyentwicklern so saumäßig schlechte Konditionen einräumt. Keine
Samples, keine Dokus, keine 3'rd Party IP Cores, prohibitäre Software
und dann noch überteuert.

Immerhin UNSER "Kaufverhalten" am Markt ist dafür verantwortlich wie
sich die Firmen am Markt positionieren müssen. Nur mal am Rande
erwähnt.

Bisher kenne ich nur eine einzigste private Anwendung des AT94k. Ich
glaube es war ein Contest bei dem ein Teilnehmer einen Fahrrad Computer
mit dem Teil gebastelt hatte.

Gruß Hagen

Autor: ope (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Parallel Thread
http://www.mikrocontroller.net/forum/read-1-204570.html#new wurden dem
LA Projekt einige  XCS40XL-4 PQ208C angeboten. Allerdings wird dieser
von ISE 7.1 nicht unterstützt. Einiges Wühlen brachte zu Tage, das dazu
ein "ISE Classics"  oder das ISE WebPACK 6.1 installiert sein muss.
Auf http://www.xilinx.com/webpack/classics/spartan_4k/index.htm steht
weiterhin, das ich bei "ISE Classics" auf 3rd Party Tools angewiesen
bin:

Synthesis can be accomplished by using Synopsys FPGA Compiler-II,
Synplicity Synplify, or Mentor Graphics LeonardoSpectrum™. The Spartan
and XC4000 series device families were never supported by Xilinx
Synthesis Technology.

Heißt das letzlich, dass ich diese FPGA niemals (oder extrem aufwendig)
mit legaler Software programmieren kann?

Viele Grüße
Olaf

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
tja die haben anscheinend 2 familien gebaut, die sie selbst nicht
supporten (zumindest haben sie keine synthese-tools dafür..)

die sinnfreiheit hat mal wieder gesiegt...

73

Autor: Clemens Helfmeier (sum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

wenn der CPLD vom AVR programmiert werden soll, siehe hier:

http://www.mikrocontroller.net/forum/read-4-228557.html#new

Schöne Grüße, Clemens

Autor: Olli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jungs,

interessanter Thread: habe selbst schon mal vor ca. 8 Jahren einen LA
(damals mit einem Altera und 486er Cash-RAMs) gebaut, und das Thema
eines Combo-Gerätes (LA + Scope) läßt mich seitdem nicht mehr los.

Egal, bzgl. des XST: Das (X)ilinx (S)ynthese (T)ool ist erst vor ca. 2
Jahren von Xilinx auf den Markt geworfen worden (sprich fertig
geworden), da waren Spartan1 (XCSxxxx) und 4000er (XC4xxxxxx) schon
abgekündigt. Für Schaltkreise, die nicht mehr verkauft werden, bauen
die Hersteller keine neuen Tools mehr :-[ das ist nur mit Arbeit, Ärger
und Kosten verbunden und bringt eben kein Geld. Spartan2 oder gar
Spartan3 sind die richtigen FPGAs für so ein Projekt!
Um die alten ICs zu programmieren bzw. dafür ein Programier-File zu
generieren muß man damit also auf traditionelle Synthese-Tools
zurückgreifen, wie Synopsys FPGAExpress oder die Mercedes-Variante
FPGA-Compiler2. Vielleicht hat jemand da noch eine Uralt-Version vom
FPGAExpress (abgekündigt - war übrigens der Grund für's XST von Xilinx
und vielleicht auch der Grundstock), die wurde zwischenzeitlich sogar
mal kostenlos 'verschleudert':-) ... ?
Ich hab leider keine.
Sonst muß man sich mit anderen Eingabe-Methoden wie SchematicsEntry
beschäftigen (kein HDL), die selbst eine Netzliste generieren. Sobald
man bei der Netzliste ist, kann man mittels des alten ISE5.1i oder so
alles nutzen und implementieren. Problem ist also nur die HDL
Synthese.
Gruß
Olli
PS: Da die Entscheidung auf VHDL gefallen ist, kann ich da leider nicht
von Nutzen sein, ich progeammier ALLES in Verilog :)!!!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.