Ausgabe an LED's

push ist hier ein Eingang es soll nur hoch/ruck zaehlen nur wenn push =1 
ist.

entity zaehler is
    Port ( clk : in  STD_LOGIC;
           reset : in  STD_LOGIC;
           push : in  STD_LOGIC;
        count_direction: in std_logic;
           led : out  STD_LOGIC_VECTOR (7 downto 0));
end zaehler;

mfg

Das HDL sieht erstmal gut aus. Wie schnell ist denn dein Takt? Wenn das 
mehr als 100..1000 Hz sind, siehst du nur ein Flimmern oder 
gleichmässiges Leuchten der LEDs. Alle Pins richtig definiert (Pad 
Zuordnung)?

MfG
Falk

In die Sensitivitätsliste gehört nur der asynchrone Reset und der Takt, 
nichts, was innerhalb der Taktanweisung gelesen wird. Für arithmetische 
Operationen nimmt man die Datentypen (un)signed aus der Bibliothek 
numeric_std. Sonst passt das schon. Der grundsätzliche Fehler ist wie 
Falk bemerkt woanders zu suchen...

1

library ieee;

2

use ieee.std_logic_vector_1164.all;

3

use ieee.numeric_std.all;

4

5

entity zaehler is

6

  Port ( clk : in  STD_LOGIC;

7

         reset : in  STD_LOGIC;

8

         push : in  STD_LOGIC;

9

         count_direction: in std_logic;

10

         led : out  STD_LOGIC_VECTOR (7 downto 0));

11

end zaehler;

12

13

architecture Behavioral of zaehler is

14

15

signal conteur: unsigned(7 downto 0) := (others => '0');

16

17

begin

18

19

process (clk, reset)

20

begin

21

   if reset='1' then

22

      conteur <= (others => '0');

23

   elsif rising_edge(clk) then

24

      if push ='1' then

25

         if count_direction ='1' then

26

            conteur <= conteur + 1;

27

         else

28

            conteur <= conteur - 1;

29

         end if;

30

      end if;

31

   end if;

32

end process;

33

34

led <= std_logic_vector(conteur);

35

36

end Behavioral;

Mein Takt war erstmal 50MHZ ich habe es jetzt um 1000HZ definiert.

PS: mein zaeher soll nicht allein zählen sondern nur wenn ich push drück 
dh. 1 mal push dann 00000001 2 mal 00000010 und so weiter. die Pins sind 
richtig defiert.

"...PS: mein zaeher soll nicht allein zählen sondern nur wenn ich push 
drück
dh. 1 mal push dann 00000001 2 mal 00000010 und so weiter. die Pins sind
richtig defiert..."

Das macht für die Sensitivitätsliste keinen Unterschied, da das Signal 
push nur relevant ist, wenn eine Taktflanke auftritt. Deshalb gehört nur 
der Takt in die Liste. Merke:
Bei einem synchronen Prozess gehören nur etweige asynchrone (Re)set 
Signale und der Takt in die Sensitivitätsliste, nichts anderes.

@jojo

>Mein Takt war erstmal 50MHZ ich habe es jetzt um 1000HZ definiert.

Was meinst du mit "definiert"? An dem Pin vom FPGA/CPLD muss wirklich 
ein Takt von 1000 Hz anliegen oder du musst einen Taktteiler im FPGA 
programmieren.

>PS: mein zaeher soll nicht allein zählen sondern nur wenn ich push drück
>dh. 1 mal push dann 00000001 2 mal 00000010 und so weiter. die Pins sind
>richtig defiert.

Das funktioniert mit deinem Code aber nicht. Dazu musst du

a) die Taste "push" entprellen
b) die steigende oder fallende Flanke erkennen und auswerten

MfG
Falk

Ist der Taktteiler noch notwendig wenn den push taste entprellt 
ist(meinnst du damit verzögerung zeit vermeiden!!?) ist?

@jojo

>Ist der Taktteiler noch notwendig wenn den push taste entprellt
>ist(meinnst du damit verzögerung zeit vermeiden!!?) ist?

Ja, sonst zählt dein Zähler mit 50 MHz hoch. Es sei denn, du machst noch 
ne Flankenerkennung für den Taster rein, dann gehts auch mit 50 MHz.

so ala

process(clk)
begin
  if clk='1' and clk'event then
    push_1 <= push;
    push_2 <= push_1;
    if push_1 ='0' and push_2 = '1' then
      push_int ='1';
    else
      push_int ='0';
    end if;
  end if;
end process;

Dieses push_int musst du dann in deinem Zähler anstatt von push 
verwenden.

MfG
Falk

Vielen Dank Falk

Jetzt funktioniert auch ohne der Taktteiler und ohne der Taste 
entprellung. Aber ich hätte gern Wissen wie man ein Taste entprellt?

MFG

@jojo

>Jetzt funktioniert auch ohne der Taktteiler und ohne der Taste
>entprellung. Aber ich hätte gern Wissen wie man ein Taste entprellt?

Hier mal ein klines Beispiel. Erst wenn die Taste 100 mal hintereinander 
einen neuen Pegel hat wird umgeschalten (taste_old).

