FPGA waarom zoweinig nieuwe gebruikers?

Op 2 februari 2007 17:23:18 schreef sven:
Lijkt dezelfde als degene dewelke verkrijgbaar is via digikey (544-1736-ND) echter hier kost hij 116€ + 18€ +21% btw = 162,14€

Oei, Dat is idd goedkoper. Ik heb gezien dat het grootste verschil komt door de verzending. Maar er is geen voorraad bij NL. Nu voor de mensen die het toch hier zouden bestellen en ietjes langer kunnen wachten is de lagere prijs goed meegenomen. De board wordt nu wel heel goedkoop. Vandaar dat mijn stelling dat de Elektuur board veel te duur is nog meer waarheid bevat. Vooral de kwaliteit van de multilayer is een totaal ander niveau.

update: leveringstermijn is dan wel echt een stuk langer ( bijna 3 weken ipv 2 dagen)

Dus free_electron denk er eens over na, tenzij je op een of andere manier gebonden bent aan Elektuur....

Hoi fotoopa,

Ik zelf ben ooit begonnen met
software programeren om te begrijpen hoe de comp. werkt.

Als ongeschoolde haal ik mijn kennis altijd via internet,
zodoende zal ik meestal kijken naar dat waar veel over gepraat word.

Ik denk dus dat er meer over gepraat moet worden
en meer tentoongesteld moet worden.
Leg de logica uit.
Laat zien wat je allemaal kunt maken.

Zelf heb ik nu al interesse,

Vincent.

Ik programmeer het liefst altijd in assembler (kan en doe het ook wel eens in andere talen.), ben daarmee begonnen toen ik met AVR's begon. maar tegenwoordig ook voor de 386 computer. opzich leer je daar wel van hoe die prossesor in elkaar zit.

Fotoopa heeft een leuke site met foto's van leuke schakelingen voor zijn foto camera. als ik je een advies vinb kijk daar eens, en zie ook wat verder terug in dit topic. download quartis eens en ga daarmee alvast aan de slag als het bij mij lukt moet het toch zeker ook wel bij jou lukken. Er zijn met google diverse verilog tutorials te vinden, eigenlijk allemaal in het engels maargoed dat werkt ook wel.

Hoi elektroverslaafde,

Ikzelf ben een paar maanden met pic's bezig,
asm om te begrijpen.
Ook heb ik de foto's kunnen bewonderen via een ander topic.
Ik snap je aanrijking en dank je hiervoor,
maar ik bedoelde eigenlijk dat ik er nog nooit over gehoord had.
Ik ben tot zover in alles geinteresseerd wat mij meer kennis geeft,

Vincent.

Op 2 februari 2007 17:41:05 schreef (Z)weetvoetje:Ik vraag me eigenlijk af wat dat FPGA ding dan allemaal uit moet rekenen. Maar goed, ik zal een hoop dingen wel niet snappen ofzo.

Bij mijn toepassing ( vliegende beestjes) is de initieele cyclus rond de 32 usec. Dit is de cyclus waarbinnen alle beslissingen genomen worden.

Opzich een nog vrij haalbare tijd moest het software matig gedaan worden. Het grote voordeel echter bij een FPGA is dat al deze afzonderlijke functie's parallel verwerkt worden. Je hebt geen de minste interactie op de timing onderling in je tijdskritische functie's. Er zijn heel wat van deze functie's. Er lopen 10 tallen timingen parrallel. De laser functie's waar ook een digitaal filter op zit loopt volledig onafhangkelijk. De display functie ook. maar tijdens experimenteele opstellingen zijn er nog meer tijds kritieke functie's.

Bij een software oplossing wordt dit een nest van probleemstellingen, in een FPGA niet. Keyboardfunctie zal bij mij geen invloed hebben op de anders tijdskritieke interrupt functie's. Timingen van de flitsen ( tot 6 stuks) kunnen mooi parrallel afgewerkt worden. Aansturing van de shutter ook. Nauwkeurigheid ligt ook hier in de usec orde. Dit alles is geoptimaliseerd en geen enkel ander proces beinvloed deze waardes. Dat zijn juist de grote voordelen van een FPGA.

Vandaag nemen al deze functie's 1174 LE's in beslag van de 5980 beschikbare LE's in de chip of 20% Als ik straks de groene lasers zal bijplaatsen komen daar nog enkele LE's bij en terug geen enkele interactie op alle bestaande timingen. Dat zijn echt heel grote voordelen tijdens de evolutie van een project die je nooit of nooit zult bekomen in de softwereld. Hoe meer je toevoegd in software hoe moeilijker je de timingen kunt beheersen.

