fragen zu fsm, verilog modulen und probleme.

[gast1 (Gast)]

hallo,

mein erstes cpld projekt funktioniert ja soweit (siehe kunstwerke -> vga 
karte) nun wuerd ich das gern noch ein wenig verbessern und da
hab ich noch ein paar fragen... bin noch anfaenger ;)

1) wenn ich eine fsm programmiere hab ich ja immer 3 always-bloecke.
    -next state logic.
    -current state logic und
    -output logic

in der next state ist ja immer der reset mit eingebaut. wenn ich kein 
reset brauche ist es ok wenn man die current state logic direkt den next 
state setzt ?

der unterschied besteht ja darin das next state logic den state immer 
mit einer non blocking zuweist hingegen current state mit blocking.

spricht irgendwas dagegen ? oder kann das probleme verursachen ?

die frage stelle ich da ich one hot encoding verwende. wenn ich next 
state und current state verwende brauche ich doppelt soviel register... 
das ist auf einem cpld natuerlich etwas problematisch

2) eine frage zur current state logic. in der sensitivliste sollten dort 
ja immer alle signale enthalten sein die zur entscheidung des current 
state noetig sind. momentan habe ich nur clock in der sensitivliste es 
funktioniert
ist das soweit ok ?

3) in manchen fsm beispielen im web lese ich das die dort non blocking 
zuweisungen im current state verwendet wird. hat das nen tieferen sinn ? 
weil die current state ist ja rein kombinatorisch ? da muss ich doch 
blocking verwenden ?

4) eine frage zu verilog modulen. ich hab ja die moeglichkeit mehrere 
module zu verwenden und diese beliebig oft zu erzeugen usw. hat das 
einteilen in module eine auswirkung auf die synthese ? oder dient das 
rein zur uebersicht bzw. code reusage ?

5) fuer mich als anfaenger ist es manchmal schwer rauszufinden warum 
etwas nicht funktioniert. ich hab hin und wieder das problem das ich 
etwas gebaut habe klappt auch soweit.

sobald ich z.b. ein counter um ein bit erweiter gibt es probleme. in der 
behavioral simulation gehts einwandfrei. auf der hardware (xc95144) 
leider nicht. oder sagen wirs so es funktioniert meisstens. nur halt 
manchmal nicht.

ich hab mir die rtl schematic mal angesehen. die ist schon recht gross 
nur fuer den counter weil die ffs woanders auch noch verwendet werden 
usw. hab auch schon versucht das ganze ein wenig flacher zu machen...

nur so recht verstehen tue ichs nicht weil ich z.b. im timing report 
kein problem gemeldet bekomme so von wegen max osc ist so gross der 
steht immer auf dem max wert.

daher die frage wie geht ihr an solche probleme ran ?


danke und lg :)


arf schon wieder montag

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

>     -next state logic.
>    -current state logic und
>    -output logic
Als VHDL-ler würde ich sagen:
Du verwendest die 3-Prozess-Schreibweise für eine FSM.
Ich verwende lieber die 1-Prozess-Schreibweise  ;-)

> eine frage zur current state logic. in der sensitivliste sollten dort
> ja immer alle signale enthalten sein die zur entscheidung des current
> state noetig sind. momentan habe ich nur clock in der sensitivliste es
> funktioniert
> ist das soweit ok ?
Nein. Eigentlich müsste dadurch deine Simulation falsch sein.
Aber ich habe einen Verdacht:
> eine frage zur current state logic.
Es gibt eigentlich keine current state logic, denn der augenblickliche 
Zustand wird ja nicht durch Kombinatorik bestimmt, sondern durch 
Flipflops (Speicherglieder). Der Current-State wird ja einfach durch 
einen Takt aus dem Next-State gespeichert.
Du hast also eher eine next state logic... :-o

> die frage stelle ich da ich one hot encoding verwende.
Bist du dir sicher, dass das gut ist?
Ich beschreibe meine FSM so, dass das Synthesetool die beste und 
effizienteste Umsetzung in eine Hardware heraussuchen kann.

> wenn ich kein reset brauche ist es ok wenn man die current state logic
> direkt den next state setzt ?
Da wäre ein wenig Code als Anschauungsobjekt ganz hübsch.


OT:
> ... immer auf dem max wert.
> ... an solche probleme ran ?
Auch ein Fragezeichen ist ein normales Satzende-Zeichen wie ein Punkt. 
Du kannst das Leerzeichen vor dem Fragezeichen (wie beim Punkt auch) 
bedenkenlos weglassen. Das Lesevergügen wird dadurch nicht 
beeinträchtigt ;-)

[gast1 (Gast)]

hi lothar,

danke fuer deine antwort. ich hab mal versucht schon ein paar sachen 
umzusetzen.

>Du hast also eher eine next state logic. :-o

jo hast recht ;)

>Bist du dir sicher, dass das gut ist? @one hot usw.

ich hatte es zuerst ohne fsm. weil ist ja ein uebungsproject da 
irgendwie
nichts richtig ging hab ich angefangen papers zu lesen z.b. das:
http://www.sunburst-design.com/papers/CummingsICU2002_FSMFundamentals.pdf

