digitaal fotolijst op basis van FPGA

Ik raad je aan om eerst eens te proberen om gekleurde blokken te maken op je FPGA. Daarmee kun je dan timing en zo onder de knie krijgen. Daarna pas de functies implementeren om afbeeldingen te tonen. Mogelijk zijn er al standaard VGA libraties beschikbaar?

Vergeet ook niet naar fotoopa z'n site te gaan. Die heeft voorbeeld FPGA-code om een vga scherm aan te sturen. ....

http://www.opencores.org/projects?cat=15&lang=0&stage=5&lic=0

Ik denk dat je een soort van Framebuffer nodig zal hebben. Een stuk geheugen waar je je hele plaatje (ongecomprimeerd) op heb staan. Het makkelijkste is blockram gebruiken van je Spartan FPGA, maar dit zal waarschijnlijk niet genoeg zijn voor een volledig resolutie plaatje. (320x240x8bpp -> 76800bytes). Daarnaast zou je SRAM kunnen gebruiken, maar zo te zien heeft je starter kit dit niet. Ik zie wel dat je 64MB DDR ram tot je beschikking hebt. Dit zou je kunnen gebruiken maar het zal niet makkelijk zijn als beginner.

Ik weet niet wat jouw voorkeur is voor taal, VHDL/Verilog. Maar op fpga4fun hebben ze een uitstekende beginners project in Verilog.
http://www.fpga4fun.com/PongGame.html
Ik raad je aan dit eerst te proberen. Het moet niet al te moeilijk zijn.

Wel toevallig, zelf ben ik nu ook bezig met een FPGA en VGA. Ben op het moment me SDRAM Framebuffer aan het debuggen. Ergens loopt er een teller niet goed...

Succes!

Goed, VGA code is af. Vast beeld op een oude CRT, kleuren te wisselen door knopjes.
Als ik echter mijn LG scherm aansluit, komt er geen beeld (LG L1715S)
beeld is 640x480 @ 60 Hz, volgens de specs zou het goed moeten gaan.

http://www.superwarehouse.com/LG_Flatron_L1715S_17_LCD_Monitor/L1715SS…
wellicht een pulsje net te lang/te kort, even verder testen.

Herkenning voor iemand?

@hvwieren

Je gebruikt de VGA code van FPGA4fun? Die is niet echt binnen spec toen ik die laatst gebruikte. Ik heb een nieuwe sync generator gemaakt waarin je alle timings kan aanpassen, deze werkt op VGA en op een sharp LQ043 (LCD scherm uit een playstation portable).

Trouwens dat Playstation portable schermpje is een heel mooi schermpje voor het weergeven van plaatjes, misschien wat voor jou? Lage prijs en makkelijk aan te sturen.

Squant.
dank voor je reactie, ik zal zeker even naar dat schermpje kijken (prijs etc).
Ik heb de VGA driver zelf geschreven, aan de hand van de informatie in de Spartan-3E Starter Kit Board User Guide, pagina 56.
de informatie is echter wel iets anders dan de info hier.

Hoeveel lijnen moet ik nu sturen per scherm?
ene document heeft het over 521 (Xilinx) andere over 525 (internet).

trail and error...

[edit:] zou het kunnen komen door het feit dat mijn pixelklok 25 MHz is en niet 25.175 MHz zoals nodig?
is een LCD zo precies?
en wanneer dit het is, zou ik dit op kunnen lossen?

[Bericht gewijzigd door hvwieren op zaterdag 27 februari 2010 12:52:17 (14%)]

Volgens die website is er maar 1 standaard: er is geen standaard! Ik zelf hou het bij 525, volgens de epanorama site. Dus zover geen problemen ermee. Verder draait mijn VGA core ook op 25MHz, moet goed zijn. Je kan even checken of je LG uberhaupt 640x480 kan draaien.

1) Vaak komt het niet zo precies. Maar....

