Forum: FPGA, VHDL & Co. VHDL Code Aufgabe, HILFE! :/

Toni Z. schrieb:
> Im Anhang ist die Aufgabe, die ich bis 7.6.2021 abgeben muss

Ich bitte dich als Ehrenmann dich selbst in den Kram einzuarbeiten. Wo 
hakt es denn genau? Wo bleibst du hängen?

Bis 7.6. ist noch eine Menge Zeit. Bis dahin hast du den Pete Ashenden 
"the student's guide to vhdl" mehrmals durchgelesen und vielleicht sogar 
verstanden ;)

mfg mf

Toni Z. schrieb:
> Ich bitte um einen Ehrenmann
> der mir von dieser Aufgabe nur b) & c) lösen kann
Ein Gedicht!
Aber ich schlage vor, dass du einfach mal anfängst und dann wieder 
fragst, wenn du nicht mehr weiter kommst und konkrete Probleme 
auftreten.

> Ich bitte um einen Ehrenmann
Das hilft dir nichts. Denn solche "Ehrenmänner" musst du im späteren 
Leben auch dauernd suchen, wenn du schon aufgibst, vor du angefangen 
hast. Und sei dir sicher: irgendwann wirst du auch dem ehrenhaftesten 
Ehrenmann lästig.

Achim M. schrieb:
> Bis 7.6. ist noch eine Menge Zeit. Bis dahin
... solltest du mal ganz von vorn anfangen und einen simplen Zähler 
simulieren. Dann einen Blinker, der auf einem Zähler basiert, und dann 
einen Blinker, der sich mit den DIP-Schaltern einstellen lässt, und dann 
hast du die Aufgabe schon gelöst.
Die Aufgabe an sich ist so einfach, dass ich zweimal schauen musste, ob 
da nicht irgendwo ein Haken ist. Aber nein: im Grunde reicht 1 
rücksetzbarer Zähler, bei 0 den SOP ausgibt und dann beim Erreichen des 
Endwerts (eingestellt durch die DIP-Schalter) den EOP ausgibt und 
gleichzeitig den Zähler wieder zurücksetzt.
Wenn der gesamte HDL-Code nicht mehr auf 1 Bildschirmseite passt, dann 
ist er zu umständlich...

Lotta schrieb:
> ooch, die Aufgabe ist absolut geil und ich darf nicht proggen! :-(((((

Wieso darfst du das denn nicht?

Lotta schrieb:
> Was soll das dann werden? Ein Protokoll-Parser?

Das ist sehr wahrscheinlich schlicht eine übliche Übungsaufgabe wie man 
sie an einer Hochschule den Studierenden vorsetzt.

Weltbester FPGA-Pongo schrieb im Beitrag #6642633:
> Komische beschrieben! Wenn ich das richtig interpretiere, dann braucht
> er nur einen Zähler, der bis Schalterstellungende zählt, sobald der SOP
> gekommen ist. um selber den EOP zu senden.

Sehe ich genauso.

Weltbester FPGA-Pongo schrieb im Beitrag #6642633:
> Dann noch ein bissl
> einsynchen wegen Schaltereffekten und globalem Timing, sowie dem
> richtigen Weiterreichen der Eingangsdaten.

Da das nur simuliert wird ist das nicht Teil der Aufgabe.

Weltbester FPGA-Pongo schrieb im Beitrag #6642633:
> Da gibt es praktisch nichts zu Codieren. Das ist eher das Level "Duale
> Hochschule".

Ja, tatsächlich eher sehr einfach. Und sehr viel Zeit.

Hallo Toni,

Du hat Aufgabe a) wohl schon gelöst? Falls es bereits daran gescheitert 
ist:
https://www.edaplayground.com/

Was ist mit d)-g)?

Weltbester FPGA-Pongo schrieb im Beitrag #6643186:
> So krigen die Studenten nur den Eindruck, dass alles so einfach ist,
> weil sie den Zähler hinbekommen haben ...

Danach sieht diese Aufgabenstellung leider aus. Schöner wäre es, wenn da 
eine Testbench vorgegeben wäre die prellende Schalter beinhaltet.

> Die Aufgabe an sich ist so einfach, dass ich zweimal schauen musste, ob
> da nicht irgendwo ein Haken ist. Aber nein: im Grunde reicht 1
> rücksetzbarer Zähler, bei 0 den SOP ausgibt und dann beim Erreichen des
> Endwerts (eingestellt durch die DIP-Schalter) den EOP ausgibt und
> gleichzeitig den Zähler wieder zurücksetzt.
> Wenn der gesamte HDL-Code nicht mehr auf 1 Bildschirmseite passt, dann
> ist er zu umständlich...
Dein Kommentar hat mir schon sehr viel geholfen, vielen Dank :)

Ich hab im Grunde einen rücksetzbaren Zähler (8-Bit) erstellt, der bei 
00000000 eine steigende Flanke ausgibt von mein SOP-Signal und dann 
beim Erreichen des Endwerts 11111111 den EOP ausgibt.

Mein Problem ist "Dann beim Erreichen des Endwerts, eingestellt durch 
die DIP-Schalter, den EOP ausgibt und gleichzeitig den Zähler wieder 
zurücksetzt", ich weiß leider überhaupt nicht wie ich das realisieren 
soll.

Hier ist mein Programm, ich weiß das es ziemlich schlecht geschrieben 
ist aber besser hab ich es nicht hinbekommen:

HAUPTPROGRAMM:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity SOURCE is
    Port ( CLK,RST, EOP, SOP : in  STD_LOGIC;
           COUNT : inout  STD_LOGIC_VECTOR (7 downto 0));
end SOURCE;

architecture Behavioral of SOURCE is

begin
process (CLK,RST)
begin

if (RST = '1')then
COUNT <= "00000000";
elsif(rising_edge(CLK))then
COUNT <= COUNT+1;

end if;
end process;

end Behavioral;

TESTBENCH:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity sync_upcounter_tb is
end entity;

architecture tb of sync_upcounter_tb is
component SOURCE is
Port ( CLK,RST,SOP, EOP : in STD_LOGIC;
COUNT : inout STD_LOGIC_VECTOR (7 downto 0));
end component;

signal CLK,RST,SOP : STD_LOGIC := '1';
signal EOP : STD_LOGIC := '0';
signal COUNT : STD_LOGIC_VECTOR(7 downto 0);

begin
uut: SOURCE port map(
CLK => CLK,
SOP => SOP,
EOP => EOP,
RST => RST,
COUNT => COUNT);

clock: process
begin
RST <= '0';
SOP <= '0';
EOP <= '0';

CLK <= '0';
wait for 20 ns;
CLK <= '1';
wait for 20 ns;
  if (COUNT = "00000001") then
  SOP <= '1';
  wait for 20 ns;
  SOP <= '0';
  elsif (COUNT /= "00000001") then
  SOP <= '0';
  end if;

  if (COUNT = "11111111") then
  EOP <= '1';
  wait for 20 ns;
  EOP <= '0';
  elsif (COUNT /= "11111111") then
  EOP <= '0';
  end if;

end process;
end tb;

Ähm ... du machst das alles in der Testbench wenn ich das korrekt sehe. 
Du solltest das aber in deiner Komponente SOURCE machen. Ich schreibe 
dir mal eine Testbench ... dauert aber etwas.

Ausserdem solltest du Quelltexte als Datei anhängen. Direkt als .vhd wie 
du sie schon hast.

> Ich bitte dich als Ehrenmann dich selbst in den Kram einzuarbeiten. Wo
> hakt es denn genau? Wo bleibst du hängen?

Ich bin leider selbst nicht der beste Programmierer und VHDL ist für 
mich eine Komplett neue Sprache.


> Bis 7.6. ist noch eine Menge Zeit. Bis dahin hast du den Pete Ashenden
> "the student's guide to vhdl" mehrmals durchgelesen und vielleicht sogar
> verstanden ;)

