[vlsi-nastava:2005] - Re: Strukturni opis.... by "Aleksandar Milutinovic" <aca.mil@galeb.etf.bg.ac.yu>

Nije problem da sve bude u jedinstvenom modulu, samo je malo verovatno da se
sve tako napravi. Moje misljenje je da treba ipak biti modularno,tj.
strukturno. Negde sam citao da bi moduli zbog sinteze trebali da budu sto
jednostavniji, sa po jednim eventualno dva procesa, da bi se lakse
kontrolisala i sinteza i testiranje, valjda.

Sledi, deo neke stare prepiske, koja preporucuje i forsira strukturiran
dizajn, mada se ja nadam da je nas problem jednostavniji i da se ne mora bas
ici na nivo FF itd. :

"
Ako nemas jos VHDL kod (ili imas, a ocajan si:( ), procitaj prvo =
Synplify manual (VHDL deo).
=20
Radite strogo strukturiran dizajn, u smislu da koristite flip flopove =
koji stvarno postoje (a ne neke koji reaguju na dve ivice i slicno). Ako =
radite dizajn za sintezu, onda imajte na umu i implementaciju, tj. sta =
to podrzava target device, tj. Xilinx Spartan 2, a to su D FF-ovi sa =
sinhrono/asinhronim setovanjem/resetovanjem sa aktivnom =
rastucom/opadajucom ivicom. Da li vam koristi blok-memorija? Napravite =
model toga (moze behavioral), ako ne mozete da nadjete vec gotov kod. =
Ako je ikako moguce, zaobidjite funkcionalno modelovanje slozenijih =
stvari. Na primer, ako vam treba slozena sekvencijalna mreza (a ne radi =
vam komapjler automata :( ), onda je isprogramirajte kao sto ste radili =
u IDE, ili ORT-u., sa D FF-ovima - strukturirano umesto da pisete =
behavioral procese i slicno. To ako stvarno zelite da vam sinteza lako =
radi.  Funkcionalni modeli ce vam olaksati testiranje, ali ce uvesti =
dodatan nivo u modelovanju, moracete skoro svaku ideju dva puta da =
kodirate. Kazem, testiranjem dva slucaja koja rade istu stvar, jednom za =
sitezu, a drugi put za simulaciju dobija se visi stepen sigurnosti u =
korektnost dizajna, ali je znatno komplikovanije to i sprovesti do =
kraja(a i nepotrebno je).
=20
Svakako ne smete da koristite after, tj. delay elemente kasnjenja =
signala (ignorise ih pri sintezi). Ne koristite procese sa wait-om, ako =
wait nije na samom kraju ili pocetku koda. Ne koristite procese za =
kombinacione mreze. Ako vam zatrebaju (ako ste fanatik) FF-ovi sa =
dvostrukim okidanjem (sa rastucom i opadajucom ivicom), razbijte ih na =
dva ili vise FF-ova. Izbegavajte dugacke ugnezdene if strukture (moze da =
pravi sa velikim prioritetnim koderom) vec koristite case. Ako imate =
vremena procitajte razne savete za sintezno kodiranje (na sajtovima =
Xilinx-a, Sinplicity-jevom, OpenCores-itd... trazite coding guidelines)
=20

Milos Milovanovic <miloshm@yahoo.com> wrote:
Da li neko zna sta sve ne sme da se koristi u VHDL da
bi moglo da se sintetise u Synplify-u?

_______________________________________________

Gvozden Marinkovic wrote:
..ovde imam jednu primedbu. Ukoliko automate pisete na pravi nacin (bilo =

na vezbama) sinteza prolazi bez problema. U jednom procesu se radi=20
prebacivanje stanja, a u drugom kombinaciona logika za racunanje=20
sledeceg stanja. Pogledajte resenja ispitnih zadataka


Primedba je na mestu.
Kada imate dobar i jasan automat u glavi (ili na papiru), treba ga =
iskodirati direktno u VHDL-u, kako ste i naveli.
=20
Ipak, ja, konkretno, nisam uspeo da svu svoju sekvencijalnu mrezu =
umetnem u automat (A imao sam ih dva, koja sam dobro iskodirao, kako ste =
i naveli da se radi), jer sam hteo (a mozda bi bolje bilo da nisam :) ) =
da obradim izuzetke u Wishbone komunikaciji (tipa, a sta ce da bidne =
kada ovaj signal padne, a ne bi trebao da to uradi...) To je mi je bilo =
tesko, nije mi bilo prirodno, da obradim preko automata, nego mi je =
logicnije da radim preko funkcionalnog modelovanja i olako sam upao u =
njegovu zamku. Znate, jako je lako isimulirati jedno when sa reagovanjem =
na rastuci signal jednog signala, a na opadajuci signal nekog drugog =
signala, pa jos i resetovanja, postavljanja. Pa, trebao mi je i =
asinhroni reset posle nekog vremena od promene stanja u nekom skupu =
signala (dakle, resetovanje treceg, garantovano posle svih promena u =
nekom skupu signala)!  A kada dodje do sinteze: %^#$%$. Dugo nisam mogao =
da se izborim. Resenje je bilo: iskodirati "pitaj Boga kakav" automat =
ili uvesti FF-ove (zapravo mnogo FF-ova). Verujte mi na rec, lakse je =
bilo uvesti FF-ove.=20
=20
Podvucicu da treba izbegavati funkcionalno modelovanje; ali cu i dodati: =
sa izuzetkom dobro isprogramiranog automata. Nista lepse od preglednog =
automata, razbijenog u dva procesa: kombinacionog i sekvencionalnog za =
promene stanja.
=20
Zakljucak: uradite sta vam se trazi u domacem (+ maaalo vise), i =
zakljucak broj dva: postujte sve faze dizajna; i tesko prelazite na novu =
fazu, sve dok ne istestirate dobro output prethodne. (Za sta i ja kazem: =
lakse je reci, nego ispostovati; sto vazi za oba zakljucka)=20
=20
=20

"

Nadam se da nam ovo nece zagorcati zivot.

Pozdrav,
 Sale



> Malo smo nesto diskutovali na poslednjim vezbama i uvideli razlicite
> koncepte resenja (sto idejnih, sto vec pretvornih u VHDL)...
> Pa me (nas) zanima sta znaci ono "struktuni opis" u postavci
> zadatka....Tj, da li moze da postoji samo jedan entitet, npr. Framer ili
> resenja mora biti modularno, odnosno iz vise entiteta (sto se u ovoj
> literaturi spominje kao "strukturni opis")?
>
> Pretpostavljam da je na nama da izaberemo.... Ili...
>
> Pzdrv, G.
>