In software dan kun je een gevonden goede timing weer kapot maken bij de minste toevoeging van een nieuwe functie. En dan spreek ik nog van goede interrupt gedreven routines en van chips waar ook nog grote delen eigen hardware tellers inzitten voor bv PWM's te maken.

Op 2 februari 2007 20:29:07 schreef vinb:
Hoi elektroverslaafde,

Ikzelf ben een paar maanden met pic's bezig,
asm om te begrijpen.
Ook heb ik de foto's kunnen bewonderen via een ander topic.
Ik snap je aanrijking en dank je hiervoor,
maar ik bedoelde eigenlijk dat ik er nog nooit over gehoord had.
Ik ben tot zover in alles geinteresseerd wat mij meer kennis geeft,

Vincent.

o zo, nu ik had er wel over gehoord maar het is me nooit gelukt. ik kan namelijk vaak slecht overweg met software, daar komt ook nog eens bij dat alles in het engels is. gelukkig word daar op school toch zoveel aandacht aan gegeven dat ik het wel steeds beter leer. ik heb natuurlijk liever informatietechniek. Ik hoop over een paar weken als ik een beetje verilog kan eens zo'n fpga te kopen lijkt me machtig mooi.

@fotoopa
als ik u goed begrijp is het dus zelfs mogelijk om meerder volledig aparte processen in een fpga te stoppen zonder dat ze enige invloed hebben op de timing?

Op 2 februari 2007 21:20:04 schreef elektroverslaafde:
als ik u goed begrijp is het dus zelfs mogelijk om meerder volledig aparte processen in een fpga te stoppen zonder dat ze enige invloed hebben op de timing?

Zeg liever dat ze geen invloed hebben op mekaar, tenzij je ze bewust afhankelijk van mekaar maakt.

Op 2 februari 2007 21:20:04 schreef elektroverslaafde:
[...]@fotoopa
als ik u goed begrijp is het dus zelfs mogelijk om meerder volledig aparte processen in een fpga te stoppen zonder dat ze enige invloed hebben op de timing?

Ja natuurlijk. Dit is het basis princiep van een FPGA. Alles loopt parrallel. Als ze toch moeten samenwerken stuur je controlle signalen van de ene functie naar de andere om te wachten of te synchroniseren. En zolang er LE's ( logische elementen) overzijn en natuurlijk pinnen om het eventueel naar buiten te brengen kun je toevoegen.

juist daarom is er tijdens de ontwerpfaze van mijn controlbox heel wat studie vooraf gegaan hoeveel outputs ik ging gebruiken. Normaal gebruik ik voor experimenteele toepasingen minstens het dubbele aan uitgangen. Als je achteraf iets extra moet toevoegen moet je enkel via de PC je nieuwe configuratie erin blazen en je uitgang aansluiten. Zo zitten er op mijn box ook 4 FET uitgangen op die elk 400V 12A kunnen schakelen. Hiermee kan ik zelfs halogeen lampen sturen op 12V maar evengoed om het even welk magneet.

Voor de lasers zijn er tot 8 uitgangen dit zijn gewoon transistor uitgangen PNP type die 4.5V kunnen doorschakelen. Rode lasers hebben 4.5V nodig. Zo kan ik extra lasers bij programmeren indien nodig.

Er is ook een reeks gewone opencollector uitgangen. Dit zijn gewoon bc546 transistors open collector die "iets" kunnen schakelen. wat speeld weinig rol. Als je een functie ervan kunt gebruken, plaats die erbij en het is klaar.

Ook zo voor een basis ingangs signaal. Zo heb ik er ook een reeks. Die zijn allemaal beveiligd tegen overspanning en ESD en verkeerde polariteits aansluiting. Zo kun je ze bijna niet stuk maken. Moet ik vb een signaal meten dan sluit ik dit aan op zo een ingang. Een toepassing is om de reactie snelheid te meten van een camera tussen het ogenblik dat je drukt en het moment dat echt de foto genomen wordt. Deze functie zit standaard in mijn controlbox waardoor ik verschillende type camera's kan meten. Tijden lopen van 37 tot 200 msec. De display geeft deze waarden weer tot 1 usec nauwkeurig.

En zo kan je door gaan. eindeloos en steeds met dezelfde basis box. Zelfs nu doe ik regelmatig testen van nieuwe functie die niets met mijn fotografie te maken hebben maar toch kunnen gestest worden in de bestaande controlbox.