Ich habe mich beim Datum verschrieben, es war nicht bis 7.6 sondern bis 
7.4 aber ich hab noch bis nächste Woche Zeit dafür bekommen 14.4 dank 
COVID-19

Ich hab im Grunde einen rücksetzbaren Zähler (8-Bit) erstellt, der bei 
00000000 eine steigende Flanke ausgibt von mein SOP-Signal und dann 
beim Erreichen des Endwerts 11111111 soll bei EOP eine steigende 
Flanke ausgegeben werden.

Mein Problem ist das die steigende Flanke von EOP eingestellt werden 
soll durch DIP-Schaltern und dann gleichzeitig wieder den Zähler 
zurücksetzt, ich weiß leider überhaupt nicht wie ich das realisieren 
soll.

Mein Programm, ich weiß das es ziemlich schlecht geschrieben ist aber 
besser hab ich es nicht hinbekommen:

HAUPTPROGRAMM:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity SOURCE is
    Port ( CLK,RST, EOP, SOP : in  STD_LOGIC;
           COUNT : inout  STD_LOGIC_VECTOR (7 downto 0));
end SOURCE;

architecture Behavioral of SOURCE is

begin
process (CLK,RST)
begin

if (RST = '1')then
COUNT <= "00000000";
elsif(rising_edge(CLK))then
COUNT <= COUNT+1;

end if;
end process;

end Behavioral;

TESTBENCH:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity sync_upcounter_tb is
end entity;

architecture tb of sync_upcounter_tb is
component SOURCE is
Port ( CLK,RST,SOP, EOP : in STD_LOGIC;
COUNT : inout STD_LOGIC_VECTOR (7 downto 0));
end component;

signal CLK,RST,SOP : STD_LOGIC := '1';
signal EOP : STD_LOGIC := '0';
signal COUNT : STD_LOGIC_VECTOR(7 downto 0);

begin
uut: SOURCE port map(
CLK => CLK,
SOP => SOP,
EOP => EOP,
RST => RST,
COUNT => COUNT);

clock: process
begin
RST <= '0';
SOP <= '0';
EOP <= '0';

CLK <= '0';
wait for 20 ns;
CLK <= '1';
wait for 20 ns;
  if (COUNT = "00000001") then
  SOP <= '1';
  wait for 20 ns;
  SOP <= '0';
  elsif (COUNT /= "00000001") then
  SOP <= '0';
  end if;

  if (COUNT = "11111111") then
  EOP <= '1';
  wait for 20 ns;
  EOP <= '0';
  elsif (COUNT /= "11111111") then
  EOP <= '0';
  end if;

end process;
end tb;

