FPGA waarom zoweinig nieuwe gebruikers?

SVF is een leuk formaat, je hebt echter ook XSVF, das hetzelfde, maar dan in binair formaat (stuk compacter maar niet meer leesbaar). Ik gebruik dat ook, je kunt daarmee direct vanuit een microcontroller een FPGA programmeren. Eigenlijk kun je alles programmeren wat een jtag interface heeft. Ik doe ook het platform flash voor de fpga ermee.

En als je nu denkt, oh jeeee.... dan moet ik alle instructies zelf gaan parsen, nee nee, niet doen. Zielinks heeft dat allemaal al bedacht:

http://www.xilinx.com/bvdocs/appnotes/xapp058.pdf

Zal ff kijken of ik de source code nog kan vinden...

... got it: ftp://ftp.xilinx.com/pub/swhelp/cpld/eisp_pc.zip

Je moet een aantal functies zelf schrijven, zoals hoe de jtag pinnen hoog en laag gemaakt moeten worden (dat verschilt per platform uiteraard) en ook pauzes ed. Verder laad je een XSVF in en de code voert alle jtag instructies automatisch uit. Erg makkelijk in gebruik.

[Bericht gewijzigd door KillerB the Supreme op ]

Op 6 februari 2007 00:14:46 schreef KillerB the Supreme:
SVF is een leuk formaat, je hebt echter ook XSVF, das hetzelfde, maar dan in binair formaat (stuk compacter maar niet meer leesbaar). Ik gebruik dat ook, je kunt daarmee direct vanuit een microcontroller een FPGA programmeren. Eigenlijk kun je alles programmeren wat een jtag interface heeft. Ik doe ook het platform flash voor de fpga ermee.

XSVF is een extensie van Xilinx zeker? Quartus kan het niet genereren iig.

Je moet een aantal functies zelf schrijven, zoals hoe de jtag pinnen hoog en laag gemaakt moeten worden (dat verschilt per platform uiteraard) en ook pauzes ed. Verder laad je een XSVF in en de code voert alle jtag instructies automatisch uit. Erg makkelijk in gebruik.

Zoiets heeft Altera ook maar dan dus voor JAM/STAPL. Probleem met kant en klare code waar je alleen I/O functies hoeft te maken is dat het lastig optimaliseert over USB. Daar moet je bits echt gaan groeperen in packets en niet een USB pakket per bit gaan sturen. Voor een embedded processor is het allemaal prima.

De code die Quartus genereert is heel eenvoudig, het is grotendeels overal hetzelfde. Dus dat moet goed te parsen zijn.

Het kan best wel eens van xilinx zijn. Maar dat hoeft geen beperking te zijn, volgens mij kun je eenvoudig svf omzetten naar xsvf.

Via usb is het inderdaad erg lastig, dan moet je zelf buffering gaan toevoegen, maar dan klopt je timing niet meer. Pak dan nog liever de parallelle poort, deze zal dan een stuk sneller zijn. Of dump de xsvf (of svf, maar das iets groter dus) over usb naar een kleine microcontroller met geheugen, die voert vervolgens de instructies uit.

Voor de mensen die met xilinx werken: een xsvf creer je met Impact (de gratis programmer tool van xilinx). In plaats van een programmer selecteer je file output xsvf formaat en hoppa, alle jtag instructies worden hierna naar de xsvf geschreven. Je kunt bijvoorbeeld ook een XSVF maken die alleen checkt of alle devices aanwezig zijn (id-code check). Zorg wel dat je in Impact de juiste jtag chain hebt gekozen (dat houd in dat je alle bsdl files hebt gekoppeld van al je jtag devices)

als je de parallel poort gebruikt krijg je d eprogramming software cadeau van altera, dan zijn al die tussenstappen niet nodig.