Een paar voorbeelden:

- Verleden week heb ik een RC5 afstands bedienings dekoder gemaakt. De codes komen zichtbaar op de display van de controlbox bij het drukken van een waarde van mijn TV bediening;

- Ook gemaakt een CW ( morse) generator. 2 ingangen genomen op de controlbox en de interne beeper gebruikt om morse codes te genereren. Alle bestaande functie voor mijn fofografie blijven daar gewoon inzitten en werken!

Zo kan ik eindeloos doorgaan en ik heb niets binnen mijn box moeten solderen of hardware matig wijzen.

juist. dat is het grote verschil met ene cpu.

in een fpga gebeurt ALLES tezelfdertijd op de cadans van je clock ( je kan zelfs meerder clock domeinen hebben die niks met elkaar te zien hebben )

bij ene cpu is het sequentieel. de processor voert de instructies 1 voor 1 uit. ene fpga niet. al de flipflops reageren op de clock.

je kan dus perfect een keyboard scanner, display controller en weetikveel wat nog allemaal naas telkaar draaiende hebben. maakt niks uit. het geeft geen invloed op je verwerkingssnelheid.
bij een cpu : hoe meer spul die moet doen hoe trager hij wordt ( je programma is groter en heeft een langere looptijd ) bij een fpga maakt dat allemaal niks uit. tloopt allemaal parallel.

bij systemen met een fpga ben je soms meer bezig met circuits te verzinnen om de ene op de andere te laten wachten ...

stel je ene 'select case voor' bij een case met 4 mogelijke combinaties heeft die cpu x werk, bij een
ene met 40000 mogelijkheden is het flink wat meer werk ( of je moet jumptables gebruiken maar haast geen enkele compiler ondersteund dat omdat tegenwoordig alles 'dynamisch' gemapt wordt omdat het voor de compiler bouwer 'makkelijker is'. bij jumptable werk je met hardcoded addressen. je kan dus niks dynamisch laden. van zodra je een operating systeem hebt werkt dat mechanisme niet meer. )