Lotta schrieb:
> ooch, die Aufgabe ist absolut geil und ich darf nicht proggen! :-(((((
>
> @toni:
> Was soll das dann werden? Ein Protokoll-Parser?
>
> mfg

Ich soll ein Passendes Programm dazu beschreiben und dann Dokumentieren 
wie mein Programm Funktioniert und was ich mir dabei gedacht habe.

>Kastanie mit Arsenglasur schrieb:

> Dann studier doch was anderes!
Ich bin noch nicht am studieren, dass ist meine Kolloquium Aufgabe die 
in einem Fach bekommen habe.

> Du hast jetzt 2 Monate Zeit, genug also um sich in VHDL einzulernen und
> die Aufgabe zu lösen.
Ich habe mich wie schon erwähnt leider beim Datum verschrieben, es war 
nicht bis 7.6 sondern bis
7.4 aber ich hab noch bis nächste Woche Zeit dafür bekommen also bis 
14.4 dank
COVID-19 (Neue LOCKDOWN)


> Ist doch eh eine schöne, nicht zu schwere Aufgabe.
> Das macht man über ein verlängertes Wochenende.
> Anfangen muss man halt.

Leider ist VHDL für mich eine komplett neue Sprache und ich hab ja von 
Null aus bekommen

Markus F. schrieb:
> Hallo Toni,
>
> Du hat Aufgabe a) wohl schon gelöst? Falls es bereits daran gescheitert
> ist:
> https://www.edaplayground.com/
>
> Was ist mit d)-g)?

Vielen Danke, Aufgabe a) hab ich schon gelöst. :)

Gustl B. schrieb:
> Ähm ... du machst das alles in der Testbench wenn ich das korrekt sehe.
> Du solltest das aber in deiner Komponente SOURCE machen. Ich schreibe
> dir mal eine Testbench ... dauert aber etwas.
>
> Ausserdem solltest du Quelltexte als Datei anhängen. Direkt als .vhd wie
> du sie schon hast.


Herr @Gustl B. das würde mich wirklich sehr freuen, ich bedanke mich 
schonmal in voraus für deine Hilfe und deine schnelle Antwort. :D

Kann es sein, dass du versuchst die Aufgabe in der Testbench zu lösen 
und nicht in der Komponente SOURCE? Mach das dort und verwende keine 
wait Statements bis vielleicht auf die Clock.

Ausserdem:

Toni Z. schrieb:
> Port ( CLK,RST, EOP, SOP : in  STD_LOGIC;
>            COUNT : inout  STD_LOGIC_VECTOR (7 downto 0));

1. RST ist nicht verlangt.
2. COUNT hat bei den Ports nix verloren, das kommt weder von außen rein 
noch soll es raus.
3. Daten sollen rein und auch wieder rein, du brauchst also einen Daten 
Ein- und Ausgang. Aber glaube nicht, dass dafür ein einziger inout geht.
4. Meide inouts.
5. Die 10 Schalter müssen irgendwie rein in deine Komponente, die 
fehlen.

Ich habe mal eine Testbench und die Komponente angehängt. Die Testbench 
ist großflächig neu und macht alles was du brauchst, die muss nicht 
angefasst werden.
In deiner Komponente "SOURCE" hast du diese Schnittstellen:

CLK      : in  STD_LOGIC;
SOP      : out STD_LOGIC;
EOP      : out STD_LOGIC;
DATA_IN  : in  STD_LOGIC_VECTOR(7 downto 0);
DATA_OUT : out STD_LOGIC_VECTOR(7 downto 0);
SCHALTER : in  STD_LOGIC_VECTOR(9 downto 0)

CLK ist der Takt, der kommt von der Testbench rein.
SOP und EOP sollst du erzeugen, das ist deine eigentliche Aufgabe. Das 
sind beides Ausgänge.
DATA_IN sind die Daten die reinkommen, aber die brauchst du nur 
durchzuschleifen an DATA_OUT, da gehen die wieder raus. Aber: Wie in der 
Aufgabenstellung geschrieben sollen die getaktet durchgeschliffen 
werden.
SCHALTER ist der 10 Bit Eingang der dir den Wert vorgibt wie lang ein 
Paket seien soll. In der Abhängigkeit vom Wert von SCHALTER sollst du 
SOP und EOP erzeugen.
SCHALTER habe ich in der Testbench fest auf den Wert 13 gelegt weil für 
den Anfang ein fester Wert völlig ausreicht.

Brich die Aufgabe in kleinere Teile runter:

1. Baue einen Zähler der so viele Takte hochzählt wie der WERT von 
SCHALTER ist und der danach direkt wieder auf Null zurückgeht.
2. Erzeuge SOP so, dass es den Wert '1' hat wenn der Zähler den 
Zählerstand 0 hat.
3. Erzeuge EOP so, dass es den Wert '1' hat wenn der Zähler sein Maximum 
erreicht hat.

Was für mich noch unklar ist, ob man hier auch den Inhalt der Daten 
erzeugen soll. Laut Aufgabenstellung nein, aber trotzdem stehen in den 
Daten Werte von 0 bis zum Maximum drinnen und wiederholen sich und 
passen auch zu SOP und EOP. Unklar, kannst du ja den Lehrer mal fragen.

@Gustl B. schrieb:
> Kann es sein, dass du versuchst die Aufgabe in der Testbench zu lösen
> und nicht in der Komponente SOURCE? Mach das dort und verwende keine
> wait Statements bis vielleicht auf die Clock.

