Mérés 1 Nagy házi

← Vissza az előző oldalra – Mérés laboratórium 1.

Tipikus szívások elkerülése végett tarts be néhány ökölszabályt:

1. wire-nek assignnal adj értéket
2. always blokkban csak reg típusnak
3. egy regiszer módosítása egyetlen always blokkban történjen (RESET + normál működés, minden ami a regiszter értékadásához kapcsolódik)
4. lehetőleg 1 órajelet használj, kerüld az aszinkron időzítést, megoldható engedélyező jelekkel
5. a Verilog nem programnyelv, hanem hardverleíró nyelv: ha a szintézer valamit talál, igyekszik optimalizálni, tehát ha valami rosszul van leírva, akkor lehet hogy el fogja dobni, kioptimalizálja
6. bár nem fog előjönni a mérés során, de jó tudni: a szintézer és a szimulátor a Verilog különböző részeit különbözőképp értelmezheti (a #-kal megadott időzítés pl. csak a szimulátornak szól)
7. hasznos tudni, hogy bár a szimulátor szerint le lehet nyomni és el lehet engedni egy gombot egy órajelciklus alatt, az FPGA panelen ehhez több(ezer) órajelciklus kell. (50 MHz-es mintavételezéssel elég sok órajelen keresztül ad 1 értéket a megnyomott gomb.)
8. az impact (a letoltoprogram) hajlamos nem elindulni, ha mar a masodik peldanyt inditod belole. az elso fogja a file-t, es a masik nem tudja megnyitni. mindig zard be, ha mar nincs ra szukseged.
9. ne vezess ki olyan jeleket a top modulban (meg egyaltalan semmilyen modulban), amik csak belso jelek, es nem kell kivul megjelenniuk. Ha kivezeted oket, akkor azt hozza is kell rendelned az FPGA valamelyik labahoz!
10. az UCF file-t nem dupla kattal kell szerkeszteni, hanem ha raallsz, akkor az alatta levo menuben a User Constraints alatt van az Edit constraints
11. a Verilog program nem C program. a tervezes kozben probalj meg olyan szemmel hozzaalni a dologhoz, mintha digit2 hazit csinalnal. gondolkodjal szamlalokban, regiszterekben, multiplexerekben! a "programozas", mint olyan, nem sok eredmenyre vezet.
12. nem kell tulzsufolni az always blokk sensitivity listajat. az a legjobb, ha csak a CLK van benne. gondolj bele, teljesen felesleges egy csomo adatvezeteket is felsorolni, ha azok is ugyis csak az orajel hatasara valtoznak! a legjobb az, ha egy szem always @( posedge CLK) van, abbol nagy baj nem lehet. ne feltsd a hardvert, hadd dolgozzon akkor is, ha nem muszaj!

Előzetes tennivalók

Szimulálj le mindent mérés előtt, úgyis lesz valami gikszer ami miatt módosítgatnod kell a mérés során, és a hardverben már sokkal kevesebb lehetőséged lesz a tesztelésre (logikai analizátor + nyomógombok, kapcsolók). A mérés végén csak elektronikus jegyzőkönyvet kérnek.

(Érdemes még otthon nem csak szimulációt futtatni, hanem "implement design"-t is. Sok hibára fényt deríthet, ami szimulációban nem derül ki - pl. warningok is érdekesek, console nézetben. Ha a letöltés nem is, de az implement mindenképpen működik otthon is, és otthon több időd van kijavítgatni, mint majd a laborban lesz.)

Olvassatok el Hainzmann Tanár Úr "gyakori hibak" leirását is, mivel tartalmaz olyan dolgokat, amiket mi itt nem irtunk le! (megtalálható a jegyzetek közt a tárgy honlapján)

Feladattípusok

Soros adás-vétel

Az UART kommunikáció esetén figyeljünk rá hogy start és stop bitet minden byte előtt-után küldenünk kell, hogy az adó és vevő szinkronban maradhasson; amikor nem küldünk semmit, akkor a kábelt logikai 1 értéken illik tartani (különben start bitet jelentene).

A kommunikációs jeleket (leginkább baudrate, txd) érdemes kikötni az analizátorra is, elsőre általában nem szokott jól menni, de így legalább látszik, miért nem.

Ha bináris csupa 0-csupa 1-et küldesz, azt a Hyperterminal nem tudja értelmesen megjeleníteni, a programok között elérhető egy másik soros porti program, amivel hexadecimálisan megjeleníthető az adat.

Hétszegmenses kijelző

A több digites kijelzés időmultiplexelt alapon megy, tehát először első jegyet engedélyezd + 7 szegmens megfelelően meghajtva, aztán második jegyre ugyanez. Az időzítésre figyelj: 1-10 KHz közötti ütemezésnél gyorsabban nem tud működni, ha az alapértelmezett 50 MHz-en multiplexelünk, akkor össze fognak mosódni a számok. Csinálni kell neki belső számlálót.

Hasznos infók találhatók a dobókockás mintapéldában...

PIN-kódos zár

Ezzel a feladattal nagyon sokat lehet szívni, ha nem figyelsz a gombok kezelésére!

• gombok pergésmentesítése: ha nem pergésmentesítesz, akkor egy gomblenyomás hatására több gombnyomást érzékelhetsz mint kéne, így hibás kódot olvasol be (pl. olvasd ritkábban, 100 Hz-en a gombok értékét)
• gombok nyomvatartása: a lenyomva tartott gombokra készülj fel, senki sem fog 50 MHz-n nyomkodni, tehát a szimulációban érdemes ellenőrizni, nem olvasod-e többször ugyanazt a gombot, ha hosszan tartják nyomva

Jellemző XST (szintézer) hibajelzések és magyarázatuk

Reference to scalar wire '...' is not a legal reg or variable lvalue

Lásd: 1. és 2. ökölszabály.

A megadott jel nem regiszter. Vagy reg-ként kell definiálni, vagy ha nem célod, hogy regiszter legyen,

assign vezetek = ertek;

módon csináld

always@(..)  
	regiszter <= ertek;

helyett.

Vigyázat: ha egy blokkon belül már reg-ként definiáltál valamit, akkor a blokkon kívül (felsőbb modulban) NE definiáld regiszterként, mert ezzel dupla flip-flopot hoznál létre, aminek nincs értelme és nem is fogja remélhetőleg szintetizálni.

Multi-source in Unit <...> on signal <...> not replaced by logic

Lásd: 3. ökölszabály.

Több blokkban hajtod meg ugyanazt a jelet. Vagy több modulban szerepel outputként, vagy több =always= blokkban próbálsz egy adott értéket módosítani. (A szintézer hardvert próbál készíteni, a külön blokkokat külön pakolja, így 2x szerepel ugyanaz a jel, és szembehajthatnák egymást.)

Line 1 in '....ucf': Could not find net(s) '...' in the design. To suppress this error specify the correct net name or remove the constraint. The 'Ignore I\O constraints on Invalid Object Names' property can also be set ( -aul switch for command line users).

Az UCF-ben megadott kivezetés hiányzik a hardverleírásból.

Tipikusan azért szokott előfordulni, mert valamelyik modul hibásan van megírva vagy rossz jeleket kap - nem változik a bemenet vagy nem használod fel a kimeneteket, emiatt a szintézer haszontalannak tekinti és kioptimalizálja, a ki/bevezetésekkel együtt. Erre egy rövid warning szokott figyelmeztetni.

Programming failed

A modell tökéletes a szimulációban, mégse lehet letölteni, az impact Programming failed-et ír ki, mondván, hogy "done did not go high". A hiba az szokott lenni, hogy a top modul interface-ében szereplő jelek közül valamelyik nincs az UCF-ben hozzákötve egy konkrét lábhoz (ilyenkor a szintézer találomra hozzáköti valamihez, és a hibásan bekötött lábak miatt hiúsulhat meg a Done láb felhúzása).

Ilyenkor le kell ellenőrizni, hogy a top modul interface-ében levő (tehát a zárójelben levő) jelek mindegyike szerepel-e az UCF-ben, és hogy a pin számok jók-e. (Tipikus hiba: "erre csak a modelsimhez volt szükség, ezt nem kötöm be".) Ugyanezt a problémát okozhatja egy olyan busz is, ami szélesebb a szükségesnél, így valamelyik bitje kihasználatlan marad, és ugyanúgy oda lesz kötve valahova. Jó esetben ezt a hibát előrejelzi egy warning.

A hibát okozo jelet meg lehet keresni a "Pad report"-ban, itt kell megnézni, hogy ott csak olyan lábak legyenek, amiket ti valóban ki akartok vezetni. A "View RTL Schematic" is segíthet, itt meg lehet nézni, hogy az egyes modulok grafikusan hogy néznek ki, stb.

Néha ok nélkül dob Programming failed üzeneteket, mielőtt tüzetesen átvizsgálnál mindent, próbáld meg legalább kétszer felprogramozni a konfigurációs fájlt.

Unknown identifier 'vector'.... VHDL Compiler exiting

Tipikus hiba: Verilogban írtuk ugyan a kódot, de a projekt létrehozásakor elfelejtettük megadni hogy nem VHDL hanem Verilog kódot készítünk. Ilyenkor a szimulátor nem fog futni, hiába tökéletes a =Check Syntax=. Javítás: jobbklikk a Source-ok között a projekten, Properties...

Nem tipikus hiba: néha a nagyon csúnyán megírt Verilog kódot a szintézer megeszi ugyan, de a szimulátor nem. -- Bandita - 2005.03.11.

Egy majdnem minimalis Hello World pelda

Ez a modell egyreszt a BTN1-el vezerli a LD1 LED-et, masreszt egy egy bites regisztert (Q) invertal az orajel hatasara, es azt megjeleniti az oszcilloszkopba epitett logikai analizator D1-es csatornajan. Tehat ket dolgot is lehet tanulni belole :) A CLKOUT-on kapja meg a logikai analizator az orajelet.

