Hallo zusammen, Vorweg: Meine VHDL-Kenntnisse halten sich stark in Grenzen, da ich komplett neu in Welt der Hardwarebeschreibung bin! Zu meinem Leidwesen muss ich jedoch ein Projekt bearbeiten, welches über einen kurzen Tastendruck LEDs ein- bzw. ausschalten, und einen 1s langen Druck der selben Taste die LEDs dimmen soll (heller und dunkler im Wechsel). Insgesamt soll sich die Helligkeit zwischen 8 Stufen in 0,5s Schritten verändern. Nun zu meinem Problem: Mit dem angehängten Programm komme ich nicht einmal über die Synthese hinweg, da mir der Error "Xst:827" ausgespuckt wird. Gesamter Fehlercode: ERROR:Xst:827 - "H:/XXXX" line 60: Signal change_pwm cannot be synthesized, bad synchronous description. The description style you are using to describe a synchronous element (register, memory, etc.) is not supported in the current software release. Nach dem Durchlesen etlicher von Google ausgespuckten Seitenvorschlägen bin ich lediglich bei der Fehlerbeschreibung einen Schritt weiter. Denn der Fehler tritt wohl dann auf, wenn ein FF mit 2 unterschiedlichen Takten angesteuert wird. -> Hilft mir nur leider programmtechnisch gar nicht weiter, da ich KOMPLETT auf dem Schlauch stehe und nicht weiß wie ich mein Programm dahingehend verändern soll, dass es endlich seinen Dienst erfüllt. Hoffentlich kann mir von euch jemand weiterhelfen und oder Denkanstöße liefern!! Ich arbeite mit dem "Xilinx ISE Project Navigator" und einem "Spartan-3A/3AN FPGA Starter Kit Board". Vielen Dank schon mal!! :)
Wie würdest Du denn das Problem ohne VHDL lösen? Nur mit digitalen Schaltkreisen. Wenn Du Dir das überlegt hast, kommt die Umsetzung mit VHDL. Duke
@ Michael Mü (no_rt) >Meine VHDL-Kenntnisse halten sich stark in Grenzen, da ich komplett neu >in Welt der Hardwarebeschreibung bin! Naja. >Zu meinem Leidwesen muss ich jedoch ein Projekt bearbeiten, welches über >einen kurzen Tastendruck LEDs ein- bzw. ausschalten, und einen 1s langen >Druck der selben Taste die LEDs dimmen soll (heller und dunkler im >Wechsel). Insgesamt soll sich die Helligkeit zwischen 8 Stufen in 0,5s >Schritten verändern. Das ist eine logischer Ablauf. Den kann man mit verschiedenen Methoden praktisch realisieren. VHDL ist nur eine Möglichkeit, und dazu nicht mal die sinnvollste. >der Fehler tritt wohl dann auf, wenn ein FF mit 2 unterschiedlichen >Takten angesteuert wird. Tja, ist wohl so. Braucht auch keiner. >-> Hilft mir nur leider programmtechnisch gar >nicht weiter, da ich KOMPLETT auf dem Schlauch stehe und nicht weiß wie >ich mein Programm dahingehend verändern soll, dass es endlich seinen >Dienst erfüllt. Ohne ein Minimum an Grundlagenwissen wirst du das Problem nicht lösen. Du brauchst einen Takt für dein System. Und zwar einen untypisch niedrigen, vielleich 100 Hz. Den muss man mit einem Teiler aus dem anliegenden Takt ableiten, meist haben die FPGA Boards so um die 50 MHZ und mehr. Deine Taste muss entprellt werden, das kann man im FPGA machen. Dann brauchst du eine statemachine, welche die Logik enthält, um in Stufen hoch und runter zu dimmen. Und der Dimmer selber braucht eine PWM Logik. Alles in Allem viel Arbeit, wenn man nahezu keine Grundlagen hat.
Danke für die schnellen Antworten! Ich bin mir durchaus bewusst, dass man diese Problemstellung auch auf anderem Wege lösen kann. Leider ist die Nutzung von VHDL eine Vorgabe. Welche Komponenten für die Umsetzung benötigt werden ist mir auch bekannt. Zumindest hatte ich gehofft, dass meine im Ausgangsbeitrag angefügte Datei z.B. eine PWM enthält, welche der Aufgabe entsprechend 8 Schritte hoch bzw. runter zählt. ;) Die Lösung meines Problems sehe ich leider auch nicht in der Entprellung des Tasters..
Michael Mü schrieb: ... > Die Lösung meines Problems sehe ich leider auch nicht in der Entprellung > des Tasters.. Stimmt, das ist dein geringstes Problem... Was mir so beim drueberfliegen aufgefallen ist:
1 | USE IEEE.STD_LOGIC_1164.ALL; |
2 | USE IEEE.STD_LOGIC_ARITH.ALL; |
3 | USE IEEE.STD_LOGIC_UNSIGNED.ALL; |
4 | USE IEEE.NUMERIC_STD.ALL; |
Wer bringt euch so einen SCHEISS bei? Such' mal nach sowas wie 'std_logic_arith obsolete'...
1 | led_control: process(CLK) |
2 | variable clk_cnt : integer range 0 to 50000000; |
3 | variable pwm_cnt : integer range 0 to 1000; |
4 | variable int_cnt_0 : integer range 0 to 7; |
5 | variable direction : integer range 0 to 1; |
6 | variable change_pwm : integer range 0 to 1; |
7 | variable dimm : integer range 0 to 1; |
da hatte ich schon fast aufgegeben... Such' mal nach sowas wie 'variable vs signal'... Ich wuerde dir echt raten, diese ganzen Signale auch als Signale zu deklarieren. Und zwar nicht als 'integer' (sind nicht per se schlecht), sondern als std_logic(_vector) und unsigned. Dann kriegst du auch eher ein Gefuehl, was du da wirklich baust. Und einen Simulator hat dein Design noch nie gesehen, stimmts? Weil ohne Initialisierung schmeisst der Simulator nur 'U' und 'X'... Zu deiner eigentlichen Fehlermeldung: In deinem (einzigen) 'process' hast du x-mal 'if rising_edge...'. Und du setzt deine Signale in 2 verschiedenen 'if rising_edge...' Bloecken. Dein FPGA hat aber nur FFs, die einen Takteingang haben. Wie soll das also auf reale HW abgebildet werden? Schreib' das ganze mal mit mehreren 'process ...' und in jedem 'process' nur ein dickes, fettes, 'if rising_edge (clk) then' (und nix mit 'and xxx=0' oder so. Und dann simuliere das ganze mal. Du kannst dir da ja jedes einzelne Signal genau anschauen und entscheiden, ob das so laeuft wie du dir das vorstellst. Weiter unten im Code habe ich dann nicht mehr nachgeguckt... PS: Der Code sieht aus wie Software, nicht wie eine Hardwarebeschreibung
berndl schrieb: > da hatte ich schon fast aufgegeben... Ich komme da schon ins Stocken:
1 | -- Necessary Header Files
|
Hoppala, "Header Files", ein C-Programmierer... Das ist auch nicht schlecht:
1 | led_control: process(CLK) |
2 | :
|
3 | begin
|
4 | if (rising_edge(CLK) and BTN = '1') then |
5 | change_pwm := 1; |
6 | :
|
7 | if (rising_edge(CLK) and BTN = '0') then |
8 | change_pwm := 0; |
9 | :
|
10 | if (rising_edge(CLK) and dimm = 1) then |
11 | :
|
12 | end process; |
Aber man muss dem Synthesizer ja auch mal eine anständige Aufgabe geben... Michael Mü schrieb: > Denn der Fehler tritt wohl dann auf, wenn ein FF mit 2 unterschiedlichen > Takten angesteuert wird. Was sollte das auch für ein Bauteil sein, das sowas könnte? Aber es ist ja nicht mal ein unterschiedlicher Takt, sondern eine ziemlich verbastelte und hirnige Beschreibung um den Clock-Enable herum. http://www.lothar-miller.de/s9y/archives/1-Clock-Enable-in-einer-ISE-VHDL-Beschreibung.html berndl schrieb: > Und dann simuliere das ganze mal. Die Simulation ist falsch, denn die Sensitivliste ist unvollständig, weil BTN und dimm fehlen. Blöderweise kannst du aber eine Variable nicht in die Sensitivliste aufnehmen... Aber ich würde auch mal einfach sagen, dass man diese Aufgabe tadellos simulieren kann. Und dass eine fehlerfreie Simulation bei diesem Design hier vor dem Synthesebutton kommen muss. Der Simulator ist der primäre Hardwaredebugger.
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.