Ich hab es tatsächlich versucht in der Testbech zu lösen, gut ich 
versuche es in Soure zu machen, ok ich probier mal weiter rum, ohne wait 
Statements. Ich bin mir zwar nicht sicher warum ich keine wait 
Statements benutzen darf aber das wird schon seine Gründe haben.

> Ausserdem:
>
> Toni Z. schrieb:
>> Port ( CLK,RST, EOP, SOP : in  STD_LOGIC;
>>            COUNT : inout  STD_LOGIC_VECTOR (7 downto 0));
>
> 1. RST ist nicht verlangt.

Stimmt, Sie haben recht es ist wirklich nicht verlangt.

> 2. COUNT hat bei den Ports nix verloren, das kommt weder von außen rein
> noch soll es raus.

Vielen Danke dies wusste ich ebenfalls nicht.

> 3. Daten sollen rein und auch wieder rein, du brauchst also einen Daten
> Ein- und Ausgang. Aber glaube nicht, dass dafür ein einziger inout geht.
> 4. Meide inouts.
> 5. Die 10 Schalter müssen irgendwie rein in deine Komponente, die
> fehlen.

Das mit den Schaltern wusste ich halt überhaupt nicht wie das machen 
soll.

> Ich habe mal eine Testbench und die Komponente angehängt. Die Testbench
> ist großflächig neu und macht alles was du brauchst, die muss nicht
> angefasst werden.

OMG VIELEN LIEBEN DANK!

> In deiner Komponente "SOURCE" hast du diese Schnittstellen:
> CLK      : in  STD_LOGIC;
> SOP      : out STD_LOGIC;
> EOP      : out STD_LOGIC;
> DATA_IN  : in  STD_LOGIC_VECTOR(7 downto 0);
> DATA_OUT : out STD_LOGIC_VECTOR(7 downto 0);
> SCHALTER : in  STD_LOGIC_VECTOR(9 downto 0)
>
> CLK ist der Takt, der kommt von der Testbench rein.
> SOP und EOP sollst du erzeugen, das ist deine eigentliche Aufgabe. Das
> sind beides Ausgänge.


> DATA_IN sind die Daten die reinkommen, aber die brauchst du nur
> durchzuschleifen an DATA_OUT, da gehen die wieder raus. Aber: Wie in der
> Aufgabenstellung geschrieben sollen die getaktet durchgeschliffen
> werden.

Ich komm mir vor wie der größte trottel aber was ist mit 
"durchzuschleifen an DATA_OUT" gemeint ?

> SCHALTER ist der 10 Bit Eingang der dir den Wert vorgibt wie lang ein
> Paket seien soll. In der Abhängigkeit vom Wert von SCHALTER sollst du
> SOP und EOP erzeugen.

Asoo je nachdem wie die Schalter geschalten sind, erst dann sollen SOP 
und EOP erzeugt werden. Ich glaub mir wird erst jetzt wirklich bewusst 
was ich überhaupt machen sollte. :D


> SCHALTER habe ich in der Testbench fest auf den Wert 13 gelegt weil für
> den Anfang ein fester Wert völlig ausreicht.

signal paketlaenge : integer range 0 to 1023:=*13*;
Diese 13 heißt also das die jetzige Schalterstellung auf 13 ist, richtig 
?


> Brich die Aufgabe in kleinere Teile runter:
>
> 1. Baue einen Zähler der so viele Takte hochzählt wie der WERT von
> SCHALTER ist und der danach direkt wieder auf Null zurückgeht.
> 2. Erzeuge SOP so, dass es den Wert '1' hat wenn der Zähler den
> Zählerstand 0 hat.
> 3. Erzeuge EOP so, dass es den Wert '1' hat wenn der Zähler sein Maximum
> erreicht hat.

Ich versuche mal die Nummer 1. zu machen :)
Ich melde mich wieder wenn ich das geschafft habe.

> Was für mich noch unklar ist, ob man hier auch den Inhalt der Daten
> erzeugen soll. Laut Aufgabenstellung nein, aber trotzdem stehen in den

Ich glaube ebenfalls nicht, dass dies verlangt wird

> Daten Werte von 0 bis zum Maximum drinnen und wiederholen sich und
> passen auch zu SOP und EOP. Unklar, kannst du ja den Lehrer mal fragen.

Mein Lehrer antwortet mir nicht mal und selbst wenn sagt er mir ich 
Zitiere " Das haben wir irgendwann mal im Unterricht besprochen" oder 
"Das solltest du schon selber wissen" :/

*NOCHMALS VIELEN DANK FÜR DEINE HILFE!*
Ich weiß das so etwas nicht selbstverständlich ist

Toni Z. schrieb:
> Ich hab es tatsächlich versucht in der Testbech zu lösen, gut ich
> versuche es in Soure zu machen, ok ich probier mal weiter rum, ohne wait
> Statements. Ich bin mir zwar nicht sicher warum ich keine wait
> Statements benutzen darf aber das wird schon seine Gründe haben.

Der Grund ist, dass es das in Hardware im FPGA nicht gibt. Der FPGA 
kennt keine Zeit. Wenn du im FPGA z. B. 1 us lang warten willst, dann 
musst du einen Takt verwenden. Wenn du beispielsweise einen 100 MHz Takt 
hast, dann ist eine Taktperiode 10 ns lang. Du musst mit diesem Takt 
also von 0 bis 99 zählen, dann hast du 1 us lang gewartet.

