Warum ist die Ausgaben mein Zaehler an die LED's nicht richtig? liegt es an die takt Frequenz mein board oder ist etwas in mein code falsh? architecture Behavioral of zaehler is signal conteur: std_logic_vector(7 downto 0) :="00000000"; begin process (clk, reset,push) begin if reset='1' then conteur <= (others => '0'); elsif clk='1' and clk'event then if push ='1' then if count_direction ='1' then conteur <= conteur + 1; else conteur <= conteur - 1; end if; end if; end if; end process; led <= conteur; end Behavioral; mfg JOJO
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.
Schlumpf wrote: > 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!!! nicht wirklich. synchrone prozesse die auf eine taktflanke reagieren - so wie bei T.M. und Falk - reicht es den clock in die sensitivity list zu nehmen, und wenns noch einen asynchronen reset hat - so wie bei T.M. - dann brauchts diesen auch noch, thats it! Den async. reset kann man sich in den meisten faellen jedoch sparen. Cheers, Roger
Hallo. @Schlumpf: >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!!! Bist Du Dir da sicher und hast Du eventuell eine Quelle wo man das nachlesen kann? 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. Gruß DaMicha.
@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?
Schlumpf wrote: > ich hab jetzt gerade keine Quelle an der Hand. Jedoch musste ich leider > schon schmerzlich selber feststellen, dass dem so ist. synchroner process? ansonsten kann das schon sein. Cheers, Roger
>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
Falk wrote: >>synchroner process? ansonsten kann das schon sein. > > XST gibt ne Warnung aus wenn Signale in der Sensitivity List fehlen, > compiliert aber dann schon richtig. ditto mit QuartusII. Cheers, Roger
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
Schlumpf wrote: > 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. Kann man sich auch drueber streiten. Bei mir haben groessere entities deutlich mehr als zwei Prozesse. > 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. mag funktionieren, aber grad in diesem Forum gibts ab und an Anfaenger die Probleme mit Zaehler und Signalen aus ihrer statemachine haben, weil diese eben mit dem synchron-asynchron tandem falsch aufgebaut ist. Der synchron only ansatz ist hingegen fast(!) idiotensicher. Cheers, Roger
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
Lieber Schlumpf, wenn Du Dein Geld mit VDHL-Designs verdienst (als ein Profi bist), dann solltest Du den Leuten hier es eigentlich richtig beibringen. Und das heißt : - Synchrone Prozesse (also die mit (rising_edge() ..) bekommen nur Takt und Reset in die sensitivity list. Im Gegensatz zu dem weiter oben behaupteten, verringert eine Angabe aller Signale die Simulationsgeschwindigkeit. - Kombinatorische Prozesse brauchen alle Signale. Die ganze Diskussion würde sich erledigen, wenn die Compiler-Hersteller endlich ein bischen korrekter mit der sensitivity List umgingen. Grüße Klaus
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
> Welcher geht denn nicht korrekt mit ihr um in aktuellen Versionen der > Compiler? Von Altera weiss ich nichts, aber XST von Xilinx gibt bei
1 | process(Clk, Reset, A) is |
2 | begin
|
3 | if Reset = '1' then |
4 | C <= '0'; |
5 | elsif rising_edge(Clk) then |
6 | C <= A or B; |
7 | end if; |
8 | end process; |
nicht einmal eine Warnung aus, obwohl das A in der sensitivity list überflüssig ist. Bei
1 | process(A) is |
2 | begin
|
3 | C <= A or B; |
4 | end process; |
wird einfach eine Warnung ausgegeben und eine Oder-Funktion generiert, obwohl Simulation und Synthese dann nicht übereinstimmen. Klaus
@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
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. Es gibt bei Modelsim in der modelsim.ini den Switch: CheckSynthesis der wenn er auf 1 gesetzt wird dafür sorgt, dass vcom eine Warnung ausgibt bzw. aussteigt, falls eine Sensitiv-Liste nicht vollständig ist oder unnötige Signale enthält. Leider fallen einem die Sensitivlisten immer mal wieder auf die Füße. Gerade wenn man mal ein weiters Signal im Process auswertet, bzw. eins nicht mehr benötigt. Konsequenterweise müsste es wenigstens (bei mir die ISE) ein Switch geben, der zu einem Abbrechen der Synthese führt. Gruß DaMicha.
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!
@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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.