[IA] FPGA development board

Wat ik op de (meeste?) bordjes mis is een microcontroller.

Een FPGA ontwikkelbord met een fatsoenlijke microcontroller (zeg een MSP430F149 of een LPC2104) maakt dat een bordje als compleet geheel inzetbaar is. Als er dan ook nog een stukje flash bij zit waarin de configuratie van de FPGA past, dan kun je de microcontroller de FPGA laten programmeren. Met een klein extra stukje software kun je de configuratie via de seriele poort downloaden. Dat scheelt weer geknoei met een JTAG tool.

Dan nog een USB naar serieel converter erbij en je heb toegang tot de microcontroller en een voeding voor het bordje.

Tijdens het ontwikkelen van een wat groter FPGA ontwerp is het verdomd handig als je met een command-line interface bitjes aan/uit kunt zetten of ergens een status kunt uitlezen.

In het begin had ik er een uC bij zitten in configuratie zoals jij hier beschrijft. Er gingen toen bij veel mensen stemmen op om dit niet te doen omdat je dan veel features van quartus niet meer kan gebruiken.

Tijdens het ontwikkelen van een wat groter FPGA ontwerp is het verdomd handig als je met een command-line interface bitjes aan/uit kunt zetten of ergens een status kunt uitlezen.

Hier heb je toch geen uC voor nodig. Beide boardjes hier (en de meeste tot alle) hebben een USB aansluiting. Je kan je FPGA dus direct aan de USB hangen om de status uit te lezen en bitjes te setten.

Maar jij zoekt dus eigenlijk meer zoiets: http://www.circuitsonline.net/forum/view/43809/1/

Iedereen heeft andere eisen voor een fpga bordje, afhankelijk van niveau en doel. Er zijn al een stuk of 3-4 mensen, die in dit topic gezegd hebben bezig te zijn, met het ontwikkelen van een fpga bordje.

Als er voor jou geen bordje er tussen zit, dan kan je zelf aan de slag .

Op 18 april 2007 23:16:30 schreef Nico.c:
Wat ik op de (meeste?) bordjes mis is een microcontroller.

Met een klein extra stukje software kun je de configuratie via de seriele poort downloaden. Dat scheelt weer geknoei met een JTAG tool.

Tijdens het ontwikkelen van een wat groter FPGA ontwerp is het verdomd handig als je met een command-line interface bitjes aan/uit kunt zetten of ergens een status kunt uitlezen.

en waarvoor denk je dat die jtag dient ? exact voor hetgene jij hierboven beschrijft.
sterker nog. je kan met die jtag gaan single steppen en dergelijke.