Das was in der Testbench steht kommt später nicht ins FPGA, da darfst du 
dich austoben und auch Beschreibungen nutzen die man nicht ins FPGA 
einbauen kann.

Toni Z. schrieb:
> Stimmt, Sie haben recht es ist wirklich nicht verlangt.

Wir duzen uns hier glaube ich ... (-:

Toni Z. schrieb:
> Ich komm mir vor wie der größte trottel aber was ist mit
> "durchzuschleifen an DATA_OUT" gemeint ?

Gute Frage. Du bekommst von außen, also von der Testbench in dem Fall, 
Daten rein, die brauchen dich nicht weiter zu interessieren, aber du 
musst sie auch wieder ausgeben. Daher habe ich die den Dateneingang 
DATA_IN und den Datenausgang DATA_OUT eingebaut.
Im einfachsten Fall kannst du die miteinander verbinden:

DATA_OUT <= DATA_IN;

Aber es ist gefordert, dass das getaktet passiert damit eben die Daten 
auch um einen Takt verzögert werden. Warum auch immer. Jedenfalls mach 
diese Zuweisung, also die Verbindung von DATA_OUT und DATA_IN in einem 
getakteten Prozess.

Toni Z. schrieb:
> Asoo je nachdem wie die Schalter geschalten sind, erst dann sollen SOP
> und EOP erzeugt werden. Ich glaub mir wird erst jetzt wirklich bewusst
> was ich überhaupt machen sollte. :D

Kein Ding, ging mir auch oft so.
Ja, die 10 Schalter sind ein 10-Bit Wert. Und Der Abatsnt von SOP bis 
EOP soll so viele Takte lang sein wie der Wert der Schalter aktuell ist.

Und auf ein EOP folgt im nächsten Takt immer das nächste SOP.

Toni Z. schrieb:
> Diese 13 heißt also das die jetzige Schalterstellung auf 13 ist, richtig
> ?

Jap. Das ist natürlich einstatischer Wert in der Testbench, aber für den 
Anfang reicht das. Wenn das bei dir funktioniert, also SOP und EOP 13 
Takte auseinander sind[*], dann können wir das umbauen und die 
Schalterwerte zur Laufzeit verändern.

[*] Genauer:
Wenn jetzt 13 eingestellt ist, dann soll dein Zähler von 0 bis 12 zählen 
und dann wieder bei 0 anfangen.
Wenn der Zähler den Wert 0 hat ist SOP 1 und sonst 0.
Wenn der Zähler den Wert 12 hat ist EOP 1 und sonst 0.

Toni Z. schrieb:
> *NOCHMALS VIELEN DANK FÜR DEINE HILFE!*
> Ich weiß das so etwas nicht selbstverständlich ist

Ich war selber mal Lehrer und helfe immer gerne. Viel Erfolg!

@Gustl B.

> Mach das dort und verwende keine wait Statements bis vielleicht auf die Clock.

> Brich die Aufgabe in kleinere Teile runter:
> 1. Baue einen Zähler der so viele Takte hochzählt wie der WERT von
> SCHALTER ist und der danach direkt wieder auf Null zurückgeht.
> 2. Erzeuge SOP so, dass es den Wert '1' hat wenn der Zähler den
> Zählerstand 0 hat.
> 3. Erzeuge EOP so, dass es den Wert '1' hat wenn der Zähler sein Maximum
> erreicht hat.

Ich hab die 3 Punkte dir du mir als Aufgabe gegeben hast, versucht zu 
lösen so gut wie ich nur konnte. Ich hab die Testbench wie du mir gesagt 
hast nicht angefasst und alles in Source gemacht.
Ebenfalls hab ich versucht keine  wait Statements zu benutzen.

Ich hab 3 Fehler in mein Programm, ich weiß aber leider nicht wo das 
Problem ist. Könntest du dir, dass was ich bis jetzt gemacht habe, mal 
anschauen und mir vielleicht sagen, was ich falsch gemacht habe?

Könntest du mir ebenso sagen ob ich diese 3 Punkte ansatzweise richtig 
gemacht habe.

Foto und Code ist im Anhang :)

@Fpgakuechle K. schrieb:
> Toni Z. schrieb:
>
>
>
> conditional assignments  (Zeilen 33,34) darf man nicht innerhalb eines
> Prozesses verwenden.

Tatsächlich hab die beiden Zeilen außerhalb des Prozesses eingefügt und 
es zeigt keine Fehler mehr an.

Vielen Dank.

Toni Z. schrieb:
> Ich hab die 3 Punkte dir du mir als Aufgabe gegeben hast, versucht zu
> lösen so gut wie ich nur konnte.

Ja, aber nicht ganz.
SCHALTER_GRENZE solltest du nicht fest auf einen Wert legen, sondern von 
dem Eingang SCHALTER übernehmen. Dann muss SCHALTER_GRENZE ebenfalls 10 
Bits lang sein.
Ausserdem hast du jetzt ein COUNT und ein COUNT_SCHALTER. Du brauchst 
nur eines der Beiden. Da aber SCHALTER 10 Bits lang ist sollte auch dein 
Zähler 10 Bits lang werden.

Wenn du in die Testbench noch