process(clk)
begin
  if clk='1' and clk'event then
    taste <= taste_int;

    if taste_int /= taste_old then
      cnt_debounce <= cnt_debounce +1;
      if cnt_debounce = 100 then
        cnt_debounce <= (others=>'0');
        taste_old <= taste_int;
      end if;
    else
      cnt_debounce <= (others=>'0');
    end if;

  end if;
end process;

MfG
Falk

Kleine Anmerkung zu T.M.:

In die Sensitivity-Liste gehören IMMER ALLE Singane, die in dem Prozess 
gelesen werden.
In deinem Fall clk, reset, count_direction und sogar conteur!!!

Je nach synthesetool kann es sonst zu schlechten Syntheseergebnissen 
führen.

Ein guter VHDL-Editor korrigiert sogar die sensititivty-List dahingehen.

@Da Micha:
@Roger

ich hab jetzt gerade keine Quelle an der Hand. Jedoch musste ich leider 
schon schmerzlich selber feststellen, dass dem so ist.
Der Code stimmte, allerdings war die Sensitivity-List unvollständig und 
nach der Implementierung auf die Zielhardware traten immer wieder 
äusserst seltsame Fehler auf, die dann verschwanden, sobald die 
Sensititivty-Liste vollständig beschrieben war.

Wie erklärt ihr euch das dann?

>Ich dachte bisher (ich bin der festen Überzeugung ;-) ), dass die
>Sensitivity-List nur der Simulator benötigt und durch die explizite
>Angabe der benutzten Quellsignale die Simulation beschleunigt wird.

Jain. Der Simulator reagiert schlicht nur auf die Signale, die in der 
Sensitivity List aufgeführt sind. Wenn in einem kombinatorsischen 
Prozess ein Eingangssignal fehlt, geht die Simulation schief! Ist mir 
schon passiert.

>ich hab jetzt gerade keine Quelle an der Hand. Jedoch musste ich leider
>schon schmerzlich selber feststellen, dass dem so ist.
>Der Code stimmte, allerdings war die Sensitivity-List unvollständig und

Says who?

>nach der Implementierung auf die Zielhardware traten immer wieder
>äusserst seltsame Fehler auf, die dann verschwanden, sobald die
>Sensititivty-Liste vollständig beschrieben war.

Welcher Compiler? Welche Zielhardware? Und da das Phänomen nicht 
wirklich untersucht und erklärt wurde, würde ich das erstmal unter 
X-Files einordnen.

>Wie erklärt ihr euch das dann?

Da gibt es dutzende Möglichkeiten, von Compilerfehler (gibt es!) über 
unsauberes Design bis wasweissich.

>synchroner process? ansonsten kann das schon sein.

XST gibt ne Warnung aus wenn Signale in der Sensitivity List fehlen, 
compiliert aber dann schon richtig.

MFG
Falk

Na dann... ordnen wir es bei x-Files ein ;-)
Ich jedenfalls vervollständige seitdem meine Sensitivity-Listen.

Die Meinungen scheinen da ja eh auseinander zu gehen. Man braucht ja 
offensichtlich gar keine Sensitivity-List zur Synthese.

Meine Prozesse waren und sind jedenfalls synchron. Vielleicht war es ja 
auch nur ein Zufall, dass sich ein  schlecht gesetztes constraint einmal 
ausgewirkt hat und mit änderung der Sensitivity_List durch den erneuten 
Sytheselauf dann das Ergebnis besser war, obwohl das mit der 
Sensitivity-Liste gar nix zu tun hatte.

Whatever. Ich beschreib sie vollständig, dann motzt weder der Editor 
noch der  Compiler, noch der Simulator....

Nur bei rein kombinatorischen Prozessen müssen alle gelesenen Signale in 
die Liste, sonst wie schon erähnt nur der asynchrone (Re)set und der 
Takt für den synchronen Teil. So steht das in allen Büchern, die ich bis 
jetzt gelesen habe.
Dass man wenn man immer alle Signale reinschreibt, nicht unbedingt was 
falsch macht kann schon sein, würde mich aber grad bei synchronen 
Prozessen nur verwirren. Ein flankengesteuertes Register wird nunmal nur 
bei der Taktflanke aktiviert und nicht bei Änderung von am Datenport 
anliegenden Signalen...

Jup, da hast du recht. Allerdings beschreibe ich grundsätzlich alles 
immer mit 2 Prozessen, da dies gerade bei sehr großen Desings deutlich 
übersichtlicher ist. Vielleicht lag es ja dann auch daran.
Das Design ist natürlich nach wie vor komplett synchron, aber nur einer 
der Prozesse wird durch den Takt gesteuert. Der andere wird durch die 
Änderung der Ausgangsregister bzw. die Eingangssignale gesteuert. So 
gesehen, ein kombinatorischer Prozess, der aber in einem vollständig 
sychronen Design eingebettet ist.
Glaubt man nun der doch recht verbreiteten Aussage, dass für die 
Synthese die Sensitivity-List völlig irrelevant ist, dann würde das auch 
wiederum entgegen der Aussage von TM stehen.
Frägste also 100 Leute, bekommst 100 Antworten.