In princiepe kan je WEL lijnen tellen, maar niet pixels. Dus als je 0.7% te langzame klok hebt, kan je formeel maar 635 pixels in het "beschikbaar voor beeldinformatie" gedeelte stoppen. De timing van dat stuk klopt dan wel. standaard PC-vga dingen kunnen slechts veelvouden van 8 aan in de H-timing, dus die zouden dan met een probleem zitten. Maar goed, Ik geloof dat de normale timing uitgaat van H-total van 800. (nagerekend, klopt precies). Ik weet de timing niet exact uit m'n hoofd, maar wat het display kan zien aan je signaal is dat ie 31500 keer per seconde een hsync pulsje krijgt en hoe lang ie duurt. Daarnaast zijn er afspraken waar de display data zou zitten t.o.v. het pulsje (front porch, back porch noemen ze dat).

In de praktijk denk ik dat ie ergens anders over struikelt dan dat je klok net niet goed is. Die 0.7% moet ie tegen kunnen. Ook 525 versus 521 zou niet uit mogen maken. Heb je wel precies 3 "VSYNC actief" lijnen?

Heb je miscchien de polariteit van je hsync verkeerdom?

[Bericht gewijzigd door rew op zaterdag 27 februari 2010 13:32:23 (43%)]

@hvwieren

Ik heb de informatie van digilent aangehouden, heb het daarna op alle schermen getest in huis en werkt goed. Ik heb ze ook op beide pixel klokken getest, 25MHz en 25.175MHz enige verschil is dat monitoren dan spreken over 59Hz dan 60Hz refresh rate.

@rew

Goh, ik heb dus ook exact zelfde probleem gehad, plus ook fouten in de timing van de porches en beeld data. Tijden tussen de sync's was geen probleem, alleen beeld data kwam veel te laat. Mijn CRT's die deden dat zonder te morren, maar LCD's kunnen daarvan de kluts kwijtraken.

Issue was dat ik dus niet lang genoeg wachtte na de beeld data. Zodoende me VGA code herschreven en zo ingesteld dat ik heel makkelijk alle data in kan vullen zoals zoveel pixels horizontaal, vertikaal en hoe lang de syncs en porches zijn.

Op 27 februari 2010 14:45:37 schreef Squant:
Goh, ik heb dus ook exact zelfde probleem gehad, plus ook fouten in de timing van de porches en beeld data. Tijden tussen de sync's was geen probleem, alleen beeld data kwam veel te laat. Mijn CRT's die deden dat zonder te morren, maar LCD's kunnen daarvan de kluts kwijtraken.

Bekend probleem. Nog eens goed naar de front en backporch gekeken, mijn puls zat 2 tellen verschoven, 2 tellen te vroeg dus.
LCD gaat nu ook netjes aan, en ik kan mooi 8 kleuren selecteren.

Volgende stap: Data uit geheugen halen.
Hier heb ik wel nog steeds een vraag over, kan ik tijdens het inladen van mijn programma ergens in het geheugen vaste data neerzetten? Op deze manier zou ik bijvoorbeeld makkelijk een paar blokjes klaar kunnen zetten en die uitlezen.
Als dit niet mogelijk is moet ik eerst een module hebben welke data wegschrijft en als dat gedaan is een ready signaal naar mijn VGA driver sturen. Is natuurlijk ook een goede optie, maar iets meer werk.

Foto's van een beeldscherm met verschillende kleurtjes geloven jullie wel denk ik he?

Ja. dat kan.

Ik heb het ooit gedaan, maar ik weet niet meer hoe.

We hebben een softcore in de FPGA gedaan, en in het begin moesten we de FPGA configuratie opnieuw maken om een ander programma in de CPU-in-de-FPGA te zetten. Later hebben we een optie gemaakt om het buitenlangs ook te kunnen.

Je kan een rommetje maken en een hex file er inladen.

Dank voor jullie reacties tot zo ver.
Ik ben gisteravond nog even verder gegaan, maar nog niet het gewenste resultaat.
Tussenstap waar ik nu mee bezig ben is:

• VGA data lezen uit block RAM
• controle blok welke data naar block RAM schrijft bij indrukken toets

het block RAM is 19k2 groot. Dit is genoeg voor het opslaan van 160x240 pixels, bij 3 bit per pixel. Horizontaal stuur ik gewoon 2x dezelfde data om een resolutie van 320x240 te krijgen.