bij een FPGA maakt dat geen fluit uit.
in het eerste geval is het een 2 bit decoder , in het laatste geval een 16 bit decoder ( en dan jeb je direct 65535 combinaties.

tis wat meer logica en poorten maar voor de snelheid maakt het NIKS uit. je verliest misschein een paar nanoseconden omdat je tree wat groter wordt. maar die cpu plooit gewoon.

ik heb zo een voorbeeldje gemaakt in mijn boek voor een stom circuit wat 2 8 bit getallen bij elkaar kan optellen ( inclusief carry ) en een 9 bit getal ( 8 bit plus die carry bit 0 naar buiten brengt.

in een cpu heb je did aan je broek
begin:
mov a,p1
mov r1,p2
add a,r1
mov p3,a
bncf
setb p4.1
clrb p4.1
jmp begin

ik tel daar 8 instructies. stel je hebt een cpu die op 800 MHz bolt. en we gaan ervanuit dat de cpu dit kan per clocktick ( wat ook geen waar is ... cpus werken met cycles. en de meeste cycles zijn 4 clockticks : dus die 800MHz clock springt plots naar 3.2 GHz ....

onze cpu kan dus 100 miljoen van die bewerkingen doen per seconde
nu is er nog ene probleem. die cpu voert dat sequentieel uit. hij gaat eerst de eerste byte van p1 halen,
dan de tweede byte van p2. dit gebeurt op een verschillend moment in tijd ! het kan dus zijn dat de data ondertussen al gewijzigd is. bij een CPU heb je daar GEEN ENKELE controle over.
ook bij het uitvoeren heb je een probleem die carry bit komt later dan de 8 bits naar buiten....

in ene fpga is dat allemaal geen probleem.
16 fliflops voor de adder en 9 flipflops erna.
en je clockt ze allemaal met dezelfde clock. en gans de boel is plots synchroon.
je maximum clock is nu bepaald door de tijd die nodig is om een wijziging aan de ingang van de adder door te voeren naar de uitgang ( de zogenaamde looptijd ) . zelfs bij de kleinste , goedkoopste , traagste cpld of fpga zit die looptijd onder de 5 nanoseconden ( mijn circuitje had een stabiele uitgang na iets van 2 nanoseconden )

dit wil zeggen dat ik mijn flifplops kan laten draaien op iets boven de 400 MHz ... die adder gaat correct werken en volledig synchrone uitgangen afleveren.
en voor ELKE clockpuls komt daar een getal uit.
als je die 400 miljoen wil laten draaien op een cpu ga je grof geschut moeten bovenhalen ....
400 miljoen x 8 instructies x 4 clocks per instructie ... vergeet het.

je hebt daar ene kanon van een machiene voor nodig om dat te kunnen.
in een fpga of CPLD is dat wat combinatorisch grut ( wat and en or poorten ) en 25 flipflops. je ziet het geneens liggen.
in een EPM240 ( das de kleinste max II ) neemt het ene halve procent in beslag van alle logica. en zo een maxII is een vierkante centimeter groot....

das ook de reden dat bijvoorbeeld Cray en nog een aantal andere bedrijven nu FPGA coprocessoren hebben voor hun supercomputers . de functies waarvan geweten is dat ze veel clockcycli in beslag nemen op een CPU en die miljoenen keer per seconde moeten kunnen gelopen worden , mappen ze uit in een FPGA. ze maken op die manier een coprocessor die het cyclus intensieve werk inkort , precies omdat alles parallel gebeurt )

er zijn speciale software tools die je code (fortran of c) kunnen omzetten in verilog code. je moet wel heeeel clean programmeren . gekke kuren zijn niet toegestaan , of de vertaler doet het niet. die wordt gesynthetiseerd , in de fpga gepletst en de FPGA zit op de hypertransport bus rechtstreeks gemapt in het geheugen van de processor.
hopla : instant coprocessor.
je kan nog vele meer. als je fpga groot genoeg is hang je er desnoods 4 processoren aan en mapt die routine daar 4 keer inf , of je hangt er 16 processorne aan en mapt ze er 16 keer in .. ( enfin je snapt het wel )
voor de fpga maakt het niks uit of ie dat 1 keer of 16 keer moet doen. de boel draait toch in parallel.

de boel is volledig combinatorisch

Het probleem voor mij het voornamelijk het "soldeer" bezwaar,
Niet omdat het goedkoop moet, maar ik wil het ding graag in de toekomst kunnen integreren in een project. Je kan wel starten met een evaluatie bordje, maar uiteindelijk wil ik het ding op een printje kunnen zetten en niet voor elk projectje een nieuw evuatiebordje te hoeven kopen.

Daarnaast heb ik niet zo'n idee waar ik zou moeten beginnen, terwijl de inversteringen toch (naar mijn mening) best groot zijn. De meeste evaluatiebordjes die ik tot nu toe voorbij heb zien komen zitten vol met poespas die het duurder maken, maar voor mij hoeft, dat (nog) niet om kennis te maken.

Ik gebruik sinds een jaar ook FPGA's en ik vind ze geweldig! Het is inderdaad een grotere drempel dan een simpele microcontroller, dus ik kan me voorstellen dat er hier op CO weinig mee gebeurd. Ik werk dan ook alleen met fpga's voor mn beroep. Ik zal hier thuis niet even snel een fpga in een design knallen, microcontrollers geen probleem. Zit hem toch in de complexiteit en kosten.

Op het werk gebruik ik nu een Xilinx xc3s1500 voor video toepassingen. Digitale HD video stroomt binnen op 1.485Gbit/s (1080i60 formaat), de fpga doet bijvoorbeeld embedden van audio packets (I2S samplen, packetizen, crc en ecc calculaties, syncen op videostream, paketjes muxen enz...) En de fpga zit nog uit zn neus te vreten... Tis allemaal mogelijk door alles parallel op te splitsen, video wordt parallel verwerkt (20 bit bus). Audio gaat door een lange pipeline heen, bij elke stage wordt er iets toegevoegd of berekend. Uiteindelijk draait de fpga op een clock van 74.25MHz (nog steeds peanuts dus)
Dit soort taken kun je shaken met een cpu, hier is een FPGA echt ideaal.

Ik ben overigens begonnen met dit bordje van xilinx, was iets van 130 euro totaal. Zit een FPGA op met 500k gates en een eenvoudige CPLD.

@JoVi:
De FPGA zelf is altijd een struikelblok. Gelukkig bezit ik hier voor de hobby nogal wat oude testprintjes waar veelal een EPM7192SQC160 opstaat. Die is voor heel veel kleine toepassingen ruim voldoende. Het toevoegen van de in en uitgangen moet je toch realiseren zij het FPGA of PIC of micro controller. Maar die toevoeging doet ik altijd op gaatjes print met klassieke componenten. Vandaar geen gezeur met pcb's tekenen terwijl de werking toch perfect gaat.

Dat ik een duurdere ontwikkelingsboard gebruik is puur luxe. Vooral in de wintermaanden zit ik lekker beneden in mijn bureel te werken. Daar moet alles heel netjes blijven van mijn vrouwtje, enkel de scoop is nog net toegelaten. Die DE1 ontwikkelings board is ook heel mooi en mag op het bureel blijven staan. Ik kan hierdoor alles ontwikkelen, testen, meten met de scoop, zelfs een VGA scherm verbinden enz. Ik heb geen soldeerbout nodig hier beneden in mijn bureel!

De laatste stap naar de echte toepassing doe ik dan boven waar ik veel meer ruimte heb en waar ook mijn kleine draaibank staat samen met nog wat tools voor ponsen en plaat bewerking. Daar kan ik alles inbouwen tot een proper geheel.

Daar gebruik ik helemaal geen kit meer. De goedkoopste oplossing is om de TQFP 144 pins behuizingen op een klein printje te hebben waarvan de I/O pinnen naar de zijkant gebracht zijn op 2.54mm raster en je die op een gaatjesprint kunt bevestigen waar je dan met klasieke transistors verder je I/O's kunt verzorgen.

Als je natuurlijk zware toepassingen hebt zoals audio of video wordt het een stukje moeilijker en is er meer nood om ook een pcb als drager te gebruiken ipv gaatjesprint. Maar ook hier is er dan geen verschil met een microcontroller toepassing.

@KillerB the Supreme:

Je zit professioneel blijkbaar met de ideale toepassingen voor FPGA's. De hoge data stroom van de HD video die op LVDS lijnen zal binnenkomen leent zich uitermate goed voor deze bouwstenen. Xilinx heeft ook heel mooie bouwstenen. Op het werk waren Altera en Xilinx ongeveer elk 50% aanwezig. In bijna ieder ontwerp zaten er FPGA bouwsteentjes. De grootste groep toepassingen waren ook voor video (de grote LED walls die je over de hele wereld ziet en de Control rooms)

Gezien ik nu op rust ben voel je al snel hoe de wereld op een 3tal jaar veranderd is. Hoe groot de FPGA's geworden zijn. Voor de hobby moeten we het rustig blijven doen maar met mijn laatste cyclone II devices voel ik mij nog steeds jong. Ik ben uiterst blij nog steeds op hobby basis verder te mogen werken in deze snelveranderende omgeving waarbij ik heel fijne technieken in mijn hobby kan toepassen. Het is verbazend hoe weinig gebruikers deze mooie techniek kunnen integreren voor andere toepassingen zoals mijn fotografie hobby. Juist de combinatie van fotografie, FPGA technologie, optica, en ook een heel stukje fijne mechanica brengen dit geheel tot mooie resultaten.

Dat ontwikkelings boardje van Xilinx ziet er ook een prachtig stukje uit. Ook de prijs ziet er hetzelfde uit als mijn DE1 board. Ik zie dat beide fabrikanten kits ter beschikking stellen die je nooit kunt zelf maken voor die prijs. Ze trachten op die manier gebruikers te winnen voor hun chips en weten goed eens je in een richting begonnen bent je toch meestal blijft verder werken met hun chips. Gelukkig kunnen we ook voor de hobby gebruik maken van deze mooie aanbiedingen.

Op 2 februari 2007 17:23:18 schreef sven:
Lijkt dezelfde als degene dewelke verkrijgbaar is via digikey (544-1736-ND) echter hier kost hij 116€ + 18€ +21% btw = 162,14€

De BTW is in nederland toch 19%, of loop ik achter??

Op 3 februari 2007 10:39:08 schreef legacy:
[...]
De BTW is in nederland toch 19%, of loop ik achter??

Nee je loopt synchroon!

Soms moet je wel ( als belg) 21% BTW betalen maar als ze enkel een zetel hebben in Nederland zal het idd 19% zijn. Dan wordt het nogeens 3 euro goedkoper.
Maar soms durven ze dan weer de verzendingskosten optrekken.....
Maar dat zal de doorslag niet meer bepalen voor een al of niet aankoop.

Op 3 februari 2007 11:04:28 schreef fotoopa:
[...]
Nee je loopt synchroon!

Soms moet je wel ( als belg) 21% BTW betalen maar als ze enkel een zetel hebben in Nederland zal het idd 19% zijn. Dan wordt het nogeens 3 euro goedkoper.
Maar soms durven ze dan weer de verzendingskosten optrekken.....
Maar dat zal de doorslag niet meer bepalen voor een al of niet aankoop.

Ik ben Belg , bestel via be.digikey.com en betaal dus ook Belgische BTW, zijnde 21%
Bestellen via nl.digikey geeft volgens mij hetzelfde omdat de BTW wordt aangerekend door het land van bestemming, dus 21%

Op 2 februari 2007 22:12:14 schreef free_electron:

je kan dus perfect een keyboard scanner, display controller en weetikveel wat nog allemaal naas telkaar draaiende hebben. maakt niks uit. het geeft geen invloed op je verwerkingssnelheid.
bij een cpu : hoe meer spul die moet doen hoe trager hij wordt ( je programma is groter en heeft een langere looptijd ) bij een fpga maakt dat allemaal niks uit. tloopt allemaal parallel.

Dat is niet zo. Een cpu heeft vaak ook modules in hardware uitgevoerd (die kun je niet zelf programeren, maar wel aan sturen, I2C, UART, Display, USB, etc.)

Als je bijvoorbeeld, simpel voorbeeld, een uart wilt aan sturen dan schrijf je naar het uart register en die handelt de hele communicatie af. Als hij klaar is krijg je een interrupt, in de tijd dat je zit te wachten op die interrupt kun je iets anders doen.

Want zeg nu zelf als je een keyboard controller en een display controller hebt lopen in een FPGA, dan wil je toch ook ergens een centrale controller hebben, in de FPGA of daarbuiten, die de input van het keyboard omwerkt naar iets op het scherm?

[edit]
Ok als je alles gaat bitbangen dan heb je gelijk, maar dan ben je wel erg achterlijk bezig, als het ook al als een hardware module in de CPU zit

En laten we er nu niet een discussie van maken als tussen PIC en AVR, als je het wilt gebruiken gebruik je een FPGA, anders een CPU, het is geen geloof.....

[Bericht gewijzigd door surge_me op zondag 4 februari 2007 12:16:42 ]

Op 4 februari 2007 12:14:17 schreef surge_me:
En laten we er nu niet een discussie van maken als tussen PIC en AVR, als je het wilt gebruiken gebruik je een FPGA, anders een CPU, het is geen geloof.....

Je kan natuurlijk altijd nog je eigen PIC of AVR in een FPGA gieten, kijk maar eens bij http://www.opencores.org/browse.cgi/by_category

Op 4 februari 2007 12:14:17 schreef surge_me:
[...]Want zeg nu zelf als je een keyboard controller en een display controller hebt lopen in een FPGA, dan wil je toch ook ergens een centrale controller hebben, in de FPGA of daarbuiten, die de input van het keyboard omwerkt naar iets op het scherm?

Voor een vaste toepassing is dit niet nodig. De scherm indeling is vooraf door de toepassing bepaald waar de gegevens komen. Er is geen extra centrale beheerder nodig om dit te schikken. Het resultaat van de tellers, timers enz zijn vast verbonden bij het opmaken van je toepassing. Als de data wijzigd zie je dit op het scherm. Je mag dit niet vergelijken met een user interface waar een standaard keyboard of muis als invoer en een scherm als uitvoer gebruikt wordt.

Variable data komt toch op een vaste voorziene plaats of regel. Bij een software oplossing gaan ze strings gaan schrijven, bij een hardware oplossing vervalt dit. Mijn display routine gaat kontinu in een eigen loop de 32 characters die aangeboden zijn op het scherm brengen. Dit merk je bij gegevens waar data heel snel veranderd. Omdat de scanrate vrij hoog kan zijn zie je bij vb een teller met 6 digits uitlezing alle digits mooi tellen. Ze lopen bijgevolg nooit blokkerig.

Teksten worden vast aangeboden. Mocht er toch iets instelbaar zijn tussen meerdere programma's dan zorgt een mux en een selectsignaal dat er een andere tekst opkomt. Ook zo voor eventueele andere data registers.

Ten eerste: FPGA's zijn gaaf. Als je eenmaal "van de grond" bent met die dingen kan je sommige projectjes veel sneller laten lopen dan eerst.

Voorbeeld: Een PIC om een 3fase motor aan te sturen. Gaat allemaal maar net, dus krijg je wat jitter in de tijden dat de spoelen aanstaan en zo. Een FPGA om dezelfde 3fase motor te sturen: Ding loopt op 50 MHz, dus max afwijking: 20ns.

Wel blijkt dat het gedoe met de FPGA compiler vervelend is. Traag, groot programma. Dus je ontwikkel-cyclus is langzaam.

Ik heb een AVR core op mijn Altera ge-implementeerd, en programmeer sindsdien dus de AVR en pas de FPGA weer weinig aan....

Ik heb een bordje met een Altera Cyclone, en een FTDI245 chip. Bitbang om de altera te programmeren: een paar seconden. 64 IO pennen van de altera vrij te programmeren. (en twee testleds op het bordje). Als er voldoende interesse is, kan ik er nog wel een paar laten maken, maar dan gaan jullie natuurlijk vragen: Wat kost dat, en daar weet ik dan weer even geen antwoord op.

De cyclone en de FTDI chip zijn lastig te solderen: .65 mm pin pitch (Of was het nog minder?).

Sinds kort ook helemaal verliefd op FGPA's.

ben er op mijn stage in contact mee gekomen. Mocht meteen spelen met het STRATIX developmentboardje van altera..Bij de uiteindelijk opdracht kon ik spelen met een printje met 2 Cyclone's en een Stratix GX erop:) opdracht zelf mag ik helaas niets over vertellen.

toch maar gauw besloten om daar ook af te gaan studeren.

Mogelijkheden zijn echt eindeloos...ik wil ook echt een leuk developmentboardje voor mezelf hebben. Dus als er iets leuks ontwikkeld word wil ik er zeker eentje hebben

Zit dit topic zo te lezen en het 'show your FPGA en CPLD project' topic en wil er toch zelf ook wel aan beginnen. Alleen heb nog wat vraagjes

1). FPGA en CPLD zijn van buiten (vanuit oogpunt van development) precies het zelfde, alleen de FPGA heeft nog extern rom nodig omdat hij anders bij stroom uitval zijn programma kwijt is en een CPLD heeft dit al intern? Als dit klopt, dan is het om te beginnen waarschijnlijk makkelijker om een CPLD te nemen?

2). Overal lees je over macrocells en usable gates. Voor beetje normale FPGA/CPLD (klein to midden groot programma), hoeveel heb je er dan nodig? Ik denk hier voornamelijk aan bijvoordbeeld een simpele soft core processor of kleine state machine.
Ik heb ook al een paar processoren in verilog en systemC geschreven voor de TU/e, kan ik bij het compileren ergens zien hoeveel cellen/gates die gebruikt?