@Schlumpf

>Jup, da hast du recht. Allerdings beschreibe ich grundsätzlich alles
>immer mit 2 Prozessen, da dies gerade bei sehr großen Desings deutlich
>übersichtlicher ist. Vielleicht lag es ja dann auch daran.

Was ist daran übersichtlicher? Du sparst dir bestenfalls einmal 
einrücken nach "if rising_edge(clk) then", der Rest ist identisch.

>Glaubt man nun der doch recht verbreiteten Aussage, dass für die
>Synthese die Sensitivity-List völlig irrelevant ist, dann würde das auch
>wiederum entgegen der Aussage von TM stehen.

Welche Aussage?

>Frägste also 100 Leute, bekommst 100 Antworten.

Ich fräge nicht 100 Leute, bestenfalls frage ich sie. Fraggen tut man 
nur bei LAN-Parties oder im Netzt bei 3D Shootern. ;-)

MfG
Falk

Weisst du was Falk, ich gehöre nicht zu der Liga der Hobbybastler, die 
gerade mal wissen, wo das heisse Ende am Lötkolben ist, sondern ich 
verdiene mein Geld damit, FPGAs und ASICs zu designen, die ein bisschen 
mehr machen, als ein Lämpchen blinken zu lassen. Und das sogar ohne mir 
die fertigen IP-Cores aus dem Netz zusammenzukramen, wenn es mal ein 
bisschen komplizierter wird!

Außerdem möchte ich mir eine kleine Anmerkung zu deinen 
orthografiefaschistischen und meines Erachtens hier völlig 
unangebrachten Ergüssen erlauben:
"Einrücken" wird in deinem Fall groß geschrieben, da es sich um ein 
substantiviertes Verb handelt... Desweiteren schreibt "Netz" ohne "t" am 
Ende!
Also lass in Zuknunft solche Anmerkungen, wenn du selber deinen Senf 
nicht fehlerfrei zum Besten geben kannst

Weiterhin hast du keine Ahnung, wie meine 2-Prozess-Struktur aussieht, 
oder kannst du etwa auf meinem Monitor schauen? schnell VNC schließen

Les dir den letzten Beitrag von TM durch und überlege, ob du dabei eine 
Aussage findest. Okay, auch dieser Satz ist nicht korrekt, aber trotzdem 
kann der erste Teil (vor dem Komma) als Aussage aufgefasst werden: "Nur 
bei rein kombinatorischen....."

@ Roger:
Da hab ich mich vielleicht etwas missverständlich ausgedrückt.
Ich wollte damit sagen, dass ich die Kombinatorik und den Register-Teil, 
der sonst gerne in einem Prozess vermischt wird, grundsätzlich in 2 
Prozesse aufteile.
Du hast natürlich recht, dass eine Entitiy aus vielen Components und 
diese wiederum aus einigen solcher Prozesse besteht. Sonst wäre das 
ganze ja nicht zu stemmen.

Klar, dass gerade bei Anfängern dies auch zu fehlern führen kann, da 
sich eben noch leichter Latches einschleichen. Aber gerade bei großen 
Designs kann hier durch KONSEQUENTES Einhalten von diesen Coding Rules 
genau das verhindert werden. Jedenfalls hat sich dies bei uns in der 
Firma durchgesetz und ich weiss auch von anderen Firmen, die immer mehr 
auf diese Art der Codierung setzen. Der Code wird länger aber am Ende 
übersichtlicher

Hallo Klaus!

Ja es ist so, wie du es sagst.
Ich hab nur gesagt, dass ich einmal schlechte Erfahrungen gemacht habe, 
und diese auf eine unvollständige Sensitivity-Liste zurückführe.
Daher der Hinweis meinerseits.

Woran es letztendlich lag, das konnte ich bis heute nicht feststellen. 
Kann natürlich auch ein Fehler im Compiler sein, der genau an dieser 
Stelle zu tragen kam.

wie auch immer..

@Schlumpf

>Weisst du was Falk, ich gehöre nicht zu der Liga der Hobbybastler, die
>gerade mal wissen, wo das heisse Ende am Lötkolben ist, sondern ich

Na wie schön.

>verdiene mein Geld damit, FPGAs und ASICs zu designen, die ein bisschen
>mehr machen, als ein Lämpchen blinken zu lassen. Und das sogar ohne mir

Mee too. Dann solltest du das aber auch rüber bringen.

>Weiterhin hast du keine Ahnung, wie meine 2-Prozess-Struktur aussieht,
>oder kannst du etwa auf meinem Monitor schauen? *schnell VNC schließen*

Ja eben, weil du dich sehr unverständlich (unlogisch?!?) ausdrückst, 
versteht ausser dir dich keiner. Da ist keine Kommunikation. Ich habe 
implizit die 2 Prozessmethode angenommen, wie sie des öfteren zu finden 
ist. Kann man so machen, ich sehe trotzdem nicht den Vorteil.

