WS2812B mit FPGA

[Mathias (Gast)]

Hallo liebe Forengemeinde.

Ich möchte gerne fünf WS2812B mit einem FPGA ansteuern, leider gehe ich 
glaube ich gerade die falsche Richtung. Ich glaube meine Denkweise ist 
noch nicht die richtige. Hier erstmal meine Beschreibung.

entity WS2812B is
    Port ( G7 : in  STD_LOGIC;
           G6 : in  STD_LOGIC;
           G5 : in  STD_LOGIC;
           G4 : in  STD_LOGIC;
           G3 : in  STD_LOGIC;
           G2 : in  STD_LOGIC;
           G1 : in  STD_LOGIC;
           G0 : in  STD_LOGIC;
           R7 : in  STD_LOGIC;
           R6 : in  STD_LOGIC;
           R5 : in  STD_LOGIC;
           R4 : in  STD_LOGIC;
           R3 : in  STD_LOGIC;
           R2 : in  STD_LOGIC;
           R1 : in  STD_LOGIC;
           R0 : in  STD_LOGIC;
           B7 : in  STD_LOGIC;
           B6 : in  STD_LOGIC;
           B5 : in  STD_LOGIC;
           B4 : in  STD_LOGIC;
           B3 : in  STD_LOGIC;
           B2 : in  STD_LOGIC;
           B1 : in  STD_LOGIC;
           B0 : in  STD_LOGIC;
           EN : in  STD_LOGIC;
           CLK : in  STD_LOGIC;
           LED_OUT : out  STD_LOGIC);
end WS2812B;

architecture Behavioral of WS2812B is
  signal led_data : std_logic_vector(23 downto 0);
  shared variable led : std_logic;
begin
  
  led_data(0) <= G0;
  led_data(1) <= G1;
  led_data(2) <= G2;
  led_data(3) <= G3;
  led_data(4) <= G4;
  led_data(5) <= G5;
  led_data(6) <= G6;
  led_data(7) <= G7;
  
  led_data(8) <= R0;
  led_data(9) <= R1;
  led_data(10) <= R2;
  led_data(11) <= R3;
  led_data(12) <= R4;
  led_data(13) <= R5;
  led_data(14) <= R6;
  led_data(15) <= R7;
  
  led_data(16) <= B0;
  led_data(17) <= B1;
  led_data(18) <= B2;
  led_data(19) <= B3;
  led_data(20) <= B4;
  led_data(21) <= B5;
  led_data(22) <= B6;
  led_data(23) <= B7;

  process(en,clk)
  begin
    if rising_edge(clk) then
    if en = '1' then
      for i in 0 to 23 loop
        if led_data(i) = '1' then
          for a in 0 to 38 loop
            --if rising_edge(clk) then
              led := '1';
            --end if;
          end loop;
          for b in 0 to 22 loop
            --if rising_edge(clk) then
              led := '0';
            --end if;
          end loop;
        else
          for c in 0 to 19 loop
            --if rising_edge(clk) then
              led := '1';
            --end if;
          end loop;
          for d in 0 to 40 loop
            --if rising_edge(clk) then
              led := '0';
            --end if;
          end loop;
        end if;
      end loop;
    end if;
    end if;
  end process;
  
  Led_Out <= led;
  
end Behavioral;

Ich hoffe ihr könnt mir helfen den richtigen weg zu finden.

mfg Mathias

[Suchfunktion (Gast)]

Beitrag "Lauflicht Ws2812B"

[J. S. (engineer)]

Deine "Loops" innen haben keinerlei Bezug zu einer Variable oder einem 
Ausgang.

Loops, Waits und alle ausdrücklichen zeitabhängigen Konstrukte sind 
Dinge, die nur zur Compile-Zeit ausgeführt werden und die helfen sollen, 
Vereinfachungen beim Programmieren vorzunehmen und sich gfs Zeit zu 
sparen oder komplexe Gebilde einfach darzustellen.

Diese Zeitabhängigkeit gibt es in der späteren Hardware nicht. Wie auch?

Alles, was in VHDL - Logik eine "virtuelle Zeit" erzeugen soll, um zu 
warten, etwas zu verzögern oder Ähnliches zu veranstalten, braucht einen 
Bezug zu einem Takt, also eine Zählschaltung mit Start und 
Abbruchbedingung.