3). Is er ergens een schema/voorbeeld hoe je zo'n FPGA/CPLD aan de PC hangt om hem te programmeren? Het liefst voor xilinx (heb ik het meeste ervaring mee) maar altera mag ook. Dus zoals Madwizard in het 'show your FPGA en CPLD project' topic heeft beschreven over het schrijven van de code, alleen dan voor het programmeren. Deze heb ik al gevonden

Hoop dat iemand hier de antwoorden op heeft.

Op 5 februari 2007 10:54:29 schreef rew:Wel blijkt dat het gedoe met de FPGA compiler vervelend is. Traag, groot programma. Dus je ontwikkel-cyclus is langzaam.
Ik heb een AVR core op mijn Altera ge-implementeerd, en programmeer sindsdien dus de AVR en pas de FPGA weer weinig aan....

Deze zin begrijp ik niet. Quartus draait toch vrij vlot... Ik heb de AVR core zopas gedownload van open-cores. Ik weet niet als het die is dat je gebruikt maar de ganse core was hier toch vrij snel gecompileerd, ruim 1 min ongeveer. Hij verbruikt ongeveer 3453 elementen op een cyclone II. Met AVR heb ik geen ervaring maar het ziet er heel mooi uit. Was geschreven in VHDL, ken ik minder, maar om te gebruiken en te compileren maakt dit niet uit natuurlijk.