>Les dir den letzten Beitrag von TM durch und überlege, ob du dabei eine
>Aussage findest. Okay, auch dieser Satz ist nicht korrekt, aber trotzdem
>kann der erste Teil (vor dem Komma) als Aussage aufgefasst werden: "Nur
>bei rein kombinatorischen....."

Zuviel zum Thema Verständlichkeit deiner Aussagen und Logik, mit der du 
dein Geld verdienst . . .

>Firma durchgesetz und ich weiss auch von anderen Firmen, die immer mehr
>auf diese Art der Codierung setzen. Der Code wird länger aber am Ende

Warum setzen die auf diese Codierung? Weils alle machen, der 
Windows-Effekt?

>übersichtlicher

Sehe ich nicht so.


@Klaus Falser

>Die ganze Diskussion würde sich erledigen, wenn die Compiler-Hersteller
>endlich ein bischen korrekter mit der sensitivity List umgingen.

Welcher geht denn nicht korrekt mit ihr um in aktuellen Versionen der 
Compiler?

MfG
Falk

@Klaus Falser

> Welcher geht denn nicht korrekt mit ihr um in aktuellen Versionen der
> Compiler?

>Von Altera weiss ich nichts, aber XST von Xilinx gibt beiprocess(Clk, >Reset, A) 
is
>begin
>   if Reset = '1' then
>      C <= '0';
>   elsif rising_edge(Clk) then
>      C <= A or B;
>   end if;
>end process;

>nicht einmal eine Warnung aus, obwohl das A in der sensitivity list
>überflüssig ist.

Warum sollte er? Ist doch alles im grünen Bereich.

>Beiprocess(A) is
>begin
>   C <= A or B;
>end process;

>wird einfach eine Warnung ausgegeben und eine Oder-Funktion generiert,
>obwohl Simulation und Synthese dann nicht übereinstimmen.

Finde ich auch vollkommen korrekt. Es wird gewarnt und gleichzeitig 
richtig synthetisiert. Was willst du mehr? Und der Simulator (Modelsim) 
meckert nicht, weil es zulässig, in Testbenches sogar sinnvoll ist, 
einige Eingangssignale nicht in die Sensitivity List zu schreiben.

MfG
Falk

Ja Falk, is recht... ich bin dann mal raus hier...

Wieso muss es denn immer in Streit ausarten? Gerade beim Thema 
Codingstyle gibt es zigtausend Varianten, über die man unterschiedlicher 
Meinung sein kann. Wenn ich mir überlege, was da zB. während meiner 
Diplomarbeit vorgeschrieben wurde... Da war mir bei einigen Sachen auch 
nicht klar warum & wieso.
Generell ich festzuhalten, dass man sich mindestens an den Standard 
halten sollte, den VHDL ansich mitbringt. Und da sind halt die 
Sens.listen eins der Probleme, wo viele Anfänger drüber stolpern...
Also nix für ungut ;-)

Ja T.M., das find ich auch schade, dass das hier so läuft.
Aber ich hab den Eindruck, dass es hier Menschen gibt, die sicher ein 
hervorragendes Fachwissen mitbringen, aber leider ihre Selbstbestätigung 
darin sehen, den anderen mitzuteilen, wie dämlich sie doch sind, dass 
sie sich nicht richtig ausdrücken könne, dass sie keine Ahnung haben und 
die jeden Satz im Detail zerpflücken und nur danach aus sind, 
irgendwelche Fehler zu suchen, die den anderen unterlaufen sein könnten.
Und wenn eine ergänzende Anmerkung meinerseits, dass ich eine 
2-Prozess-Methode verwende, und vielleicht die die Ursache für das 
fragliche Verhalten der Syntehse sein könnte, als Aufhänger dafür 
genommen wird, erneut einen Punkt aufzureissen, da ich nicht vollständig 
beschrieben habe, WIE diese Methode bei mir aussieht, dann kann man in 
JEDEM Beitrag etwas finden, das man dem anderen als Inkompetenz 
vorhalten kann.

Sicher bin ich nicht allwissend, aber das kann wohl keiner von sich 
behaupten, auch wenn er es gerne wäre. Und spätestens dann, wenn man die 
Tippfehler herauspickt, um dem anderen zu zeigen, wie blöd er doch ist, 
macht es echt keinen Spass mehr.

Da ist dann auch keine Diskussion mehr möglich. Denn wer nicht verstehen 
will, wird nicht verstehen. Ich meine, Deine "Aussage" war, abgesehen 
von ein paar fehlenden Kommas, durchaus klar formuliert. Und ich denke 
auch, dass mein Bezug auf deine Aussage durchaus verständlich formuliert 
war...
Aber offensichtlich ist die Tatsache, dass ich Dich verstehe, nach 
Falk´s Auffassung ein klares Zeichen dafür, dass ich doch ein deutliches 
geistiges Defizit aufweise. (vgl. Beitrag von 16:50) Oder hat er sich da 
vielleicht am Ende etwas unklar ausgedrückt, so dass man die Aussage 
falsch interpretieren musst????

