FPGA waarom zoweinig nieuwe gebruikers?

@ f_e
Heldere uitleg voor de beginners
Zo, en nu eerst nog zo'n knutselbordje.

Op 13 april 2007 21:20:05 schreef flipflop:
En vervolgens als de sodemieter Verilog leren!

juist ! mar ik dacht dat jij een VHDller was ? ( Very Hard Design Language )

Op 13 april 2007 21:35:14 schreef legacy:
@ f_e
Heldere uitleg voor de beginners
Zo, en nu eerst nog zo'n knutselbordje.

Hier staat ene boekd ( maar das voor gevorden en/of mensen die vana andere platformen komen ( ASICs , Xilinx, Lattixce of ACTEL ). die kennen al die dingen en willen weten waar het zich bevind in Quartus

http://www.altera.com/literature/manual/intro_to_quartus2.pdf

Ik besteed toch dik 20 paginas in mijn boek aan quartus.

eerst project aanmaken,.
schematje leren tekenen .
compileren
dan simulatie aanmaken en simuleren
dan stukje VHDL of VERILOg toevogen , block symbol leren aanmaken en instantieren.
dan de megawizrd leren gebruiken.
dan device en pintoekenning leren doen
en dan programmeren.

@F_E

Als ik het goed begrijp kun je dus echte intergrades circuits maken ik een FPGA? zo ja.. Vet... Ik wil ook een ontwikelboard + alles!!

Op 13 april 2007 21:49:01 schreef free_electron:
juist ! mar ik dacht dat jij een VHDller was ? ( Very Hard Design Language )

Ik vind VHDL een betere taal ja. Maar dat wil niet zeggen dat ik met oogkleppen op alleen maar VHDL wil aanbevelen. Als ik de post ven Henk zo lees wil ie alleen een beetje ruiken aan FPGA design. In dat geval is Verilog goed genoeg en de beste keuze. Maar natuurlijk zijn het beide serieuze talen. Daarom spreek ik biede

Op 13 april 2007 22:04:33 schreef Technojunk:
@F_E

Als ik het goed begrijp kun je dus echte intergrades circuits maken ik een FPGA? zo ja.. Vet... Ik wil ook een ontwikelboard + alles!!

inderdaad. een FPGA stelt je in staat om zelf chips te maken. is weer eens wat anders dan printjes etsen of wat programmeren.

Op 13 april 2007 16:20:24 schreef free_electron:
[...]

langzaam ? verklaar u nader ...

dat ding compileert designs met een miljoen gates binnen het half uur .. das razendsnel. !

bij quartus is het vooral memory wat ene limiet is. zorg maar als je met grote designs aan de slag gaat dat je tikbak 2 of meer gig ram heeft ...

voor normale designkes compileert dat 2 a 3 minuten. volkomen normaal.

je mag blij zijn dat je geen silicon compiler moet lopen .... daar zijn runs van dagen niet uitzonderlijk.

Ehh, het kan best zijn dat jij dat "Volkomen normaal" vind, maar nadat ik met "make" m'n software project netjes heb ingedeeld heb ik het over "enkele seconden".

Volgens mij zitten we rond de 10 minuten te wachten op een compilatie van rond de 4500 LE's.

De term "volkomen normaal" kan ik best achter staan. Maar ik blijf het langzaam vinden....

[edit].. Nog even zitten rekenen. In de flex serie is geloof ik de 100k gates variant degene met 5k LEs. Dus miljoen gates, komt overeen met 50k LEs. Als jou "half uur per miljoen gates" klopt, zouden we het over 3 minuten voor 5k LEs moeten hebben (ware het niet dat een aantal optimalisatie problemen kwadratisch en nog vervelender zijn als een design groter is.)

[Bericht gewijzigd door rew op zaterdag 14 april 2007 10:39:30 ]

Op 14 april 2007 10:33:52 schreef rew:
[...]

Ehh, het kan best zijn dat jij dat "Volkomen normaal" vind, maar nadat ik met "make" m'n software project netjes heb ingedeeld heb ik het over "enkele seconden".

Volgens mij zitten we rond de 10 minuten te wachten op een compilatie van rond de 4500 LE's.

De term "volkomen normaal" kan ik best achter staan. Maar ik blijf het langzaam vinden....

Software compileren is simpel.
Hardware compileren daarentegen ....

je mag niet vergeten dat dat ding al die logica moet aanmaken , al de vergelijkingen moet vereenvoudigen. daar een netlist van trekken en dan gaan routen op de fpga !.
vooral het routen ( vergelijk dat met ene autorouter voor ene pcb ) neemt tijd in beslag.
het aantal raceways en interconnects is gelimiteerd. om daar een beetje effecient mee om te springen duurt dat wel ene tijdje.

10 minuten voor 4500 LE's vind ik inderdaad wel een beetje veel ...

Veel hangt af van de 'tikbak' waarop je loopt. Opt werk staan we met Pentium D op 3.6 GHz en 4 gig ram erin. gaat goed vooruit.

Trouwens sourcecode compileren ... Als wij de firmware voor een harddisk compileren kan dat ook een kwartier of langer duren hoor. Das rond de 6 megabyte rom image.

Zomaar even een vraagje he,

weet iemand hoe je automatisch een buildnummer kunt integreren in je VHDL code?

Ik heb zegmaar een FPGA met registers, en in 1 van die registers staat de firmware versie (waaronder ook het buildnummer). In mijn VHDL code is dit een constante STD_LOGIC_VECTOR. Nu moet ik bij iedere build deze vector aanpassen (natuurlijk vergeet ik dat iedere keer), dat is dus niet erg praktisch.

Ik zoek dus eigenlijk een manier om met behulp van een buildnummer een STD_LOGIC_VECTOR te genereren. (ik stel me voor dat deze automatisch verhoogd wordt na iedere succesvolle synthetiseer slag, of iedere succesvolle place/route slag)
Ik werk nu met ISE 9.1 SP3.

Ik zal maar eens beginnen met toe te geven dat ik niet heel het topic gelezen heb, en dat ook niet meer ga doen

- Wat is de reden waarom jullie nog niet gestart zijn met CPLD of FPGA ?
Luiheid, met de PIC kreeg ik hulp voor ik hem uberhaupt in huis had van een persoon die ik op ieder willekeurig moment lastig kan vallen, een FPGA kost wat meer dan een PIC (hoewel ik daar niet zo veel van weet), ik werk meestal op een breadbord, zijn daar ook FPGA's voor? En ik weet ook nog niet echt hoe het geval te programmeren is, bij mijn eerste PIC bijvoorbeeld, kwam ik er later achter dat heel mijn (zelfgebouwde) programmer niet geschikt was voor dat model. Beschikbaarheid is ook een probleem geweest, ze zijn wel te bestellen ergens in de VS ofzo, maar dat is toch minder toegankelijk dan een klik-en-pay webshop

- Wat mag het kosten om te starten ( prijs range)
<15 euro... (stel je voor dat ik et perongeluk sloop :|)

- Is er meer hulp nodig van andere om jullie op weg te brengen?
Denk het wel

- Ja Free_electron is bezig met een goed boek te schrijven, dus Free.... doe een beetje vooruit hé.
Is dat een vraag?

- Is er hulp nodig bij de juiste keuze van de componenten om te starten ?
Ja.... of kan de mini-machine geheel op zichzelf draaien? Iig, ik heb bij voorkeur iets dat in mijn breadbord past

Anyone een inkoopactie oid organiseren ?

Op 19 april 2007 16:41:43 schreef UFO:
- Is er hulp nodig bij de juiste keuze van de componenten om te starten ?
Ja.... of kan de mini-machine geheel op zichzelf draaien? Iig, ik heb bij voorkeur iets dat in mijn breadbord past

Je hebt natuurlijk een voeding nodig (vaak meer dan 1 niveau) en een klok. FPGA's beschikking niet over een interne klok. Wel hebben ze frequency synthesizers om vanuit een bepaalde klok andere kloks te genereren (clk/2, clk*2, clk/x, clk*x/y) soort van PLLs zeg maar...

Breadboard zal wel lastig worden, maar niets is onmogelijk

Buildnummer in VHDL lijkt mij ook wel handig. Als je wat vind, dan houd ik me aanbevolen. Als ik wat vind, dan post ik het.

@free_electron

Hoe vlot het met je FPGA boek? We hebben er al maanden niets meer van gehoord

nog steeds aant schrijven.
vooral al de tekeningskes nemen tijd in beslag

[Bericht gewijzigd door free_electron op maandag 20 augustus 2007 18:13:11 (48%)]

Op 20 augustus 2007 18:12:51 schreef free_electron:
nog steeds aant schrijven.
vooral al de tekeningskes nemen tijd in beslag

Ik wacht geduldig af.

Het wordt toch geen stripboek

Ik moet zeggen dat dit topic me toch ook wel heel erg nieuwsgierig gemaakt heeft, en ik toch er toch ook eens in wil gaan verdiepen....

moet alleen zeggen dat ik het wel moeilijk vind , wat ik nu eigenlijk kopen moet....

Tis allemaal niet echt goedkoop ..

Ik denk dat ik eerst maar een op F_E zijn boek wacht...(zijn vorige boek "visual Basic for electronics engineering applications" is me ook heel goed bevallen, ondanks dat het in het engels was)

zit er ook hardware bij het boek?

@Foto_opa:
Oke je maak heel veel reclame voor FPGA, en verwijs heel vaak naar je foto's... van de bloempjes en de bij-jes ...

en dan zie ik daar fotos van een fototoestel, waar van alles en nogwat aanhangt.... Maar ik heb geen idee wat dat nu met FPGA's temaken heb... en of het ook niet met een PIC of een AVR gekunt had...

zou je misschien (misschien zelfs in een ander topic) kunnen uitleggen wat je daar nu allemaal doe... en wat daar nu de grote kracht is van de FPGA die je gebruik?

misschien wel een stomme vraag...

^Dé kracht van FPGA is dat het hardware is, terwijl µC software zijn.
Een µC voert het programma sequentieel uit, hij doorloopt je code van de eerste tot de laatste letter uit, instructie per instructie. Als je een lang programma hebt, en je laat (zonder interrupts te gebruiken) met een knop een ledje oplichten, duurt het maximaal zolang als het duurt om heel je programma te doorlopen.
Een FPGA werkt parallel, je hangt daadwerkelijk een nest AND, OR, NOT poorten aan elkaar, met wat flipflops en lookup-tables erbij, waardoor alles aan enorme snelheden wordt uitgevoerd. Hetzelfde knopje om een ledje op te doen lichten, zal enorm snel werken, net zo snel als wanneer je het via een buffer zou aansluiten, ook al gebruik je 99% van de capaciteiten van je FPGA.

Videomodulator slaat de nagel op de kop.
Alles is parallel. Je hebt ook gene probleme om iets bizar te doen.
Stel je hebt een 4 bit teller nodig teller nodig die als volgt telt : E-1-7-F-3-2-B-8-9-C-4-0-D-6-5-A
Als je dat in software moet doen kost je dat ene pak code. ( je zult met ene lookup tabel moeten werken.
In ene fpga worden dat 4 flipflops en ene paar poortjes.
Je processor is misschien 10 tot 15 klokpulsen bezig om gewoon 1 stap te zetten.Die fpga doet dat in 1 klokpuls.

Ander voorbeeldje.

Je gaat een 7 segment displaytje sturen. 4 digits.

Je processor moet continue dat display staan 'scannen' ( we gaan er even vanuit dat je de display rechtstreeks stuurt vanuit de io poten )

dat kost tijd en geheugen. je moet ook de boel gaan ecoderen om de juiste segmenten te laten oplichten. en dat steeds opnieuw en opniew en opnieuw.

in die fpga worden dat :
4x een 4 bit register om de waarde op te slaan. = 16 flipflops
2 fliplfops om ene scanteller mee te maken. en de rest zijn and,or en not poorten. rekentijd : nul. 1 klokpuls is 1 digit die oplicht.
je zet gewoon de getallen in die registers en tis gebakken.

je kan dat als schema gaan uittekenen. een paar 74573's een paar 747 een 7447 en ene paar multiplexers. en je kan dat schema perfect door de fpga synthesizer jagen.

Maar als je het nog simpeler wilt doen. ( tekenen ben je ene uurtje mee zoet ). code kloppen is op 5 minuten geakken.

een voorbeeld ( in Verilog , die 'very hard design language' laten we links liggen)

module display(input [3:0] data,   // data ingang
               input [1:0] address, // address ingang
               input write,      // write signaal
               input clock,      // een clock
               output a,         // de segmentuitgangen
               output b,
               output c,
               output d,
               output e, 
               output f,
               output g);

reg [3:0] digit_1;  // ik heb 4 variablen nodig die elk 4 bit kunnen opslaan : een 'register' van bits van 3 tot 0 wat digit_1 noemt
reg [3:0] digit_2;
reg [3:0] digit_3;
reg [3:0] digit_4;

always @(posedge write) begin      // als er ene write komt
     case address                  // kijk naar het address
       2'b00 : digit_1 <=data;     // als dat 2 bits met waarde 00 is stop de data in digit_1
       2'b01 : digit_2 <=data;     // enzovoort
       2'b10 : digit_3 <=data;
       2'b11 : digit_4 <=data;
     endcase
end

reg[1:0] teller;   // we maken nog ene 'variable' met 2 flipflops aan
wire [3:0] nummer // en ook 4 draden .. nummer[3] tot nummer[0]

always @ posedge (clock) begin
    teller <= teller +1;  / als er ene clockpuls komt : teller met 1 omhoog
    case teller 
      2'b00 : nummer = digit_1; // zet op de draden de inhoud van digit_1
      2'b00 : nummer = digit_2; // enzovoort
      2'b01 : nummer = digit_3;
      2'b11 : nummer = digit_4;
    endcase
end

assign display = {a,b,c,d,e,f,g}  // ik maak hier iets wat 'display' noemt 
                                  // en een collectie is van de uitgangen voor de segmenten
                                  // dat maakt mij straks het leven gemakkelijk

always    // doe dit altijd . je moet niet wachten op iets.
    case nummer  // als er op de 'draden' het volgende staat
                 // zet dan op het 'display' ( wat een collectie van uitgangne a,b,c,d,e,f,g is )
                 //     abcdefg  : de segmenten
      0 : display = 7'b 1111110;    // 1 is aan , 0 is af
      1 : display = 7'b 1100000;
      2 : display = 7'b 1011011;
      3 : display = // enzovooort. ik ga hier nu niet gans die tabel uitschrijven
      4 :
      5 :
      6 :
      7 :
      8 :
      9 :
    endcase
end

endmodule

das ook ene 'programma' maar met verschil dat dat een blok echte hardware wordt wat gene rekentijd in beslag neemt.

elk 'always' blok word een apart stuk electronica wat een eigen leven leidt. het ene blok kijkt naar het andere. het enige wat jij als designer regelt is wanneer een bepaald blok iets binneneemt en anneer het iets buitenstuurt.

bijgevolg is ene fpga veel en veel sneller dan ene programma op een cpu.

bij beeldbewerking wordt dat hele duidelijk bijvoorbeeld.
2 beelden laten overvloeien.
ene processor moet dat pixel per pixel gaan doen. 2 pixels samentellen en delen door 2. ( we gaan even van 50 % mix uit )
als je dat moet doen op 2.1 miljoen pixels aan 50 beelden per seconde ... dan heb je een zeeeer straffe cpu nodig.
die loop moet imers 2.1 miljoen keer uitgevoerd worden , de input data ( 2 bytes per pixels ) meot 2.1 miljoen keer opgehaald worden en de output moet 2.1 miljoen keer weggeschreven worden. en dat 50 x per seconde.
als je daar geen cpu hebt die minstens 50 x 10 miljoen bewerkingen per seconde kan doen . ( das dus al 500 MHz ) kun je het vergeten

in ene fpga is dat kinderspel. je kan die fpga clocken aan 50 hertz ... dat spul pakt elke 2 pixels telt die op ( optellen is puu rcombinatorisch ) en deelt door 2 ( smijt laatste bit weg )

het enige wat aan 50 hertz moet gebeuren is de data laden.
een paar microsconden ( tzal eerder nanoseconden zijn ) later heb je dan het gemixte beeld klaar.
alle pixels worden immers simultaan verwerkt.

een fpga is dus niks anders dan een parallel 'processor'

het verschil in programmeren zit hem dat , bij een cpu je een lijst geeft met daarin een 'volgorde' van ewerkingen , en bij ene fpga je een lijst geeft met 'wat' er 'wanneer' moet gebeuren. je regelt alleen de manier waarop bits van het ene blok naar het andere gaan. binnenin ene blok is de snelheid alleen begrensd door de transmissietijd in de logische poorten.

[Bericht gewijzigd door free_electron op zaterdag 25 augustus 2007 18:12:23 (11%)]

Op 25 augustus 2007 18:02:53 schreef free_electron:
een voorbeeld ( in Verilog , die 'very hard design language' laten we links liggen)

Laat JIJ links liggen omdat je in de US zit. In Europa laten "WE" VHDL helemaal niet links liggen.

Op 25 augustus 2007 18:02:53 schreef free_electron:
Videomodulator slaat de nagel op de kop.
Alles is parallel. Je hebt ook gene probleme om iets bizar te doen.

bij beeldbewerking wordt dat hele duidelijk bijvoorbeeld.
2 beelden laten overvloeien.
ene processor moet dat pixel per pixel gaan doen. 2 pixels samentellen en delen door 2. ( we gaan even van 50 % mix uit )
als je dat moet doen op 2.1 miljoen pixels aan 50 beelden per seconde ... dan heb je een zeeeer straffe cpu nodig.
die loop moet imers 2.1 miljoen keer uitgevoerd worden , de input data ( 2 bytes per pixels ) meot 2.1 miljoen keer opgehaald worden en de output moet 2.1 miljoen keer weggeschreven worden. en dat 50 x per seconde.
als je daar geen cpu hebt die minstens 50 x 10 miljoen bewerkingen per seconde kan doen . ( das dus al 500 MHz ) kun je het vergeten

Dat is eerder een kwestie van slim aanpakken. Ik heb weleens een programma in C geschreven voor real-time image warping (om met een goedkope beamer toch op onregelmatige oppervlakten te kunnen projecteren) met anti-aliasing gemaakt dat op een P-4 1,4GHz onder Windows zo'n 110 frames/s haalde bij 800x600 in 24 bit kleur (dat is 158MB/s naar binnen halen, verwerken en uitspugen).

@Arjan Swets,

Een ervaren programmeur zal het ook wel in software kunnen realiseren. Immers, iemand die goed interrupt drivend events kan behandelen kan heel wat oplossen. Toch heeft een FPGA hier een belangrijk voordeel omdat je geen invloed van de ene functie op de andere hebt als er iets moet gewijzigd worden.

In die toepassing maak ik gebruik van scanrates in de orde van 10 usec. In software dan ga je al heel goed moeten opletten om dit op te lossen. Over het algemeen heb ik ook vrij veel uitgangen nodig. Die zijn massaal aanwezig op een FPGA, op een uC moet je dan ook al snel naar de grotere types gaan.

Mijn toestel is niet enkel voor die beestjes. Er zijn tot 8 lasers voorzien en die maken nog vele andere toepassingen mogelijk.

Ik heb een afzonderlijke topic over moodlight gemaakt. Zopas heb ik een eerste test programma geschreven voor mijn kleinste CPLD module met een EPM2210F324 chip. Ik heb die gemaakt voor 192 pwm's om 64 RGB leds te kunnen aansturen. De chip zit nu voor 75% vol en voor iedere led gebruik ik 9 bit kleur informatie die serieel ingescant wordt. Een dubbele buffering zorgt ervoor dat er nieuwe data mag ingeclockt worden terwijl de voorgaande date op de kleur RGB leds komt via die 192 pwm's. Met een gewone uC moet je daar niet aan denken. terwijl mijn gebruikte pwm frequentie 4 Mhz is zodat er op 10 Khz gescant wordt per led. Hierdoor wordt een stroompuls op de led nooit langer dan 100 usec, iets dat je moet in de gaten houden bij multiplexing en gebruik van de maximaal toegelaten piekstroom.

Die 192 pwm's heb ik geschreven in een goed uurtje werk. In een uC zal het wel moeilijker worden om je timing aan te houden en zeker voor 192 pwm's. Ik heb nu 1664 LE's nodig van de 2210 die beschikbaar zijn.

Op 26 augustus 2007 00:22:35 schreef Nico.c:
[...]

Dat is eerder een kwestie van slim aanpakken. Ik heb weleens een programma in C geschreven voor real-time image warping (om met een goedkope beamer toch op onregelmatige oppervlakten te kunnen projecteren) met anti-aliasing gemaakt dat op een P-4 1,4GHz onder Windows zo'n 110 frames/s haalde bij 800x600 in 24 bit kleur (dat is 158MB/s naar binnen halen, verwerken en uitspugen).

jep 800x600 lukt op die cpu.
ik gaf als voorbeeld dat het met een 500 MHz cpu misschien al moest lukken.

maar probeer eens een moderne videostandaard : 1920x1080 - 30 beelden per seconde (progressive scan) 36 bit kleur (12 bit per rgb pixel) .

dat lukt gewoon niet meer. Ik heb zo een kaart (RTx2). dat ding doet realtime color correctie , scaling , mix , whatever. en wat zit erop ? 2 immense fpga's ( Virtex met PowerPC processor aan boord, en een Stratix die de pci express doet, de dvi output regelt. en die de video a/d en d/a stuurt ( component input en outputs. de kaart kan ook analoog HD capturen en weergeven ). Elk effect wat je aantikt in premiere wordt gewoon in de fpga geladen. ( zijn ene pak binaries. ik vermoed dat ze gewoon een nieuwe bitstream laden per effect. )

enfin. het voorbeeld wordt gegeven om proberen uit te leggen wat het verschil is tussen fpga en cpu.

leuk element : in heel vele LCd en plasma tv's zit ene altera chip... wordt gebruikt om de scaling te doen van de binnekomende video aar de display output. is goedkoper dan daarvoor een asic te gaan maken. de evolutie in die markt gaat zo snel dat je chip ouderwets is tegen dat je 3 maand later een nieuwe tv op de markt brengt.

das nog ene voordeel. dat alteratje kost misschien hoop en al 10 dollar. als je voor het zelrfde een PIV met alle peripherie moet inschakelen. kost veeeeee meer.

@fotoopa. hoeveel bit pwm je ? ik heb ene probleem voor het moment. ik heb 8 pwm's gemaakt ( elk 16 bit maar met programmeerbaar start en stoppunt ( ik kan ze dus verschuiven in tijd ten opzichte van elkaar )

de logica werkt. maar ze is wel verschrikkelijk groot ( 1600 Le's .... ) tzal wel door het immense aantal flipflops komen.. (

d

@free_electron,

Ik gebruik 3 pwm's van 8 bit, een voor elke kleur. Binnen die pwm's bepaal ik 8 levels die via mux's door iedere led vergeleken worden met een 3 bit waarde per kleur (vandaar die 8 levels). 1 led kan bijgevolg 3x3bit of 512 kleuren weergeven. Ik vond het overkill om iedere kleur de volledige 8bit range te laten regelen omdat de verschillen veel klein zijn voor zo een toepassing. Maar binnen die 8 bit van de pwm's kan ik wel de beste stappen bepalen. Die stappen zelf hoeven niet linair te zijn. Anders zou ik voor de 192 pwm's alleen al 1536 LE's nodig hebben. Ook zou het doorsturen van de databits en de buffering veel te veel LE's vergen indien ik 8 bit regeling per kleur zou gebruiken. Het gaat hier tenslotte niet om video beelden maar een moodlight met vooral wat mooie design eigenschappen.

Defazering van de level sturing gebeurt op kleur niveau omdat de R, G en B levels in de pwm comparatoren verschoven outputs hebben. Zo kan ik de inschakelstromen ook wat verschuiven tov elkaar zonder veel LE's te gebruiken. Enderzijds heb ik 2 groepen van 32 RGB leds waardoor de uitgangen beperkt worden tot 32 voor de leds en 2x3 uitgangen voor de row RGB power sturingen van de led matrix.

Om zeker te zijn dat het geheel volgens mijn wensen verloopt heb ik de meeste delen via schema entry getekend. Eerst 1 blok als lib, daarna een blok van 8 kleine lib bloks en dan nog eens blokken van die grote blokken. Vandaar dat er eel weinig werk is of dit te realiseren.

8 PWM kanalen van ieder 16 bit? Dat is een kwestie van 2 16 bits registers en 2 comparators per kanaal. De eerste comparator geeft de start (set puls), de tweede de stop (reset) puls. Ik kom op 2*16+1=33 flipflops per kanaal (=264 flipflops voor 8 kanalen). Ik weet niet hoe hoog je frequentie is, maar je zou iets van een geheugen kunnen gebruiken waarbij je voor iedere tellerstand door het geheugen loopt en kijkt of je een start/stop conditie hebt. Dan kun je het ontwerp nog kleiner maken.

Op 26 augustus 2007 18:50:01 schreef Nico.c:
8 PWM kanalen van ieder 16 bit? Dat is een kwestie van 2 16 bits registers en 2 comparators per kanaal.

tis iets complexer dan dat .. iedere pwm heeft zijn eigen counter. Je kan val elke pwm de periode instellen ( de pwms kunnen niet alleen in puls/pauze geregeld worden maar elk ook in 'frequentie'. )
er zijn ook 2 outputs per pwm met elk hun eigen start en stoppunt ( maar met gemeenschappelijke counter en gemeenschappelijke periode comparator. )

16 bit teller gevolgd door comparator die kijkt naar het 'periode' register. als dat matcht : reset counter en herbegin van voor af aan.

en dan 2 start registers en 2 stop registers.
das dus al 96 flipflops voor dat spul ... en dan nog 1 flipflop per output die gest en gerest wordt door de comparatoren. dat zijn er nog eens 16 ...

( 8 x 96 ) + 16 .. das ene flink blokje ... het werkt hoor. ( aan 48 MHz zelfs .. ) maar ik was alleen verbaasd dat het zoveel lu's in beslag neemt.

kga vandaag ees proberen in het schema kijken wat die compiler gemaakt heeft. misschien dat ik het ook eens uitteken in schema vorm. kwestie van eens te vergelijken wat die synthesizer er van bakt. ( das allemaal leuk , maar soms vertrouw ik die synthesizer niet helemaal )

ik heb zo ook een skew generator gemaakt. soms synthetiseert dat niet helemaal correct . je moet dan met allerhande opties liggen modderen om aan te geven dat hij van de 2 invertoren die na elkaar staan moet afblijven en die niet mag minimaliseren ( ik gebruik een invertorketen om delay te genereren ). met die skew generator kan ik van een SPI-achtige bus de clock en data gaan shiften ten opzichte van elkaar. ( zowel uitgaande als binnekomende ) kwestie van de looptijd op het bord te kunnen compenseren. ( bus clockt op dik 320 Mhz )

als je dat uittekent in schemavorm klopt dat altijd. er is een optie die aangeeft dat hij schemas moet implementeren 'as-is' en niks mag minimaliseren.