Ik zou hem zo kunnen gebruiken mocht ik daar behoefte aan hebben, das het grote voordeel van die open-cores en de grote devices. Hij neemt 18% resources van de chip in beslag....

Mooi om dit allemaal zo snel te kunnen uitvoeren!

Op 5 februari 2007 11:49:31 schreef xantus:
1). FPGA en CPLD zijn van buiten (vanuit oogpunt van development) precies het zelfde, alleen de FPGA heeft nog extern rom nodig omdat hij anders bij stroom uitval zijn programma kwijt is en een CPLD heeft dit al intern? Als dit klopt, dan is het om te beginnen waarschijnlijk makkelijker om een CPLD te nemen?

Klopt, CPLD is makkelijker mee te beginnen. De MAX II CPLD is qua structuur een soort mix van CPLD en FPGA heb ik ergens gelezen waardoor ze heel krachtig zijn, ook al blijft het een CPLD. Ik weet niet of Xilinx iets soortgelijks heeft, geloof dat de Coolrunner er wel op lijkt maar ik ben totaal niet thuis in Xilinx.

2). Overal lees je over macrocells en usable gates. Voor beetje normale FPGA/CPLD (klein to midden groot programma), hoeveel heb je er dan nodig? Ik denk hier voornamelijk aan bijvoordbeeld een simpele soft core processor of kleine state machine.
Ik heb ook al een paar processoren in verilog en systemC geschreven voor de TU/e, kan ik bij het compileren ergens zien hoeveel cellen/gates die gebruikt?