process begin
  wait for 10 us;
  paketlaenge <= 5;
  wait for 10 us;
  paketlaenge <= 95;
  wait for 10 us;
  paketlaenge <= 866;
  wait for 10 us;
  paketlaenge <= 61;
  wait;
end process;

einfügst ändert sich der Wert von deinem Eingang SCHALTER.

@Gustl B.


> Ja, aber nicht ganz.
> SCHALTER_GRENZE solltest du nicht fest auf einen Wert legen, sondern von
> dem Eingang SCHALTER übernehmen. Dann muss SCHALTER_GRENZE ebenfalls 10
> Bits lang sein.
> Ausserdem hast du jetzt ein COUNT und ein COUNT_SCHALTER. Du brauchst
> nur eines der Beiden. Da aber SCHALTER 10 Bits lang ist sollte auch dein
> Zähler 10 Bits lang werden.
>
> Wenn du in die Testbench noch
>
> process begin
>   wait for 10 us;
>   paketlaenge <= 5;
>   wait for 10 us;
>   paketlaenge <= 95;
>   wait for 10 us;
>   paketlaenge <= 866;
>   wait for 10 us;
>   paketlaenge <= 61;
>   wait;
> end process;
>
> einfügst ändert sich der Wert von deinem Eingang SCHALTER.


Ok, ich versuch das mal zu Verbessern und das in der Testbench 
einzufügen.
Danke :)

@Gustl B.

> Ja, aber nicht ganz.
> SCHALTER_GRENZE solltest du nicht fest auf einen Wert legen, sondern von
> dem Eingang SCHALTER übernehmen. Dann muss SCHALTER_GRENZE >ebenfalls 10 Bits 
lang sein.

Ich hab SCHALTER_GRENZE jetzt auf 10 Bit umgeschrieben.
Aber ich weiß leider nicht wie ich SCHALTER_GRENZE den Wert vom Schalter 
Eingang geben kann.



> Ausserdem hast du jetzt ein COUNT und ein COUNT_SCHALTER.
> Du brauchst nur eines der Beiden. Da aber SCHALTER 10 Bits lang ist
> sollte auch dein Zähler 10 Bits lang werden.


Ich hab dies ebenfalls umgeschrieben und verwende jetzt nur Counter als 
mein Zähler.

Weiß aber trotzdem nicht wie das Problem mit SCHALTER_GRENZE machen soll 
?

1.
Toni Z. schrieb:
> Aber ich weiß leider nicht wie ich SCHALTER_GRENZE den Wert vom Schalter
> Eingang geben kann.

Dafür gibt es Zuweisungen.

SCHALTER_GRENZE <= SCHALTER;

Weil das aber noch unterschiedliche Typen sind musst du SCHALTER noch 
nach unsigned wandeln.

2.
Du kannst hier problemlos .vhd Dateien anhängen.

3.
Du zählst COUNT an zwei Stellen hoch. An der ersten Stelle in jedem Takt 
und an der zweiten Stelle nur wenn die Bedingung zutrifft. Das Ergebnis 
ist also, dass er in jedem Takt hochgezählt wird.

4.
Simuliere deinen Code! Dann hättest du das selbst gemerkt, dass der 
weiter zählt also SCHALTER_GRENZE.

@Gustl B.

> Dafür gibt es Zuweisungen.
>
> SCHALTER_GRENZE <= SCHALTER;
>
> Weil das aber noch unterschiedliche Typen sind musst du SCHALTER noch
> nach unsigned wandeln.

Hab ich gemacht.


> 2. Du kannst hier problemlos .vhd Dateien anhängen.
> 3. Du zählst COUNT an zwei Stellen hoch.An der ersten Stelle in jedem Takt
> und an der zweiten Stelle nur wenn die Bedingung zutrifft. Das Ergebnis
> ist also, dass er in jedem Takt hochgezählt wird.

Hab ich beseitigt.

Aber irgendwie bekomme ich viel zu viele SOP & EOPS beim Simulieren.
Meinen Neuen Code und das Bild von der Simulation ist im Anhang.
Hab jetzt wieder keine Ahnung warum es so ausschaut.

Danke für die Antwort um diese späte Uhrzeit :)

Toni Z. schrieb:
> Hab ich gemacht.

Jap, ist auch korrekt, du musst aber keine Integer nehmen sondern kannst 
unsigned verwenden.

Toni Z. schrieb:
> Hab ich beseitigt.

Passt auch.

Toni Z. schrieb:
> Aber irgendwie bekomme ich viel zu viele SOP & EOPS beim Simulieren.

Nein, das passt schon. Wenn mit den Schaltern z. B. der Wert 13 
eingestellt ist, dann wiederholt sich das eben alle 13 Takte. Du kannat 
ja mal länger simulieren, so 10 us oder so und gucken ob das wirklich 
immer die geforderte Anzahl an Takten ist von SOP bis EOP.

Einen Fehler hast du noch:
Zwischen EOP und dem nächsten SOP ist eine Lücke von einem Takt. Die 
soll da nicht sein.

