Hallo Leute, Ich habe ein kleines Problem!! Und zwar muss ich eine bestimmte Bitfolge [DATA_IN] im Manchester-Code kodieren. Dabei kann die Pulsbreite [PULSE_W] des Signals (also der kodierten Datenbits) verändert werden. Auch die Anzahl der Ausgangsbits kann beschränkt werden (durch [BIT_CNT]). Wie die Manchester-Kodierung funktioniert ist mir klar. Ich habe 2 Signale ([clock_reference] und [data_reference]) die durch eine XOR Verknüpfung zusammengeführt werden ([DP]). [clock_reference] ist ein Takt mit der halben Pulsbreite ([PULSE_W]/2) und [data_reference] mit der Pulsbreite [PULSE_W]. Es gibt auch die Möglichkeit ein Paritätbit zu erzeugen wenn [BIT_CNT] = 9 ist. Das Paritätbit ist die XOR Verknüpfung aller Datenbits. In der Simulation sieht (wie üblich) alles wunderschön aus... Aber in der Praxis ist es der totale Müll. Könnte mal jemand auf den Code schauen und auffälliges melden?? Ich würde euch sehr dankbar sein!!! Gruss, DeLUru
Deine CounterClock und CounterData Prozesse sind z.B. nicht synthese-konform geschrieben. Ein getakteter prozess soll die Form haben.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Bei Dir befindet sich der Takt auch im Reset-Pfad, das geht in Hardware nicht.
Gast
#482922
@Klaus Falser >Deine CounterClock und CounterData Prozesse sind z.B. nicht >synthese-konform geschrieben. Ach so? >Bei Dir befindet sich der Takt auch im Reset-Pfad, das geht in Hardware >nicht. Schon mal was von SYNCHRONEM Reset gehört? Geht wunderbar. MfG Falk
Gast
#482928
Allderdings geht das nicht > CounterClock : process( CLK_IN, start_clk_counter ) > begin > if ( CLK_IN = '0' and clk_counter = 0 ) then > clk_counter <= clk_ref_counter; > elsif ( CLK_IN'event and CLK_IN = '1' ) then > if ( start_clk_counter = '1' ) then > clk_counter <= clk_counter - 1; > else > clk_counter <= clk_ref_counter; > end if; > end if; > end process CounterClock; Ein Taktsignal ist nur Takt signal ist nur Taktsignal . . . MfG Falk
@Falk Was soll Dein Kommentar? Ich habe nur behauptet, daß es so wie es geschrieben wurde nicht geht. Etwas anderes hast Du auch nicht geschrieben.
Hallo @all, Erstmal Danke für die Antworten. Ich denke aber nicht, dass das Problem an den Zählern liegt weil die ja korrekt funktionieren (habe das [clock_reference] Signal über ein Testpin am Oszi angeschaut und sieht sehr gut aus). Das Problem könnte eher bei DGenerator bzw. StateMachine liegen, weil nach max. 9 Datenbits nicht abgebrochen wird ([done] immer 0). Ich habe zu Testzwecken [BIT_CNT] auf 3 gesetzt, so dass normalerweise nach 3 Datenbits das [done] Signal auf 1 übergehen sollte und somit [BUSY] auf 0. Tut es aber nicht!
Gast
#482984
@Klaus Falser >Was soll Dein Kommentar? >Ich habe nur behauptet, daß es so wie es geschrieben wurde nicht geht. Dein Kommentar war aber missverständlich. MFG Falk
Dein Index-Signal wird nicht in einem mit CLK_IN getaktetem Prozess incrementiert. Das gibt sicher Probleme, weil DGenerator ziemlich sicher Latches erzeugt. Schreib den Prozess auf synchron um, sodaß nur an der steigenden Flanke vom CLK_IN etwas passiert. Die Zähler CounterClock und CounterData solltest Du aber auch verbessern. Es mag zwar sein, daß sie so funktionieren, sie sind aber sicher nicht korrekt, weil das CLK_IN signal auch im > if ( CLK_IN = '0' and clk_counter = 0 ) then > clk_counter <= clk_ref_counter; vorkommt. Am besten, Du ziehst alles in den "if(CLK_IN'event .. )" Block hinein. Grüße Klaus
@Klaus Besten Dank! Es funktioniert jetzt... Gruß, DeLUru