Kopioi artikkelin
PDF-versio
Elektronista kytkentää voidaan kuvata monella tasolla. Kytkintasolla voidaan määritellä IC-piirin johtimien sijoittelu, vastukset ja transistorit. Porttitasolla suunnittelun pääosassa ovat portit ja kiikut. Tätä korkeammalla tasolla määritellään kytkentä rekistereinä ja niiden välisenä tiedonvaihtona. Tätä kutsutaan rekisterinsiirtotason suunnitteluksi. (Register Transfer Level, RTL).
Tiukasti tulkiten nykyiset synteesiohjelmat toimivat jo hieman rekisterinsiirtotasoa korkeammalla tasolla.
Rekisterinsiirtotason synteesityökalut ovat olleet jo jonkin aikaa arkipäivää ASIC-suunnitte-lijoille. Rekisterinsiirtotason suunnittelussa kuvataan käytettävät muistielementit (kiikut ja lukkopiirit) sekä tarvittavan logiikan niiden väliin. Rekisterinsiirtotason synteesi kääntää tämän suunnittelun automaattisesti teknologiariippuviksi porteiksi.
Miltei aina suunnittelu kuvataan näille ohjelmistoille jollakin laitteistonkuvauskielellä (HDL, Hardware Description Language, kuten VHDL ja Verilog). Laitteistonkuvauskielet ja synteesiohjelmat tarjoavat monia etuja muihin suunnittelumenetelmiin verrattuna, kuten suuren riippumattomuuden kohdeteknologiasta ja helpon parametroinnin.
Silti HDL-pohjainen suunnittelu ja jopa nykyisin käytössä olevien kielien rakenne ovat tuoneet suunnittelutyöhön uusia haasteita. Ohjelmistotalot ovatkin esitelleet useita työkaluja, joiden tarkoituksena on madaltaa laitteistonkuvauskielten käyttökynnystä.
Synteesiohjelmien ja suunnittelijoiden tulkinnat rekisterinsiirtotason lähdekoodista eroavat usein toisistaan. Toiminnallisesti samankaltaiset rakenteet saattavat tuottaa hyvinkin erityyppisiä lopputuloksia huolimatta siitä, että toiminta simulaattorissa on samanlaista.
Joskus suunnittelija saattaa kuvata koodiin epähuomiossa mukaan ylimääräistä logiikkaa, joskus taas synteesiohjelma vain yksinkertaisesti osaa syntesoida tietyt koodirakenteet paremmin kuin toiset. Suunnittelijan on hankala ennakoida tämänkaltaisia ongelmia. Ainoat keinot ovat huolellinen tutustuminen ohjelmaan ja aiempi kokemus. Synteesin jälkeen havaittujen ongelmien kohdentaminen alkuperäiseen lähdekoodiin saattaa myös olla hankalaa mitä rakennetta pitäisi muuttaa, jotta ongelma saataisiin ratkaistua?
RTL Analyzer yrittää selkeyttää ja helpottaa lähdekoodin kirjoittamista Synopsyksen synteesityökaluille. RTL Analyzer on lähdekooditason arviointiin perustuva ohjelma. Se lukee rekisterinsiirtotason koodin, rakentaa siitä geneerisen mallin ja arvioi piirin eri rakenteiden ajoituksia ja tarvittavaa logiikan määrää.
RTL Analyzer osaa näyttää arviot lähdekoodista rivi riviltä. Tällöin suunnittelija pystyy paikantamaan hidasta ja mahdollisesti tarpeetonta logiikkaa tuottavat koodirakenteet ja muuttamaan niitä.
RTL Analyzerin arviot eivät edusta todellisia mittayksiköitä, sillä geneerisessä suunnittelussa logiikkaa ei ole optimoitu eikä kohdeteknologiakirjastoa käytetty. Eri koodeilla saadut tulokset ovat kuitenkin keskenään vertailukelpoisia, jos niiden toiminnallisuus on sama. Johdotusviiveitä ei arvioida millään tavoin geneerisessä vaiheessa.
Geneerinen suunnittelu esitetään graafisesti niin sanotun Gantt-kaavion avulla. Kaavio esittää suunnittelun ajoituksen logiikkatasoihin perustuen. Ajoituksen lisäksi RTL Analyzer esittää Gantt-kaaviossa polkujen rakennelohkotyypit karkeasti, kuten aritmeettiset operaatiot, multiplekserit ja kombinatorisen logiikan.
Osoitettaessa hiirellä rakennelohkoa kaaviossa, RTL Analyzer näyttää erillisessä lähdekoodi-ikkunassa koodin, joka on tuottanut kyseisen rakenteen tai päinvastoin. Suunnittelija saa selkeän kuvan koodin ja tarvittavan logiikan yhteydestä. Kaavioon voidaan piirtää näkyviin koko suunnittelu tai osia siitä.
RTL Analyzerissa on automaattinen Timing Wizard, joka osaa hakea kaavioon muutamia yleisimmin tarvittuja polkuja. Polkuja voidaan analysoida pelkästään logiikkatasojen perusteella tai logiikkatasojen suhteessa ajoituspakotteisiin. Jälkimmäisellä menetelmällä saadaan arvio polusta, jolla on eniten suoritettavaa pienimmässä ajassa. Lisäksi RTL Analyzer arvioi logiikkasolujen ja sisääntulojen fan out -lukuja. Pinta-ala arvio geneeriselle logiikkaportille perustuu portin sisääntulojen lukumäärään.
Myöhemmässä vaiheessa synteesien ja optimointien jälkeen RTL Analyzer osaa lukea lopputulosta ja edelleen osoittaa yhteyden syntesoitujen rakenteiden ja lähdekoodin välillä. Tämä on erityisen hyödyllistä pitkien ajoituspolkujen löytämisessä lähdekoodista. Nyt myös johdotusviivemallit ovat käytössä. Jos käytettävissä on Design Power -työkalu, voidaan suunnittelua analysoida myös tehonkulutuksen suhteen.
Vaikka RTL Analyzerin avustuksella on mahdollista parantaa rekisterinsiirtotason suunnittelua huomattavastikin, on epävarmaa, olisiko varsinainen synteesityökalu osannut itse tehdä samat optimoinnit. Toisaalta laadukkaan lähdekoodin merkitystä ei pidä väheksyä. Aloittelevalle suunnittelijalle RTL Analyzer tarjoaa nopean tien oppia synteesiohjelman toimintaa. Kokeneempi suunnittelija arvostaa mahdollisuutta löytää yhteys jo syntesoitujen suunnitteluiden ja lähdekoodin välillä. RTL Analyzerilla voidaan myös tehdä nopeita arviointeja muualta saatuun lähdekoodiin ja sen tuottamaan tulokseen.
Mentor Graphics on tuonut markkinoille uuden graafisen HDL-työkalun Renoir. Ohjelmistotekniikassa graafisia (CASE) työkaluja on käytetty jo pitkään. EDA-rintamallakin on jo aikaisemmin ollut markkinoilla useita ohjelmistoja, kuten Summitin Visual HDL ja suomalaisen Hantro Oy:n CompLib. Myös Mentor Graphicsilla on ollut aikaisemmin tarjolla ohjelmistotekniikasta tuttu, SA-menetelmään (Structured Analysis) perustuva työkalu Falcon Framework-käyttöliittymällä. Renoir noudattaa kuitenkin Motif-käyttöliittymää eikä perustu enää SA-menetelmään.
Graafisten HDL-työkalujen ideana on helpottaa suunnitteluhierarkian ja versioiden hallintaa, ryhmätyöskentelyä ja jopa koodin generointia. Suunnittelun hierarkia kuvataan graafisilla symboleilla ja yhteydet niiden välillä signaalilinjoilla. Tämä helpottaa suunnittelun kokonaisuuden hallintaa sekä vähentää työtä, joka aiheutuu hierarkian kuvaamisesta koodiin. Suuremmissa suunnitteluissa työnsäästö saattaa olla merkittävä.
Jokainen symboli hierarkiatasolla aukeaa toteutusarkkitehtuuriksi tai uudeksi hierarkiatasoksi. Toteutusarkkitehtuuri voidaan kuvata käsin tai generoida automaattisesti. Automaattisia koodigeneraattoreita voidaan käyttää työkalusta riippuen esimerkiksi tilakoneiden tai aritmeettisten lohkojen kuvaamiseen.
Mentor Graphicsin Renoir sisältää editorit tilakoneiden, vuokaavioiden ja totuustaulujen sekä luonnollisesti suunnittelun hierarkian kuvaamiseen. Renoirin editorit toimivat joustavasti, esimerkiksi hierarkiaeditorissa on mahdollista upottaa HDL-koodia graafisen suunnittelun joukkoon. Tilakone-editorissa voidaan generoitavan koodin tyyliä vaihdella ja joidenkin FPGA-teknologioiden vaatima one-hot-koodaus onnistuu.
Hyödyllinen ominaisuus editoreissa on mahdollisuus ankkuroida kommenttitekstit tiettyyn graafiseen elementtiin, jolloin kommentti sijoittuu myös generoidussa koodissa oikeaan kohtaan. Renoir tukee myös RCS-versionhallintaa, jolloin historiatiedot ja ryhmätyöskentely helpottuvat huomattavasti. (RCS = Revision Control System, saatavissa korvauksetta GPL-lisenssin alla). Uusin Renoirin versio osaa lisäksi lukea valmiita suunnitteluita graafiseen muotoon. Näin vanhat suunnittelut voidaan liittää osaksi graafista komponenttikirjastoa.
Renoir tukee Mentor Graphicsin omia HDL-simulaattoreita, QuickHDL ja V-systems sekä HW/SW-yhteissimuolointiohjelmaa Seamless. Muita tuettuja simulaattoreita ovat Cadencen Leapfrog ja Verilog-XL sekä Synopsyksen VSS. Animoidut tilakoneet ja vuokaaviot toimivat ainoastaan QuickHDL, V-systems- ja Leapfrog-simulaattoreilla. Tuettuja synteesityökaluja ovat AutoLogicII, Galileo, Leonardo ja Design Compiler. Tosin automaattisesti generoitu koodi on selkeästi saatavilla, ja sitä on mahdollista käyttää missä tahansa sopivassa työkalussa.
Graafiset HDL-työkalut helpottavat suurien suunnitteluiden hallintaa sekä uuden suunnittelijan kiinnipääsyä HDL-maailmaan. Myös suunnittelujen dokumentointi helpottuu, sillä graafinen esitys toimii eräänlaisena dokumenttina jo itsessään. Graafiset työkalut eivät kuitenkaan poista tarvetta tuntea ikonien takana olevaa laitteistonkuvauskieltä. Lisäksi jatkotyökalujen kuten rekisterinsiirtotason synteesityökalun tunteminen on edelleen tärkeää. Työkalun automaattisesti generoima koodi vaikuttaa suoraan lopputulokseen, ja siksi kriittisissä suunnitteluissa generoidun koodin laatu on syytä varmistaa huolellisesti.
Geneeristen datapolkurakenteiden kuvaaminen ei ole yksinkertaista VHDL-kielellä, mutta joskus tarpeellista. Monasti suunnittelija löytää itsensä tutkimasta synteesityökalun tuottamaa piirikaaviota tuloksen varmistamiseksi. Erilaisten datapolkuvaihtoehtojen arviointi on jo yleensä tehty muilla työkaluilla tai intuitiivisesti suunnittelijan mielessä.
Synopsys on lähestynyt ongelmaa uudella tavalla ja julkistanut datapolkujen synteesiohjelman, Module Compilerin. Module Compiler lukee erityistä datapolkujen kuvauskieltä, module compiler language (MCL). MCL:n ulkoasu muistuttaa Verilogia ja C-kieltä. Kieli on Synopsyksen kehittämä ja toimii ainoastaan tässä työkalussa.
Tämä ei välttämättä ole niin suuri haitta kuin aluksi voisi ajatella. Erot yleiskäyttöisten kielien tulkinnassa eri synteesityökalujen välillä erityisesti datapolkujen tapauksessa ovat jo tehneet lähdekoodeista enemmän tai vähemmän työkaluriippuvaisia. Lisäksi MCL-kielellä on kevyt kielioppi, joten sen käyttöönottokynnyksen pitäisi olla matala.
Suunnitteluvuo Module Compilerilla on samantapainen kuin rekisterinsiirtotason synteesiohjelmilla. Ainoa merkittävä ero on rekisterinsiirtotason simulointi. MCL-kielelle ei ole olemassa simulaattoria, joten suunnittelu on aina ensin syntesoitava. Synteesituloksesta Module Compiler tuottaa käytöstason mallin, jonka suunnittelija voi simuloida. Käytännössä tämä ei tuottane ongelmia, sillä synteesiajat ovat suhteellisen lyhyitä ja generoidun käytöstason mallin simulointi on nopeaa. Luonnollisesti optimoinnin jälkeen varsinainen porttitason simulointi on myös mahdollista. Module Compiler tukee kahden komplementti lukujärjestelmää negatiivisille luvuille.
Suunniteltava datapolku voidaan liukuhihnoittaa automaattisesti tai käsin. Module Compiler osaa liukuhihnoittaa polun mistä kohtaa tahansa myös aritmeettisten lohkojen keskeltä. Automaattista liukuhihnoitusta käytettäessä, Module Compiler osaa myös viivästää sisääntuloja siten, että logiikkapolkujen syvyys (latency) on oikea.
Koko suunnittelun syvyyttä ei kuitenkaan voi antaa optimointiparametrina. Jos suunnitellaan esimerkiksi alilohkoa, jolla tulisi olla tietty syvyys, suunnittelijan on koodissa pakotettava tietty liukuhihnoitus ja kytkettävä automaattinen pois, tai iteroitava oikea syvyys vaihtelemalla erilaisia ajoitusparametreja. Varsinaisia optimointiparametreja ovat piirin nopeuden lisäksi tarvittava pinta-ala ja tehonkulutus. Piirin nopeus on kuitenkin aina ensimmäinen optimointiparametri.
Module Compiler eroaa perinteisestä korkean tason synteesistä sillä, sisään luettava kielen taso vaihtelee operaattoritasolta algoritmitasolle. Lisäksi Module Compiler syntesoi suoraan porttitason vetolistaa. Erillistä HDL-välivaihetta ei ole. Module Compiler tekee siis myös rekisterinsiirtotason synteesille kuuluvan optimoinnin. Tämän pitäisi parantaa optimointitulosta, sillä operaattoreiden arkkitehtuurivalinta ja logiikkatason optimointi ovat lähempänä toisiaan kuin perinteisessä korkean tason synteesivuossa.
Porttitason mallit Module Compiler saa samasta kirjastosta kuin Design Compiler. Pinta-ala ja ajoitusparametrit on kuitenkin skaalattava kokonaisluvuiksi, sillä Module Compiler ei käsittele liukulukuja. Joidenkin piitoimittajien pitää mahdollisesti kirjoittaa uudelleen ja kääntää teknologiakirjastonsa. Module Compilerille on kuitenkin olemassa jo laaja kohdeteknologiatuki.
Cadence on yhdistänyt alunperin ruotsalaisen korkean tason synteesiohjelman Visual Architect (omaa sukua Synt) ja järjestelmän suunnitteluohjelmiston SPW. Tarkoituksena on lähentää systeemi- ja arkkitehtuurisuunnittelua keskenään.
Järjestelmätason suunnittelu ja simulointi voidaan tehdä SPW:ssä, jonka jälkeen Visual Architect rakentaa suunnittelusta tai sen osasta rekisterinsiirtotason kuvauksen. Tämä kuvaus voidaan syntesoida porttitasolle normaalilla rekisterinsiirtotason synteesiohjelmalla tai datapolkutyökaluilla. SPW:n tuottamaa testidataa ja simulointituloksia voidaan käyttää testipenkkinä koko suunnitteluvuon ajan.
SPW on datavuo-orientoitunut DSP- ja telekommunikaatiosysteemien suunnitteluohjelmisto. Suunniteltava järjestelmä kootaan toiminnallisista osista, joiden välille kytketään signaaleja. Valmiilla lisäkirjastoilla SPW:tä voidaan laajentaa useisiin erikoistarkoituksiin. Saatavilla on lukuisia telekommunikaatio- ja signaalikäsittelykirjastoja. Lisäksi on mahdollista suunnitella omia lohkoja.
On kuitenkin huomattava, että Visual Architectiin voidaan syöttää vain erityisen HDS-kirjaston (HDS = Hardware Design System) moduuleista koottuja järjestelmiä. Mitä tahansa systeemiä, joka on mahdollista kuvata SPW:llä, ei siis voi automaattisesti syntesoida. HDS kirjasto on erityisesti laitteistosuunnitteluun tarkoitettu kirjasto, joka sisältää kiinteän pilkun aritmeettisia funktioita sekä bittitason loogisia lohkoja.
HDS-lohkoista suunniteltu systeemi syötetään korkean tason synteesiin. Visual Architect generoi datapolku-kontrollerityyppisen piiriarkkitehtuurin suunnittelusta. Koska SPW:n simulaattori on datavuo-orientoitunut, ajoitus astuu vasta nyt varsinaiseksi systeemiparametriksi. Suunnittelun optimointi on vuorovaikutteista ja suunnittelija saa välittömästi palautetta erilaisista ajoitus- ja arkkitehtuurivalinnoista.
Optimointiparametreina voidaan antaa muun muassa käytettävissä olevien kellojaksojen määrä, kellojakson pituus sekä haluttu liukuhihnoituksen määrä. Myös käytettäviä muistimalleja on mahdollista vaihtaa ja suunnittelija voi valita, käytetäänkö muistina rekistereitä vai RAM-muistia. Käyttöliittymältään Visual Architect on selkeä ja helppokäyttöinen.
Visual Architect tarvitsee porttitason kirjaston kohdeteknologiasta, jotta käytettävien komponenttien ja operaattoreiden todelliset kustannukset olisivat tiedossa. Teknologiakirjastot ovat tekstimuotoisia, ja siten suunnittelijan itse modifioitavissa.
Suunnittelija voi myös lisätä omia komponentteja datapolkukomponenttien kirjastoon. Design Compilerin käyttäjät saattavat esimerkiksi haluta ottaa käytettävissä olevat DesignWare komponentit mukaan korkean tason synteesiin. Kokonaan uusia kohdeteknologioita varten on olemassa työkalu, joka generoi automaattisesti kirjaston Visual Architectille.
SPW:n ja Visual Architectin voima on helpossa aloituksessa arkkitehtuuritason suunnitteluun. Hyöty on ehkä suurempi systeemisuunnittelijalle kuin jo kokeneelle arkkitehtuurisuunnittelijalle. Vaikka lopputulos ei olisikaan optimaalisin mahdollinen, SPW ja Visual Architect tarjoavat nopean reitin spesifikaatiosta lopputulokseen ja erinomaisen ympäristön erilaisten arkkitehtuuriratkaisujen ja rajoitetun sananleveyden vaikutusten tutkimiseen.
Työkalutoimittajat ovat lähteneet tehostamaan HDL-pohjaisia suunnittelumenetelmiä eri lähtökohdista. Yksinkertaisimmillaan suunnittelua helpottava työkalu on käytettävän kielen rakenteen osaava editori. Toista laitaa edustavat korkean tason synteesityökalut, jotka muuttavat koko suunnitteluvuon erilaiseksi.
Luonnollisesti eri lähestymistavat ratkaisevat erityyppisiä ongelmia. Jokaisen suunnittelijan tulisikin kartoittaa omassa työssään esiintyvät ongelma-alueet, ja etsiä ratkaisua tältä pohjalta. Kaikki ongelmat ratkaisevaa hopeista luotia ei ole näköpiirissä.
EDA: Electronic Design Automation
GPL: General Public License
HDL: Hardware Description Language, esimerkiksi VHDL ja Verilog
RCS: Revision Control System
RTL: Register Transfer Level, rekisterinsiirtotaso
SA: Structured Analysis, tietovuohon perustuva systeemien mallinnusmenetelmä