Na ja, mir ist das jedenfalls zu dumm, mich auf dem Niveau weiter zu 
unterhalten.

Ja ja, und wieder kommt die Überheblichkeit Falks zum Vorschein. Ich 
finde das wirklich zum ko...

> aber leider ihre Selbstbestätigung
> darin sehen, den anderen mitzuteilen, wie dämlich sie doch sind,

FULL ACK!

Also ich weiss nicht so richtig, ob es einen Sinn macht, nach diesen 
Wortmeldungen noch einen sachlichen Einwurf zu machen, aber ich hätte 
doch noch gern auf Falk geantwortet.
Bei meinen 2 Beispielen hast Du dem Compiler recht gegeben.

Mein 1. Beispiel war ein FF mit einem Oder-Gatter am Eingang.
Da die Synthese nichts anderes machen soll, als aus der VHDL 
Beschreibung eines FF eben ein FF in HW zu generieren, soll meiner 
Meinung nach nur eine korrekte Beschreibung eines FF akzeptiert werden. 
Dazu gibt es auch IEEE 1076.6, welche Strukturen vorgibt die ein 
Compiler erkennen soll.
Zumindest sollte der Compiler eine Warnung ausgeben.
Aber das ist meine Meinung, du hast eine andere.

An meinem 2. Beispiel aber kann man erkennen, welche Fehler ein Compiler 
macht, der die Sensititity List autonom ergänzt.
Wenn ich mich nicht komplett täusche, existiert nämlich (zufällig) eine 
korrekte Umsetzung des VHDL Codes mit einem an der fallenden Flanke 
triggerndem FF.

   |-------|
   |   +-------+
   |   |  Set  |
   |   |       |
A -+--o|>     Q|------- C
       |       |
       |       |
B -----|D      |
       +-------+

Dass der Compiler die Liste selbständig ergänzt, nur eine Warnung 
ausgibt und eine HW generiert, welche seiner Meinung nach richtig ist, 
ist nach meiner Meinung nach Fehler.
Der Compiler sollte stoppen und den Programmierer zwingen, die Liste 
richtigzustellen. So viel Arbeit ist das nicht.
Das bestehende Verhalten ist ein Nachteil weniger für die VHDL-Experten 
(diese würden so einen Code niemals schreiben), sondern für die 
VHDL-Anfänger, welche die Meldung (unter vielen) übersehen und sich dann 
wundern, daß das Programm, welches eben in der Simulation so wunderbar 
funktioniert hat, in HW überhaupt nicht läuft.

Ende, Klaus

@Klaus Falser

>Bei meinen 2 Beispielen hast Du dem Compiler recht gegeben.

>Mein 1. Beispiel war ein FF mit einem Oder-Gatter am Eingang.

Genau.

Da die Synthese nichts anderes machen soll, als aus der VHDL
Beschreibung eines FF eben ein FF in HW zu generieren, soll meiner
Meinung nach nur eine korrekte Beschreibung eines FF akzeptiert werden.
Dazu gibt es auch IEEE 1076.6, welche Strukturen vorgibt die ein
Compiler erkennen soll.

Er hat doch ein FlipFlop mit ODER am Eingang generiert, oder? Wo ist das 
Problem?

Wenn ich in C schreibe A = B + C -B; gibts doch auch keine Warnung dass 
B rausfliegt. JEDEN Pipifax als Warnung auszugeben wird irgendwann 
unübersichtlich und schwierig, denn hellsehen kann ein Compiler auch 
nicht.

>Zumindest sollte der Compiler eine Warnung ausgeben.
>Aber das ist meine Meinung, du hast eine andere.

So siehts aus ;-)

>An meinem 2. Beispiel aber kann man erkennen, welche Fehler ein Compiler
>macht, der die Sensititity List autonom ergänzt.
>Wenn ich mich nicht komplett täusche, existiert nämlich (zufällig) eine
>korrekte Umsetzung des VHDL Codes mit einem an der fallenden Flanke
>triggerndem FF.

Ahhh verstehe. Aber Gott sei Dank sind VHDL Compiler nicht so auf dem 
Murks-Trip wie viele Digitaldesigner vor vielen Jahren (und einige heute 
noch). Die sind auf solides synchrones Design getrimmt und machen aus 
deinem 2. Beispiel schlicht und ergreifend ein ODER. Mischungen mit SET 
und CLK sind Murks aus alten TTL Zeiten. Tonne auf, ALtlast rein, Tonne 
zu.

   |-------|
   |   +-------+
   |   |  Set  |
   |   |       |
A -+--o|>     Q|------- C
       |       |
       |       |
B -----|D      |
       +-------+

>Dass der Compiler die Liste selbständig ergänzt, nur eine Warnung
>ausgibt und eine HW generiert, welche seiner Meinung nach richtig ist,
>ist nach meiner Meinung nach Fehler.
>Der Compiler sollte stoppen und den Programmierer zwingen, die Liste
>richtigzustellen. So viel Arbeit ist das nicht.

Der Compiler warnt, das reicht IMHO. Wer alle Compilerwarnungen in den 
Wind schlägt muss eben durch Schmerz lernen.