Het controle blok heb ik ontworpen als state machine. Eerst zal het block RAM geschreven worden met data (2 horizontale balken van 32 rijen breed). Hierna zal de VGA driver een enable krijgen en wordt er gewacht op het indrukken van een toets. Wanneer dit gebeurd zal de VGA driver gedisabled worden, zal het block ram geschreven worden met nieuwe data (zelfde idee, andere kleur). Wanneer dit gedaan is zal de VGA driver weer data uit mogen sturen.

Momenteel heb ik alle modules gemaakt, de statemachine loopt correct door de verschillende states heen (getest met LEDS), en het VGA scherm gaat ook aan en uit op de juiste momenten.

De data wordt echter nog niet correct uit het block RAM gelezen of correct erin geschreven, want op het beeld verschijnt enkel een zwart blok in het middel van 320x240 pixels met daaromheen witte randen.
Ik zal deze week dan ook proberen een chipscope module in het ontwerp te koppelen en hiermee te controleren of de data correct naar het block ram gaat.

Ik heb thuis een mooi blokschema gemaakt van het ontwerp tot nu toe en een flow diagram voor de state machine, wellicht heb ik tijd dit even in visio te tekenen en hier te posten.

[edit:]
Natuurlijk is het aanwezige block ram niet toereikend genoeg voor de applicatie die ik uiteindelijk wil bereiken. Hiervoor zal ik toch echt een keer het externe DDR ram geheugen moeten gaan aanspreken. Aangezien het geheugen groot genoeg is wil ik dan twee blokken van 640x480x3 gaan gebruiken, 1 met data welke op dat moment op het VGA scherm zichtbaar is en 1 waarin een volgende afbeelding opgebouwd wordt.

De tijd die nodig is om een afbeelding op te bouwen zal dan wel relatief lang worden, aangezien het geheugen de meeste tijd uitgelezen wordt.

[Bericht gewijzigd door hvwieren op dinsdag 2 maart 2010 13:24:43 (15%)]

Je kan altijd op een hogere snelheid schrijven dan uitlezen

Nu je met on-FPGA RAM werkt, kan je makkelijk zeggen dat dit dual-ported moet zijn. Omdat dit wel eens voorkomt, heeft de fpga-fabrikant bijna alle onboard rams van twee poorten voorzien. Dus als jij zegt dat je maar 1 poort nodig hebt, gebruikt ie de andere poort gewoon niet. Makkelijk toch?

Tegen de tijd dat je een externe dram gebruikt, moet je gaan truuken. Bijvoorbeeld: data opslaan in een FIFO. Zodra de VGA module geen beeld-data meer nodig heeft (hsync of vsync), doe je snel een paar writes naar het video-geheugen....

Goed, gisteravond wat chipscope testen gedaan.
Data gaat goed het block RAM in, maar komt er niet meer uit.

Het block ram heeft aparte data en adres lijnen voor read en write mode. Het block ram staat wel in read mode, maar de adreslijnen geven geen correcte waardes.

Uit mijn VGA module komen twee telwaardes, Hcount en Vcount. Hcount loopt van 0 tot 160 en Vcount van 0 tot 240. het readadres moet dus worden: Vcount*80 + Hcount/2

Ik ben bang dat ik de * 80 functie niet goed uitvoer.
Hoe raden jullie aan om dit te doen?

Je zou een losse teller voor de pixels kunnen laten lopen en die gebruiken als adresteller voor je ram. Als je * 80 schrijft dan zou het best kunnen dat er een multiplier gemaakt wordt.

[color=grey]_{Btw, hey miniK0bo!}[/color]

Gisteravond verder gegaan, VGA module aangepast zodat er een pixelteller meeloopt.
Ook aanpassingen aan de rest van de code gedaan, onder andere het block ram.
Nu past mijn ontwerp echter niet meer in het device, en krijg ik 2000+ warnings op de block ram code. Hier heb ik echter niet veel aangepast, alleen het ram laten reageren op een falling edge in plaats van een rising edge, zodat de data uit het ram een halve klokperiode eerder uitgestuurd wordt voordat deze ingelezen wordt door de vga module. Zo weet ik zeker dat de data stabiel is.
Kan dit veranderen van de klokflank problemen opleveren, of is het gewoon de grootte van het gekozen block ram? (19k2 en 9k6 geprobeerd)