JTAG zuigt want je hebt voor ieder device weer een andere programmer/interface/software nodig. En meestal werkt het ook niet helemaal vlekkeloos (ik heb zelfs FPGA's stukgemaakt door er via JTAG een verkeerde bitstream in te laden -lang verhaal-).

Als ik zie/lees hoe mensen zitten te klooien om een jtag debugger aan de gang te krijgen dan ben ik toch heel blij met mijn simpele commandline interface die domweg werkt zodra de seriele poort werkt.

Bovendien, als je een microcontroller kiest die goed met C te programmeren is, dan kun je je software op de PC schrijven en op de PC debuggen.

Zo schrijf ik heel veel van mijn embedded software. Ik ben momenteel (o.a.) bezig met een tcp/ip stack. Die heb ik eerst helemaal op de PC uitgeprobeerd en aangepast alvorens deze in een microcontroller toe te passen. Hetzelfde ga ik doen met de http-server die er bovenop moet gaan draaien.

Hetzelfde geldt voor een FPGA; die kun je eerst op de PC simuleren. Aan de andere kant is een logic-analyzer geen overbodige luxe om de uiteindelijke werking to controleren.

systemC anyone? kan je hele je design op de PC schrijven en in C (het zij een set van classes voor C++). Daarna kan je het nog runnen als .exe ook . Maar ook alle andere talen kan je op je pc debuggen met een waveanalyzer alvorens je hem in je FPGA laad.

Op 19 april 2007 21:40:42 schreef Nico.c:
JTAG zuigt want je hebt voor ieder device weer een andere programmer/interface/software nodig. En meestal werkt het ook niet helemaal vlekkeloos (ik heb zelfs FPGA's stukgemaakt door er via JTAG een verkeerde bitstream in te laden -lang verhaal-).

Bovendien, als je een microcontroller kiest die goed met C te programmeren is, dan kun je je software op de PC schrijven en op de PC debuggen.

??? JTAG is net universeel !
JTAG is JTAG. punt amen en uit

en als je verkeerde bitstreams laadt en zo de boel opblaast. tjah .. eigen schuld dikke bult.

trouwens ik zie daar dat je het over 'C' hebt. als er een ding is wat zuigt ... dan is het dat.

JTAG is niet meer dan een manier van bitjes in een device laden. Wat een device er vervolgens mee doet is verre van universeel. Bovendien zijn jtag implementaties regelmatig buggy waardoor de tap interface zichzelf kan ophangen. Het is niet voor niets dat er op veel devices een extra 'jtag reset' pin aanwezig is om de tap interface weer aan de gang te helpen.

juist. maar de manier waarop bitjes geladen worden is wel universeel.

Trouwnes die implementatie via ene micrcontroller is ook niet universeel.

En die chips waarvan te TAP zich ophangt : smijt die in de vuilbak, ze zijn hun geld niet waard ( laat me raden. t'zijn er met een ARM in zeker ? dat kreng is daarvoor gekend. k'heb nog nachtmerries van hunne zwarte 'icebox' met de 'angel' monitor. je was ene half uur bezig om de icebox te resetten , je systeem te resetten en de pc software opgestart te krijgen in de juiste volgorde of de jtag liep inderdaad continue vast. en de nieuwe ice boxen met ethernet zijn al geen haar beter. geef mij maar een wiggler van greenhills. 4 weerstanden aan de printerpport en aan de jtag poten van de chip... en't werkt altijd ).

De TAP heeft een TRST pin. als ie het daar niet mee kan doen .... en trouwens TAP is maar 1 van de toepassingen van de JTAG poort.

Bij FPGa's kan je via die jtag poort veel meer dingen doen. Naast de TAP je kan via een signaltap analyser bijvoorbeeld intern in de fpga gaan meten , en je kan er zelfs een seriele poort over jagen. en de config roms programmeren.

altera heeft een macroblok waarbij ze een standaard uart via de jtag naar buiten laten komen.
als je een NIOS processor in je fpga zitten hebt kan je dan via de jtag met de pc communiceren. instant sourcecode debugging voor je embedded processor!

trouwnes hoe ga je die processor op je bord programmeren ? ook via een jtag zeker ?

dat is rommelen.
je snijdt jezelf de handen af. quartus stelt je in staat om allerhande leuke dingen te gaan doen via de JTAg poort van de chips en dat werp je allemaal in 1 klap weg om dan op een krakkemikkerige manier het wiel te proberen heruitvinden.

enfin, das mijn gedacht. elk 't zijne

Nee, Xilinx heeft er -voor zover mijn ervaring- last van gehad in de Spartan2 / Spartan 2E serie.

Microcontrollers die ik kies zijn bij voorkeur via de seriele poort te programmeren. De UART moet 100% goed werken anders verkoopt de chip uberhaupt niet.

Sourcecode debugging is een handige feature, maar ik heb daar eigenlijk alleen tijdens het ontwikkelen van de modules op de PC behoefte aan. In de embedded omgeving zelf ben ik meer geinteresseerd in tussenresultaten (dat de code werkt weet ik al) en die zijn veel beter op te vragen met een command line interface. Denk bijvoorbeeld aan een lijstje met geopende sockets. Bovendien verstoor je op die manier het eigenlijke proces het minst. Via jtag debugging zul je toch breakpoints moeten zetten die de processor redelijk lang stoppen om de waardes uit te lezen.

Als je dan bezig bent om iets van een acculader met een 120kHz interrupt voor de PWM te testen dan wordt het toch wel tricky.

Op 20 april 2007 00:54:05 schreef Nico.c:
Microcontrollers die ik kies zijn bij voorkeur via de seriele poort te programmeren.

dan is je keuze toch wel heel erg beperkt.

microcontrollers die een bootloader ingebakken hebben vanuit de fabriek zijn zeer dun gezaaid ...

Dat zou ik toch niet willen beweren. Sterker nog, de meeste microcontrollers hebben tegenwoordig een bootloader die programmeren van flash via de seriele poort ondersteund. Uit mijn hoofd: vrijwel alle ARM7TDMI derivaten (dat zijn er heel veel), de meeste 8051 derivaten van NXP, MSP430 serie van TI, 68HC11.

wat je daar opnoemt is 0.1 % van de microcontrollers out there ....

motorola is dood en begraven.
msp340 is propietary rommel van TI
op al de 8051 van philips ken ik er 1 die een bootloader heeft via de seriele poort. en das een heel oud beest.

arm7 derivaten ... noem er eens 10 ?
die dingen zijn zeer dun gezaaid. en verrekte moeilijk om mee te werken ( het is gewoonweg zeer moeilijk om daar development 'tools' voor te vinden. ze zijn er wel maar schrikbarend duur. )

Ach, als ie geen booloader ingebakken heeft dan maak je er toch even zelf een?

Op 20 april 2007 20:49:48 schreef flipflop:
Ach, als ie geen booloader ingebakken heeft dan maak je er toch even zelf een?

daar gaat het niet om !.

de vraag is hoe krijg je die bootloader in dat ding ? weer va de jtag. dat is dus het kip-ei probleem ...

Free_electron, tijd voor een opfriscursus

Kijk eens naar een LPC89C935 of een LPC2104 bij NXP. Kijk daarna nog eens bij ST, Freescale (voorheen Motorola en nog springlevend) en TI naar hun ARM derivaten.

Perfecte -gratis- ontwikkeltools voor ARM: GCC en Eclipse
( www.gnuarm.com, www.eclipse.org)

De GCC versie voor ARM laat bovendien alle commerciele ARM compilers ver achter zich. Sterker nog, vrijwel iedere compilerboer levert GCC mee in hun ARM omgeving... Het enige wat dan nog telt is de efficientie van de C-library, maar ook daar zijn goede alternatieven voor te vinden. De stdlib van de MSP430 GCC compiler ( http://mspgcc.sourceforge.net ) is super compact en laat zich eenvoudig compileren voor de ARM.

Voor een hoog volume product (+/- 5000 stuks/jaar) bleek dat de ARM7TDMI controllers van NXP (zo goed als) de beste prijs/prestatie verhouding hebben.

De MSP430 is overigens beslist geen rommel. Uitstekende analoge eigenschappen, extreem laag verbruik (<1mA), zeer compacte code (je kunt dus vrij veel programma kwijt in weinig flash), snel en een goede ondersteuning door GCC. Kortom, perfect ding dat weinig tot geen gelijkwaardige alternatieven kent. Olimex heeft MSP430 bordjes in alle soorten en smaken. Schaf er eens 1 aan en speel er eens mee.

T'is inderdaad wel erg makkelijk om alles maar rommel, ouwe meuk en ouden brol te noemen. Mooi dat er ook eens wat andere geluiden te horen zijn hier. Zet 'm op Nico!

En msp430 kun je met JTAG programeren en er zit ook nog een soort van opgerolde jtag in (scheelt 2 pennen)

MSP430 is prima om mee te werken ze hebben ook een eclipse omgeving om in c te programeren.

Werkt anders dan een FPGA maar het is zeker geeen rommel

Op 20 april 2007 23:42:47 schreef Nico.c:
Free_electron, tijd voor een opfriscursus

Kijk eens naar een LPC89C935 of een LPC2104 bij NXP. Kijk daarna nog eens bij ST, Freescale (voorheen Motorola en nog springlevend) en TI naar hun ARM derivaten.

De GCC versie voor ARM laat bovendien alle commerciele ARM compilers ver achter zich.

??? Ik ga op het bovenverdiep eens ene paar oorvegen moeten uitdelen als blijkt dat de onze met een seriele bootloader zitten .. Mij hebben ze altijd wijsgemaakt dat de download via Jtag gebeurt. (via de Raisonance probe of via de KEIL probe. of eendert welke jtag probe )

GCC ....je moet de output eens vergelijken tegen een Tasking of Greenhills. GCC is steevast 10 tot 20 % groter in romspace , en heeft meer ram nodig.

We hadden een paar maand terug zo een probleem : Klant had een probleem dattie niet genoeg rom meer had voor zijn applicatie. gebruikte GCC. onze embedded groep heeft die code binnegenomen , opgekuist hier en daar om 'eigenaardigheden' eruit te halen. gecompileerd terug met gcc. Paste net niet in een 8 megabyte flash.
zelfde source door Greenhills getrokken.( greenhills produceerde wel nog een waslijst warnings die GCC totaal niet vond , maar compileerde het wel) was net over 7 megabyte ... das 1/8 kleiner ... vooral als je daarmee ene dure 16 Meg flash uitspaart, je bord niet moet reviseren en met een 8 megabyte verder kan.

Als je dan weet dat sommige van die producten 'hoge volumes zijn' .. reken en tel uw kostenbesparing. als je dan moet kiezen tussen 'gratis gcc' en board redesigen + grotere flash, of een '10K dollar' Greenhills of Tasking..

Nuja, onze 'hoog volume cijfers' liggen wel iets anders ... tegen de 150 miljoen stuks per jaar .. draai maar eens een WD,Seagate of Maxtor schijf ondersteboven... en mocht er 'Agere' op staan : zij verkopen hem in licentie, maar wij designen en fabben hem.

en die andere klant met dat probleem was ook geen kleintje.. maar die wouden eens experimenteren met GCC... ze zijn rap teruggeschakled naar hun vertrouwde tools.

Half internet draait op applicaties die met GCC zijn gecompileerd van kleine broadbandrouter tot de webserver waar deze website op staat. Zo slecht kan het niet zijn, maar je moet er wel even de tijd in steken om het onderste uit de kan te halen.

Waar meestal het grote verschil in performance en grootte van de code in zit zijn de bijgeleverde libraries en de optimalisaties (sommige opties produceren grotere maar snellere code door loop-unrolling toe te passen).

Keil heeft bijvoorbeeld hun eigen ARM compiler vergeleken met GCC waarvan alle optimalisaties uit stonden. Natuurlijk is de Keil compiler dan sneller.

Bovendien wordt er voor de benchmarks meestal de dry-stones test gebruikt. Helaas gebruikt een deel van de dry-stones test ook de standaard C libraries. Een betere standaard C library resulteerd ook in een betere dry-stones rating!

Lees en huiver:
http://www.compuphase.com/dhrystone.htm

net dat artikel gelezen.
die kerel geeft zelf toe dat hij 1) andere versies gebruikt 2) andere settings ( keil heeft ook gefoefeld) en 3) een ander stuk code om de test te doen.

zo kan je niks vergelijken.

Dat voorbeeld wat ik daar gaf was dezelfde sourcecode gecompileerd met GCC en gecompileerd met Greenhills.
greenhills was 1 megabyte kleiner in rom.

plus dat greenhills met een gans pak extra warnings op de pinnen kwam voor mogelijke problemen.

enfin ik ben gene compilerspecialist. (geef mij maar assembly , PL/M of Visual Basic) Af en toe prul ik eens wat in C maar das heel summier (meestal librariekes om tegen bepaalde blokken hardware te praten. heel veel van de code in harde schijven wordt nog steeds in assembler geschreven. gans dat ding is time critical en t'moet bullet proof zijn)

Bij al de klanten waarmee ik in contact kom is er geneen die durft GCC gebruiken. je hebt ook nergens om heen te lopen als er een probleem is. stel dat er een compiler bug is en je hebt 10 miljoen systemen in de field zitten. Allemaal met het zelfde probleem , wat de schuld blijkt te zijn van een compilerbug. Waar ga je aankloppen als je gcc gebruikt ? ( en dat gebeurt ! wij hebben het voorgehad in code gemaakt door de ARM C++ compiler ( een jaar of 8 terug ), gelukkig gevonden voordat de code in productie kwam. Bij ARM hebben ze 3 dagen serieus gezwoegd om dat probleem uit de compiler te halen en de factuur betaald voor 3 dagen verloren productietijd. Als je zoiets voor hebt met GCC kun je alleen beroep doen op de goodwill van 'de community', hopelijk heb je dan na een paar weken een fix, en naar verloren tijd en geld kan je fluiten.

enfin. neemt niet weg dat GCC bruikbaar is om wat mee te spelen, maar voor industriele toepassingen zou ik het NOOIT durven gebruiken.

Waarom wordt dan steeds meer in velden Linux toegepast. Ook hier gaan dezelfde argumenten op als die jij noemt voor de GCC vergeleken met een commerciele compiler.
Ik denk dat elke commerciele compiler bouwer echt wel ergens in zijn overeenkomst heeft staan dat hij niet aansprakelijk is voor eventuele schade ontstaan door gebruik te maken van zijn product. Dat ze dit wel bij jullie doen is waarschijnlijk gelegen aan het feit dat ze jullie niet als klant kwijt willen en staan die 3 dagen tijd die ze moeten vergoeden in het niets tegen het bedrag dat ze binnen halen met licenties. Als het om echt veel geld gaat geven ze zeker niet thuis.
Ik weet dat zelfs in de luchtverkeersbeveiliging steeds meer Linux wordt toegepast vanwege de openheid van code en de grote communitie die je om raad kunt vragen.
Dus ik denk dat een opensource compiler lang zo gek nog niet is, ook niet voor kritische toepassingen.
Alles valt en staat bij testen / qualiteits controle ongeacht het product dat je gebruikt. Dus als er in het veld producten voorkomen die een fout bevatten die terug te wijzen valt op een compilerfout kun je alleen maar concluderen dat de mensen van Q.A. de producten niet volledig gevalideerd hebben.

Tja, 'your milage may vary'. Bij een voormalige werkgever van me gebruiken ze al ongeveer 10 jaar GCC voor de H8/300 serie van Renesas (Hitachi) omdat GCC juist minder bugs bevatte dan de IAR compiler. De spullen die ze verkopen staan bij duizenden wereldwijd geinstalleerd voor kritische toepassingen.

Ik vind het trouwens vreemd dat mensen nog steeds in assembly schrijven. Ik kijk af en toe weleens wat de C compiler ervan maakt, maar daar kan echt geen assembler programmeur meer tegenop. Die code is al tot op het bot uitgebeend waarbij in sommige gevallen ook rekening is gehouden met prefetching en caching.

Bij heel veel producten maakt de efficientie ook niet eens veel uit. Niet alles gaan in miljoenen aantallen de markt op. Andere voordelen kunnen dan zwaarder wegen.

ik deed vorig jaar mn stage bij een bedrijf hier in belgië. Een bedrijf waar, in de sectie waar ik werkte, satellieten ontwikkeld worden. Daarnaast ontwerpen ze ook nog allerhande betalingssystemen ea.., en ook daar wordt er overtuigend gekozen voor een open source compiler (in dit geval was dat GCC). Ook waar het best kritisch is kan een open source compiler zijn voordelen geven tegen een andere ..