und dort stand das es das schnellste ist.daher ;)
aber hab das jetzt mal wie du meintest auf auto umgebaut

>Nein. Eigentlich müsste dadurch deine Simulation falsch sein.
>Aber ich habe einen Verdacht:

die state machine ist momentan so gebaut das bei jedem clock immer
ein schritt weitergeht. aber
am besten ein source der sagt mehr als 1000 worte.
ist nicht der volle source ich hab mal paar sachen rausgenommen
damit es nicht zu unuebersichtlich wird:

http://orb-demo.net/elevator/ultraVga.v


vielleicht noch ein paar worte wie die funktionsweise ist.

die verbindung zum ram sollte denke ich klar sein.

das cpu interface funktioniert mit einem 16 bit bus
wobei es 3 steuersignale gibt
  -cpuASel
   dient zum setzen der adresse wohin die cpu schreibt
   reagier auf ein low
  -cpuDSel
   dient zum schreiben oder lesen ins ram
   das schreiben/lesen wird mit einem flankenwechsel gestartet
   bei jedem schreiben wir die cpu adresse um 1 erhoeht
   damit nicht jedes mal neu die adresse gesetzt werden muss bei jedem
   pixel
  -cpuCSel
   dient dazu um double buffering zu machen sprich
   -den aktiven und offscreen zu setzen
   und momentan noch um lesen oder schreiben zu setzen (aender ich noch 
auf ein pin)

da der 95144 voll war hab ich das syncen fuer den bildschim in ein
xc9572 ausgelagert . der xc95144 bekommt nun zwei signale vSync und
wenn noBorder (sprich wenn man im sichtbaren bereich sich befindet).

seither ich das ausgelagert habe tritt der fehler immer auf.
vorher war es nur wie ich oben sagte wenn ich
cpuAdr[7:0] <= cpuAdr[7:0]+1; auf z.b. cpuAdr[15:0] <= cpuAdr[15:0]+1;
aendere.

im prinzip funktioniert es auch.also meisstens :) das anzeigen ist 
stabil.

ich beschreib mal das problem:
ich anfange zu schreiben gibt es probleme.
ich benutze ja momentan die karte um eine 3d grafik zu zeigen.
die grafik besteht ja aus polygonen wobei immer zeilenweise gemalt
wird d.h. es wird einmal in jeder zeile die cpu adresse gesetzt und
dann nur noch daten geschrieben. und dieses adresse setzen oder erhoehen
geht anscheinend schief. manchmal.
man sieht das manche zeilen vom polygon
nicht gefuellt werden. die polygon routine ist 100% richtig weil wie man
in dem movie sieht gehts einwandfrei:

http://orb-demo.net/elevator/action.mov

das ist aufgenommen mit der alten version.


momentan steht ich etwas auf dem schlauch ;) so als hinweis
timing constraints hab ich ausser clock keins gesetzt. da ist leider
ueberhaupt noch nicht der groschen gefallen.  vielleicht liegt auch da
das problem. keine ahnung. waere schoen wenn du mal draufsehen koenntest
vielleicht ist ja grundsaetzlich was falsch. ist halt der erste verilog
source.

lg ;)

ot:
@? das kommt irgendwie automatisch weiss nicht woher... ;)

[gast1 (Gast)]

moin,

ich hab das problem mittlerweile vor einiger zeit geloest. und es lag an 
den asynch-eingaengen cpuASel, cpuDSel und cpuCSel.

ich hatte zwar per ff so ne flankenerkennung gemacht und dachte das 
reicht zum eintakten. tut es aber nicht. da muss noch nen flip flop 
davor.
dumm wenn man das als anfaenger nicht weiss bzw. denk so wie mans 
gemacht hat reicht das.

aber hatte auch einen vorteil. dadurch habe ich viele papers gelesen und 
viel gelernt. als ich dann metastabilitaet und dessen beschreibung 
durchgelesen habe hats klick gemacht.


also fuer andere anfaenger. immer schoen mit einem zusaetzlichen flip 
flop ein async signal eintakten.


dann klappt das auch immer!
und nicht nur meisstens ;)

lg :)

[gast1 (Gast)]

ahso... und vielleicht fuer anfaenger noch ein nettes dokument... dort 
hab ich die info her...

unter 5. design issues sind haeufige probleme im design erklaert und 
loesungsansaetze...

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

gast1 schrieb:
> als ich dann metastabilitaet und dessen beschreibung
> durchgelesen habe hats klick gemacht.
Das mit der Metastabilität ist ein allemein anerkanntes Schauermärchen. 
Viel eher als irgendeine Art von Metastabilität (die in halbwegs 
modernen FPGAs bei ca. 300MHz dann eine Rolle spielen kann) bekommst du 
schon bei langsamtesn Designs (sagen wir mal 10MHz) Probleme mit der 
Laufzeit von asynchronen Signalen, die auf irgendeine Art von 
Kombinatorik gehen. Hier mal meine Erkenntnisse dazu:
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
Und auch immer wieder gern mal falsch gemacht:
http://www.lothar-miller.de/s9y/archives/70-Asynchroner-Reset.html