Ausserdem bekommt SCHALTER_GRENZE jetzt sofort immer den aktuellen Wert 
von Schalter. Das ist nicht gut.
Stell dir vor da ist der Wert 100 eingestellt. Als Beispiel. Dein Zähler 
zählt, ist z. B. schon beim Wert 80. Jetzt ändert Schalter und damit 
auch dein SCHALTER_GRENZE den Wert auf z. B. 20. Dann geht dein Zähler 
sofort auf 0 zurück. Es wäre vielleicht schöner wenn zuerst bis 100 
weitergezählt würde und dann neu gezählt würde, dieses Mal dann bis 20.
Das ist aber nicht in der Aufgabenstellung gefordert.

Weiterhin:
Die DATA_IN sollen getaktet an DATA_OUT weitergereicht werden, das fehlt 
noch.

Anbei eine Testbench die in jedem Takt Daten ausgibt. Und auch noch eine 
leicht angepasste Version von deinem Code, ich habe das mal etwas 
strukturiert und eingerückt.

Du kannst hier auch direkt .vhd Dateien in den Anhang hängen, die muss 
man nie in .txt umbenennen. Ein guter Editor wie Notepad++ kann auch 
.vhd öffnen. https://notepad-plus-plus.org/

@Gustl B.


> Aber irgendwie bekomme ich viel zu viele SOP & EOPS beim Simulieren.

> Nein, das passt schon. Wenn mit den Schaltern z. B. der Wert 13
> eingestellt ist, dann wiederholt sich das eben alle 13 Takte. Du kannat
> ja mal länger simulieren, so 10 us oder so und gucken ob das wirklich
> immer die geforderte Anzahl an Takten ist von SOP bis EOP.
>
> Einen Fehler hast du noch:
> Zwischen EOP und dem nächsten SOP ist eine Lücke von einem Takt. Die
> soll da nicht sein.


> Weiterhin:
> Die DATA_IN sollen getaktet an DATA_OUT weitergereicht werden, das fehlt
> noch.

Ich hab dafür einfach DATA_OUT <= DATA_IN;  geschrieben.
Ich weiß nicht ob das so wirklich richtig ist aber beim Simulieren 
bekommt DATA_FROM_SOURCE die sachen von DATA_TO_SOURCE 1zu1 also das 
scheint so zu stimmen oder ?

> Anbei eine Testbench die in jedem Takt Daten ausgibt. Und auch noch eine
> leicht angepasste Version von deinem Code, ich habe das mal etwas
> strukturiert und eingerückt.
Ohh Vielen Dank, sieht jetzt echt etwas strukturierter aus.

> Du kannst hier auch direkt .vhd Dateien in den Anhang hängen, die muss
> man nie in .txt umbenennen. Ein guter Editor wie Notepad++ kann auch
> .vhd öffnen. https://notepad-plus-plus.org/
Hab mir jetzt Notepad geholt :D

@Fpgakuechle K.

> ich habe die Zeile "DATA_OUT <= DATA_IN;" jetzt auf die schnelle nicht
> in deinem angehangenem Code gefunden.

> "Getaktet zugewiesen" meint hier, das die Zuweisung nicht immer aktiv
> ist sondern nur zum Taktzeitpunkt. In Hardware bedeudet eine
> 'ungetaktete' Zuweisung einfach ein Stück Draht zwischen DATA_OUT  und
> DATA_IN, während für gGetaktet' ein Delay-FlipFlop zwischen beiden
> Signalen liegt.
> in deinem angehangenem Code gefunden.

Ich hab jetzt meinen aktuellsten Code und meine Testbench mal eingefügt.
In hab in meinen Code auch Kommentiert wo ich "DATA_OUT <= DATA_IN;" 
davor hatte und wo ich es jetzt eingefuegt habe.


> "Getaktet zugewiesen" meint hier, das die Zuweisung nicht immer aktiv
> ist sondern nur zum Taktzeitpunkt. In Hardware bedeudet eine
> 'ungetaktete' Zuweisung einfach ein Stück Draht zwischen DATA_OUT  und
> DATA_IN, während für gGetaktet' ein Delay-FlipFlop zwischen beiden
> Signalen liegt.

Ich weiß da jetzt da wo ich es davor das "DATA_OUT <= DATA_IN;" 
geschrieben habe, war es ungetaktete also sozusagen einfach ein Stück 
Draht, wie du es beschrieben hast.


> Du musst also deine Zuweisung innerhalb eines Processes, der auf den
> Takt empfindlich (sensitive) ist, setzen. Das stellt klar, das Data_out
> nur zum Zeitpunkt der aktiven Taktflanke seinen Wert ändert. Es genügt
> also nicht irgendwo im Code die Zeile 'DATA_OUT <= DATA_IN;' zu
> platzieren, sie muss auch an der richtigen Stelle (Kontext) (hier
> beispielsweise innerhalb eines prozesses) stehen, damit daraus eine
> getaktete Zuweisung wird.


Ich hab "DATA_OUT <= DATA_IN;" jetzt innerhalb eines Processes 
geschrieben, würde es jetzt so passen ? Ich hab bin ziehmlich unsicher 
ob das jetzt passt so wie es jetzt ist.

Ja, sieht gut aus. Du könntest auch noch die Zuweisung

Schalter_grenze <= unsigned(SCHALTER(9 downto 0));

nur dann machen wenn der Zähler gerade seinen Höchststand erreicht hat.

Es wäre auch schön, wenn das ganze Design getaktet wäre, wurde aber 
nicht gefordert.

Und dann hast du vermutlich weiterhin den Fehler, dass nach einem EOP 
ein Takt Pause ist und erst dann das nächste SOP kommt.