In Quartus kun je na de compilatie het aantal logic elements zien dat het inneemt, in het compiler report. Wel moet je zorgen dat je code ook daadwerkelijk aan inputs en outputs hangt anders wordt alles of een deel weggeoptimaliseerd.

Gates komen volgens mij van ASICs (custom chips) af en zijn simpele logische poorten. Soms worden FPGA's daar in uitgedrukt. Macrocells en logic elements zijn meer bouwblokken. Een LE van altera heeft bijvoorbeeld een 4-input look-up table, een 1-bit register met adder/carry gebeuren en nog wat verbindingen.

Om een idee te geven trouwens: de PWM code die geschreven had (2x4-bit) nam 14 LE's in. De LCD-video player zit bijna aan de maximale 240 van de kleinste MAX-II. Vooral met registers gaat het hard, elke bit geheugen neemt 1 LE in beslag. De Cyclone's e.d. hebben ook RAM ingebouwd, maar de MAX-II's hebben dat niet (meeste CPLDs niet).

@ xantus,
1. klopt, CPLD heeft geen extra componenten nodig, en is meest eenvoudig om te starten.

2. Beste keuze is ergens een MAX II Altera ( Xilinx weet ik niet, ben enkel Altera gebruiker)Deze hebben 240, 570, of 1270 elementen. Ik zou aanraden 570 of 1270 LE's want zoveel verschil in prijs zal er niet zijn. Ook het solderen op een pcb zal hetzelfde zijn.