Alles, was in VHDL - PHYSIK eine "reale Zeit" erzeugen soll, braucht 
zeitabhängige Hardware, also ein physisches Delay, eine physische PLL, 
eine physische LUT, die an den Nanosekunden herumschieben.

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

Mathias schrieb:
> Ich glaube meine Denkweise ist noch nicht die richtige.
Eines sieht man ganz sonnenklar: du bist ein Softwerker.

Vergiss Schleifen vorerst gleich wieder, die tun nicht das, was du 
erwartest.
Und ein Prozess wird nicht "von oben her abgearbeitet", sondern er ist 
als Logik jederzeit komplett in der Hardware und wird parallel 
ausgewertet.

Wenn du zeitliche Abläufe willst, dann brauchst du einen 
Zustandsautomaten (FSM). Das ist halb so schlimm (schon ein Zähler ist 
eine FSM), aber eben eine vollkommen andere Denkweise: VHDL hat kein P 
im Namen, weil es eine HDL also eine HardwareBESCHREIBUNGssprache ist. 
Und um etwas "beschreiben" zu können muss man sich selber (wenigstens in 
Gedanken) ein Bild davon machen...

ALLES was du beschreibst muss sich mit Logik (LUTs) und Flipflops 
abbilden lassen. Nur diese Komponenten hast du im FPGA zur Verfügung.

[Softwareentwickler (Gast)]

Ich glaube, es ist ein großes Problem, dass FPGAs mit Software-Code 
programmiert werden. Wäre das nicht der Fall, käme keiner auf die Idee 
beim FPGAs vom "Programmieren" zu reden.

Lothar M. schrieb:
> Und um etwas "beschreiben" zu können muss man sich selber (wenigstens in
> Gedanken) ein Bild davon machen...
Da liegt der Hase im Pfeffer! Die meisten an der HS lernen schon direkt 
im 3. Semester VHDL, neben Python und C und sehen einfach die 
Unterschiede nicht.

[J. S. (engineer)]

Softwareentwickler schrieb:
> Wäre das nicht der Fall, käme keiner auf die Idee
> beim FPGAs vom "Programmieren" zu reden.

Ob man das Programmieren nennen will, oder nicht, ist nicht wirklich der 
Punkt. FÜr mich ist FPGA-Entwicklung sehr wohl Softwareentwicklung und 
sehr wohl auch Programmieren. Klar, der Begriff "Programmieren" hat 
diesbezüglich eine Begriffsverengung erfahren und wurde von den 
Softwerkern belegt. Das muss aber nicht so bleiben :-)

Mithin ist das mehr Wortspiel als Sinnspiel, denn der Knackpunkt ist ein 
ganz anderer:

Ich habe das bereits an mehreren Stelle geschrieben, daß es bei FPGAs 
einen Wichtigen - und zwar den ENTSCHEIDENDEN Unterschied gibt:

Beim C-Compiler wird der Code nicht ausgeführt, sondern nur 
interpretiert und in eine quivalente Form in Assembler / Maschinen-code 
übersetzt. Dabei bleibt die Funktion des Codes, also das, was ausgeführt 
werden soll, komplett erhalten. Bei C wird also eine Schleife von 1-100 
in eben wieder eine Schleife übersetzt. Dann kommt später ein Prozessor, 
der sich den Code ansieht und ihn ausführt.  Es wird zwar oft anders 
umgestzt, als kommandiert, aber es ist funktionell Dasselbe!

Beim VHDL-Compiler und auch beim Simulator wird der Code aber nicht 
(nur) interpretiert, sondern zur Compile-Zeit ausgeführt! Das ist der 
entscheidende Unterschied! Und um es noch deutlicher zu sagen: Er wird 
NUR von der Software ausgeführt und nicht etwa vom FPGA, weil der FPGA 
keinen Code interpretieren kann und auch nicht soll.

Eine Schleife wie oben läuft daher nur beim Comppilieren ab und baut 
etwas oder erzeugt ein Zwischenergebnis, das irgendwo eingesetzt wird. 
Z.B. kann man sich einen Sinuswert berechnen lassen, wenn man ihn 
braucht, oder was aus einem file lesen. Direkt programmiert wird also 
die Synthesesoftware und nicht die FPGA-firmware! Was da raus kommt, 
hängt von der Beschreibung und den Randbedingungen ab. Der funktionelle 
Ablauf im Quell-Code findet sich dort definitiv nicht wieder.