>(diese würden so einen Code niemals schreiben), sondern für die

Naja, es gibt genug "Experten" die ganz schönen Murz zusammenschreiben.

>VHDL-Anfänger, welche die Meldung (unter vielen) übersehen und sich dann
>wundern, daß das Programm, welches eben in der Simulation so wunderbar
>funktioniert hat, in HW überhaupt nicht läuft.

In diesem Fall ist es wohl eher umgekehrt, die Simulation läuft nicht, 
aber die Hardware. Ist ne wichtige Lektion für Entwickler ;-)

MfG
Falk

@Schlumpf

>Ja Falk, is recht... ich bin dann mal raus hier...Antwort

Was ist los? Kritikunfähig?

@T.M.

>Wieso muss es denn immer in Streit ausarten? Gerade beim Thema

Streit ist elementaer Bestandteil des Leben. Und wenn er halbwegs 
sachlich durchgeführt wird auch produktiv.

>Codingstyle gibt es zigtausend Varianten, über die man unterschiedlicher
>Meinung sein kann. Wenn ich mir überlege, was da zB. während meiner

Sicher. Aber dann kann ich klare Argumente dafür und dagegen aufführen, 
und die besseren Argumente gewinnen die Streitfrage. Das müssen aber 
auch die Leute mit den schlechtere Argumenten akzeptieren, ohne die 
beleidigte Leberwurst zu spielen. Thema Sportsgeist.

>Diplomarbeit vorgeschrieben wurde... Da war mir bei einigen Sachen auch
>nicht klar warum & wieso.

Deshalb fragt man. Und wenn dann nur kommt, "das war immer so" oder 
"weils besser ist" oder "weils alle machen" sind das zumindest schwache 
Erklärungen/Argumente.

@Schlumpf

>irgendwelche Fehler zu suchen, die den anderen unterlaufen sein könnten.

Und ich finde es schade, dass Leute bei Kritik sofort die beleidigte 
Leberwurst spielen. Und Humorlosigkeit ist auch sehr bedauerlich.

>>Frägste also 100 Leute, bekommst 100 Antworten.
>Ich fräge nicht 100 Leute, bestenfalls frage ich sie. Fraggen tut man
>nur bei LAN-Parties oder im Netzt bei 3D Shootern. ;-)

http://de.wikipedia.org/wiki/Smiley

>fragliche Verhalten der Syntehse sein könnte, als Aufhänger dafür
>genommen wird, erneut einen Punkt aufzureissen, da ich nicht vollständig

Niemand hat einen Punkt aufgerissen. Ich habe gefragt was die 2 
Prozessmethode an Vorteilen bringen soll. Und die simple Aussage "ist 
übersichtlicher" hab ich schlicht in Frage gestellt.

>Sicher bin ich nicht allwissend, aber das kann wohl keiner von sich
>behaupten, auch wenn er es gerne wäre. Und spätestens dann, wenn man die

Doch, es gibt einen. Der ist Bayer und wohnt im Vatikan ;-)

>Tippfehler herauspickt, um dem anderen zu zeigen, wie blöd er doch ist,
>macht es echt keinen Spass mehr.

http://de.wikipedia.org/wiki/Humor

>von ein paar fehlenden Kommas, durchaus klar formuliert. Und ich denke
>auch, dass mein Bezug auf deine Aussage durchaus verständlich formuliert
>war...

Das denkst du, was aber noch lange nicht bedeutet, dass andere das 
ebenso sehen. Wenn scih zwei Chinesen auf chinesisch unterhalten 
verstehen die sich prächtig, aber als Nichtchinese steht man auf dem 
Schlauch.

MfG
Falk

Hallo Leuten

Ich habe nicht erwartet daß mein klein Beitrag so viele Anregungen 
bewirkt, ich danke alle für die Antworten an die Fragen (FALK-:)) ich 
habe aber noch eine Problem(ich bin hier um zu lernen). Ich will ein 
Sinus Schwingung von 54,68 kHz erzeugen. Ich habe die Core Generator von 
Xilinx benutz um ein DDS zu haben. Am Ausgang mein DDS ist ein 6 bits 
Daten.

1- Ist der korrekte weg um so ein Schwingung zu erzeugen?
2- Wie übergibt ich die 6 bits  an mein DAC wenn er nur seriellen Daten 
an der SPI_MOSI akzeptiert?

PS: Sorry für mein Deutsche Sprache!

Mit freundlichen Grüßen

Klar Falk, Humor ist, wenn DU dich über andere lustig machen kannst... 
das haben ich und einige andere hier schon verstanden.
Doch wer austeilt, sollte auch einstecken können.
Und zu deiner persönlichen Weiterbildung werde ich den Satz von T.M. 
jetzt extra hier für dich aus der Idiotensprachen, wie T.M. und ich sie 
sprechen, in die Falk-Sprache übersetzen:

"Nur bei rein kombinatorischen Prozessen müssen alle gelesenen Signale 
in
die Liste, sonst #KOMMA# wie schon er#w#ähnt #KOMMA# nur der asynchrone 
(Re)set und der Takt für den synchronen Teil."