Verilog forras:

module lampa(BTN1,LD1,CLK, Q, CLKOUT);
	 input CLK;
	 input BTN1;
	 output LD1;
	 output CLKOUT;
	
output reg Q;

assign LD1 = BTN1;
assign CLKOUT = CLK;

always @(posedge CLK)
	begin
		if (Q == 1) Q <= 0;
		if (Q == 0) Q <= 1;
	end

endmodule

UCF file:

NET "CLK" LOC = "P80"; #GCLK, 50 MHz
NET "Q" LOC = "P133"; # 38 / P1:Ch1  
NET "CLKOUT" LOC = "P152"; # 23 / P1:CLK1  
NET "BTN1" LOC = "P37";
NET "LD1" LOC = "P44";

Par tipp debuggolashoz

Ha nem mukodik valami, akkor probalkozz a kovetkezo strategiaval:

Elobb a gepen szimulald a moduljaidat teszt adatokkal. ez azert jo, mert gyorsabban haladsz, mintha mindig letoltened, es jobban is latod az eredmenyeket.

Mindig nezd a warningokat! van nehany warning amivel nem erdemes torodni, de jo reszuk valami hibaba torkollik kesobb. a warningokat mindig a Console ablakban nezd, ne pedig a Warnings vagy az Errors ablakban, mert az utobbi ketto felrevezethet: egyreszt tobb soros warning eseten csak egy sort mutat meg belole, masreszt vannak "Info" kategorias uzenetek, amik bar negyon sokat segitenek, megsem jelennek meg egyikben sem. Ha hibat keresel, akkor a Console ablakot mindig a legelejerol olvasd, mert sok, a forditas vegen jelenkezo hiba okat a forditas elejen jelentkezo warningok vagy infok mar elore jeleznek (es ezekbol sokkal konnyebb rajonni, hogy mi a hiba, mint a tenyleges hibauzenetbol)