Bruikbare Gates speelt minder rol maar is toch in functie van je aantal LE's. Met 1270 LE's kan je echter al heel grote projecten maken. Wat wel veel LE's verbruikt zijn de uP cores die men soms wilt integreren. Maar ik vind dat je daarvoor al een goede reden moet hebben anders kun je evengoed eentje afzonderlijk gebruiken. De meesten gebruiken die uP cores omdat ze dan gemakkelijker overgaan van de uP's naar CPLD of FPGA.

Ik heb hier een LCD 2x16 char display op mijn toepassing. Die is volledig zelfstandig geschreven, auto scanning, alle 32 characters zijn verbonden met de toepassing en die verbruikt opzich 109 LE's. PWM's verbruiken heel weinig maar wat Madwizard uitgewerkt heeft is wel een beetje brut van instelling. Ik gebruik mijn PWM's altijd met 8 bit counters, die hebben dan een fijne regeling tot 1/256. Maar dannog komen daar weinig LE's bij.

Mijn volledige uitrusting voor het fotograferen van vliegende beestjes zoals in de andere topic's getoont verbruikt 896 LE's. Daar zit enorm veel logica in, heel veel beveiligingen, volledige LCD display, keyboard scan, power control inclusief 10 bit PWM, laser scan en digitaal filter, en heel veel 5 digit timmers die configureerbaar zijn. Dit zou nept nog in een MAX II 1270 LE's kunnen. Praktisch ga je best niet al te ver over 80% usage van de chip.

update: Ik zie dat madwizard mij juist voor is met een antwoord!

Bedankt voor de snelle antwoorden

Als ik het goed begrijp wordt dus aangeraden of de MAX II EPM1270 of EPM570 te nemen of een Coolrunner II XC2C384 of XC2C512.

Dan komt het volgende probleem. Deze komen alleen in TQFP (en BGA) packages. Waar zijn dit soort adapter prints naar dip to koop? (zelf etsen voor TQFP en BGA heeft voor mij geen zin, kleinste wat zeker lukt is 14mil en met een aantal keer proberen 12mil (met 14 mil clearance).