op usb in bitbang mode kan je met een 245 read en write simultaan doen ( vida de fifos in de ftdi chip. der is een appnote voor.
ik dat blok je logica voorzien ( een een 74139 .. )
kzal er beide op zetten.
als ik dan 5 minuten heb schrijf ik wel ene progje wat sfv kan parsen en uitvoeren via de 245.

kheb hier ondertusen documentatie gevonden van sfv ( ze gebruiken dat op teradyne testers ook om via jtag poort chips te testen. )
dus der zitten hier gurus genoeg die dat spul kennen.

de timing speelt geen rol. je mag niet sneller dan xxx. maar trager mag altijd op jtag. je mag zelfs met horten en stoten , maakt niks uit.

[Bericht gewijzigd door free_electron op ]

Dank je F-E, heb begrip voor je werk :)

Op 6 februari 2007 02:34:59 schreef free_electron:
op usb in bitbang mode kan je met een 245 read en write simultaan doen ( vida de fifos in de ftdi chip. der is een appnote voor.

Inderdaad dat gebruik ik ook. Alleen weet ik niet hoe het met de buffering zit. De appnote zegt eerst (over Synchronous bitbang):

With Synchronous Bit Bang mode, data will only be sent out if there is space in the device for data to be read from the pins.

Maar verderop:

FT_Read will return a buffer of values which have been sampled from the pins at the rate set by FT_SetBaudRate. If the read buffers have filled, data willl be lost.

Dus wat is het nou?

Ook weet ik niet of je kunt switchen tussen async en sync zonder data te verliezen. Voor een deel van het programmeren zou je namelijk alleen data hoeven verzenden, bij synchronous zou je volgens mij dan alle data ook moeten uitlezen om de sync niet kwijt te raken / om de boel te laten verzenden (onduidelijk dus vanwege bovenstaande stukjes).

Op 5 februari 2007 19:03:10 schreef free_electron:
nog efkes geduld. als alles goed gaat post ik vanavond mij experimenteerbord ontwerpje.

16 druktoetsen in matrix
8 displays ( 7 segment ) in multiplex
16 leds
een rotary encoder
en een lcd display ( 2x16 ) ( ofwel installeer je de lcd ofwel de led displays...

Kun je eventueel het schema eens door mailen wat je tot nutoe hebt. Een pdf file-tje of zo. Soms kunnen kleine details de zaak nog aanvullen. Ik denk aan een TSOP1738 te gebruiken als IR dekoder. Dan kun je dit gebruiken om nog meer waarden of commands in te geven ipv of naast het kleine klaviertje. De TSOP neemt maar 1 I/O in beslag en met 3 gaatjes op de print kun je hem bestukken! (is wel 5V, dus 3.3V ingang aanpassen) wordt hij niet bestukt dan blijft de I/O toch vrij voor iets anders.

Ook zo voor je multiplexing, ik weet niet of je een hardware lijntje voorzien hebt om dit te kunnen disabelen. Vooral moest er bij de powerup ergens wat mis lopen kun je soms grote stromen door de segmenten treken als de scanning niet zou werken.

Ik heb ook wel protel 99, dus een zip file is ook goed....Ik heb mijn email actief geplaatst bij mijn gegevens.

Op 6 februari 2007 02:34:59 schreef free_electron:
de timing speelt geen rol. je mag niet sneller dan xxx. maar trager mag altijd op jtag. je mag zelfs met horten en stoten , maakt niks uit.

Klopt, horten en stoten is toegestaan, maar voor bepaalde acties is het noodzakelijk te voldoen aan minimum pauzetijden. Flash programeren bijvoorbeeld. Je dumpt via de jtag bus een aantal bytes naar het flash memory, en vervolgens moet je het flash een pauze gunnen, zodat deze de data intern kan programmeren. Zelfde voor erase commando's. Fpga's zijn wat dat betreft makkelijker.

Op 6 februari 2007 08:35:46 schreef madwizard:
[...]
Inderdaad dat gebruik ik ook. Alleen weet ik niet hoe het met de buffering zit. De appnote zegt eerst (over Synchronous bitbang):
[...]
Maar verderop:
[...]
Dus wat is het nou?

Ook weet ik niet of je kunt switchen tussen async en sync zonder data te verliezen. Voor een deel van het programmeren zou je namelijk alleen data hoeven verzenden, bij synchronous zou je volgens mij dan alle data ook moeten uitlezen om de sync niet kwijt te raken / om de boel te laten verzenden (onduidelijk dus vanwege bovenstaande stukjes).

zolang je niet over de fifo size gaat is er gene probleem.
de tx fifo is 128 byte diep , de rx 512 byte bij ene ftdi chip

dus als je de transport blokken beperkt tot maximum 128 bytes per keer krijg je geen verlies.

Op 6 februari 2007 09:36:43 schreef KillerB the Supreme:
[...]

Klopt, horten en stoten is toegestaan, maar voor bepaalde acties is het noodzakelijk te voldoen aan minimum pauzetijden. Flash programeren bijvoorbeeld. Je dumpt via de jtag bus een aantal bytes naar het flash memory, en vervolgens moet je het flash een pauze gunnen, zodat deze de data intern kan programmeren. Zelfde voor erase commando's. Fpga's zijn wat dat betreft makkelijker.

minimum tijden zijn geen probleem. de miserie zou 'maximum tijden ' geweest zijn.

Op 6 februari 2007 09:35:17 schreef fotoopa:
[...]Kun je eventueel het schema eens door mailen wat je tot nutoe hebt. Een pdf file-tje of zo. Soms kunnen kleine details de zaak nog aanvullen. Ik denk aan een TSOP1738 te gebruiken als IR dekoder. Dan kun je dit gebruiken om nog meer waarden of commands in te geven ipv of naast het kleine klaviertje. De TSOP neemt maar 1 I/O in beslag en met 3 gaatjes op de print kun je hem bestukken! (is wel 5V, dus 3.3V ingang aanpassen) wordt hij niet bestukt dan blijft de I/O toch vrij voor iets anders.

Ook zo voor je multiplexing, ik weet niet of je een hardware lijntje voorzien hebt om dit te kunnen disabelen. Vooral moest er bij de powerup ergens wat mis lopen kun je soms grote stromen door de segmenten treken als de scanning niet zou werken.

Ik heb ook wel protel 99, dus een zip file is ook goed....Ik heb mijn email actief geplaatst bij mijn gegevens.

die maxII zetten hun uitgangen 3state tijdens powerup. en als ze niet gevonfigd zijn.
de multiplexing is zo gedaan dat er niks kan mislopen. ( boven Pmossen , onder Nmossen

kzal schema straks eens posten

gedeelte voor de usb poort is nog nie af.

geef eens typenummers van ene tsop. ik weet dat er 2 pinouts zijn. dan voorzie ik beide.
en der moeten toch 3.3 volt tsops zijn ook ?

ik heb niks meer over van de ios op het baseboard. dus nog iets toevoegen wordt moeilijk ( ik houd de bovenste connector vrij om daar zelf nog peripherie aant e kunnen sluiten.
enfin twordt duidelijk als je de pcb layout ziet en tschema.

Op 6 februari 2007 17:08:21 schreef free_electron:
[...]
geef eens typenummers van ene tsop. ik weet dat er 2 pinouts zijn. dan voorzie ik beide.
en der moeten toch 3.3 volt tsops zijn ook ?

De meest gebruikt is de TSOP1738 . Intern staat een 80K naar de 5V en de uitgang is een NPN tor. Ik heb gewoon een zenertje van 3V0 op de uitgang gezet daardoor is de high-level 3V max en een extra pullup van 4K7 naar de 3V3. Die interne pullup speeld dan geen rol meer.

Ik heb hem zopas op mijn DE1 board gezet. Als je geen pin meer over hebt kan er wel iets dubbel die dan in de bestukking kan weggelaten worden. Of anders een kleine jumper. Op een TV bediening zitten heel veel knoppen, je hebt dus heel veel entry's, meer dan een 4x4 keypad. En het is draadloos !

die maxII zetten hun uitgangen 3state tijdens powerup. en als ze niet gevonfigd zijn.
de multiplexing is zo gedaan dat er niks kan mislopen. ( boven Pmossen , onder Nmossen

prima, is veilig zo!

[Bericht gewijzigd door fotoopa op ]

Is het niet beter om de TSOP1736 (36KHz) te gebruiken?
De meeste afstandsbedieningen (Philips, RC5)
werken toch met 36 KHz?

Op 6 februari 2007 18:26:24 schreef peterrr:
Is het niet beter om de TSOP1736 (36KHz) te gebruiken?
De meeste afstandsbedieningen (Philips, RC5)
werken toch met 36 KHz?

Ja maar ze hebben hem bijna niet in voorraad! Het kleine verschil in carrier frequentie merk je nauwelijks, de pinout en de werking is hetzelfde. Waarschijndelijk is dit de reden waarom ze bijna altijd de 38 KHz in stock houden. Er zijn ook een aantal bedieningen die op 40KHz draaien en die werken even goed. Mits je het protocol aanpast natuurlijk.

Dus ja al je de keuze hebt, 36KHz is de correcte, voor layout en aansluiting maakt het geen verschil.

ok. ik zet dat erop.

enige probleem is dat er geen 5 volt voorhanden is op mijn bord... alles is 3.3 volt. ( das maximum spanning voor die maxII .... alsook voor cyclones )

rats.
bon , dan takken we af uit de voedingsstekker. ( daar komt 5 volt binnen )

ik laat de uitgang van die tsop wel een gate van een mos sturen.. de drain knoop ik dan aan ene io pin. ik ben niet zo zot van zenerdioden. die dingen reageren te traag ...

Op 6 februari 2007 16:45:59 schreef free_electron:
zolang je niet over de fifo size gaat is er gene probleem.
de tx fifo is 128 byte diep , de rx 512 byte bij ene ftdi chip

Dacht 128/256 maar misschien is dat alleen bij de FT232R. Toch vreemd dat ze in de documentatie zetten dat er alleen een byte verzonden wordt als er ook ruimte voor is deze te ontvangen.. Volgens mij gedraagt het ding zich niet zo.

edit: Vreemd genoeg gaat tot en met 65 bytes (!) versturen goed, dan krijg ik exact dezelfde data een cycle later terug. Vanaf 66 bytes gaat het mis.

Op 6 februari 2007 17:08:21 schreef free_electron:
die maxII zetten hun uitgangen 3state tijdens powerup. en als ze niet gevonfigd zijn.

En als je de instellingen niet veranderd staan alle ongebruike pinnen na power-up laag te trekken. Kan waarschijnlijk geen kwaad maar heb dat altijd wat raar gevonden.

Op 6 februari 2007 18:59:30 schreef free_electron:
ok. ik zet dat erop.ik laat de uitgang van die tsop wel een gate van een mos sturen.. de drain knoop ik dan aan ene io pin. ik ben niet zo zot van zenerdioden. die dingen reageren te traag ...

Oké, dat is nog beter natuurlijk!

En die 5V, kan nog gunstig zijn voor iets anders ook! Als daar een gaatje is in de print kan er nog afgetakt worden....

Op 6 februari 2007 17:08:21 schreef free_electron:
[...]die maxII zetten hun uitgangen 3state tijdens powerup. en als ze niet geconfigd zijn.
de multiplexing is zo gedaan dat er niks kan mislopen. ( boven Pmossen , onder Nmossen

Ik plaatste altijd nog een pullup of puldown weerstandje op die kritische signalen dan is hun tristate level altijd duidelijk bepaald.

Mijn rede om het nog niet te doen is:

Het lukt me niet om de juiste licentie te krijgen, wie weet hoe ik dat moet aanpakken?
ik krijg er gewoon een via de mail van altera, zet hem op de juiste plaats enzo wijs hem aan met die licentie setup.

dan wil ik een project compileren en dan gaat het fout de volgende meldingen krijg ik:

Info: *******************************************************************
Info: Running Quartus II Analysis & Synthesis
Info: Version 6.1 Build 201 11/27/2006 SJ Web Edition
Info: Processing started: Tue Feb 06 19:49:59 2007
Info: Command: quartus_map --read_settings_files=on --write_settings_files=off ledblink -c ledblink
Info: Found 1 design units, including 1 entities, in source file ledblink.v
Info: Found entity 1: ledblink
Info: Elaborating entity "ledblink" for the top level hierarchy
Warning (10230): Verilog HDL assignment warning at ledblink.v(6): truncated value with size 32 to match size of target (24)
Info: 1 registers lost all their fanouts during netlist optimizations. The first 1 are displayed below.
Info: Register "cnt[23]" lost all its fanouts during netlist optimizations.
Info: Implemented 26 device resources after synthesis - the final resource count might be different
Info: Implemented 1 input pins
Info: Implemented 1 output pins
Info: Implemented 24 logic cells
Info: Quartus II Analysis & Synthesis was successful. 0 errors, 1 warning
Info: Allocated 120 megabytes of memory during processing
Info: Processing ended: Tue Feb 06 19:50:01 2007
Info: Elapsed time: 00:00:02
Info: *******************************************************************
Info: Running Quartus II Fitter
Info: Version 6.1 Build 201 11/27/2006 SJ Web Edition
Info: Processing started: Tue Feb 06 19:50:03 2007
Info: Command: quartus_fit --read_settings_files=off --write_settings_files=off ledblink -c ledblink
Warning: FLEXlm software error: System clock has been set back Feature: quartus_lite License path: C:\quartus2we\0014A438D170__0-0403529773654197.dat FLEXlm error: -88,309 For further information, refer to the FLEXlm End User Manual, available at "www.macrovision.com".
Error: Current license file does not support the EPM240F100C4 device
Error: Quartus II Fitter was unsuccessful. 1 error, 1 warning
Info: Allocated 120 megabytes of memory during processing
Error: Processing ended: Tue Feb 06 19:50:04 2007
Error: Elapsed time: 00:00:01
Error: Quartus II Full Compilation was unsuccessful. 1 error, 2 warnings

wie weet wat ik hier aan kan doen? ik zou hem heel graag helemaal goed werkend hebben zodat ik ook aan de hardware kan gaan denken.

Op 6 februari 2007 19:29:44 schreef madwizard:
[...]
Dacht 128/256 maar misschien is dat alleen bij de FT232R. Toch vreemd dat ze in de documentatie zetten dat er alleen een byte verzonden wordt als er ook ruimte voor is deze te ontvangen.. Volgens mij gedraagt het ding zich niet zo.

edit: Vreemd genoeg gaat tot en met 65 bytes (!) versturen goed, dan krijg ik exact dezelfde data een cycle later terug. Vanaf 66 bytes gaat het mis.

[...]
En als je de instellingen niet veranderd staan alle ongebruike pinnen na power-up laag te trekken. Kan waarschijnlijk geen kwaad maar heb dat altijd wat raar gevonden.

dat zou erop kunnen zijzen dat ze bij die bitbang mode gelimiteerd zijn tot 1 usb frame ....

ze halen de io state op voor ze ene output doen
dus als jij 64 byte schrijft hebben zij er al 65 gelezen.
een usb frame is 64 bytes. bij 65 heb je twee frames aan je borek. en hun endpoint kan daar niet mee overweg denk it ...

Op 6 februari 2007 19:59:10 schreef elektroverslaafde:
Warning: FLEXlm software error: System clock has been set back Feature: quartus_lite License path: C:\quartus2we\0014A438D170__0-0403529773654197.dat FLEXlm error: -88,309 For further information, refer to the FLEXlm End User Manual, available at "www.macrovision.com".
Error: Current license file does not support the EPM240F100C4 device

Blijkbaar heb je uw PC clock terug gedraaid! Je licence zal hierdoor niet meer werken!

Wat je hier vooraf allemaal gedaan heb weet ik niet maar dit kan zo niet werken.

- clock mag nooit teruggedraaid worden eens je een licentie bekomen hebt.

update had niet alles goed gelezen....

Je clock is blijkbaar toch een probleem...

[Bericht gewijzigd door fotoopa op ]

Op 6 februari 2007 19:59:10 schreef elektroverslaafde:
Mijn rede om het nog niet te doen is:

Warning: FLEXlm software error: System clock has been set

wie weet wat ik hier aan kan doen? ik zou hem heel graag helemaal goed werkend hebben zodat ik ook aan de hardware kan gaan denken.

uw computer clock goed zetten en er dan vanaf blijven !
of je licentie is vervallen.
vraag ene licentie aan met dezelfde computer waar je quartus op draait !

Bedankt voor de reacties,

De tijd stond goed, maar heb hem toch maar gesynchoniseerd.
De licentie is van vorige week, dus vervallen kan hij nog niet zijn.

verder heb ik nog iets gezien:
Bij "software guard id:" staat "Not found"
(in het license setup menu)

das normaal.
je gebruikt een web liventie.
die software guard id werkt alleen als je de hardware sleutel hebt. ( softguard module die je op de printerpooort stopt. maar das alleen voor ene betalende ongelimiteerde licentie ... )

vul de vraagtekens eens in :

licence type : ???? ( zou moeten web edition zijn )
expiration : ???? ( ergens in de toekomst normaal )
host id type : ???? ( ethernet normaal )
en host id value : ???? ( je mac address normaal)

der is iets niet goed met je licence file... juiste mac address doorgegeven ?

Op 6 februari 2007 20:17:55 schreef free_electron:
dat zou erop kunnen zijzen dat ze bij die bitbang mode gelimiteerd zijn tot 1 usb frame ....

ze halen de io state op voor ze ene output doen
dus als jij 64 byte schrijft hebben zij er al 65 gelezen.
een usb frame is 64 bytes. bij 65 heb je twee frames aan je borek. en hun endpoint kan daar niet mee overweg denk it ...

65 bytes werkte ook nog :) Maar ik weet al wat het probleem was. Ik had een pull down van 10k op een van de pinnen staan (hergebruik even een printje), maar de FT stond niet in high current I/O mode waardoor het geen kracht genoeg had 1 van de bits hoog te trekken. Dit was bit 6, en ik testte met oplopende getallen van 0 t/m het 64. Deze worden geschreven, weer uitgelezen en vergeleken. Bij 64 wordt bit 6 pas aan gezet, en omdat de read cycle 1 cycle achterloopt gaat dit dus pas bij 66 bytes fout omdat je dan de byte waarde '64' ook uitleest :P lekker suf probleem zeg.

Dit was dus al de hele tijd zo, misschien dat ik dus compleet fout zat met die hele buffering. Net 900 bytes geschreven en daarnaa weer gelezen (1 write, 1 read), en ook dat gaat goed lijkt. Snelheid schoot omhoog van 57kb/s naar 227kb/s.

In de documentatie wordt trouwens gesproken over een standaard USB packet grootte van 4KB, in te stellen t/m 64KB. Heeft de FT232 dit dan ook aan boord? Het lijkt dat die alleen 128/256 bytes buffer heeft maar wat heb je dan aan zulke USB packet groottes?

Wordt dat tijdens het packet verwerken uitgeklokt ofzo? Wat met 64 bytes packets elke 1ms (minimale latency) ga je echt geen 3Mbit serieel halen. Dus moeten er wel grotere USB packets gestuurd worden. Maar hoe kan zo'n FT232 dat dan verwerken met alleen een 128/256 byte buffer?

edit:
Test met random getallen, buffer 3968 bytes (optimaal volgens FTDI), 2000x FT_Write, FT_Read en valideren in synchronous bitbang met clock iets onder 10Mhz:

17842 msecs for 7936000 bytes. Is 444793 bytes/sec

Hoezo bitbangen traag :)