Heisst:
Asynchrone Prozesse: Alle Signale in Sens.Liste
Synchrone Prozesse: Nur Reset und CLK in Sens.Liste

Und ja, das denke ich, dass das zu verstehen ist, auch wenn zwei Kommas 
fehlen.

Ich hoffe, dir damit von dem Schlauch runtergeholfen zu haben
;-)  <- Smilie -> HUMOR

Weiterhin hast du bei deiner Jagd auf Unzulänglichkeiten anderer nicht 
erkannt, dass der Kern der Diskussion nicht die 2-Prozess-Methode und 
deren Vor- und Nachteile ist, sondern es um die Frage ging, ob die Wahl 
der Signale in der Sens.Liste Auswirkungen auf das Syntheseergebnis 
haben oder nicht. Und ich suchte nach dem FEHLER (ja, du liest richtig), 
den ICH gemacht haben könnte, dass es bei mir in diesen einen Fall 
offensichtlich doch eine Auswirkung hatte, weil es ja nach der 
einhelligen Meinung der Beteiligten, keine Auswirkung haben dürfte. DAS 
WAR SELBSTKRITIK!

http://de.wikipedia.org/wiki/Selbstkritik

Aber wahrscheinlich liegt das auch daran, dass ich chinesisch spreche. 
Gott sein dank sind noch einige andere Chinesen in diesem Forum.

Aber hier ist jede weitere Diskussion Nonsens.

Schöne Grüße von dem chinesisch sprechenden, geistig minderbemittelten, 
humorlosen, beleidigten und kritikunfähigen Schlumpf

@jojo

>1- Ist der korrekte weg um so ein Schwingung zu erzeugen?

Ja.

>2- Wie übergibt ich die 6 bits  an mein DAC wenn er nur seriellen Daten
>an der SPI_MOSI akzeptiert?

Du brauchst ein Modul, das die 6 Bit parallel in einen seriellen, SPI 
kompatiblen, Datenstrom umsetzt. Ist im wesentlichen ein Schieberegister 
und eine State Machine.

>PS: Sorry für mein Deutsche Sprache!

Kein Problem, du bist ja kein Muttersprachler. Wo kommst du her? 
Frankreich oder Belgien? (Wegen "conteur").

MfG
Falk

-:)aus Frankreich Falk,

Mit den Schieberegister ist mir klar aber der state Machine nicht so 
ganz! also ich probiere es

mfg

hi

wäre es nicht möglich einfach mit ein Parallel-In, Serial-Out shift 
register zu realisieren?

@jojo

>wäre es nicht möglich einfach mit ein Parallel-In, Serial-Out shift
>register zu realisieren?

JAIN. Es kommt da auf ein paar Details an, wie der DAC die Daten haben 
will.

MfG
Falk

Hallo zusammen!

Ich habe wieder eine Problem! Ich versuch ein Sinus von 54,70khz mit der 
core Generator DDS 5.0 zu generieren, alle Parameter wurde gegeben und 
das Signale mit eine 6 bits parallele DAC konvertiert. Auf den 
Oscilloscope ist meine Sinus zwar mit die richtige Frequenz aber mit 
eine Phase Sprung von ungefähre 180° . wie kann ich das korrigieren? 
Liegt an die gegebenen Parameter in DDS oder an mein DAC?

Mit freundlichen Grüßen

@jojo

>Oscilloscope ist meine Sinus zwar mit die richtige Frequenz aber mit
>eine Phase Sprung von ungefähre 180° . wie kann ich das korrigieren?

???? Was meinst du mit Phase Sprung?

MFG
Falk

        '-           -'
        '  -        - '
        '   -      -  '
        '    -    -   '
        '     -  -    '
--      '      --     '
-  -    '             '
    -   '             '
     -  '
      - '
       -'

So ungefähre sieht mein Signal aus!

Könnten verdrehte Bits sein. MSB und LSB vertauscht?

MfG
Falk

@jojo: Mag Dein DAC die Bits vielleicht als Zweier-Komplement? Invertier 
mal das MSB.

Rick

Da liegt wahrscheinlich nicht das Problem weil ich habe schon LSB und 
MSB getauscht und kommt ein ganz komische Signal raus.

@jojo

>Da liegt wahrscheinlich nicht das Problem weil ich habe schon LSB und
>MSB getauscht und kommt ein ganz komische Signal raus.

Nicht nur MSB und LSB tauschen, den gesamten Vektor umdrehen.
Und wenn es wirklich an Einer-Zweierkomplement liegt, musst du das 
umrechnen.

Zweierkomplement in Einerkomplement

Wert_einer = Wert_zweier + 32  (bei 6 Bit)

MFG
Falk

Ich habe mich vielleicht falsch ausgedruckt es wurde schon den gesamten 
Vektor umgedrehen!

Dan mach ne Simulation und schau dir die Werte an. Vielleicht gibts ein 
Problem mit der DDS.

MFG
Falk

Der Core Generator habe ich verlassen und selbe ein Sinus erzeugt über 
ein Art look up table  wie folge:

process(entre)
begin

if CLKL'event and CLKL = '1'  then

case entre is

when "000" => entredeux <= "100000";--32
when "001" => entredeux <= "110111";--55
when "010" => entredeux <= "111111";--64
when "011" => entredeux <= "110111";--55
when "100" => entredeux <= "100000";--32
when "101" => entredeux <= "001001";--9
when "110" => entredeux <= "000000";--0
when "111" => entredeux <= "001001";--9


when others => entredeux <=  "100000";--32

end case;

pinout <= entredeux;

end if;

end process;

Ich will aber dieser Sinus von 30khz mit anderen Sinus von 200 Hz 
modulieren. Der zweite Sinus erzeuge ich in den gleiche Art und weise. 
Dazu muß ich sagen, Für die Frequenzen habe ich ein Frequezteiler 
benutz. Mein frage ist jetzt. Wie moduliert ich beide Signale? Reich ein 
Multiplikation von beide 6 Bits Vectore? normale weise soll ich ein 
vierquadranten multiplizierer benutzen hat jemand ein Beispiel davon?

MFG

@jojo

>benutz. Mein frage ist jetzt. Wie moduliert ich beide Signale? Reich ein
>Multiplikation von beide 6 Bits Vectore? normale weise soll ich ein

ja.

a <= b*c;

MfG
Falk

Danke Falk

Kann ich aber dieser Berechnung synchronisieren zum Beispiel mit

process (clock)
begin
   if clock='1' and clock'event then
      output <= input1 * input2;
   end if;
end process;

wenn ja mit welchen Clock muß ich synchronisieren weil in mein Programme 
sind zwei clockteiler und der Haupt clock zu Verfügung! Mein Modulation 
scheint nicht richtig ich vermute ein clock Problem!

MFG

@jojo

>Kann ich aber dieser Berechnung synchronisieren zum Beispiel mit

Ja.

>wenn ja mit welchen Clock muß ich synchronisieren weil in mein Programme
>sind zwei clockteiler und der Haupt clock zu Verfügung! Mein Modulation

Du musst alle Prozesse mit einem Takt laufen lassen. Wenn du einige 
langasmer takten möchtest, dann musst du Clock enables benutzen, NICHT 
geteilte Takte.

Beispiel

-- Clock enable genarator

process (clock)
begin
   if clock='1' and clock'event then
     cnt = cnt+1;
     if cnt =0 then
       ce_16 <= '1';
     else
       ce_16 <= '0';
     end if;
   end if;
end process;

-- langsam getakteter Prozess

process (clock)
begin
   if clock='1' and clock'event then
     if ce_16 ='1' then
       output <= input1 * input2;
     end if;
   end if;
end process;

MFG
Falk

Wo ist denn der Unterschied zwischen Clock enable generator und 
Taktteiler ?
Nur das die Ausgänge beim CEG nicht nochmal auf FF geführt sind ?

Grüße

Dirk

@Dirk

>Wo ist denn der Unterschied zwischen Clock enable generator und
>Taktteiler ?

http://www.mikrocontroller.net/articles/Taktung_FPGA/CPLD

>Nur das die Ausgänge beim CEG nicht nochmal auf FF geführt sind ?

Nein, es ist der Skew (Verschiebung) zwischem dem ungeteilten Takt und 
dem geteilten. Wenn in der Schaltung Teile mit dem ungeteilten und 
welche mit dem geteilten laufen kommt es bei der Datenübergabe zwischen 
den beiden Taktblöcken zu Problemen.

MfG
Falk

Hallo Leute

Ich bin wieder, wie werden die flisskoma Zahlen in VHDL behandeln als 
Beispiel, ich deklariere ein Signal wie folgende:

Signal omega: real;

when "00000" => omega <= "1.8";

und habe ein Fehler der so aussieht: „Type of omega is incompatible with 
type of 1.8.“

Und ich will nachher Berechnungen in mein Programm mit flisskoma Zahlen 
machen

Hilfe

@Falk
Vielen Dank !!!
Grüße

Dirk

Ich formuliert andere, ich will so ein Berechnung machen,

omega von type real( also flisskoma zahl)

lamda = 4* omega

ich will mein Ergebnis am ende in binäre umwandeln. Wie mache ich die 
Berechnung   4*omega  welche Bibliotheque brauche ich?

Wie wandle ich mein Ergebnis Lamda in binäre(10001) um?

Viele danke für Hilfe.

Die meisten VHDL Compiler unterstützen nur Integerzahlen. Fliesskomma 
wird meist nur für die Simulation unterstützt/genutzt.

MfG
Falk

Hallo

Warum erhalte ich so ein Fehler Meldung?

/ can not have such operands in this context.
* can not have such operands in this context.

Wenn ich dieser Berechnungen machen?

constant A : integer := 4;
constant B : integer := 2;

pinout_sinus ist auc integer.

I <= A*(pinout_et_sinus/B);
J <= A*(pinout_et_sinus);

Ich benutze die Bibliotheque

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

Ich arbeite mit ISE von Xilinx.

Viele dank hilfe

mfg
JoJO