Kurz gesagt;

Die CPU-firmware ist ein reines Interpretationsergebnis und nur eine 
modifizierte Form des Quellcodes, in der die Funktionen explizit 
vorgegeben waren.

Die FPGA-firmware ist hingegen ein komplettes Analyse- und 
Rechenergebnis der Synthesesoftware, wobei die Funktionen implizit 
definiert wurden.

Ob man jetzt "Vorgeben" und "Definieren" als "Programmieren" oder 
"Beschreiben" bezeichnen möchte und dort inhaltliche Abgrenzungen 
eininterpretieren möchte, sei jedem selber überlassen.

[J. S. (engineer)]

Softwareentwickler schrieb:
> Da liegt der Hase im Pfeffer! Die meisten an der HS lernen schon direkt
> im 3. Semester VHDL, neben Python und C und sehen einfach die
> Unterschiede nicht.

Um es dem Anfänger zu verklickern, was VDHL-Programmieren ist, verwende 
ich gerne das Beispiel einer Arbeitsanweisung. Früher zu ABEL- und 
Genrad-Zeiten war das nur eine einfache Vorschrift für einen virtuellen 
Layouter. Da steht dann was drin wie : "Nimm die Gatter, klappere die 
Eingänge ab und verbinde sie so und so mit den Ausgängen". Dabei wird 
detailgenau und vollständig jede Leiterbahn bechrieben, wo wie man eine 
CNC-Maschine programmiert. Irgendwann kamen dann Freiheitsgrade dazu und 
der Layouter durfte vorher noch die Logik etwas optimieren und 
vereinfachen :-)

Heute ist das eine komplette Abstraktionsebene höher:

VHDL ist eine Art Pflichtenheft für einen Elektronikentwickler geworden, 
dem man das Eval-board hinlegt, die Funktionen (Mathematik, Timing, 
Abläufe) vorschreibt und Randbedinungen für die Physik vorgibt und dann 
nur noch in Einzelfällen detailgenau die Leiterbahnen bechreibt. In der 
Regel werden nur logische und oftmals nur noch funktionelle 
Verknüpfungen vorgegeben. Die Art der Umsetzung liegt dann komplett beim 
Layouter, der inzwischen eine Art denkender Elektronikentwickler 
geworden ist und Entscheidungen hinsichlich der Wahl der Resourcen sowie 
der Konfiguration und der Platzierung derselnben trifft. Das Ergebnis 
entzieht sich damit immer mehr der Betrachtung durch den 
"Programmierer",

Wer da von Anfang an dabei war, der sieht diese Ebenen und kann damit 
umgehen und die entsprechenden Schritte einordnen. Man kann bis zu einem 
gewissen Punkt auch entscheiden, welche Abstraktionsebene der 
Beschreibung in welchen Fällen die zielführendere ist oder die, welche 
zu einer besseren Darstellung und Pflegbarkeit führt - bzw in 
Einzelfällen Macken der tool chain umgeht :-)

Kurz gesagt:

Wer komplette Elektronikpflichtenhefte schreiben- sowie Chips einsetzen 
und verbinden kann, der kann das Ganze dann auch leicht als 
Anweisungskette in VHDL tun. Wer aber mit VHDL anfängt und sich das 
Gebiet über diese abstrakte Sprache erarbeiten möchte, der hat ein 
Problem.

Da hast du Recht! Eine Lösung dafür kann ich aber auch nicht bieten, 
außer eben mit den basics anzufangen und dann am Ende mit abstrakten 
Beschreibungen zu arbeiten. Das scheint aber in der Tat nicht der Fall 
zu sein.

Wenn man sich die FPGA-Projekte an den Unis so ansieht (und auch das, 
was hier im Forum oft so gefragt wird), dann stöpseln die Leute heute 
offenbar ohne große Vorkenntnisse aus dem Stand ganze 
Multiprozessorsysteme per SOPC-builder zusammen, während früher eine 
komlette kleine RISC-CPU mit 10 Befehlen eine ganze Diplomarbeit war.

Ich bin nicht sicher, ob das so gut ist.