Sose debuggolj "vakon"! ha kivancsi vagy, hogy egy belso regiszter erteke mi lehet valahol, hat vezesd ki atmenetileg a modul interfeszere! ekkor latni fogod a szimulacioban. kesobb, ha a modulod mar jo, akkor kitorlod az interfeszbol, vagyis csinalsz belole ujra belso valtozot.

A modulok szimulaciojat alulrol felfefe csinald. vagyis eloszor a legalso, mas modult nem hasznalo modulokat, aztan az arra epuloket, stb...

addig nem is erdemes letolteni a programot, amig nem jutottal el odaig, hogy a top modulodat sikerrel szimulaltad. ha az mukodik, akkor letoltheted.

Ha letoltotted, es a hardveren megsem mukodik, akkor megintcsak ne debuggolj vakon, hasznald az oszcilloszkopbe beepitett logikai nalaizatort. a P1-re van rakotve. amit latni akarsz, azt egyszeruen vezesd ki (ha meg nincsen), es az UCF-ben vedd fel! (ld. az elobbi peldat)

Jegyzokonyv!!!

Mikor osztalyozunk, mar nem biztos, hogy emlekezni fogunk mindenkire, es hogy hogyan es mikent sikerult osszehoznia az 5. merest. Ezert a jegyzokonyv irasa nagyon fontos!! Kerunk benneteket, hogy a jegyzokonyvat az 5. meresnel is folyamatosan csinaljatok (bar tudom, ez nehezebb itt, mint a tobbi meres alkalmaval), es ne a meres vege elott 5 perccel alljatok neki! A jegyzokonyv 1 file legyen, ne csak utalasok legyenek az otthon vegzett munkat tartalmazo file-okra, stb. nagyon rossz osszevalogatni oket, sokkal jobb, ha egyutt lehet latni (es igy nem is fogjak letorolni oket). A jegyzokonyvben legyen benne, hogy ki melyik feladatot csinalta (ti tudjatok, de mi nem biztos), legyenek benne a papiron hozott dolgok scannelve (scanner a laborban), lehet benne forraskod, idodiagramok a szimulaciobol, es ha meg a hardverre letoltve is mukodott, azt feltetlenul irjatok bele! A legfontosabb, hogy legyen benne, hogy mi a legnagyobb eredmeny, amit elertetek, mert ez alapjan tudunk jegyet adni (egyaltalan nem mukodott, szimulacioban mukodott, letoltve mukodott kisebb hibaval, letoltve is jol mukodott, stb..)