Guten Abend zusammen,
für ein aktuelles Projekt von mir versuche ich einen exklusiven Zugriff
auf zwei RAM-Blöcken aufzubauen.
Zu den technischen Hintergundinfos. Ich benutze einen Cyclone IV FPGA.
In diesem habe ich zwei RAM-Blöcke mit jeweils 1024 Speicherzellen
aufgebaut. In diesen Speicherzellen lade ich Stromwerte, die ich nach
einem festen Zeitabstand Zelle für Zelle wieder auslese. Nun will ich
aber, dass im laufenden Betrieb neue Daten in den RAM-Block geschrieben
werden, der gerade nicht ausgelesen wird. Zum besseren Verständnis: Die
RAM-Blöcke sind mit RAM1 und RAM2 benannt. RAM1 wird mit den Daten voll
geschrieben. Ist Beschreibung abgeschlossen, beginnt das Auslesen von
RAM1. Nun wird von außen ein neuer Datensatz gegeben. Jetzt soll
automatisch erkannt werden, dass aus RAM1 ausgelesen wird, woraufhin die
Daten in RAM2 geschrieben werden. Nach dem Beschreiben von RAM2 (und
nachdem RAM1 vollständig ausgelesen wurde) soll das Auslesen zu RAM2
switchen.
Wenn wieder ein neuer Datensatz vorliegt, soll erneut erkannt werden,
dass aus RAM2 aktuell ausgelesen wird und das Einschreiben in RAM1
erfolgen soll. Und so soll sich das ganze Spiel immer und immer wieder
abwickeln.
Ich habe mir überlegt sowohl das Beschreiben, also auch das Auslesen als
zwei Prozesse zu gestalten. Die Zugriffe auf die beiden RAM-Blöcke soll
dabei über Semaphore geregelt werden (bzw. Sperrvariable/signale nach
dem Semaphor-Prinzip). Für jeden Block soll es jeweils zwei Semaphore
geben, eine zu Anzeige, ob auf dem RAM gerade zugegriffen wird und die
Andere um den Zugriff zu bestätigen. Nachfolgend ein kleiner
Beispielcode wie ich mir vom Prinzip her die Verwendung der Semaphore
gedacht habe.
Bei dem Beispielcode habe ich aber das Problem, dass ein Signal von zwei
Treiber getrieben wird und die ganze Geschichte verkompliziert.
Nun weiß ich aber nicht, wie ich mein Problem sonst lösen soll und
hoffe, dass ihr mir hier weiter helfen könnt. Wie kriege ich den
abwechselnden, exklusiven Zugriff aufgebaut?
Schon einmal ein Danke im Vorraus.
Robert M. schrieb:> Zum besseren Verständnis:...
Wenn ich mir die Beschreibung so durchlese komme ich zum Schluss, dass
du eigentlich einen simplen Fifo brauchst. Warum hampelst du da mit 2
RAMs herum?
Da denkt einer wohl noch viel zuviel in SW...
a) Der Process hat einen Takt in der Sensitivitylist, der wird intern
aber nie benutzt.
b) Wenn beide Prozesse denselben Takt haben, kann es auch einer werden.
Das löst zwar praktischerweise das multiple driver Problem, aber
trotzdem noch nicht den ganzen Sempahor/Exklusiv/Lock-Mist-Knoten in
deinem Kopf ;)
Du hast/brauchst ein Signal, das entscheidet, aus welchem RAM gelesen
werden soll. Damit ist auch klar, in welches geschrieben werden soll
(nämlich das andere). Wobei mir aber überhaupt nicht klar ist, woher man
bei deinem aktuellen Konzept wissen soll, in welchem RAM die Daten
eigentlich gelandet sind. Das wird ja offenbar intern ausgewürfelt,
wobei das Wissen aber eigentlich nur aussen vorhanden ist ("RAMx voll").
Dann soll das gefälligst auch von aussen rein und wählt intern nur aus,
wohin die Adressen und rd/wr-en Signale geroutet werden. Da braucht es
kein Semaphor.
Generell hast du noch das Problem, dass am Ausgang des RAMs keiner
weiss, wann da was sinnvolles anliegt. Da liegen ja ein paar Takte von
rden bis data-valid. D.h. die Weiterverarbeitung müsste man dann passend
verzögert starten. Handshake-Signale sind da praktisch, da braucht es
aber etwas mehr Wissen, wie der Datenfluss sein soll.
Kann man das ganze nicht auch so machen: Du legst die beiden Ramblöcke
zu einem doppelt so langen zusammen. Der Schreiber schreibt immer
umlaufend.
Wenn der Schreiber in der ersten Hälfte ist (ist am obersten Adressbit
erkennbar), darf der Leser in der zweiten Hälfte lesen und umgekehrt.
Wenn der Zugriff wahlfrei sein muss/soll (wenn man mal wie bei
Videocoding Daten umsortiert): Stichwort Pingpong-Buffer mit zwei
identischen RAM-Blöcken und etwas Muxerei. Der "Filler" schreibt immer
gerade den Block voll, den der "Drainer" gerade nicht ausliest. Bloss
nicht so kompliziert machen.
Strubi schrieb:> Der "Filler" schreibt immer gerade den Block voll, den der "Drainer"> gerade nicht ausliest.
Die "Semaphore" besteht dann aus einem einzigen Bit, das in geeigneter
Weise eigentlich nur das höchstwertige Adressbit darstellt. Und dann
braucht es nur noch einen, der dieses Bit zum geeigneten Zeitpunkt
umschaltet.
Robert M. schrieb:> Ich habe mir überlegt sowohl das Beschreiben, also auch das Auslesen> als zwei Prozesse zu gestalten.
Wozu?
> Die Zugriffe auf die beiden RAM-Blöcke soll dabei über Semaphore(n)> geregelt werden
Wozu?
Du weißt, wozu Semaphoren verwendet werden? Nämlich, um Prozesse, die
nicht hart synchron sind, weil sie in einer virtuellen Umgebung mit
unbekanntem timing ablaufen, zu synchronisieren und sicherzustellen,
dass eindeutig beobachtbare Zustände hinsichtlich der Gleichzeitigkeit
erzielt werden?
Also etwas, was in einem hart am Takt hängenden FPGA schon voll
automatisch realisiert ist?
> Bei dem Beispielcode habe ich aber das Problem, dass ein Signal von zwei> Treiber getrieben wird und die ganze Geschichte verkompliziert.
Da braucht es wohl ein Semaphor! :D
Im Ernst, Du solltest mal das Konzept checken. Normalerweise muss man
nicht mehrere Prozesse nehmen, um ein RAM zu timen und niemals sollte
ein Signal aus zwei Prozessen heraus getrieben werden.
Die Lösung wäre eine einzige FSM. Wenn mehrere Module mit dynamischem
Ablauf vorkommen, reicht ein einfaches flag mit Prio eines Prozesses,
damit im nächsten Takt kein nichtinterpretierbarer Zustand vorkommen
kann.
Du setzt einfach mit dem P1 das Sem auf "P1" und mit dem anderen auf
"P2" ansonsten ist es "Null". Dann müssen im nächsten Takt beide FSM
schauen, ob sie arbeiten dürfen.
Aber wie gesagt: Im FPGA sollte man schauen, dass man einen
kontinuierlichen flow hinbekommt und Zugriffe mit einer FSM steuert, die
entscheidet, welcher Datenpfad aufs RAM geht und welcher nicht.
Eigentlich ist das deutlich einfacher, als es in Software zu machen. Die
Verrenkungen mit Semaphoren, priorisierten Lese- und Schreibeprozessen,
Lösung von Philosophenproblemen gibt es ja nur wegen der
Multi-Thread-Thematik und dem Umstand, dass in einem richtigen
Multitaskingsystem keine Annahmen über die Zeiten gemacht werden (dürfen
und können).
Lothar M. schrieb:> Wenn ich mir die Beschreibung so durchlese komme ich zum Schluss, dass> du eigentlich einen simplen Fifo brauchst. Warum hampelst du da mit 2> RAMs herum?Martin O. schrieb:> Kann man das ganze nicht auch so machen: Du legst die beiden> Ramblöcke> zu einem doppelt so langen zusammen. Der Schreiber schreibt immer> umlaufend.> Wenn der Schreiber in der ersten Hälfte ist (ist am obersten Adressbit> erkennbar), darf der Leser in der zweiten Hälfte lesen und umgekehrt.
In meinem Projekt geht es darum eine Prozessstromquelle zu bauen. Diese
soll in der Lage sein, ihr vorgegebene Stromverläufe (bspw.
Dreiecksverlauf, Sinusverlauf etc.) nachzubilden. Die Stromverläufe
werden in einem MatLab-Modell erzeugt und besitzen dabei 1024
Stützpunkte. Diese Stützpunkte werden im RAM abgespeichert und nach
einem festen Zeitabstand werden dann Zelle für Zelle ausgegeben. Eine
Nachgestellte Regelung samt Leistungselektronik setzt den Verlauf dann
um. Für diese Betriebsweise reicht mir ein RAM-Block vollkommend, nur
jedes mal wenn ich einen neuen Stromverlauf draufgeben will, muss ich
mein System erst wieder reseten.
Was ich aber will ist einen neuen Stromverlauf laden zu können ohne das
der Betrieb der Prozessstromquelle deswegen unterbrochen werden muss.
Dazu wollte ich den zweiten RAM als Hilfs-RAM nutzen. Während aus dem
Ersten noch gelesen wird, kann das Zweite beschrieben werden. Ist das
Zweite beschrieben und das Erste komplett ausgelesen, dann soll aus dem
Zweiten gelesen werden, solange bis eine neue Vorgabe eintrifft.
Was ich will ist, dass der Leser ununterbrochen ausliest. In wie weit
ist es mit dem FIFO gewährleistet? So wie ich es von Martin verstanden
habe muss der Leser solange pausieren bis der Schreiber fertig ist.
Schreiber und Leser wechseln sich also ab, bei mir sollen sie aber
parallel arbeiten.
Georg A. schrieb:> Da denkt einer wohl noch viel zuviel in SW...Jürgen S. schrieb:> Im Ernst, Du solltest mal das Konzept checken. Normalerweise muss man> nicht mehrere Prozesse nehmen, um ein RAM zu timen und niemals sollte> ein Signal aus zwei Prozessen heraus getrieben werden.>> Die Lösung wäre eine einzige FSM. Wenn mehrere Module mit dynamischem> Ablauf vorkommen, reicht ein einfaches flag mit Prio eines Prozesses,> damit im nächsten Takt kein nichtinterpretierbarer Zustand vorkommen> kann.> kontinuierlichen flow hinbekommt und Zugriffe mit einer FSM steuert, die> entscheidet, welcher Datenpfad aufs RAM geht und welcher nicht.
Mein Problem liegt wirklich darin, dass ich noch zu starkt in SW
denke.^^
Den Ansatz über eine FSM werde ich mal weiter verfolgen.
Robert M. schrieb:> Was ich will ist, dass der Leser ununterbrochen ausliest. In wie weit> ist es mit dem FIFO gewährleistet? So wie ich es von Martin verstanden> habe muss der Leser solange pausieren bis der Schreiber fertig ist.> Schreiber und Leser wechseln sich also ab, bei mir sollen sie aber> parallel arbeiten.
Diese "Schreiber" und Leser" Ansicht ist viel zu abstrakt.
Du musst in (DP)RAMs mit Steuer-, Adress- und Datenleitungen denken.
Robert M. schrieb:> Die Stromverläufe werden in einem MatLab-Modell erzeugt und besitzen> dabei 1024 Stützpunkte. Diese Stützpunkte werden im RAM abgespeichert> und nach einem festen Zeitabstand werden dann Zelle für Zelle> ausgegeben.
Zyklisch, bis auf das andere RAM umgeschaltet wird?
Dann brauchst du am einfachsten 1 DPRAM mit 2048 Speicherzellen. Du
liest/gibst dann z.B. kontinuierlich die "untere" Hälfte aus. Neue Daten
werden in die "obere" Hälfte geschrieben.
Wenn dann irgendwann die "obere" Hälfte fertig beschrieben ist, dann
schaltet (sinnvollerweise zum Nulldurchgang) der Lesepointer auf den
"oberen" Bereich um und gibt fürderhin diese Daten aus. Und jetzt darf
der "untere" RAM-Bereich beschrieben werden.
Letztlich muss jetzt nur noch irgendwer festlegen, wann von wo gelesen
werden soll. Das ist schlussendlich der eigentliche Knackpunkt. Denn das
DPRAM an sich könnte gleichzeitig gelesen und beschrieben werden...
Robert M. schrieb:> Was ich will ist, dass der Leser ununterbrochen ausliest. In wie weit> ist es mit dem FIFO gewährleistet? So wie ich es von Martin verstanden> habe muss der Leser solange pausieren bis der Schreiber fertig ist.> Schreiber und Leser wechseln sich also ab, bei mir sollen sie aber> parallel arbeiten.
Eben gerade nicht, sie arbeiten synchron. Das "pingpong"-Signal für die
zwei Buffer ist identisch mit Lothars Adress-MSB. Der Schreiber/Leser
schaltet das aber jeweils nicht, sondern deine übergeordnete Logik, die
bestimmt, wann du mit dem Füllen des Puffers fertig bist.
Du musst nur dafür sorgen, dass Schreiber/Leser gleichzeitig loslaufen
und beachten, das der Leser erst einen Takt später (in Bezug auf das
Pingpong-Signal) ein gültiges Datum hat.
So wie ich verstehe, brauchst du ein Double-Buffer-Konzept, da du:
- Hilfs-RAM (Shadow) ev. von einer CPU beschreibst
- Arbeits-RAM zyklisch ausliest
- Glitchfrei die Konfiguration umschalten willst
In dem Fall würde dann der Leser signalisieren, wann genau das
Pingpong-Signal getoggelt werden darf, und der Schreiber setzt
FILL_DONE, wenn alle Daten ins Shadow geschrieben wurden. Das FILL_DONE
muss nur bei der Uebernahme (Pingpong-Toggle) wieder gelöscht werden.
Wenn Ich mir das so durchlese, dann verstehe Ich, warum heutige
FPGA-Entwickler so enorme resourcen benötigen. Ich glaube, Xilinx baut
auch genau deshalb den nativen Suppoort vieler Cores zurück, um die neue
FPGA-Entwickler-Riege alle auf Bussysteme und Softwaredenken zu eichen,
damit sie richtig fette Teile verkaufen können.
Also das ist aber auch nicht einfach in Hardware zu denken. Wenn man
schon als Kind TTL Gräber verlötet hat dann mag das einfach sein, kommt
man aber mit Softwarevorbelastung, dann ist das Leuland. Hat bei mir
auch lange gedauert.
Da hilft am Ende nur klein anfangen. Lauflicht usw.
Das Problem ist, dass die Meisten gar keine Vorstellung davon haben, was
ein FPGA ist und wie digitale Schaltungen funktionieren und wie die
Software den VHDL-Code verwurstet, um rauszubekommen, wie die
FPGA-Zellen verschaltet werden müssen. DAMIT muss man anfangen und nicht
mit VHDL und Prozessen. Wir arbeiten z.B. auch im Bereich Schulung von
Entwicklern und unterstützen Kunden und Ich sehe da zwei Typen:
1) Der Jüngling, meist aus der Programmiererecke kommend, unter 40 - oft
noch unter 30 , der nur in Prozessen denkt und überhaupt nicht
durchblickt, was er da beschreibt und somit auch noch nach Monaten immer
noch nicht richtig weiß, was er da zusammenbaut. Die Sorte brutzelt
schnell Lösungen zusammen, die aber im Detail ein Grauß sind und nicht
selten in einer kompletten Sackgasse münden. Diese Leute brauchen auch
noch nach Monaten Schulung! Und: Sie kommen immer wieder. Firmen wie
PLC2 leben prächtig von denen! Oft sind es Anfänger, die im
Schnellstudium mal was mit VHDL gemacht haben und ihr Wissen von
Professoren haben, die selber nicht richtig Digital können.
2) Elektronikdesigner, die nicht oder nur wenig Software können und sich
jetzt mit FPGAs befassen wollen oder müssen. Meistens sind das Typen um
die 45-50 aufwärts, die immer nur Platinen gemacht haben und
Logiggattergräber erzeugt haben. Die bringen sich auch selber mal
schnell die Mikrocontrollerprogrammierung bei, wenn es sein muss und
sind bei den FPGAs gut aufgehoben!
Dem Typ 1 kannst Du nämlich erklären, was Du willst, es bleibt an der
Oberfläche. Er stöpselt zwar recht rasch SOC-Systeme zusammen, scheitert
aber immer wieder an einfachen eigentlich klaren Dingen. Er findet
umständliche bis unmögliche Lösungen und hat immer die Tendenz, einen
kleinen Computer zu bauen, der so funktioniert, wie eine CPU. Von der
Sorte werden dann mehrere reingeworfen, die sich dann wie eine
Multi-Core-System verhalten und er ist stolz, dass er es nach Wochen der
Firckelei geschafft hat, dass sie sich unterhalten. AXI, Wishbone,
Atlantic und Avalon leisten da Vorschub. MATHWORKS erledigt den Rest.
Die zeichen diese Wege vor, so als gäbe es nichts anderes.
Dem Typ 2 hingegen musst Du nur klarmachen, was er durch das VHDL
jeweils kriegt und ihm ein paar Beispiele hinschreiben. Diese Leute
haben nur das Problem, was zu formulieren. Was sie jedoch brauchen, das
wissen sie ganz genau! Schaltungen, die ihnen die Funktion liefern,
schütteln die aus dem Ärmel. Irgendwann, meistens nach 10-20h kommt
dann plötzlich ein Punkt, wo es Bing macht und er alles von alleine
kann. Ab dann baut der die kompliziertesten Sachen zurecht, kriegt sie
auch zum Laufen und das einzig zu Bemängelnde besteht darin, dass er
viele Dinge in VHDL nicht nutzt und es zu umständlich formuliert. Aber
er ist jederzeit in der Lage, eine Schaltung zu bauen, die er braucht
und sehr sehr schnell kommt dann auch der Punkt, wo der Typ Dir wegläuft
und er Dich nicht mehr braucht, sondern im Gegenteil Dir die neuesten
schlaue Schaltung erklärt, die er gebaut hat. Da knallt es dann Tag für
Tag und er hat ein "Aha-Erlebnis" nach dem anderen.
Diese Leute sind einfach geerdet und haben von klein auf Digitales
gemacht und brauchen nur jemanden, der sie richtig aufs Pferd setzt.
Typ 1, kann weder reiten noch kennt er Pferde, sondern bewegt sich nur
virtuell an der Playstation. Der reale Sachbezug zur Hardware wurde bei
ihm übersprungen und das alles müsste er sich nun anhand der vielen
virtuellen Konstruktionen und Prozesse zusammenreimen und was da
rauskommt, ist bei jedem eine andere Welt. Diese Leute können eigentlich
nur sinnvoll eingesetzt werden, wenn sie einen Typ 2 um sich haben, die
ihnen was bauen, was sie dann programmieren können. Sonst ist grosser
Mist angesagt!
>Semaphore in VHDL
Die Fragestellung exisitiert bei einem Hardwareentwickler im Grunde
überhaupt nicht. Denn wenn er wirklich softwareähnliche Prozesse hätte,
die wirklich später im FPGA auch als Prozesse laufen, dann wären diese
auch so zu gestalten, wie man sie in Software realisiert. VHDL braucht
da nichts Spezielles. Sondern es wäre einfach irgendwo eine
Speicherzelle wie eben in Software auch. Vermutlich wissen aber viele
Softwareheinis nicht einmal, wie ein Semaphor durch das OS gemanaged
wird, dass es eins sein kann und durch die SW benutzt werden kann.
Das Schlimmste, was es in dem Zusammenhang gibt, sind Mathematiker und
Physiker, die sich Programmieren selber beigebracht haben und die
Grundlagen der Interprozesskommunkation nicht kennen sich jetzt noch
Elektronik selber beibringen und dann FPGAs machen wollen. Das diese
Leute an obskuren Ideen und Methoden erdenken und was sie an Lösungen
skizieren, spottet jeder Beschreibung. Da werden Analogeffekte von FPGAs
genutzt und kompensiert, die es bei richtiger elektrischer Beschaltung
und funktioneller Nutzung (entkopplung der jitternden Schaltung) gar
nicht gäbe, es werden Prozesse und pipelines aufgesetzt, Daten dynamisch
und pulsierend durchgeschaltet, weil vollkommen asynchrone Module in
FPGAs erzeugt werden, wo es unnötig war und dort, wo es wiederum
sinnvoll und einfach gewesen wäre, aufwändig verhindert wird. Da wird
einsychronisiert und überabgetastet, was das Zeug hält, wo eine einfache
Flankenbetrachtung gereicht hätte und es werden FSMs und Filter mit
Taktfrequenzen gefahren, die extreme Auflösungen und Speicherzellen
erfordern, wo es ein trickreiches enable getan hätte.
Und täglich grüsst das Murmeltier...
War wohl spät, und es ist immer schön, wenn man seinen in Ueberlänge
kundgetanen Weltschmerz hinter der Anonymität verstecken kann, ne.
Nur der Diskussion vermutlich nicht zielführend (TL;DR). Für mich sind
die Zeiten, wo noch in HW/SW 'gedacht' wird, längstens vorbei.
Strubi schrieb:> Für mich sind die Zeiten, wo noch in HW/SW 'gedacht' wird, längstens> vorbei.
Solange alles "läuft" und "schnell genug" ist, passt diese Aussage.
Interessant wird es aber bei Problemen, die man nicht mit Google lösen
kann. Dann muss man wissen, worauf letztlich ein Code "läuft". Nur so
kann man einschätzen, woher die Probleme kommen, die er macht. Mir sind
schon Softies untergekommen, die nicht mal ihre Toolchain kannten. Die
nicht wussten, dass man aus dem C-File Assembler machen und darin
nachsehen kann, was und wie lange der Prozessor letztlich an einer
einzigen Zeile Code zu arbeiten hat. In deren Vorstellung hat jede Zeile
ihres Codes 1/fcpu (mit fcpu=1..5GHz) lang gedauert...
> wenn man seinen in Ueberlänge kundgetanen Weltschmerz hinter der> Anonymität verstecken kann, ne.Falsch ist das dort dargestellte nicht. Bestenfalls in akzeptablen
Rahmen satirisch überzogen...
Und offenbar hat Robert Malle diesen täglichen Gruß des Murmeltiers noch
nicht gehört.
Hi Lothar,
Lothar M. schrieb:> Strubi schrieb:>> Für mich sind die Zeiten, wo noch in HW/SW 'gedacht' wird, längstens>> vorbei.> Solange alles "läuft" und "schnel genug" ist, passt diese Aussage.>
Naja, robust muss es auch sein. Jeder darf ja seinen Anspruch haben.
Wenn ich Roberts Ansatz richtig verstanden habe, steckt da durchaus ein
pragmatischer Gedanke dahinter, nur wurde er für die
Hardliner-HDL-Fraktion nicht günstig formuliert. Und ok, zu umständlich
angesetzt, aber trivial ist das Problem auch nicht.
> Interessant wir es aber bei Problemen, die man nicht mit Google lösen> kann.> Dann muss man wissen, worauf letztlich ein Code "läuft". Nur so kann> man einschätzen, woher die Probleme kommen, die er macht.> Mir sind schon Softies untergekommen, die nicht mal ihre Toolchain> kannten. Die nicht wussten, dass man aus dem C-File Assembler machen und> darin nachsehen kann, was und wie lange der Prozessor letztlich an einer> einzigen Zeile Code zu arbeiten hat. In deren Vorstellung hat jede Zeile> ihres Codes 1/fcpu (mit fcpu=1..5GHz) lang gedauert...>
Die kommen mir heutzutage mindestens so oft unter wie die
HDL-Einserkandidaten, die nicht wissen, was eine Clamping-Diode ist.
Ueber die Bildungslandschaft können wir uns aber auch anderswo
unterhalten, dass da generell der Wurm drin ist, bestreite ich ja nicht.
>> wenn man seinen in Ueberlänge kundgetanen Weltschmerz hinter der>> Anonymität verstecken kann, ne.> Falsch ist das dort dargestellte nicht. Bestenfalls in akzeptablen> Rahmen satirisch überzogen...> Und offenbar hat Robert Malle diesen täglichen Gruß des Murmeltiers noch> nicht gehört.
Kann sein, vielleicht auch nicht. Ist mir eigentlich egal, nur muss der
Murmeltiergruss nicht immer in der redundanten Form eines obsoleten
Grabenkampfs ausgetragen werden. Als Satire war's nicht erkennbar.
Ich verstehe nur nicht, wie manche hier den Hausaufgabenmachern unter
die Arme greifen, bei einer "divide et impera"-Problemstellung aber
immer die alte "Nicht in SW-denken"-Leier abspulen. Hilft nicht...
Bei den meisten pragmatischen Lösungen geht es nun mal schlicht darum,
SW mit HW optimal interagieren zu lassen. Dass es da nicht gleich einen
AXI-Bus und HAL braucht, sehen auch SW-Leute ein.
Da würde ich etwas kreative Querdenkerei bevorzugen, von mir aus auch
von überm[uü]tigen Physikern, die alles können, aber nix richtig :-)
weltbester FPGA-Pongo schrieb im Beitrag #4918182:
> ...und pulsierend durchgeschaltet, weil vollkommen asynchrone Module in> FPGAs erzeugt werden, wo es unnötig war und dort, wo es wiederum> sinnvoll und einfach gewesen wäre, aufwändig verhindert wird. Da wird> einsychronisiert und überabgetastet, was das Zeug hält, wo eine einfache> Flankenbetrachtung gereicht hätte und es werden FSMs und Filter mit> Taktfrequenzen gefahren, die extreme Auflösungen und Speicherzellen> erfordern, wo es ein trickreiches enable getan hätte.
Laaber, laaber, laaber. Meine Güte. Sag doch einfach das er falsch denkt
und lass es gut sein. Ewig am rumheulen, ohne nix.
ui schrieb:> Sag doch einfach das er falsch denkt> und lass es gut sein.
Für eine überzeugende Argumentation reicht es nicht, zu postulieren,
dass etwas falsch ist, sondern man unterlegt es auch mit Beispielen.
Zu der Frage, ob man Semaphore in VHDL benötigt, genauer: Ob man bei der
Programmierung von FPGAs Semaphore braucht, habe Ich Beispiele genannt.
Zu der anderen Frage, ob man Physiker oder Mathematiker an die Themen
ranlassen sollte, habe Ich ebenfalls Beispiele gebracht. Es hat ja
seinen Grund, warum es ein Elektrotechnik- und Informatikstudium gibt.
Die Elektroingenieure setzen in erster Linie physikalische Messmethodik
in Elektronik um, die Informatiker wiederum Mathematik in Software. In
beiden Fällen gibt es eine Reihe von Dingen, die man eben gelernt haben
muss, weil es Generationen vom Ingenieuren vor einem optimiert und
rausgeforscht haben und das gilt inzwischen auch für die 40 Jahre alte
Informatik und Computertechnik. Wenn da die "me too"-Generation nach der
Hausmannsart rangeht, nur weil sie in ihrem eigentlichen
wissenschaftlichen Fachgebiet nicht so richtig haben landen können, ist
das schon zweckmäßig, es in Frage zu stellen und mit Beispiel zu
unterlegen.
Für ihre Profifussballmannschaft stellt sich der FC Bayern ja auch
gelernte Fussballer ein und nicht etwa Lederproduzenten, Rasenforscher
oder FLugbahnberechnungsexperten. Die sind am Rande sicher interessant,
um Bälle, Plätze und Schusstechniken zu verbessern, aber Treten können
die eben nur hobbymässig.
Unverständlicherweise ist unsere Industrie auf dem Wege, genau das zu
tun: Man fordert immer spezifischere Ausbildung, stellt dann aber die
Quereinsteiger ein, weil sie billiges Arbeitsvieh sind.
Weltbester FPGA-Pongo schrieb im Beitrag #4919369:
> Unverständlicherweise ist unsere Industrie auf dem Wege, genau das zu tun
Ähem, wir sind hier nicht in Arbeit&Beruf. Zudem ist dieses Thema
mindestens genau so alt wie das Thema mit der "frechen und faulen
Jugend"(*) und "früher war alles besser"...
(*)http://www.gutzitiert.de/zitat_autor_sokrates_thema_jugend_zitat_11962.html
Lothar M. schrieb:> Weltbester FPGA-Pongo schrieb im Beitrag #4919369:> Ähem, wir sind hier nicht in Arbeit&Beruf.
Gut, da hast Du natürlich recht. Ich hätte die allgemeine Kritik
abkoppeln und ins Jobforum schieben sollen, wobei Ich doch noch einen
gewissen Unterschied zwischen meiner konkreten Betrachtung zu den
Physikern und der doch recht allgemeinen Plattitude mit dem "früher
alles besser" sehe, die manche gerne benutzen.
Thread beobachten
Seitenaufteilung abschalten