Moi.
Hankin tossa jouluna Spartan 3e(xc3s250) ympärille pienen harjoitus alustan ja olen ISE(Xilinx WebPack) IDEllä kopeloinut sitä ja värmäsin STN-paneelille pienen softa modulin joka piirtää neliön, eli siis yksi process laskurina ja paaaljoon if () then lauseita. Tässä vaiheessa olen sitä mieltä että nyt ei oikein "tartu".
Eli olenko vaan näin tyhmä, vai onko VHDL todella näin vaikeata?
Ja please, postatkaa linkkejä VHDL tutoriaaleihin, oppaita ja yleensä kaikkea mikä liittyy aiheisiin FPGA, VHDL, PLD.
Tässä esmes: http://www.seas.upenn.edu/~ese201/vhdl/vhdl_primer.html
www.moli.uwaterloo.ca/VHDLTutorial/vhdl2005-audio.pdf
Kannattaako opetella VHDL vai Verilog? onko paljon eroa?
T: dazled
Hankin tossa jouluna Spartan 3e(xc3s250) ympärille pienen harjoitus alustan ja olen ISE(Xilinx WebPack) IDEllä kopeloinut sitä ja värmäsin STN-paneelille pienen softa modulin joka piirtää neliön, eli siis yksi process laskurina ja paaaljoon if () then lauseita. Tässä vaiheessa olen sitä mieltä että nyt ei oikein "tartu".
Eli olenko vaan näin tyhmä, vai onko VHDL todella näin vaikeata?
Ja please, postatkaa linkkejä VHDL tutoriaaleihin, oppaita ja yleensä kaikkea mikä liittyy aiheisiin FPGA, VHDL, PLD.
Tässä esmes: http://www.seas.upenn.edu/~ese201/vhdl/vhdl_primer.html
www.moli.uwaterloo.ca/VHDLTutorial/vhdl2005-audio.pdf
Kannattaako opetella VHDL vai Verilog? onko paljon eroa?
T: dazled
Vastaukset 31
Vanhimmat
"Kannattaako opetella VHDL vai Verilog? onko paljon eroa? "
Keskity suoraa kunnolliseen kehitysympäristöön, jolla saa aikaan ja voi laskuttaa asiakkaalta enemmän kun tuottavuus kasvaa, opettele .NET. Kun sen osaat ei muuta tarvi, kieli ja työkalut ovat ylivertaisia kaikkiin muihin. Sillä saa kaiken tehtyä.
Reps (movsd)! Tuo Jepulis Jeep todellakin aina tyrkyttää sitä .NET:tiään. Itse en ymmärrä, kun saman tekee Javalla ihan yhtä hyvin joka suhteessa kun jollain C#:lla. No, paitsi että Java-hommia voi ajaa ihan oikeilla servereillä. Edellinen lause ei ole sitten mikään provo, vaan totuus: kovimmilla ibarin power-pohjaisilla servereillä ei .NET CLR:n ajaminen vain onnistu.
Btw, käytän seuraavia tilanteen mukaan, toimii hyvin: C/C ( jokin skriptikieli), Java, perl ja PHP. Hyvin ja nopeasti pärjätään noilla. Ainiin, olen myös C#:lla tehnyt. Ja alustoina on mm. Windows, Linux, *BSD, S60 ja Solaris tuttuja. En yritä kehua tällä, vaan painottaa sitä, että eri tarkoituksiin eri työkalut on parhaita. Jos sitä ei tajua, on väärällä alalla!
Ite käyttelen käytännössä tota C:tä, Javaa ja .NET:ä. Minkäs sille voi jos toi .NET on sopinut pikkasen paremmin täälläkin esillä olleisiin tapauksiin kuin vaikka nyt joku C. Pyyttonillakin meinasin tehä yhteen väliin, mutta kun oli pikkasen surkeeta semmosten tarttemieni hommien tuki niin jäi siihen.
Tommonen, että ympäristöä ei ole, on ihan selvää kauraa. Tosin vaan tommosia rojekteja joissa softaa ajetaan kovimmilla iparin poverpohjasilla koneilla, ei sitten loppujen lopuksi Suomessakaan ole edes sitä enemmistöä kun työtunteja katotaan.
Eiköhän se meikäläisen jutuista pitäsi tulla selväksi lähinnä se, että .NET:llä tekee myös hommaa eikä kaikkea tartte vääntää C:llä tai Pyyttonilla siltä varalta jos asiakas vaihtaa ympäristönsä.
>Kun sen osaat ei muuta tarvi, kieli ja työkalut ovat ylivertaisia kaikkiin muihin.
Just' just'.
Taidat olla mikkismerkonomi vai mitä tradenomeja ne nykyään on? ;)
Teillä muuten tuntuu menevän vähän heikosti siellä Microsoftilla. Saitko jo kenkää?
jotka luulevat kielen ja systeemin yleensäkin pystyvän mihin tahansa jos se on hyvä jossain. Samat kaverit aattelee sitten, ettei kielestä ole mihinkään jos se ei sovi tarkoitukseen y.
Kun saat hieman teknistä osaamispohjaa varustettuna elämänkokemuksella rupeat hiffaamaan mistä on kyse. Tule 10v päästä lukemaan näitä viestejä, niin saat hyvät naurut.
Vaikutat hyvin kokemattomalta.
Moi.
Kiitos vinkistä, monolla olen tähän asti porskutellut :)
Muistan kuinka joskus vaahtosammuttimen kokosena harrastettiin tommosta.
Ette sitten tajunnu mistä tässä edes puhuttiin.
>ihan yhtä hyvin joka suhteessa kun jollain
>C#:lla.
Ihan yhtä hyvin tai melkein:) Clientti- sovelluksia en javalla tekisi. .Net sopii useampaan tarkoitukseen kuin java - usko jo se fakta.
Mites javalla teet ne windows- servicet? Entä grafiikkaa vaativat väännöt? Pärjääkö XNA:lle?
Kyllä se .NET vain on hyvin monesti parempi ratkaisu. Ei sitä pääse karkuun. .NET on tuottava ja kätevä kieli, jonka käytön esteitä ei ole kuin osaamattomuus.
Kunhan ihmiset ymmärtävät .NET:n ruvetaan sillä tekemään käytännöllisesti katsoen kaikki pankkisovelluksista kännykän puhelinluetteloihin. Kun ymmärrät tämän osoitat ammattimaisuutesi.
Oikeen välineen käyttämistä estää useimmiten se osaamattomuus. Se ei vaan tarkota sitä, että pitäs osata kaikki tekniikat jotta vois käyttää aina optimivälinettä. Kaiken opettelu kun ei oo ihan kauheen järkevää.
http://www.fpga4fun.com/
http://www.interq.or.jp/japan/se-inoue/e_cpld.htm
" värmäsin STN-paneelille pienen softa modulin joka piirtää neliön, eli siis yksi process laskurina ja paaaljoon if () then lauseita. Tässä vaiheessa olen sitä mieltä että nyt ei oikein "tartu".
Eli olenko vaan näin tyhmä, vai onko VHDL todella näin vaikeata?"
Olen tehnyt VHDL:llä n. 6v töitä ennen palaamistani (10v sitten) pehmeiden ohjelmistojen pariin (C ).
Mutta kerro nyt mihin suunnittelet VHDL:ää käyttäväsi? Neliön piirtäminen kuullostaa siltä, että olet tekemässä grafiikkaohjainta. Grafiikkaohjain muodostuu väkisinkin isosta joukoista toiminnallisuuksia (jotka tietenkin voi olla jo osittain valmiina). Minulla on esim jemmassa muinoin suunnittelemani kellojaksoja haaskaamaton moniporttiohjain SDRAMmille, jota yritin patentoidakin, mutta ASIC-toteutusten patentointikriteerit työnanajallani muuttuivat, eikä enään kelvannut (vaikea valvoa). Mutta esim sellaista voisit tarvita grafiikkaohjaimeesi.
VHDL ei ole "korkean tason ohjelmointikieli", vaan erikoistunut bittien kääntelyyn kellojakson tarkkuudella. Mutta hierarkista suunnittelua käyttäen ja turvautuen esim ulkoiseen ulkoiseen muistiin voi tietysti VHDL:llä (tai Verilogilla, en painottaisi eroja) tehdä mitä vaan jos portit riittää.
Moi.
Kyllä olen kirjoittamassa "grafiikkaohjainta".
Tarkoitus vielä tässä vaiheessa ei ole (sillä olen aika pihalla viellä) toteuttaa näytönohjainta mitenkään monimutkaisesti vaan tehdä mahdollisimman yksinkertaisesti.
Käytössä:
128kB flash -> softa.
64kB sram -> kuva ja käyttömuisti.
Laite:
XC3S250E -> clk 66Mhz, samalla levyllä ohjelma ja käyttömuistit(flash, sram) tosin levy toteutettu niin että voidaan lisätä ulkoisia komponentteja helposti, esim dram muisti.
Hitachi 800x600 paneeli -> 15bit mutta käytössä 3 bit R,G,B. Tosin muistin puutteen vuoksi.... käytän 1bpp (musta/valko) -> (800 x 600) / 8 = 60kB kuvalle -> 4kB käyttömuistia.
Tarpeet:
I2C liityntä ohjaukseen.
Näytölle HSYNC,VSYNC,CLK,DEnable,Data.
Näytön kello(Clk) taajuus 16Mhz.
API:
Aseta tavu muistiin joka esitetään seuraavalla päivitys kerralla.
Erityinen syy FPGA:n käyttöön? Muutamalla eurolla saa 32-bittisen kontrollerin joka jaksaa 800x600 1-bit näyttöä pyörittää, ja josta löytyy 128kB muistia, 64 kB NAND, I2C, 1wire, SPI, sarjaportti ja liuta I/O lähtöjä, yms. Sellaisiakin malleja löytyy joissa on myös "raakapaneeliohjain" valmiina. Muutoin voi aina käyttää SPI:tä tukevaa paneelia, ihan hyvin tuloksin. Ja homman voi tehdä ihan C:llä, ehkä hieman assembleria mausteeksi jos nopeuden puute ahdistaa. Yleensä ei tarpeen.
Moi.
Miksi käyttää uC? miksen saman tien osta uutta näyttöä? pääsen "helpommalla".
Eli ideanahan on että uC on... hmm... tai siis oikeastaan se ei ole. Se ei ole sopiva päneelin käyttöön.
Mietitäänpä vähän, paneelissa on 800x600 pikseliä jokaista pikseliä varten täytyy antaa 1 kello pulssi.
Jos haluttaisiin 5fps "taso" tarvitaan (800 * 600 * 5) = 2.4M kellopulssia. Jos valmistaja lupaa uClleen vaikkapa 40MIPS voi tällöin tuon yhden framen aikana suorittaa (40 / 2.4) = 16 käskyä.
Voinko 16 käskyllä toteuttaa lataajan joka siirtää muistista datan paneelille ja kuuntelee samalla i2c väylää? Entä jos haluan 15fps löytyy kyllin nopeata uCta?
Sitten aiheeseen "raakapaneeliohjain", tuo kyllä on aika houkuttelevaa, mutta eipä taida olla oikeen piirejä tähän, vai? Tässä haen oikeastaan sitä että vaikea löytää sopivaa eval kittiä tomosselle, siis "hieman liian iso näyttö" ongelma.
Tarkoitus on tehdä paneelille ohjain ei käyttää "valmista näyttöä". Muutoinhan tämä keskustelu voisi edetä siihen pisteeseen että. "miksi ei osta valmista näyttöä, pääse kaikista helpommalla ja käyttää senkin tuhraamiseen käytetyn ajan vaikkapa... pelaamiseen."
T: -> tulipa tästä pitkä :/
Eihän mikrokontrollerilla ihan koodilla lähetetä pulsseja näytölle. Kyllä sekin varmaan onnistuu, mutta kun on vähän virtaa syövä kellopulssit yms lähettävä logiikka valmiina, DMA:lla...
SPI-vaihtoehdossa näytöllä on tietysti oma logiikka ja sen framebufferiin pääsee kirjoittamaan. Vaikka tämä ei hintaa paljon lisää, se voi silti olla huonompi vaihtoehto virrankulutuksen suhteen. Lisäksi pitänee olla uC:ssä oma framebuffer, ettei turhaa lähetä SPI:n yli, tosin riippuen SPI:n kellotaajuudesta. SPI:stäkin menee megabittikaupalla sekunnissa tavaraa yli, 1-10 Mbit/s olen nähnyt. Sellainen uC missä on bufferoitu SPI-lähetyslogiikka (tai peräti DMA) on tietysti paras. 800x600 kun on vain 480000 bittiä.
1-bit näytössä muuten 32-bittinen prosessori tyhjentää yhden 32-bittisen sanan per muistisykli (tai 2 jos on 16 bittinen väylä muistiin), joka sisältää siis 32 pikseliä. Fontit ja bittikartat on helppoa ja nopeaa kopioida ja shiftata tarvittava määrä bittejä. Ei niitä pikseleitä yksittäin tarvitse piirtää! Lopuksi vaan load-or-store framebufferiin ja 16 tai 32 vaakapikseliä menee per loopin kierros, nopeaa, ja jos framebufferissa ei ole alla mitään, OR:raa rekisteriin ja store muistiin vaan, säästäen loadin. Vaakaviivat ovat helppoja, maskaa vaan viivan alun ja lopun pois, muuten pelkkä filli. Pystyviivat vievät hieman enemmän tehoa, muttei silti niin paha. Viivanpiirto prosessorista riippuen DDA:lla tai bresenhamilla. Fillatut polygonit saa ihan tavallisella y-sorttaus-scanline metodilla, ja kun fiksusti tekee, parhaillaan 32-pikseliä per sisimmän loopin kierros. Jos kolmiot kelpaavat, saa vieläkin nopeamman. Jos on ovela, saa eri piirtomoodit (OR, XOR, NAND) vain muuttamalla sisimmän loopin opcodea ennen rutiinin kutsumista. Ei sitä silti tarvitse assyllä vääntää, kunhan katsoo kääntäjän outputtia hieman.
Kun kuitenkin muistaa, että 20 vuotta takaperin tehtiin *hitaammilla* prosessoreilla ihan filled polygon 3D-pelejä...
Pari vuotta sitten leikin tuollasella, ja ihmettelen jos yksi 800x600 1-bit ruutu ei vastaavalla päivity. Omassa sovelluksessa oli 320x240x1 bit ja nopeutta piisasi yllin kyllin. uC oli muistaakseni 16 MHz opencore.
Tietysti jos harjoituksen vuoksi saman tekee FPGA:lla, mikäs siinä sitten. :)
Tosin yleensä ei tarvitse koko ruutua piirtää, ellei ole peli kyseessä, eikä aina silloinkaan.
Ellei tietysti siihenkin ole oma bufferointi uC:ssä. Ja koodinkin voi suojata uteliailta, kun hommaa sellaisen uC:n missä on AES salausmoduuli ja ns. 'sulakemuisti' salausavaimelle.
Moi.
Olen pahoillani kun en osaa selittää ongelmaani oikein sillä teillä ei näytä olevan minkäälaista, edes ideaa mistä minä kirjoitan.
T: Löydätkö läppäristäsi tähän projektiin soveltuvan näyttö paneelin? Minä olen suunnittelemassa sitä sun ATI/nVidia/Intel ohjaintasi. Tosin hieman raakileen.
Moi.
Voisitko postata tänne koodin joka ohjaa tätä näyttöä: www.gblcd.com/datacenter/samsung/LTN154X1-L02.pdf ja mieluiten 15fps nopeudella?
Niin ja tuo näyttö ei ole se mille olen sehittämässä ohjainta, tuo olisi kohteena seuraavana jos saan tämän toimimaan mieleisekseni :)
T: Yritä edes, jooko.
Ei taida FPGA:nkaan rahkeet tuollaiseen riittää. Se signaali on sellaista mössöä oskilloskoopilla katsottuna... No ehkä olen väärässä.
Moi.
Nyt en oikein ymmärtänyt kysymystä, "Aiotko todellakin jutella LVDS:ää..... jotain ihmettä".
Eli eihän se FPGA juttele tolla tavalla vaan se juttelee tuo: focus.ti.com/lit/ds/symlink/sn75lvds84.pdf kautta.
T: Kyllä, FPGA:n rahkeet riittää tuollaiseen.
Luultavasti olet tekemässä jotain tämän kaltaista mutta paneelinäytön ohjainpiirin ohjainta. http://www.ulrichradig.de/home/index.php/cpld/8bit_c_graka
Niin, noin pienellä muistilla ei todella muuta saa aikaiseksi kuin mustavalkonäytön hyvin pienellä funktionaalisuudella.
"Oikea" 800x600 grafiikkaohjain tarvitsisi 480 000 pikseliä X 3 tavua väreihin eli 1 440 000 tavua pikseleille videomuistia. Sitten tarvittaisiin toinen muistialue grafiikkaprimitiiveille, vektoreille, eli 2MB riittäisi kivasti. Käytännössä muistin leveys tulisi olla väh. 32bittiä.
Muistiin pitäisi liittyä neliporttisesti: yksi portti, josta korkeimmalla prioriteetillä luetaan pikselitavuja kolme kerrallaan ja viedään DA-muuntimelle pikselikellon tahtiin. Toinen portti on se, jonka kautta ladataan, koska meillä ei ole varaa kahdennettuun työvideomuistiin, uusia pikseliarvoja videomuistiin. Kolmannen kautta kontrolleri kirjoittaa uusia primitiivejä vektorimuistiin ja neljännen kautta "grafiikkaprosessori" lukee vektoreita ja niiden mukaan manipuloi pikselikenttää.
Kun meillä on 66MHz kello, voisi pikselikello olla esim 1/4 siitä eli 16,5MHz, jolla päästään 34 fps näytön virkistykseen.
Haastavia hommia on tietysti tuon grafiikkaprosessorin suunnittelu ja sitten tuo neliporttirammi, muistityypistä riippuen.
Tämäntasoisia olivat grafiikkaohjaimet 80-luvulla.
En ymmärtänyt ehdotusta tehdä homma mikrokontrollerilla. Ainoa osahomma josta se selviäsi, olisi tuo grafiikkaprosessorin homma.
I2C-väyläohjaimen ole myös joskus toteuttanut, sekin on haastavaa (patsi jos toteutetaan vain osa standardista, joka tässä voi riittää), mutta siihen voi löytyä netistä sorsiakin.
Oikein hieno VHDL-projekti. VHDL:ssä nautittavinta on rinnakkaisuuden hallinta, johon pian pakko siirtyä tosissaan muussakin ohjelmoinnissa multicore-arkkitehtuureiden myötä.
Moi.
Kiitos kiinnostuksesta, tosin... tässä ei tarvita DA-muunninta/DAC:kkia sillä myös paneeli ymmärtää suoraa 3.3v logikaa ;) (huoh.. olen huojentunut tuosta)
Toisekseen itse olen miettinyt kannettavissa masiinoissa olevan SDRAM muistin liittämistä tuohon. Veisi tosin 3-lohkoa liitäntöjä.
Niin ja korjaus myös tuohon "grafiikka prosessoriin" Eli minulla EI OLE AIKOMUSTA toteuttaa tuota itse PROSESSORIA FPGAlle, voisi tulla turhan monimutkainen ;/
Eli siis, ainut mitä tuolla FPGAlla teen on paneelin OHJAIN jota ilmeisesti ainakin aluksi ohjaan I2C kautta (myöhemmin taitaa taipua johonkin tooosi monta kertaa nopeampaan)
Olisi tosi hienoa liittää ARM9:si tohon FPGAn rinnalle jolloin ARM toimii prosessorina (neliöt, kolmiot.... graphic API) ja FPGAlle jää vain paneelille datan piirtäminen.
Tässä on se etu että mikäli muistin nopeus ja määrä riittävät voidaan tuohon liittää useampi paneeli, sillä FPGAllahan voidaan toteuttaa rinnakaisuus "rinnakkaisena".
Pistelen tänne jonnekkin kuvia sitten kun rupee olemaan jotain "näytettävää", tällä hetkellä olen liittänyt kirjotinportin kautta tuon ja ohjailen sillä :/ tosin ..... ei tuolla ainakaan leffoja katso :P ~0.25 fps
T: -> Kiva kun vaihtui libusb API, kun ei muuten olisi jo hommaa.
Moi.
Eli tuommoinen olisi tulossa, tosin tarkoituksena on tehdä vain tuo (hmmm.. mikäköhän olisi oikea termi) ohjain. Eli FPGAlla en rupea kolmoita, ympyröitä.... piirteleen.
T: -
tekisi saman halvalla? Tosin haastetta ei olisi paljoakaan.
Moi.
Joo eli siis kyllähän tuo LVDS onnistuisi suoraankin tolla FPGAlla.
T: Hmmm.... kamalaa olla väärässä.