Tänkte höra om någon annan här har pillat med LCD-controller av typ SSD 1963? Har beställt en sådan som jag väntar på nu. Är en 5" 800*480 med Touch kopplad till en sådan Controller inklusive 1.2 MB SRAM framebuffer. Skulle vara perfekt om någon testat detta och har en snutt VHDL/Verilog som man kan utgå ifrån eller några andra hjälpfulla kommentarer. Egentligen är det väl overkill att överhuvudtaget ha en sådan controller när jag ska koppla den till en FPGA, men priset var så pass bra så jag slog till iallafall.
Produkt: http://iteadstudio.com/store/index.php? ... cts_id=542
Datablad: http://www.techtoys.com.hk/Components/S ... 63_1.1.pdf
Jag har försökt komma fram till vad den maximala bandbredden mellan denna enhet och mitt kort kommer att bli, men inte säker.. 110 MHz max på klockan externt betyder väl att max bandbredd torde bara databussbredden (16-bit/2 bytes max) gånger frekvensen => 110*2 = 220 MByte/s max. Eftersom det dessutom tillkommer några styrkommandon så borde ju den faktiska bandbredden för bild-data ligga aningen lägre tycker jag.. Varje bild för denna skärm bör vara c:a 768Kbyte (800*480 65K färger) och om jag strävar efter 60 bilder/sekund krävs kring 46Mbyte/s dvs c:a 20% av full bandbredden. Tänker jag rätt här?
Jag fattar inte hur jag ska kunna läsa mig till vilken uppdateringsfrekvens denna skärm har? Har alla sådana här samma och i så fall vilken?
Målet jag har är väl att kunna använda denna skärm till många roliga hobbyprojekt framöver.
LCD 5" med SSD 1963 och styrning via FPGA
-
overclocked
- Inlägg: 71
- Blev medlem: 13 juni 2006, 21:34:24
- Ort: Gävle
Re: LCD 5" med SSD 1963 och styrning via FPGA
Dina uträkningar verkar korrekta. Sen beror en hel del på vilket sätt kommunikationen föregår, synkront eller kommando/respons osv. Dubbelklockningsläge osv.
Uppdateringsfrekvens lär ju vara (överföringshastighet / okomprimerad bildstorlek). En tanke kanske kan vara att synkronisera uppdateringar så att uppdateringar ej orsakar jitter i tiden.
Uppdateringsfrekvens lär ju vara (överföringshastighet / okomprimerad bildstorlek). En tanke kanske kan vara att synkronisera uppdateringar så att uppdateringar ej orsakar jitter i tiden.
Re: LCD 5" med SSD 1963 och styrning via FPGA
Jag har en SSD1906 liggande, sannolikt ung. samma krets men inte med fullt så mycket minne.
I grunden är den krets att betrakta som ett vanligt RAM-minne där man skriver vissa data till vissa platser, detta ställer in skärmstorlek i X och Y osv. Jag har ett exempel till SSD1906:
När denna initiering är klar skulle resten tydligen "bara" vara att skriva rätt pixeldata på rätt plats i minnesdelen av kretsen, sedan skulle det hela fungera.
I grunden är den krets att betrakta som ett vanligt RAM-minne där man skriver vissa data till vissa platser, detta ställer in skärmstorlek i X och Y osv. Jag har ett exempel till SSD1906:
Kod: Markera allt
;Init Controller SSD1906
BEGIN
MOV FSTATUS,#11110000B
MOV BUS_DATA,FSTATUS ;Disable All Flash ROM
SETB FLASH
CLR FLASH
MOV CSTATUS,#00000000B ;Enable SSD1906 DB6
MOV BUS_DATA,CSTATUS ;A0=0 Command DB5
SETB FUNCT ;DB3 DATA OUT from MPU
CLR FUNCT
MOV ADD1906,#00000000B
MOV BUS_DATA,ADD1906 ;ADD16, ADD17 = 00
SETB SSDADD
CLR SSDADD
MOV BUSH,#00H ;Memory Clock
MOV BUSL,#04H ;
MOV WORD,#00000000B ;DB5,DB4
CALL WRITE_COMMAND ;BCLK=MCLK 00
MOV BUSH,#00H ;REG[05H]
MOV BUSL,#05H ;Pixel Clock
MOV WORD,#00100011B ;PCLK=AUXCLK
; MOV WORD,#01000011B ;PCLK=AUXCLK/8
; MOV WORD,#00110011B ;PCLK=AUXCLK/4
CALL WRITE_COMMAND ;
MOV BUSH,#00H ;REG[10H]
MOV BUSL,#10H ;Panel Type
MOV WORD,#01100001B ;TFT 18-bits
CALL WRITE_COMMAND ;
MOV BUSH,#00H ;REG[11H]
MOV BUSL,#11H ;MOD Rate (M)
MOV WORD,#00010011B ;
CALL WRITE_COMMAND ;DB5->DB0
MOV BUSH,#00H ;REG[12H]
MOV BUSL,#12H ;Horizontal Total
MOV WORD,#50 ;(408/8)-1=50
CALL WRITE_COMMAND ;HT Max.=1024 pixel
MOV BUSH,#00H ;REG[14H]
MOV BUSL,#14H ;Horizontal Display Size
MOV WORD,#39 ;(320/8)-1=39
CALL WRITE_COMMAND ;HDP
MOV BUSH,#00H ;REG[16H]
MOV BUSL,#16H ;Horizontal Period Start
MOV WORD,#63 ;DB7->DB0 HDPS
CALL WRITE_COMMAND ;bit7->bit0
;HDPS offset 22->CSTN
MOV BUSH,#00H ;REG[17H]
MOV BUSL,#17H ;Horizontal Period Start
MOV WORD,#00000000B ;DB1->DB0 HDPS
CALL WRITE_COMMAND ;bit9->bit8
;HT > HDP+HDPS
MOV BUSH,#00H ;REG[18H]
MOV BUSL,#18H ;Vertical Total
MOV WORD,#06H ;DB7->DB0 VT
CALL WRITE_COMMAND ;bit7->bit0 Max. 1024
MOV BUSH,#00H ;REG[19H]
MOV BUSL,#19H ;Vertical Total
MOV WORD,#01H ;DB1->DB0 VT
CALL WRITE_COMMAND ;bit9->bit8
MOV BUSH,#00H ;REG[1CH]
MOV BUSL,#1CH ;Vertical Display Size
MOV WORD,#239 ;DB7->DB0 VDP 320*240
CALL WRITE_COMMAND ;bit7->bit0
MOV BUSH,#00H ;REG[1DH]
MOV BUSL,#1DH ;Vertical Display Size
MOV WORD,#00000000B ;DB1->DB0 VDP
CALL WRITE_COMMAND ;bit9->bit8
MOV BUSH,#00H ;REG[1EH]
MOV BUSL,#1EH ;Vertical Period Start
MOV WORD,#18 ;DB7->DB0 VDPS
CALL WRITE_COMMAND ;bit7->bit0
MOV BUSH,#00H ;REG[1FH]
MOV BUSL,#1FH ;Vertical Period Start
MOV WORD,#00000000B ;DB1->DB0 VDPS
CALL WRITE_COMMAND ;bit9->bit8
;VT > VDP+VDPS
MOV BUSH,#00H ;REG[20H]
MOV BUSL,#20H ;LLINE Pulse Width
MOV WORD,#00011101B ;HPW
CALL WRITE_COMMAND ;
MOV BUSH,#00H ;REG[22H]
MOV BUSL,#22H ;LLINE Pulse Start
MOV WORD,#00 ;DB7->DB0 HPS
CALL WRITE_COMMAND ;bit7->bit0
MOV BUSH,#00H ;REG[23H]
MOV BUSL,#23H ;LLINE Pulse Start
MOV WORD,#00000000B ;DB1->DB0 HPS
CALL WRITE_COMMAND ;bit9->bit8
MOV BUSH,#00H ;REG[24H]
MOV BUSL,#24H ;LFRAME Pulse Width
MOV WORD,#00011101B ;VPW
CALL WRITE_COMMAND ;
MOV BUSH,#00H ;REG[26H]
MOV BUSL,#26H ;LFRAME Pulse Start
; MOV WORD,#01 ;DB7->DB0
MOV WORD,#00 ;DB7->DB0 VPS
CALL WRITE_COMMAND ;bit7->bit0
MOV BUSH,#00H ;REG[27H]
MOV BUSL,#27H ;LFRAME Pulse Start
MOV WORD,#00000000B ;DB1->DB0 VPS
CALL WRITE_COMMAND ;bit9->bit8
MOV BUSH,#00H ;REG[30H]
MOV BUSL,#30H ;LFRAME Pulse Start Offset
MOV WORD,#00000000B ;DB7->DB0
CALL WRITE_COMMAND ;bit7->bit0
MOV BUSH,#00H ;REG[31H]
MOV BUSL,#31H ;LFRAME Pulse Start Offset
MOV WORD,#00000000B ;DB1->DB0
CALL WRITE_COMMAND ;bit9->bit8
MOV BUSH,#00H ;REG[34H]
MOV BUSL,#34H ;LFRAME Pulse Stop Offset
MOV WORD,#00000000B ;DB7->DB0
CALL WRITE_COMMAND ;bit7->bit0
MOV BUSH,#00H ;REG[35H]
MOV BUSL,#35H ;LFRAME Pulse Stop Offset
MOV WORD,#00000000B ;DB1->DB0
CALL WRITE_COMMAND ;bit9->bit8
MOV BUSH,#00H ;REG[45H]
MOV BUSL,#45H ;STN Color Depth Control
MOV WORD,#00000001B ;DB0
CALL WRITE_COMMAND ;1-> 256K 0->32K
MOV BUSH,#00H ;REG[50H]
MOV BUSL,#50H ;Dithering/FRC Control
MOV WORD,#00000000B ;
CALL WRITE_COMMAND ;
MOV BUSH,#00H ;REG[70H]
MOV BUSL,#70H ;Display Mode
MOV WORD,#00000100B ;64K
CALL WRITE_COMMAND ;
MOV BUSH,#00H ;REG[71H]
MOV BUSL,#71H ;Special Effects
MOV WORD,#01000000B ;
CALL WRITE_COMMAND ;
MOV BUSH,#00H ;REG[74H]
MOV BUSL,#74H ;Main Windows address Start
MOV WORD,#000 ;DB7->DB0
CALL WRITE_COMMAND ;bit7->bit0
MOV BUSH,#00H ;REG[75H]
MOV BUSL,#75H ;Main Windows address Start
MOV WORD,#00000000B ;DB7->DB0
CALL WRITE_COMMAND ;bit15->bit8
MOV BUSH,#00H ;REG[76H]
MOV BUSL,#76H ;Main Windows address Start
MOV WORD,#00000000B ;DB0
CALL WRITE_COMMAND ;bit16
MOV BUSH,#00H ;REG[78H]
MOV BUSL,#78H ;Main Windows Offset Address
MOV WORD,#160 ;DB7->DB0 320*240 CSTN
; MOV WORD,#120 ;DB7->DB0 240*160 CSTN
CALL WRITE_COMMAND ;bit7->bit0
MOV BUSH,#00H ;REG[79H]
MOV BUSL,#79H ;Main Windows Offset Address
MOV WORD,#00000000B ;DB1->DB0
CALL WRITE_COMMAND ;bit9->bit8
; MOV BUSH,#00H ;REG[7CH]
; MOV BUSL,#7CH ;Floating Windows Start
; MOV WORD,#00000000B ;DB7->DB0
; CALL WRITE_COMMAND ;bit7->bit0
; MOV BUSH,#00H ;REG[7DH]
; MOV BUSL,#7DH ;Floating Windows Start
; MOV WORD,#00000000B ;DB7->DB0
; CALL WRITE_COMMAND ;bit15->bit8
; MOV BUSH,#00H ;REG[7EH]
; MOV BUSL,#7EH ;Floating Windows Start
; MOV WORD,#00000000B ;DB0
; CALL WRITE_COMMAND ;bit16
; MOV BUSH,#00H ;REG[80H]
; MOV BUSL,#80H ;Float Windows Offset
; MOV WORD,#00000000B ;DB7->DB0
; CALL WRITE_COMMAND ;bit7->bit0
; MOV BUSH,#00H ;REG[81H]
; MOV BUSL,#81H ;Float Windows Offset
; MOV WORD,#00000000B ;DB1->DB0
; CALL WRITE_COMMAND ;bit9->bit8
; MOV BUSH,#00H ;REG[84H]
; MOV BUSL,#84H ;Float Start Position X
; MOV WORD,#00000000B ;DB7->DB0
; CALL WRITE_COMMAND ;bit7->bit0
; MOV BUSH,#00H ;REG[85H]
; MOV BUSL,#85H ;Float Start Position X
; MOV WORD,#00000000B ;DB1->DB0
; CALL WRITE_COMMAND ;bit9->bit8
; MOV BUSH,#00H ;REG[88H]
; MOV BUSL,#88H ;Float Start Position Y
; MOV WORD,#00000000B ;DB7->DB0
; CALL WRITE_COMMAND ;bit7->bit0
; MOV BUSH,#00H ;REG[89H]
; MOV BUSL,#89H ;Float Start Position Y
; MOV WORD,#00000000B ;DB1->DB0
; CALL WRITE_COMMAND ;bit9->bit8
; MOV BUSH,#00H ;REG[8CH]
; MOV BUSL,#8CH ;Float End Position X
; MOV WORD,#00000000B ;DB7->DB0
; CALL WRITE_COMMAND ;bit7->bit0
; MOV BUSH,#00H ;REG[8DH]
; MOV BUSL,#8DH ;Float End Position X
; MOV WORD,#00000000B ;DB1->DB0
; CALL WRITE_COMMAND ;bit9->bit8
; MOV BUSH,#00H ;REG[90H]
; MOV BUSL,#90H ;Float End Position Y
; MOV WORD,#00000000B ;DB7->DB0
; CALL WRITE_COMMAND ;bit7->bit0
; MOV BUSH,#00H ;REG[91H]
; MOV BUSL,#91H ;Float End Position Y
; MOV WORD,#00000000B ;DB1->DB0
; CALL WRITE_COMMAND ;bit9->bit8
MOV BUSH,#00H ;REG[A0H]
MOV BUSL,#A0H ;Power Saving
MOV WORD,#00000000B ;
CALL WRITE_COMMAND ;
; MOV BUSH,#00H ;REG[A2H]
; MOV BUSL,#A2H ;Software Reset
; MOV WORD,#00000000B ;DB1->DB0
; CALL WRITE_COMMAND ;bit9->bit8
; MOV BUSH,#00H ;REG[A4H]
; MOV BUSL,#A4H ;Scratch Pad
; MOV WORD,#00000000B ;DB7->DB0
; CALL WRITE_COMMAND ;bit7->bit0
; MOV BUSH,#00H ;REG[A5H]
; MOV BUSL,#A5H ;Scratch Pad
; MOV WORD,#00000000B ;DB7->DB0
; CALL WRITE_COMMAND ;bit15->bit8
;***************************************************************************
-
overclocked
- Inlägg: 71
- Blev medlem: 13 juni 2006, 21:34:24
- Ort: Gävle
Re: LCD 5" med SSD 1963 och styrning via FPGA
Tack känns bra med lite support så man tänker rätt. Absolut, om du menar att se till att överföring skall ske så att inte sk. "tearing" uppstår i bildvisning så är det in strävan. Alltså att inte uppdatera bilden precis när den ritas ut. Annars får du gärna förklara närmare, LCD-styrning är lite nytt för mig.. Däremot har jag labbat mycket med VGA-skärmar hemma och det har fungerat väldigt bra.blueint skrev:En tanke kanske kan vara att synkronisera uppdateringar så att uppdateringar ej orsakar jitter i tiden.
Re: LCD 5" med SSD 1963 och styrning via FPGA
Alltså... kretsen är så att säga ett komplett grafikkort och man behöver inte uppdatera sin skrivning av bildminnet om det inte är ändringar.
Ritar man alltså en bild via parallellinterfacen står det kvar till man ändrar, SSD-kretsen tar hand om allt annat. Man skriver alltså rätt data till bildminnet och ändrar vid behov.
Man kan köpa en PICtail med SSD1926, 73-344-91 hos ELFA, 500:-. Kallas AC164127-5 av Microchip, där kan det nog finnas en del information att hämta om man vill.
För mig känns det ganska mycket överkurs med FPGA till att styra kretsen, helt enkelt för att kretsen inte ska uppdateras kontinuerligt. Jag ska bygga ett system som jag kan skicka data till: "Öppna en låda, storlek xxx, yyy, start xxx, yyy". "Skriv '???' på xxx, yyy, storlek zzz" osv. för att se om det fungerar bra.
Blir det användbart har jag en QVGA pekskärm som jag ska bygga en enhet med, då kan jag få en bra test/demo-enhet till vidare användning.
Ritar man alltså en bild via parallellinterfacen står det kvar till man ändrar, SSD-kretsen tar hand om allt annat. Man skriver alltså rätt data till bildminnet och ändrar vid behov.
Man kan köpa en PICtail med SSD1926, 73-344-91 hos ELFA, 500:-. Kallas AC164127-5 av Microchip, där kan det nog finnas en del information att hämta om man vill.
För mig känns det ganska mycket överkurs med FPGA till att styra kretsen, helt enkelt för att kretsen inte ska uppdateras kontinuerligt. Jag ska bygga ett system som jag kan skicka data till: "Öppna en låda, storlek xxx, yyy, start xxx, yyy". "Skriv '???' på xxx, yyy, storlek zzz" osv. för att se om det fungerar bra.
Blir det användbart har jag en QVGA pekskärm som jag ska bygga en enhet med, då kan jag få en bra test/demo-enhet till vidare användning.
-
overclocked
- Inlägg: 71
- Blev medlem: 13 juni 2006, 21:34:24
- Ort: Gävle
Re: LCD 5" med SSD 1963 och styrning via FPGA
Wow det var lite register att sätta där, tack för exemplet! Det står ju helt klart att någon form av soft-CPU är att föredra, åtminstone för att utföra init. Alternativt en smart uppbyggd statisk array som skickar ut de värden som behövs för att sätta skärmen i "rätt" läge.Icecap skrev: När denna initiering är klar skulle resten tydligen "bara" vara att skriva rätt pixeldata på rätt plats i minnesdelen av kretsen, sedan skulle det hela fungera.
Blir väl till att börja med långsam överföring och få något att fungera och sedan öka efter behov. Kring 25-30 Mhz borde räcka för att få min 60 bilder/sekund tror jag. Blir intressant och roligt att labba med detta!
Re: LCD 5" med SSD 1963 och styrning via FPGA
Vad ska du använda FPGA:n till om skärmen ej behöver den?
Re: LCD 5" med SSD 1963 och styrning via FPGA
> för att få min 60 bilder/sekund tror jag.
Var kommer "bilderna" ifrån ?
Var kommer "bilderna" ifrån ?
-
overclocked
- Inlägg: 71
- Blev medlem: 13 juni 2006, 21:34:24
- Ort: Gävle
Re: LCD 5" med SSD 1963 och styrning via FPGA
sodjan:
Bilderna i detta fall kommer ifrån olika FPGA-projekt som jag redan har gjort eller kommer att skriva i Verilog/VHDL. Exempelvis: http://wedmark.blogspot.se/p/fpga-test-card.html. Dock i just detta projekt så jobbar ju FPGA:n i realtid (utan Framebuffer) med att skapa bilden medan man vid användning av LCD-skärmen får se till att skriva det i SRAM, alternativt om Controllern kan godta att köra linje-baserat och rendera en linje i taget och visa denna.
Ja framtiden får väl utvisa vilket som känns smidigt. När jag beställde denna produkt trodde jag att man kontrollerade skärmen i realtid vilket kanske hade passat bäst tillsammans med FPGA:er, men med ett bra pris kan man ju anpassa sig. Det finns en kontakt mellan Controllern och skärmen på vilken jag vid behov kan koppla in mig och på så sätt koppla bort Controllern..
blueint:
Jag förstår din fråga. Basen till ALLA mina hobby-projekt är FPGA, oavsett om den behövs eller ej!
Skämt och sido, kan jag bara fylla detta RAM-minne tillräckligt fort så kan jag ju likväl köra datat rakt ut i buffern som att skapa styrsignalerna till skärmen. För mig är det detsamma. Som jag sa ovan (till Sodjan) så kan jag vid behov kortsluta Controllern också, men jag satsar nog på att lära mig en del om 1963.an till att börja med.
Många att mina projekt går bara ut på roligt labbande och inte på ett exakt resultat. Som t.ex. mitt senaste FPGA-BitCoin mining projekt. Resultatet (i ren krytografi-prestanda) blev väl så där men det fungerande och jag har lärt mig en del där också!
Bilderna i detta fall kommer ifrån olika FPGA-projekt som jag redan har gjort eller kommer att skriva i Verilog/VHDL. Exempelvis: http://wedmark.blogspot.se/p/fpga-test-card.html. Dock i just detta projekt så jobbar ju FPGA:n i realtid (utan Framebuffer) med att skapa bilden medan man vid användning av LCD-skärmen får se till att skriva det i SRAM, alternativt om Controllern kan godta att köra linje-baserat och rendera en linje i taget och visa denna.
Ja framtiden får väl utvisa vilket som känns smidigt. När jag beställde denna produkt trodde jag att man kontrollerade skärmen i realtid vilket kanske hade passat bäst tillsammans med FPGA:er, men med ett bra pris kan man ju anpassa sig. Det finns en kontakt mellan Controllern och skärmen på vilken jag vid behov kan koppla in mig och på så sätt koppla bort Controllern..
blueint:
Jag förstår din fråga. Basen till ALLA mina hobby-projekt är FPGA, oavsett om den behövs eller ej!
Skämt och sido, kan jag bara fylla detta RAM-minne tillräckligt fort så kan jag ju likväl köra datat rakt ut i buffern som att skapa styrsignalerna till skärmen. För mig är det detsamma. Som jag sa ovan (till Sodjan) så kan jag vid behov kortsluta Controllern också, men jag satsar nog på att lära mig en del om 1963.an till att börja med. Många att mina projekt går bara ut på roligt labbande och inte på ett exakt resultat. Som t.ex. mitt senaste FPGA-BitCoin mining projekt. Resultatet (i ren krytografi-prestanda) blev väl så där men det fungerande och jag har lärt mig en del där också!
Re: LCD 5" med SSD 1963 och styrning via FPGA
Känns som en array med register-nummer och registervärde är enklaste sättet. Att läsa arrayen och skriva värdena till registren är väl en process i VHDL på kanske 20-30 rader. Att fixa in en soft-cpu är ju säker 100 ggr mer komplicerat.overclocked skrev:Wow det var lite register att sätta där, tack för exemplet! Det står ju helt klart att någon form av soft-CPU är att föredra, åtminstone för att utföra init. Alternativt en smart uppbyggd statisk array som skickar ut de värden som behövs för att sätta skärmen i "rätt" läge.
Re: LCD 5" med SSD 1963 och styrning via FPGA
@overclocked, Ser ut att vara XC3S1600E men dess datablad sidan 3 anger 622 Mbit/s per I/O. Annars kunde man kört S-ATA direkt (1,5 Gbit/s) med dito bitcoin inspiration .
Vad använder du för CPU/moderkort för att syntisera ("kompilera") ..?
Hur lång tid tar det att syntisera Minimigs källkod (d) på den ..? (från .v till .bit)
Hur har du fått ordning på DDR chippet på utvecklingskortet?, det skulle visst finnas någon kodgenerator hos xilinx, men den fungerade ej.
Var fick du fatt på kontakten till underkortet?
Philips PM5544, slår "underhållningen" på andra kanaler alltför ofta
.Vad använder du för CPU/moderkort för att syntisera ("kompilera") ..?
Hur lång tid tar det att syntisera Minimigs källkod (d) på den ..? (från .v till .bit)
Hur har du fått ordning på DDR chippet på utvecklingskortet?, det skulle visst finnas någon kodgenerator hos xilinx, men den fungerade ej.
Var fick du fatt på kontakten till underkortet?
Philips PM5544, slår "underhållningen" på andra kanaler alltför ofta
-
overclocked
- Inlägg: 71
- Blev medlem: 13 juni 2006, 21:34:24
- Ort: Gävle
Re: LCD 5" med SSD 1963 och styrning via FPGA
Jo Andax jag håller med. Som du säger så passar ju en enkel tillstånds-maskin som bara trycker ut värden enligt det du skriver perfekt. Enda potentiella begränsningen jag ser med det är om man vill ha flera saker som både ska vara dynamiska värden bland dessa, kanske kunna anta flera olika värden OCH kunna kontrolleras av något annat lämpligt: Knappar, snurr-spakar eller annat. Då väljer jag direkt en liten enkel 8-bit CPU eftersom dessa fort kan tävla i storlek med en större tillstånds-maskin. Speciellt den underbara och fria Picoblaze'n från Xilinx. Inte alls något problem att använda 1 eller flera sådana. Kanske jag är hemmablind som gammal assemblerräv och systemutvecklare. Dock kan jag ju som glad hobbyhackare frånse nackdelar som komplexitet för en oinvigde och begränsad portabilitet eftersom just denna är Xilinx-only (om man inte kör PacoBlaze)Andax skrev: Känns som en array med register-nummer och registervärde är enklaste sättet. Att läsa arrayen och skriva värdena till registren är väl en process i VHDL på kanske 20-30 rader. Att fixa in en soft-cpu är ju säker 100 ggr mer komplicerat.
KUL att vi fick igång en diskussion här även om det börjar bli Off-topic(blueint's frågor under). Jag väljer att fortsätta svara i denna tråd, men om någon nitisk Forum-guru vill bryta/flytta runt så varsågod!
-
overclocked
- Inlägg: 71
- Blev medlem: 13 juni 2006, 21:34:24
- Ort: Gävle
Re: LCD 5" med SSD 1963 och styrning via FPGA
Stämmer bra det blueint! ABSOLUT, kunnat ha blivit något det! Nä verkar väl som om dom där snabba SERDES-grejorna kom senare va?
Jag byggde nyligen en ny dator specifikt för att kunna köra snabba syntetiseringar på och den fungerar rätt bra. Quad I7-2600K, 8Gbyte 1800Mhz minne och en SSD-disk att lägga projekten på. Jag tror den var c:a 10ggr snabbare än min Dell XPS M1730 Laptop om jag minns rätt.. Men man får ju vänta ändå... suck! Dock är det ju först med nyare familjer med 6-LUT's som bygg-motorn i ISE har blivit genuint multitrådad. Innan har det påståtts detta, men jag har provat och det stämmer inte! Dock kan man få till Synthesize multitrådad genom att själv bygga ett script som forkar på ett lämpligt sätt.. tråkigt dock!blueint skrev: Vad använder du för CPU/moderkort för att syntisera ("kompilera") ..?
Hur lång tid tar det att syntisera Minimigs källkod (d) på den ..? (från .v till .bit)
Det jag lärt mig att är Floor-planning OCH Timing-Constraints är A och O i stora kopplingar, annars väntar man i onödan. Märkte detta speciellt ju på FPGA-BitCoin-Mining-projektet. Gick från 8H+ (aldrig klar typ) till c:a 10-20min.
Jag ska prova att bygga minimig-projektet och återkommer med tid! Dock finns väl inte en ny version(ink. soft-68K) av Minimig till Xilinx som faktiskt fungerar va? DET skulle jag verkligen vilja ha till mitt kort.. Begränsningen är bl.a. en trilskande multiplexad-SDR-controller som skulle behöva bli en DDR-Controller.
TYVÄRR! Jag har iofs fått igång (EN write och EN read korrekt) ett enkelt exempel från OpenCores (ingen länk eftersom den verkar vara nere just nu..) att fungera efter många om och med hjälp av flera där. De filer som jag tog fram till 1600E checkades in vet jag och vi arbetade fram enklare ändringar i strukturen på projektet.blueint skrev: Hur har du fått ordning på DDR chippet på utvecklingskortet?, det skulle visst finnas någon kodgenerator hos xilinx, men den fungerade ej.
En kombination av dåliga exempel, MIG(som du nämner) som inte är användarvänlig, tryckfel i dokumentationen till 1600E-kortet och helt enkelt att jobba med har satt käppar i hjulen genom åren. Värt att nämna är att systemkortet med 500E INTE är 100% pinn-kompatibelt med 1600E-kortet. DDR-controller är just nu min akilleshäl i FPGA-sammanhang.. suck!
Sen har jag iofs inte hittat nåt projekt som varit helt beroende av DDR heller.. Jag har mitt Spartan-3 Starter Kit 200K med 1MB SRAM som är enklare att jobba med.
Jadu... om du menar FX2... var rätt svårt att hitta den för överkomliga pengar och när jag ursprungligen byggde mitt ArcadeExtender-kort så var det avsett för Spartan-3 StarterKit-kortet med en 0,1" 40-pin kontakt. Jag löste detta genom att helt enkelt löda fast en flatkabel-anslutning med en 40-pin hona på undersidan av FX2-kontakten på FPGA-kortet! Fuling men billigt.. Idag kanske man väljer att punga ut för denna: http://www.digilentinc.com/Products/Det ... =FX2SOCKET Går säkert att hitta billigare om man har för vana att beställa saker. Jag kommer ihåg att jag som privatperson fick nej från nåt ställe också.. surt!blueint skrev: Var fick du fatt på kontakten till underkortet?
Absolut, alldeles för mycket skit på TV! Roligare att hacka FPGA:er! Dock är det inte alltid som frun tycker likadant!?!blueint skrev: Philips PM5544, slår "underhållningen" på andra kanaler alltför ofta
Re: LCD 5" med SSD 1963 och styrning via FPGA
Tror endast de finns i Virtex som kommer i jobbiga kapslar med dito jobbiga priseroverclocked skrev:Nä verkar väl som om dom där snabba SERDES-grejorna kom senare va?
Fuling idé.. prova att kommunicera med en S-ATA disk i 500 Mbit/s ?, har du tur kanske det fungerar ändå.
Vad är det för sidokort du använder annars?
Det är L2-cache, FSB, och minnesstorlek i den ordningen som är mest betydelsefullt. Har testat olika konfigurationer. 64-bit ger sådär 20% extra. Men testsyntes på båda vore braoverclocked skrev:Quad I7-2600K, 8Gbyte 1800Mhz minne
Det behöver ju inte fungera, inte är bara en mätbänk så att säga.
Syntesprogrammet kanske testar ALLA kombinationer annars..overclocked skrev:lärt mig att är Floor-planning OCH Timing-Constraints är A och O
DDR..
När jag kollade sist på det så måste man helt enkelt se SDRAM/DDR minne som ett batchjobb. Dvs du skickar förfråga #0 först, fråga #1, fråga #2, och får sedan svar på #0, skicka fråga #3, får svar på #1 osv..
En enkel variant är att använda var 6:e tidslucka utan dubbelklockning och hoppa två klocksteg.
Men minnet behövs om man vill ha höga upplösningar, musik mm. Det är nyckeln så att säga.
FX2..
Specialkontakten är en pain-in-the-ass!
Bra att du lyckats koppla in något utan att ha sönder det. Det är rätt känsligt och specialdyrt och svårt att få fatt på sakerna.
Philips PM5544..
Saknas bara lite animation av den där SVT klockan
Sen kan man bygga på med I/Q tuner interface och QPSK demodulering, samt MPEG dekodning.. så tja kan man se TV på FPGA
Re: LCD 5" med SSD 1963 och styrning via FPGA
Har du lite tips kring detta. Har själv bara använt timing-constraints till viss del (och då mest gissat mig till).overclocked skrev:Det jag lärt mig att är Floor-planning OCH Timing-Constraints är A och O i stora kopplingar, annars väntar man i onödan. Märkte detta speciellt ju på FPGA-BitCoin-Mining-projektet. Gick från 8H+ (aldrig klar typ) till c:a 10-20min.