Gustl B.
> Ja, sieht gut aus. Du könntest auch noch die Zuweisung
> Schalter_grenze <= unsigned(SCHALTER(9 downto 0));

> nur dann machen wenn der Zähler gerade seinen Höchststand erreicht hat.

> Es wäre auch schön, wenn das ganze Design getaktet wäre, wurde aber
> nicht gefordert.

> Und dann hast du vermutlich weiterhin den Fehler, dass nach einem EOP
> ein Takt Pause ist und erst dann das nächste SOP kommt.


Ich möchte mich nochmals bedanken bei dir, für deine Hilfe.
Dass du mir jedes mal schnelle & verständlichen Antworten gegeben hast 
und alles bezogen auf meine Aufgabenstellung.

*Vielen lieben Dank Herr @Gustl B. !* :D

Bitte! Vor grob 10 Jahren bin ich hier so aufgeschlagen wie du jetzt. 
Damals wurde mir sehr geduldig auf meine laienhaften Fragen geantwortet. 
Das gebe ich jetzt weiter (-:

Gustl B. schrieb:
> Ja, sieht gut aus.
Bis zum Juni wird das schon noch ;-)


Toni Z. schrieb:
> meinen aktuellsten Code
Sieh dir mal das an, simuliere es und sinniere ein wenig drüber nach:

1

:

2

signal COUNT            : unsigned(9 downto 0):=(others => '0');

3

signal Schalter_grenze  : unsigned(9 downto 0):=(others => '0');

4

5

begin

6

7

  process (CLK) begin

8

    if rising_edge(CLK) then

9

      SOP <= '0'; -- Defaultwerte für die beiden Signale = '0'

10

      EOP <= '0'; -- diese Werte werden später im Prozess evtl. noch "überschrieben"

11

12

      DATA_OUT <= DATA_IN; -- Wuerde es hier jetzt passen?

13

      --> ist laut Aufgabenstellung irrelevant, aber allemal besser 

14

      --  hier einmal registriert als nebenläufig einfach durchgereicht.

15

16

      COUNT <= COUNT+1;  -- Zähler weiterzählen, Achtung:

17

      -- der Wert von COUNT ändert sich noch nicht!

18

      -- der "neue" Wert wird lediglich "vorgemerkt" und nachfolgend

19

      -- wird noch der alte Zählerstand zum Vergleich genommen.

20

      -- Siehe dazu das Kapitel: "Verhalten von Signalen in Prozessen"

21

      -- frei nach dem Motto "die letzte Zuweisung gewinnt!"

22

      if COUNT+1 = Schalter_grenze then   -- der nächste Zählerschritt ist der letzte?

23

        EOP   <= '1';                     -- Ja: EOP aktiv, Defaultwert überschreiben

24

      elsif COUNT >= Schalter_grenze then -- Obergrenze erreicht?

25

        S0P   <= '1';                     -- Ja: SOP aktiv, Defaultwert überschreiben

26

        COUNT <= (others=>'0');           -- Zähler auf 0 setzen

27

        -- definierter Zeitpunkt zur Übernahme eines neuen Schalterwerts: 

28

        -- beim Übergang(!) zum Zählerstand 0

29

        Schalter_grenze <= unsigned(SCHALTER(9 downto 0));

30

      end if;

31

   end if;

32

end process;

33

:

34

:

Dadurch, dass kein Vergleich und keine Zuweisung ausserhalb des 
getakteten Prozesses ist, ist garantiert das gesamte Design synchron. 
Wenigstens ausgangsseitig, denn am Eingang müsste man ggfs. noch ein 
wenig mehr Gehirnschmalz stecken, dass nicht beim Umstellen der 
DIP-Schalter auf einen anderen Grenzwertes vogelwilde Obergrenzen 
eingelesen werden. Aber das wird schon wieder ein wenig akademisch... 
;-)

Damit die Simulation auch funktioniert sollte noch eine 0 gegen ein O 
getauscht werden ...
Und dann wird noch einen Takt zu lange gezählt.

Gustl B. schrieb:
> 0 gegen ein O getauscht werden ...
Ich muss da einen anderen Font einstellen. Irgendwie... :-/

> Und dann wird noch einen Takt zu lange gezählt.
Und auch die Forderung, dass bei Schalterstellung 00..00 (und somit 1 
einzigem Zähltakt) sowohl SOP als auch EOP gleichzeitig ausgegeben 
werden müssen, funktioniert so nicht. Da muss ich wohl nochmal ran. Aber 
bis zum 7.6. ist ja noch Zeit  ;-)

Lothar M. schrieb:
> Aber bis zum 7.6. ist ja noch Zeit  ;-)

Tatsache!

Fpgakuechle K. schrieb:
> Garnicht so einfach

Du kannst auch nach 0 suchen. Und nach 1. Oder eben gucken was Modelsim 
dazu sagt.
Auch gerne verwechselt wird das l mit 1.

Fpgakuechle K. schrieb:
> (weiss jetzt aber nicht,
> ob man den Modelsim 'unterschieben' kann:

Klar geht das.

Lothar M. schrieb:
> Wenn der gesamte HDL-Code nicht mehr auf 1 Bildschirmseite passt, dann
> ist er zu umständlich...
Hab mal kurz in der Mittagspause ein paar Fingerübungen gemacht  ;-)