@hvwieren

2000+ errors? hoe heb je die blockram aangemaakt? Dat je device gelijk vol zit klinkt als dat je geheugen niet als blockrams wordt geinstantieerd maar als flipflops.

Laat even de blockram code eens zien?

In "echte" vga chips is het zo dat zodra hpos (actuele waarde) == htot (ingestelde beeldschermgrootte horizontaal) dan doet ie: "pixelpos += skip".

Jij wilt daar dus voorlopig gewoon skip=0 doen.

Anderzijds, begrijp ik nu goed dat jij een hele byte uit een geheugen ophaalt, en vervolgens de boven of de onderkant gaaat gebruiken? Je kunt veel beter gewoon een vierbit breed stuk geheugen nemen.

Trouwens, als je maar 3 bits per pixel gebruikt, kan je misschien nog zuiniger met geheugen doen door een buffer te maken. Je pakt steeds de onderste drie bits uit de buffer, en zodra er minder dan drie over zijn, haal je de nieuwe byte op uit de RAM.... Hoef je maar een 10bits schuifregister voor te maken.

Maar goed. Dat is natuurlijk allemaal niet nodig. Straks zet je er een extern geheugen op, en dat is natuurlijk zomaar ruim groot genoeg, dus bitneuken om nu een paar bits te besparen hoeft niet.

Het zou zomaar kunnen dat RAM in de hardware gewoon synchroon is. En dat je niet kunt kiezen welke flank. Dus zodra jij opschrijft dat het de negatieve flank moet zijn, kan ie niet anders doen dan het met losse flipflops te implementeren. Je 19k videobuffer neemt dan ineens alle LEs die je FPGA bevat in beslag....

dank voor jullie reacties.
ik zal eind van de middag als ik thuis ben de block ram code even posten.
Het lijkt er idd op dat er flipflops gebruikt worden.
Kan ik ergens visueel zien wat er gemaakt wordt van mijn code?

@rew,
ik gebruik de onderste 6 bits per byte voor 2 pixels.

Over dat externe geheugen, is het te doen zelf een driver ervoor te schrijven of kan ik beter een bestaande gebruiken?

Ik ben niet beroerd de datasheet door te lezen, maar heb liever niet dat het veel meer dan bijvoorbeeld 2 weken werk is.

Ik heb voorzichtig geprobeerd om iets met RAM te doen vanuit een FPGA, en dan met de meegeleverde "handige" module. Dat is niet gelukt.

Maar zo hard als jij nu gaat, heb je meer talent dan ik.

Wat ik aanraad, is om gewoon 2 dagen te investeren om het zelf te doen. Da's niet omdat die module van Xilinx niet goed is, maar om het te leren.

Lees het datasheet van de dram chip, probeer daar een module voor te maken. Als je dat gedaan hebt, kan je voortaan de module van xylinx in 1x goed instellen. Anders zit je zoals ik: Ehh, dat weet ik niet, noot van gehoord. En als de term die Xilinx gebruikt dan anders is dan die van de memory fabrikant, dan kan JIJ dat gewoon toch linken, terwijl ik met de handen in m'n haar zit.

Nou rew, voor mijn gevoel ga ik echt niet hard genoeg hoor! Ik had eigenlijk gehoopt dat block ram in 1 of 2 avonden af te hebben en dan de eerste variabele data op mijn scherm zichtbaar te hebben, het worden er 4 of 5.
maargoed, ik kan inderdaad de datasheet doorlezen en een eerste ontwerp maken, zeker om de werking door te hebben is dat verstandig.
Over de snelheid waarmee ik werk, ik heb al enkele ervaring met FPGA's ivm mijn studie elektronica, dus geheel onbekend ben ik er niet mee.
(laatste project met FPGA was het maken van een netwerkkaart. Vanuit de PC stuurde je seriele commando's naar een ARM, deze stuurde data naar de FPGA, die zette adressen etc erbij, deed CRC en stuurde uit. Ontvangen zelfde, maar andere kant op.)