Nein. Es gibt einfach wesentlich weniger Leute, die sich mit VHDL und
programmierbarer Logik abplagen wollen... ;-)
Aber bei den DSPs und bei den HF-Fuzzis ist noch weniger los. Vielleicht
haben die auch weniger Probleme... :-/
Lothar Miller schrieb:> Es gibt einfach wesentlich weniger Leute, die sich mit VHDL und> programmierbarer Logik abplagen wollen...
abplagen... ;.) macht doch Spass.
Es muss ja nicht immer unbedingt was sinnvolles dabei herauskommen (s.
LED-Blinker, das geht auch mit einem Schalter manuell ;-). Hauptsache
schöner Zeitvertreib.
Der Lerneffekt ist - zumindest bei mir - sicher irgendwann später wieder
weg. Man hat ja nicht ständig oder berufl. damit zu tun.
HF? Ist was für die OMs.
Lothar Miller schrieb:> Wenn du sowieso grad mit der Tonerzeugung rumspielst: probier doch mal> den legendären SAB0600 Gong ins CPLD reinzupacken
Ich kenn das Teil nicht, nicht das ich wüsste, würde es gern mal hören.
Wenn ich das Datenblatt lese, komme ich erst mal ins Grübeln:
Es ist ein 3-Klang-Gong.
The sound pattern is created by three harmonically tuned frequencies
which are switched in succession to a summing point and decay
individually in amplitude.
The three frequencies - 660 Hz, 550 Hz, and 440 Hz - are obtained by
dividing the output of a 13.2 kHz oscillator. One of these three
frequencies is divided again to obtain the time base for the tone-decay
process. From this time base, 4-bit D/A converters (one for each tone)
generate the decay voltage with which the three tones are successively
activated and, overlapping each other, are attenuated. The basic
frequency is determined by an external RC network (pin R and C).
Mit Sicherheit reicht mein 95144 nicht. Da muss ich erst mal passen.
Hmm, wie würde ich den DingDangDong vom SAB0600 Chip mit CPLD/FPGA
umsetzen ?
Mir fallen auf Anhieb 2 Wege ein, einer speicherintensiv und einer
logikintensiv.
Die Speicherintensive wäre, den Sound digitalisieren, 44.1kHz, ca 6
Sekunden,
das braucht bei 16 bit 512kB Speicher. Die Qualität kann man ja
reduzieren, um Platz zu sparen. Anschliessend legt man die Samplewerte
auf ein einzelnen PWM Ausgang mit der 10 fachen PWM Frequenz und voila,
fertig. Ressourchen für 1 PWM, ein Zähler für die Adressgenerierung und
externes RAM, fertig ist die Laube. Viel Speicher, wenig Logik.
Interessanter wäre es, den Ton im Schaltkreis selbst zu generieren, 1
PWM für die Basisfequenz und 2 PWM für die Resonanzfrequenzen und ein
wenig kB RAM für die Lautstärkenhüllkurve. Das CPLD Board von Karl-Heinz
mit XC95144 plus dem Onboard SRAM sollte ausreichen, den Grundton und
die Lautstärkenhüllkurve auszugeben, vielleicht auch mehr ...
Gruß,
dasrotemopped.
sorry, bin absolut damit überfordert. Ich hab noch viel zu lernen...
Ich verstehe nur soviel, dass ich die 1. Möglichkeit nicht wirklich
aufregend finde ;-)
Karl-Heinz M. schrieb:> Mit Sicherheit reicht mein 95144 nicht.
WAAAAAAS? Mit so einem mach ich nen ganzen Farbgrafik-Controller.
Im Prinzip braucht man ja nur 3 Teiler, die aus einem gemeinsamen Takt
die 3 Ausgangsfrequenzen erzeugen. Anschließend drei umfunktionierte R2R
Netzwerke: Alle n Bits schalten gemeinsam mit dem jeweiligen Takt und
zum Abklingen werden die Ausgänge beginnend vom höchstwertigen Bit
abgeschaltet. Fertig. Das Mischen überlassen wir dann einem OpV und ein
paar Widerständen.
W.S.
Du kennst Dich aus. Respekt. Kanntest Du Dich schon immer aus?
Ich nicht... sorry. Ich geb zu, dass ich noch am Anfang steh und sicher
noch viel lernen muss.
@Karl-Heinz
Zum Einlesen vielleicht mal Hüllkurve als Begriff klären durch das Wiki:
http://de.wikipedia.org/wiki/ADSR
Als praktisches Experiment einen PWM ( Pulsweitenmodulator ) im CPLD
implementieren, mit dem man auch die Lautstärke des Audiosignals regeln
kann:
Beispiel Testton 1kHz :
Grundfrequenz des PWM : 200kHz
Für ein 1kHz Signal den PWM für 0.5 ms einschalten und für 0.5ms
ausschalten.
Für die Lautstärkeregelung das Puls-Pausenverhältnis ändern.
Damit der PWM Ausgang am CPLD an ein Lautsprecher oder Kopfhörer
angeschlossen werden kann, muss noch ein Verstärker angeschlossen
werden.
Ein einfacher NPN Transistor und ein PC Speaker sollten für die ersten
Experimente reichen.
Wenn der erste Testton mit an- und abschwellender Lautstärke
funktioniert
gehts in die nächste Runde.
Die erste Lösung ist bestimmt nicht so spannend, aber vordefinierte
Werte aus Speicherzellen lesen ist etwas, das auch für die 2. Lösung am
Ende gebraucht wird. Die Hüllkurve z.B. kann man so vordefinieren.
Was ist noch unklar ?
Gruß,
dasrotemopped.
Ich habe mir jetzt mal 2 Stunden genommen und interessehalber den
SAB0600 nachgebaut. Hört sich ein wenig "digitaler" an als das Original,
aber einer, ders nicht weiß, wird das nicht unterscheiden können... ;-)
Das Ding passt recht locker in einen 9572XL CPLD rein und braucht dabei
50 der 72 Flipflops. Davon fallen schon einige Register für den 50MHz
Vorteiler an. Wenn man da mit einer entsprechend niedrigeren Frequenz
ankäme, sähe das noch besser aus.
Das verwenden eines Enable-Signals en440 statt des hz440 als Takt kostet
1 zusätzliches Flipflop.
Christoph Kessler (db1uq) schrieb:> Der SAE0800 ist neuer und im Datenblatt etwas ausführlicher erklärt:
Richtig, ich habe da beim Original diese Nichtlinearität in der
Hüllkurve rausgehört. Da muss ich ich wohl den Hüllkurvengenerator noch
ein wenig aufbohren und überarbeiten... ;-)
Und klar: den analogen Mischer hinten raus habe ich auf einem CPLD auch
nicht... :-(
Lothar Miller schrieb:> Ich habe mir jetzt mal 2 Stunden genommen und interessehalber den> SAB0600 nachgebaut.
Bekommst Du mit dem CPLD auch den Standby-Strom von 1µA hin?
;-)
Bronco schrieb:> Bekommst Du mit dem CPLD auch den Standby-Strom von 1µA hin?
Bin dran. Und die Versorgung mit 18V sehe ich mir auch noch mal genauer
an... ;-)
Lothar Miller schrieb:> Bin dran. Und die Versorgung mit 18V sehe ich mir auch noch mal genauer> an... ;-)
Bitte bei der Gelegenheit auch die Form des Chips an den SAB0600
anpassen ;-)
Lothar Miller schrieb:> Bin dran. Und die Versorgung mit 18V sehe ich mir auch noch mal genauer> an... ;-)
Im Ernst: Die Existenz des SABs ist ein echtes Ärgernis für mich!
Wir haben vor 3 Jahren ein neues Haus gebaut und der Elektriker hat
einen solchen SAB-Türgong mit 9V-Blockbatterie eingebaut. Dabei hat sich
der Frechdachs die Leitung zum Sicherungskasten (für einen Klingeltrafo)
gespart.
Als ich dann auf eine "echte" Klingel umgerüstet hab, mußte ich wieder
Batterien nehmen.
Bronco schrieb:> Als ich dann auf eine "echte" Klingel umgerüstet hab, mußte ich wieder> Batterien nehmen.
Dann musst du an die Klingel schreiben: "1x kurz läuten!" ;-)
Das Problem an dem elektromechanischen Gong ist, daß der Magnet solange
bestromt wird, wie der Taster gedrückt wird. Deshalb plane ich, den Gong
mit einem 74HC123 zu pimpen, so daß der Magnet automatisch wieder
losgelassen wird... und das plane ich jetzt schon seit 3 Jahren, weil
bisher die Batterien gehalten haben...
>Die erwarten doch ernsthaft, dass man seine Klingel mit 9V-Batterie >betreibt.
Und das geht ziemlich gut. Meine Eltern haben so ein Teil 1992 eingebaut
bekommen. Es läuft noch heute, macht genug Krach, Batterielebensdauer
ca. 1x 9 V Block alle 2-3Jahre. Besonderes Feature welches in eurem CPLD
evtl. noch fehlt: Geht die Batterie zur Neige fängt der Ton an zu
"jaulen". Man merkt es deutlich und hat genug Zeit für Ersatz zu sorgen.
Zum Eingangspost:
Es gibt tatsächlich nicht so viele hier die sich mit CPLD, FPGA, VHDL
und dem ganzen Kram auskennen. Ich stehe selbst vor dem Problem das ich
ein Projekt im Hinterkopf habe bei dem mir die 32 PWM Kanäle des STM32
nicht reichen werden. Da die Hälfte der Signale redundant ist, bräuchte
ich draussen nur ein CPLD das mir für jede Gruppe die korrekten PWM
Signale ableitet, Totzeiten beachtet und noch ein paar kleine
Schutzfunktionen übernimmt. Eigentlich nichts dramatisches, allein ich
trau mich nicht dran weil ich den Zeitaufwand fürs einarbeiten nicht
abschätzen kann.
Bin ich sicher nicht der Einzige.
viel Erfolg
Hauspapa
S. K. schrieb:> Da die Hälfte der Signale redundant ist, bräuchte ich draussen nur ein> CPLD das mir für jede Gruppe die korrekten PWM Signale ableitetCPLDs sind wegen ihrer wenigen Flipflops mit sowas sehr schnell
überfordert. Da nimmt amn dan ein FPGA mit CPLD-Feeling wie den Lattice
MachXO.
> Eigentlich nichts dramatisches, allein ich trau mich nicht dran weil ich> den Zeitaufwand fürs einarbeiten nicht abschätzen kann.
Wenn du Hardware entwickelst, und ein gutes auge für Schaltungstechnik
hast, dann kannst du die (zugegeben steile) Lernkurve locker schaffen.
Und dann eben nicht gleich alles wollen (Ethernet, PCIe, USB), sondern
sinnvoll wachsen...
Sieh dir mal die Hallo-Welt-LED an:
http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html
Das ist nicht mehr Aufwand, als du mit einem uC auch hättest... ;-)
Lothar Miller schrieb:> Nein. Es gibt einfach wesentlich weniger Leute, die sich mit VHDL und> programmierbarer Logik abplagen wollen... ;-)
Nur die harten kommen in den Garten... oder so ;)
Wer baut schon freiwillig einen Zustandsautomaten, wenn es das schon
fertig im (DIL)Gehäuse gibt. :-b
S. K. schrieb:> Es gibt tatsächlich nicht so viele hier die sich mit CPLD, FPGA, VHDL> und dem ganzen Kram auskennen.
Insgesamt dürfte es weniger Hardware-Leute als Softwerker geben, ganz
naturgemäß. Dann resultieren die meisten Threads im uC-Forum aus falsch
verstandenen aber leicht verfügbaren und meist auch nachvollziehbaren
Informationen. Hier kann man mit ein wenig Erfahrung schon weiterhelfen,
was dann auch viele tun.
Wenn Hardware auf CPLDs oder FPGAs abgebildet wird, ist die
Grundvoraussetzung eine ganz andere. Man muss das System, das abgebildet
werden soll, komplett verstanden haben (ist umfangreicher als eine API
zu studieren) und die Plattform kennen. Der erste Teil ist je nach
Anforderung ungleich schwerer als der zweite Teil, also kommen
automatisch weniger Fragen auf - entweder man scheitert schon an Punkt
eins oder man ist kaum mehr auf Hilfe angewiesen. Einfach weil man
gewohnt ist in der Tiefe zu arbeiten und man nicht wegen jedem Schatten
im "Stollen" gleich wieder ans "Tageslicht" flüchten muss.
>Warum ist hier weniger los als.
Vielleicht liegts auch daran, dass PLD/FPGA (insbes Lowend-Bereich)
letzte Jahre im Preis bei weitem nicht so gefallen sind wie uCs, oder
daran dass es da viel weniger (zu wenige?) Hersteller gibt.
War ja neugierig, was Lothar da in VHDL gezaubert hat.
Verstehe den Code allerdings noch nicht bis ins letzte Detail,
aber habe das ganze mal in mein Cyclone Eval Board reinprogrammiert.
( hat nen Audio Verstärker und Lautsprecher integriert ).
Klingt schon ganz super. Verbraucht in meiner Konfiguration ein bisschen
mehr Ressourcen, aber ist ja genug im FPGA vorhanden.
Das macht mir wieder mehr Lust, wieder mehr Zeit mit FPGAs zu
verbringen.
Muss unbedingt mal wieder mein VHDL Buch zur Hand nehmen !
Gruß,
dasrotemopped.
Ulrich S. schrieb:> Warum der Vergleich auf <24999999 und nicht in der Form?:
Oder in der äquivalenten "Ungleich" Form:
1
if(c/=24999999)then
2
c<=c+1;
3
else
4
c<=0;
5
x<=notx;
6
endif;
Ich habe das mal auf den SAB0600 angewendet, da sind ja einige Vergleich
drin. Fazit ist, beim CPLD schenkt sich das wegen der mächtigen
Produktterme nichts (die könnten noch viel mehr), aber bei einem S3 FPGA
kommt das raus:
"Ungleich":
Number of Slice Flip Flops 48
Number of 4 input LUTs 71
"Gleich":
Number of Slice Flip Flops 48
Number of 4 input LUTs 70
"Kleiner":
Number of Slice Flip Flops 48
Number of 4 input LUTs 68
Also eine sichtbare Ersparnis bei der Logik. Das kommt daher, dass sich
ein größer-kleiner Vergleich durchschnittlich besser optimieren lässt.
Probiers mal auf dem Papier mit so einem Extrembeispiel:
if cnt/="0x800" then
oder
if cnt="0x800" then
oder
if cnt<"0x800" then
Da wird sofort klar, dass die dritte Variante garantiert die einfachste
ist, weil nur auf das höchstwertige Bit geschaut werden muss.
Und als "Abfallprodukt" habe ich mehr Sicherheit, denn wenn mal ein Bit
umkippt, fängt sich der Zähler schneller wieder ein. Bei der
gleich-ungleich Methode muss er zum Zurücksetzen ja genau passen...
Markus Horbach schrieb:> Das macht mir wieder mehr Lust, wieder mehr Zeit mit FPGAs zu> verbringen.
Das ist doch schon mal was... ;-)
Lothar Miller schrieb:> Also eine sichtbare Ersparnis bei der Logik. Das kommt daher, dass sich> ein größer-kleiner Vergleich durchschnittlich besser optimieren lässt.
Sehr interessant!
Ich war bisher immer geneigt, auf "kleiner" zu vergleichen, weil das
eben die Bitkippersicherheit hat, dachte aber, daß das bestimmt mehr
Logik braucht als "gleich". So kann man sich irren.
Markus Horbach schrieb:> War ja neugierig, was Lothar da in VHDL gezaubert hat.
Ok, ist ja verständlich. Die Klingel war aber nicht das eröffnende Thema
dieses Threads. Ich halte den Übergang zur Diskussion des (echt
unwichtigen) Geräuschbausteins nicht für besonders höflich, aber das
kennt man ja aus dem uC-Forum. Hier wird es bald nicht anders sein - war
das etwas die Intention des Threads?
@Edson
>war das etwas die Intention des Threads?
Nicht die Intention des Threads am Anfang, aber der TO Karl-Heinz hat
mich auf das Gong Thema aufmerksam gemacht und ob ich auch etwas dazu
sagen kann. Bin seinem Wunsch nachgekommen. Ist das im Sinne des Forums
?
Gruß,
dasrotemopped.
Markus Horbach schrieb:> Ist das im Sinne des Forums ?
Mehr oder weniger. Eher weniger denn ein Thread namens "SAB0600 im CPLD"
würde leichter gefunden und sagt bereits im Betreff aus um was es geht.
Ich wollte dir keinen Vorwurf machen, es fällt einfach immer mehr auf
dass Themen vermischt werden anstatt neue zu eröffnen.
Edson schrieb:> Eher weniger denn ein Thread namens "SAB0600 im CPLD"> würde leichter gefunden
Es ist kein Problem, mit der Forumssuche den SAB0600 hier zu finden:
https://www.mikrocontroller.net/search?query=sab0600&forums[]=9
Und auch mit Google klappt das tedellos:
https://www.google.de/search?q=sab0600+vhdl
Aber zur besseren Übersicht passe ich den Threadtitel mal an...
Edson schrieb:> Ok, ist ja verständlich. Die Klingel war aber nicht das eröffnende Thema> dieses Threads. Ich halte den Übergang zur Diskussion des (echt> unwichtigen) Geräuschbausteins nicht für besonders höflich
Wenn dieser "echt unwichtige" Geräuschgenerator dazu beiträgt, dass hier
mehr los ist, dann finde ich das toll.
> Ich halte den Übergang zur Diskussion des (echt unwichtigen)> Geräuschbausteins nicht für besonders höflich
Zur ursprünglichen Frage war eigentlich alles gesagt.
> nicht für besonders höflich
Es ist einfach passiert. Wer konnte schon vermuten, dass das so
ausartet...
Lothar Miller schrieb:> Wenn dieser "echt unwichtige" Geräuschgenerator dazu beiträgt, dass hier> mehr los ist, dann finde ich das toll.
Gerade im uC+Elektronik Forum sieht man doch ganz gut, dass "viel Los"
nicht unbedingt die Qualität hebt. Das "echt unwichtig" hätte ich mir
sparen können, das sehe ich ein - wollte niemandem zu nahe treten.
>> nicht für besonders höflich> Es ist einfach passiert. Wer konnte schon vermuten, dass das so> ausartet...
Heh, gleich drei mal zitiert, habe ich da einen Nerv getroffen? Mir ist
übrigens auch aufgefallen dass meine letzten Beiträge den höchsten
OT-Anteil in diesem Thread haben, wofür ich mich entschuldigen möchte.
Ausgeartet ist es ja nicht, gerade deshalb hatte ich das Gefühl dass
eine kritische Anmerkung dann auch gehört wird.
Edson schrieb:> Ok, ist ja verständlich. Die Klingel war aber nicht das eröffnende Thema> dieses Threads.
Vom Sinn her schon. Wie ich ziemlich erfreut sehe, hat es Ansporn
gegeben, auch das wollte ich provokativ erreichen. Mir ist daher jedes
neue Thema dazu recht; es passt immer zum Thread! Und sei es nur, um zu
zeigen, auch hier ist was los...
Leider hab ich selbst momentan nur wenig Zeit, ändert sich aber wieder.
Ich bin auch schon sehr gespannt und will selbst mal den Gong hören.
Suche: Gibte es hier im Forum doch und man findet nicht nur in
Überschriften das Gesuchte. Ausserdem hat Google auch ziemlich schnell
die Foren hier neu indiziert. Dauert ca. 1 Tag, wenn ichs richtig
erkannt hab, so dass es auch damit gut klappt.
Lothar Miller schrieb:> Das Ding passt recht locker in einen 9572XL CPLD rein und braucht dabei> 50 der 72 Flipflops.
Habs gerade ausprobiert, kein Problem, läuft einwandfrei auf dem
CPLD-Evalboard von embedded projects mit einem 9572. Erst recht auf dem
Pollin-CPLD-Board mit einem 95144XL.
Bin begeistert! :-)
bei 50MHz hat
Lothar Miller schrieb:> braucht dabei> 50 der 72 Flipflops. Davon fallen schon einige Register für den 50MHz> Vorteiler an. Wenn man da mit einer entsprechend niedrigeren Frequenz> ankäme, sähe das noch besser aus.
Bei mir sind es 60 von 72 Registern des 9572 bei 50Mc. Erst bei 1Mc sind
es 50.
Karl-Heinz M. schrieb:> Bei mir sind es 60 von 72 Registern des 9572 bei 50Mc. Erst bei 1Mc sind> es 50.
Ich ich hatte den XL eingestellt. Evtl. macht das einen Unterschied...
Markus Horbach schrieb:> Verstehe den Code allerdings noch nicht bis ins letzte Detail,
@Lothar:
Ich hab den Code mal versucht zu verstehen / nachzuvollziehen und
Kommentare eingefügt. Ich würd mich drüber freuen, wenn Du mal
reinschauen könntest und Dir den Rotstift schnappst ;-) und meine
Kommentare auf Richtigkeit checkst. Auch habe ich leichte Änderungen
vorgenommen anhand des SAE800 Datenblatts (z. B. ADSR-Start des nächsten
Tons ab 11, nicht ab 10).
Gesucht habe ich auch nach einer Tonunterdrückung nach dem Einschalten,
doch bin ich nicht fündig geworden. Das Teil legt bei mir nach dem
Einschalten gleich undefiniert los, beruhigt sich aber nach ein, zwei
Sekunden und ist dann einsatzbereit.
Ich musste auch den Starttaster ändern, da meiner low-active ist.
Karl-Heinz M. schrieb:> Gesucht habe ich auch nach einer Tonunterdrückung nach dem Einschalten,> doch bin ich nicht fündig geworden.
Probiers doch mal an dem Initialisierungseck da:
1
-- Tondauer
2
signaladsr660:integerrange0to15:=15;
3
signaladsr550:integerrange0to15:=15;
4
signaladsr440:integerrange0to15:=15;
Als Tipp:
Was bedeutet "aus" aund was "voll laut"?
Karl-Heinz M. schrieb:> Ich würd mich drüber freuen, wenn Du mal> reinschauen könntest und Dir den Rotstift schnappst ;-)> und meine Kommentare auf Richtigkeit checkst.
Passt schon, du hast hauptsächtlich erst mal die Zahlenwerte
ausgerechnet. Ich hätte aber wegen des Wiedererkennungswerts zum
Datenblatt z.B. geschrieben:
1
signalcnt660:integerrange0tom660:=0;-- 0 to 9 --> f1 = f0 / 20
> Auch habe ich leichte Änderungen vorgenommen anhand des SAE800> Datenblatts (z. B. ADSR-Start des nächsten Tons ab 11, nicht ab 10).
Jeder wie er es mag... ;-)
Bei einer Kompatibilität zum SAE800 müsstest du den ADSR aber auch bei
einer unterschiedlichen Amplitude starten und unterschiedlich schnell
abklingen lassen. Dazu wäre eine Entkopplung von der Zeit oder eine
Tabelle sinnvoll...
BTW: das hier ist "doppelt gemoppelt":
1
waituntilrising_edge(hz440);
2
-- wenn 440Hz
3
ifen440='1'then
Denn en440 ist genau dann für 1 Takt aktiv, wenn eine Flanke vom hz440
auftritt:
1
cnt440<=0;
2
hz440<=nothz440;
3
en440<='1';-- 440Hz sind da
Ich hatte das en440 nur zum Test zusammen mit dem rising_edge(clk) drin.
Für dich sollte also das wait until rising_edge(hz440) ausreichen. Das
en440 kannst du kicken.
Und AUA: jetzt habe ich auch den Fehler gesehen, der bei mir auf dem
FPGA mit dem en400 aufgetreten ist. Da ist irgendwie alles doppelt so
schnell als erwartet in der Hüllkurvenecke, weil ja das en440 bei jeder
Flanke des hz440 und damit eigentlich mit 880 Hz kommt... :-/
Alejandro P. schrieb:> PALCE
Ach neee... :-D
Lothar Miller schrieb:> Alejandro P. schrieb:>> PALCE> Ach neee... :-D
Du meinst, ein normales PAL16R4 reicht aus? Ein großes PALCE wäre
Verschwendung? Im PALCE könnte man doch noch einen Taschenrechner mit
Uhr unterbringen.
Andreas Schweigstill schrieb:> Im PALCE könnte man doch noch einen Taschenrechner mit Uhr> unterbringen.
Logisch. Mit automatischer Schaltjahrberechnung und Stoppuhr. Und ich
überlege noch, was man mit den übrigen FFs sinnvolles tun könnte... ;-)
Lothar Miller schrieb:> Logisch. Mit automatischer Schaltjahrberechnung und Stoppuhr. Und ich> überlege noch, was man mit den übrigen FFs sinnvolles tun könnte... ;-)
Cool! Ich bin schon gespannt auf Deine Lösung. :-)
Frank Petelka schrieb:> Macht das Sinn, ein PAL in VHDL zu programmieren?
Also gut: war nur ein Scherz... ;-)
> Macht das Sinn, ein PAL in VHDL zu programmieren?
Nein, denn es gibt gar keinen Synthesizer dafür. Oder?
Lothar Miller schrieb:> Frank Petelka schrieb:>> Macht das Sinn, ein PAL in VHDL zu programmieren?> Also gut: war nur ein Scherz... ;-)>>> Macht das Sinn, ein PAL in VHDL zu programmieren?> Nein, denn es gibt gar keinen Synthesizer dafür. Oder?
GALs eventuell mit Synplify, müsste man mit ispLever Classic probieren.
Lothar Miller schrieb:>> Macht das Sinn, ein PAL in VHDL zu programmieren?> Nein, denn es gibt gar keinen Synthesizer dafür. Oder?
Mit einem kleinen TCL-/Perl-/Python-Skript lässt sich ein
Virtex-Bitstream ganz einfach in eine JEDEC-Datei für die
PAL-Programmierung konvertieren. Zumindest sind die Erfolgsaussichten
ähnlich hoch wie bei der PAL-Implementierung des Türgongs mit
Taschenrechner und Uhr.
Lothar Miller schrieb:> Andreas Schweigstill schrieb:>> konvertieren> Müsste das nicht eher "komprimieren" heißen?
Betrachtet man das im Zusammenhang mit dem Begriff
Andreas Schweigstill schrieb:> Erfolgsaussichten,
ist es ziemlich egal, ob man komprimiert, konvertiert, korrigiert,
kommuniziert, kommutiert oder komsonstwasiert.