xc9500, ps2

[marcel (Gast)]

hallo,

ich versuche mit einem xilinx xc9536 einen kleinen controller zu
entwerfen welcher die seriellen daten einer ps2 tastatur intern in
parallele daten wandelt und nach erhalt eines kompletten frames einen
interrupt "am zielsystem" auslöst indem er eine steigende flanke an
einem seiner ausgänge erzeugt.

der controller funktioniert unregelmäßig ein paar tastendrücke
(jedesmal drei scancodes) wunderbar aber irgendwann (meistens nach ca 4
tastendrücken) "übersieht" er irgendwie eine fallende flanke an der
clock-leitung der tastatur oder erkennt eine zu viel und somit erhalte
ich nur noch unbrauchbare daten :(

ich habe das komplette webpack-projekt als rar-archiv im anhang

ich hab schon allesmögliche versucht und bin total am verzweifeln
kopfaufdietastaturschlag ich wäre überglücklich falls ihr mir helfen
könntet den fehler zu finden :)

gruß
marcel

[Jörn (Gast)]

Hast du deine Schaltung mal simuliert?

[FPGA-User (Gast)]

sorry, aber der VHDL-Code sieht total chaotisch aus.
Habe wenig Zeit, aber folgendes ist mir aufgefallen:
- ist reset bei Dir synchron ? Ich hoffe ja, ansonsten
  musst Du Deine Prozesse alle umschreiben :

process (reset, clk)
   if reset='0' then
      ...
   elsif rising_edge(clk) then
      ...

Wenn Du zuerst die Taktflanke abfragst, dann wird
alles nachfolgende synchron mit clk implementiert.

core.vhd, Zeile 92 : process(clk)
- ist hier völlig falsch, wenn Du anschließend
  reine Kombinatorik beschreibst.
richtig wäre : process (cs, rd, wr, read)

rxunit.vhd, Zeile 36: warum sind kclk und kdata
in der Sensitivity-List des Prozesses ?

Wie wärs, wenn Du über jeden process mal einen
Kommentar schreibst, was das ganze machen soll?

Weiterer Vorschlag:

Alle Signale die als Register/FF implementiert werden
sollen erhalten am Ende des Namens ein _q
z.B. counter_q
alle L-aktiven Signale _n, also reset_n,
alle asynchronen Signale wenigstens in Kommentaren
erwähnen, dann kann man die Sourcen besser lesen.

[marcel (Gast)]

vielen lieben dank für die antworten :)

wie man unschwer erkennen kann bin ich blutiger neuling in dem gebiet

ich werde deine ganzen vorschläge gleich mal umsetzen und dann
weiterschaun

gruß
marcel

[FPGA-User (Gast)]

OK, dann poste mal die neuen Sourcen, wenn
Du soweit bist, ich schau dann nochmal drüber

[marcel (Gast)]

so hier ist der aktuelle code :)

mein systemtakt wird von einem 4mhz quarzoszilator erzeugt... also habe
ich die ganze zeit mit diesem 4mhz takt am clk-eingang meines
controllers gearbeitet und nur unsinniges zeugs erhalten. gestern habe
ich mit einem HC74 einen einfachen frequenzteiler gebaut und somit
einen 2mhz takt an meinen controller gegeben... und siehe da... er hat
genau(meistens) das gemacht was er machen soll

ich verwende den xc9572-15 also die langsame 15ns version... aber diese
sollte doch dazu in der lage sein mit meinem 4mhz-takt zu funktionieren,
oder?

gruß
marcel

[FPGA-User (Gast)]

keine Angst wegen der Geschwindigkeit, habe mit
einem 9572-15 einen 7-stelligen Frequenzzähler gebaut,
der bis 200 MHz zählt, also die Teile sind schnell.
Sehe mir heute Nachmittag mal die Sourcen an.

[FPGA-User (Gast)]

na sehr viel Arbeit hast du dir nicht gemacht, aber
ok, ich hab mal die rxunit modifiziert weil ich denke,
dass schon dort probleme entstehen, wenn du kclk und
kdata abfragst, ohne sie auf deinen internen clk zu
synchronisieren. kclk ist jetzt nur noch vom typ IN,
weiss nicht, ob INOUT nötig war.
schau dir einfach mal die neue rxunit an + die Modelsim-
Waves.
Ist bestimmt nicht optimal, sollte aber erstmal so gehen.

viel spass

[marcel (Gast)]

wow danke :)

des muss ich jetzt erstmal verstehen g

gruß
marcel

[marcel (Gast)]

so... ich habe nochmal den aktuellen code angehängt

es will irgendwie nicht so richtig... im großen und ganzen funktioniert
der controller aber ab und zu löst er einfach so einen interrupt zu viel
aus... ich weiß nicht recht warum :)

könntest du nochmal drüberschaun?

gruß
marcel

[johnny (Gast)]

hallo.
bin zwar auch neuling in sachen vhdl habe aber mit elektronik viel zu
tun.
wäre es nicht besser wenn du das "rxunit.vhd - Zeile 64 - kclk2_q <=
kclk1_q;"
bei der steigenden flanke machst. den hast du nen master slave
flipflop
weil momentan laufen diese beiden dinge " kclk1_q <= kclk; kclk2_q <=
kclk1_q;" gleichzeitig ab. das ist nicht so gut.
probier mal den etwas veränderten code aus.
mfg

[FPGA-User (Gast)]

an der Stelle sollte es keine Probleme geben,
das ist die typische Flankenerkennung bei
synchronen Schaltungen mit 2 hintereinander-
geschalteten FFs.
Im Gegenteil : wenn man hier mit 2 verschiedenen
Flanke arbeitet, kann es Timing-Probleme geben,
da ja nur noch die halbe Clockperiode verfügbar ist.
(ist hier unkritsch aufgrund sehr niedriger Taktfrequenz)

Also eine gute Design-Praxis ist : möglichst nur mit
einer Taktflanke arbeiten u. alles synchron implementieren.

marcel: ich schau bei Gelegenheit nochmal auf den Source-Code