Op 5 februari 2007 14:35:42 schreef xantus:
Als ik het goed begrijp wordt dus aangeraden of de MAX II EPM1270 of EPM570 te nemen of een Coolrunner II XC2C384 of XC2C512.
Je moet natuurlijk zelf kiezen, maar persoonlijk vind ik vooral de software van Altera duidelijker. Ook weet ik niet hoe die macrocells van Coolrunner zich verhouden met MAX II's logic elements dus wat vergelijkbaar is kan ik niet zeggen. Max II is wel zuiniger dacht ik.
Houdt er met de MAX-II trouwens rekening mee dat er twee versies van zijn (naast de packages). De ene heeft alleen T in z'n typenummer (voor TQFP), de andere GT. Die met een G heeft een aparate 1.8V voeding nodig voor de core, naast de I/O voeding (meestal 3.3V maar kan lager zijn). De T versie heeft alleen 3.3V nodig en heeft een interne regelaar voor de 1.8V. Een losse 1.8V spanning kan nuttig zijn voor minimaal stroomverbruik en lage warmte productie maar dat zal je in de praktijk nauwelijks nodig hebben. De T versie is dan handiger.
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).
Waar ze zo te koop zijn weet ik niet, zelf etsen gaat altijd wel goed bij mij. Met 10mil baantjes/clearance ben je er al in principe.
Wel is als je het direct op het printje soldeert dubbelzijdig meestal wel handig, omdat je 8 voedingsparen hebt (6 voor I/O en 2 voor de core en bij grotere nog meer) tussen de I/O pinnen in. Zo kom je er nog lastig tussen met je I/O pinnen op 1 laag. Kan ook wel met draadbruggen eigenlijk maar goed.
Op 5 februari 2007 14:50:49 schreef madwizard:
[...]
Je moet natuurlijk zelf kiezen, maar persoonlijk vind ik vooral de software van Altera duidelijker. Ook weet ik niet hoe die macrocells van Coolrunner zich verhouden met MAX II's logic elements dus wat vergelijkbaar is kan ik niet zeggen. Max II is wel zuiniger dacht ik.
De max II is idd ongeveer 10x zuiniger (volgens de reclame van altera). 1 macrocell is ongeveer 1,3 LE
Houdt er met de MAX-II trouwens rekening mee dat er twee versies van zijn (naast de packages). De ene heeft alleen T in z'n typenummer (voor TQFP), de andere GT. Die met een G heeft een aparate 1.8V voeding nodig voor de core, naast de I/O voeding (meestal 3.3V maar kan lager zijn). De T versie heeft alleen 3.3V nodig en heeft een interne regelaar voor de 1.8V. Een losse 1.8V spanning kan nuttig zijn voor minimaal stroomverbruik en lage warmte productie maar dat zal je in de praktijk nauwelijks nodig hebben. De T versie is dan handiger.
Dit had ik idd ook al gevonden.
Maar ik was even mijn mMIPS core (hele kleine uP met 32 instructies instructie set, 32 byte RAM, 4 stage pipeline en 1x 8 bits interrupt timer) En volgens de xilinx FPGA Compiler II heeft deze 3 latches en 513 filpflops (=513 macrocells?) En een spoorbaan automatisering zou 150 macrocells zijn (zit nu in een spartan II en gebruikt 2% van de 200k usable gates)
Vanwege de quartus tool mag je verwachten dat hiet op CO meer Altera gebruikers zullen zijn. Xilinx en Altera chips liggen heel dicht bij elkaar, daar zal het verschil niet zo groot zijn. Werk je in verilop of vhdl dan maakt het ook niets uit want je kunt alle projecten op beiden fabrikanten wel draaien. Dit is dan weer het grote voordeel van die hardware ontwerpen. Volledig uitwisselbaar en dezelfde taal!
Voor je chips zijn er 2 zaken:
- je ontwikkelings basis
- je toepassingen.
Als je geen echt lowbuget hoeft aan te houden is een ruimere ontwikkelings basis altijd goed meegenomen. Geen enkele beperking, geen voedings problemen, netjes enz. Ik heb het gedaan via de DE1 kit Dit heeft mij €189 gekost, 2 dagen leveringstermijn vanuit Taiwan. Veel geld zou je denken tot je daadwerkelijk ziet wat je er allemaal hiervoor ontvangt. Hier in .nl of .be stellen is nog goedkoper ( €163) als je wat langere leveringstermijn aanvaard.
Voor je toepassingen kun je ook kleine boardje bestukt aankopen zoals deze pluto3 kost relatief weinig en is heel geschikt om in te bouwen.
Moet het nog goedkoper dan vermoed ik dat er binnen kort wel hier of daar op CO een gebruiker zal zijn die de opplugprintjes met een MAXII beschikbaar zal stellen aan een heel lage prijs.
Wil je nog meer lowcost en zonder moeilijke soldeering hebben dan is er nog de mogelijkheid om de EPM7064SLC44 in een PLCC44 socket te plaatsen op gaatjesprint of kleine pcb en daarmee een opstelling te maken. 64 LE's is natuurlijk wel beperkt maar enkele 7 segment display's, leds, PWM's enz zijn perfect realiseerbaar als begin waarde.
CycloneII devices zijn al voor grotere projecten en moeten zeker een prom naast zich hebben. Ik gebruik de cyclone versie's EP1C3 en EPM1C6 voor mijn applicatie's. Deze beide versie's zijn maar 18 - 20 % volzet.
..... zie zie juist je antwoord passeren....
Als je met spoorbaan automatisering bezig bent zou ik iets nemen die bij de start niet te klein is. Dergelijke automatiseringen kunnen al heel snel groeien en worden vaak sterk uitgebereid. Net zoals mijn applicatie zou ik kiezen voor vrij veel standaard gebufferde in en uitgangen infunctie van je basis behoeften. Later kunt je eindeloos wijzigingen doen aan je spoorbaan zonder nog zware ingrepen te moeten doen op de sturing. Zoiets is echt ideaal voor CPLD/FPGA toepassingen!
Spoorbaan regeling was een school project. Dus ik denk niet dat Xantus deze "misere" thuis nog een keer wil doen 
.
Dat was idd een grote ramp. 2 maanden werken (4 dagen per week 8 uur per dag) om een treintje zo ver te krijgen 4 in willekeurige volgorde staande wagonnen in correcte volgorde te zetten (en dat zo snel mogelijk).
Des al niet te min kan ik die verilog files mooi in quartus compilen en zien hoe vol de MAX II komt, op die manier kan ik een beetje in schatten welke MAX II ik zou moeten kiezen.
Als je met spoorbaan automatisering bezig bent zou ik iets nemen die bij de start niet te klein is. Dergelijke automatiseringen kunnen al heel snel groeien en worden vaak sterk uitgebereid. Net zoals mijn applicatie zou ik kiezen voor vrij veel standaard gebufferde in en uitgangen infunctie van je basis behoeften. Later kunt je eindeloos wijzigingen doen aan je spoorbaan zonder nog
zware ingrepen te moeten doen op de sturing. Zoiets is echt ideaal voor CPLD/FPGA toepassingen!
Ik zat zelf meer in de richting te denken van
1) Dot matrix led klok (gewoon om er in te komen een dot matrix van 8x32 aansturen)
2) avionix (autonome vliegen van een model helicopter)
Wil je nog meer lowcost en zonder moeilijke soldeering hebben dan is er nog de mogelijkheid om de EPM7064SLC44 in een PLCC44 socket te plaatsen op gaatjesprint of kleine pcb en daarmee een opstelling te maken. 64 LE's is natuurlijk wel beperkt maar enkele 7 segment display's, leds, PWM's enz zijn perfect realiseerbaar als begin waarde.
Zit ik idd ook naar te kijken (of een XC9572, XC95108 met 104 en 140 LE's). Deze kleine(re) zijn makkelijker te etsen in zo'n socket. En zo'n kleintje in een QFN package druf ik ook nog wel aan op de etsen / solderen, gaat ie kapot dan is het hek niet van de dam met 5 euro voor z'on CPLD. Met 25~40 euro voor een EPM1270 is dat wel een stuk erger...
[Bericht gewijzigd door xantus op ]
ik ben wel geinstresseerd geraakt in FPGA tot nu toe alleen nog maar PIC's gedaan maar zoals voor velen is het denk ik wat lastig om de 1e stap te zetten en neit te struikelen over de drempel 
.
ik vroeg me af:
als ik die pluto3 (kost idd heel weinig)
en dan zoals surge_me zei:
Nieuwsgierig?
hier kun je het downloaden (even aan melden, het is gratis)
https://www.altera.com/support/software/download/altera_desi...tus_we.…
Kies voor Quartus® II Web Edition Software v6.1 dit is een download van 458MB.
deze download en installeer, kan ik dan met zo een TXDI bordje er bij en een (eigen) rs232 kabel al een FPGA programmeren of vergis ik me nu?
FPGA's lijken me erg leuk maar ben wat onzeker met starten, darom graag wat zekerheid. Dit niet zelf uitvinden is misschien een beetje lui maar wel erg makkelijk
Willem
Op 5 februari 2007 15:58:48 schreef willem.
.... kan ik dan met zo een TXDI bordje er bij en een (eigen) rs232 kabel al een FPGA programmeren of vergis ik me nu?
Ja dat zou moeten gaan. Tot heden gebruik ik hier altijd de byteblasterMV of een gewone zelfgemaakte byteblaster. Maar nu op mijn DE1 board kan het via USB2.
Als je Quartus eerst installeerd kun je alles al compileren en simuleren en zien welke device je nodig hebt of hoeveel LE's gebruikt worden. Je kunt vooraf je ontwerp uittesten zonder iets aan te kopen of te maken. Dit kost gewoon niets!
free_electron
Silicon Member
Professioneel ElectronenTemmer - siliconvalleygarage.com - De voltooid verleden tijd van 'halfgeleider' is 'zand' ... US 8,032,693 / US 7,714,746 / US 7,355,303 / US 7,098,557 / US 6,762,632 / EP 1804159 - Real programmers write Hex into ROM
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.
eurokaartje wat op 2/3 breekt.
1/3 is de cpld ( tqfp144) je kan er epm570 of epm1270 op solderen .
de core regelaar zit op het cpld printje dus van die grap ben je vanaf.
1 van de clock signalen gaat naar ene kristaloscillator op het cpld printje. zo heb je meteen een mooie klok ( 50MHz)
ALLE io pinnen komen op idc headers naar buiten ( standaar 100 mil pitch ( 2.54 millimeter steek )
als je er iemand die borden laat maken bij eurocircuits( inkoopactie of zoiets doen ) dan kost het haast niks.
op de resterende 2/3 ( het base board ) zit allerhande experimenteerspul : druktoetsen , displays, leds, een programmer (parallele poort) en nog meer spul ( waaronder ook een ftdi245 ... ik ben nog aant spelen met het idee om de download ook te kunnen doen via die usb , ik dacht dat het hier al iemand gedaan had.. weet niet meer wie . madwizard misschien ? der zou een stukje software moeten zijn wat de pof file rechtstreeks kan pakken en in de fpga pletsen. ( omwegen via stapl files is veel te veel werk , das weer allemaal extra klikwerk om die file aan te maken ). de pof file wordt automatisch gemaakt tijdens compilatie.
of als er zich iemand geroepn voelt om een script te maken in quartus zelf wat al dat werk doet .. ( stapl aanmaken en programmer oproepen )
de bedoeling is om later nog een dochterkaartje te maken ( zelfde grootte als het cpld kaartje ) maar daar met een cyclone op (1c3) en een config prom.
het klein grut wat erop zit zal rond de 10 euro zijn ( druktoetsen , displays encoders . die led displays kosten 2 $ voor 4 .... )
de cpld is het duurste. 24 $
maar als er iemand de inkoopactie doet en de cpld gelijk kan solderen voor de mensen die daar bang van zijn dan loopt dat als een trein.
tzou moeten lukken voor 50 euro ...
Op 5 februari 2007 19:03:10 schreef free_electron:
ik ben nog aant spelen met het idee om de download ook te kunnen doen via die usb , ik dacht dat het hier al iemand gedaan had.. weet niet meer wie . madwizard misschien ? der zou een stukje software moeten zijn wat de pof file rechtstreeks kan pakken en in de fpga pletsen. ( omwegen via stapl files is veel te veel werk , das weer allemaal extra klikwerk om die file aan te maken ). de pof file wordt automatisch gemaakt tijdens compilatie.
of als er zich iemand geroepn voelt om een script te maken in quartus zelf wat al dat werk doet .. ( stapl aanmaken en programmer oproepen )
Ik had dat idd met STAPL gedaan en dan bitbangen via een FT232. Pof file is makkelijker maar wat voor formaat is dat en hoe krijg je dat in de CPLD? Een FPGA heeft config pinnen waar je de boel gewoon serieel in kan klokken, maar een CPLD heeft alleen JTAG. Ik weet niet of de interface voor de pof files programmeren via JTAG ergens gedefinieerd staat?
JAM/STAPL was het makkelijkst omdat Altera hier kant en klare player source voor heeft. Het enige wat aangepast moest worden is de I/O interface van parallel naar (synchronous) USB-bitbang. Vervelende is dat JAM/STAPL ongeveer om de 60 bits oid. data terug wil hebben van de CPLD waardoor een snelle datastroom door de USB latencies lastig is. Een FT232RL heeft een 128 byte buffer die hij synchroon kan uitklokken en inlezen op een paar MHz snelheid. Helaas moet je de data ook steeds uitlezen om de buffers niet over te laten lopen.
Ik wil die IA wel graag doen. Vind ik wel leuk om te doen, en heb het al eens eerder gedaan.
Hoe het protocol verloopt om via de jtag een .pof file door te sturen moet ik hier nog ergens staan hebben. Dat hebben we vroeger altijd gedaan om via de PC de 10KE50 devices te programmeren. De PC software werd door onze groep software mensen geschreven maar ik heb hun destijds dat protocol gegeven en moeilijk was het zeker niet. Trouwens...... dat staat ook beschreven in de jtag van Altera zelf, je hebt gewoon een klok lijntje en een data lijntje, een start seq en een stop seq....
Ik zoek dat word doc even op, ik had daar een verslag van gemaakt.
free_electron
Silicon Member
Professioneel ElectronenTemmer - siliconvalleygarage.com - De voltooid verleden tijd van 'halfgeleider' is 'zand' ... US 8,032,693 / US 7,714,746 / US 7,355,303 / US 7,098,557 / US 6,762,632 / EP 1804159 - Real programmers write Hex into ROM
Op 5 februari 2007 19:09:52 schreef madwizard:
[...]
Ik had dat idd met STAPL gedaan en dan bitbangen via een FT232.JAM/STAPL was het makkelijkst omdat Altera hier kant en klare player source voor heeft. Het enige wat aangepast moest worden is de I/O interface van parallel naar (synchronous) USB-bitbang. Vervelende is dat JAM/STAPL ongeveer om de 60 bits oid. data terug wil hebben van de CPLD waardoor een snelle datastroom door de USB latencies lastig is.
aha je gebruikt een RL ... dat bekent dat je dus ook eigenlijk ene 245 RL zou kunnen gebruiken ( das dezelfde driver voor bitbang ...
POF file is gewoon de bitsream die in de rom moet (daar staat niks extra in)
stapl is dan nog geen probleem. je kan in quartus scriptekes maken. dus ergens op de menu ene button toevoegen die een scripteke start wat de stapl aanmaakt. , programmer code oproept en flasht.
ik ben voorstander van een 245 omdat het geen uart vereist aan de andere kant. je hangt dat aan wat io pinnen en je kan vooruit ...
ik zou dan een schakelaarjte voorzien wat de 4 pinnekes omswitcht van io's naar de jtag poort.
zo kan je schakelen tussne 'program mode' en user mode
Op 5 februari 2007 19:34:00 schreef fotoopa:
Hoe het protocol verloopt om via de jtag een .pof file door te sturen moet ik hier nog ergens staan hebben. Dat hebben we vroeger altijd gedaan om via de PC de 10KE50 devices te programmeren. De PC software werd door onze groep software mensen geschreven maar ik heb hun destijds dat protocol gegeven en moeilijk was het zeker niet. Trouwens...... dat staat ook beschreven in de jtag van Altera zelf, je hebt gewoon een klok lijntje en een data lijntje, een start seq en een stop seq....
Weet je zeker dat dat JTAG was? Want klok+data lijntje klinkt meer als een andere interface zoals FPGA's hebben. Al heeft JTAG natuurlijk TCK en TDI maar ook TDO en TMS. Helaas ben ik niet zo bekend met JTAG maar als het mogelijk is via JTAG eenvoudig die pof file erin te gooien kan de snelheid nog wat geoptimaliseerd worden.
Maar als je informatie hebt, graag. Je kunt het ook eventueel mailen, adres staat in m'n profiel.
@free_electron:
245 kan ook inderdaad, dat is hetzelfde principe. Ik ga even kijken in de JTAG docs.
Ja het was via de JTAG pinnen. Het was een PCI kaart met een 9030 PCI controller. Daar waren enkele pinnen die je als gewone I/O kon gebruiken. Die waren verbonden met:
nCONFIG
TCK
TDI
config_done
nStatus
Het file type was een .rbf file maar die kon je direct aanmaken met een van de Quartus tools functie's. Je kon tot 10 Mbit speed gaan, dus enkele seconden waren nodig om een 20KE400 op te laden. Omdat we er 2 gebruikten hadden we die data lijnen ontdubbeld en met dezelfde clock gingen we beide chips gaan laden. Daarvoor was dus maar 1x de tijd nodig. Dit gebeurde tijdens de powerup van de applicatie maar kon ook om bepaalde algorithmes te wijzigen voor een ander type proces.
Ik had hetzelfde gedaan voor 3 stuks 10KE50 devices vroeger maar daar was er een EPM7192 CPLD die een deel van de timing deed. Maar dat was een ISA bus waar de .rbf files parrallel doorgestuurd werden en in de EPM7192 serieel LSB first uitgeschoven werden.
Als de volledige file was doorgestuurd moest je nog minstens 40 CLK pulsen verder gaan om de FPGA in actieve mode te laten starten waardoor de level van de config_done hoog werd. Dit wilde zeggen dat je device geladen was.
Enkel de max snelheid is begrenst, lager zelfs tijdelijk mag/kan zonder problemen.
Op 5 februari 2007 20:44:59 schreef fotoopa:
Ja het was via de JTAG pinnen. Het was een PCI kaart met een 9030 PCI controller. Daar waren enkele pinnen die je als gewone I/O kon gebruiken. Die waren verbonden met:
nCONFIG
DCLK
DATA
config_done
nStatus
Die pinnen bedoelde ik dus, die zitten niet op een CPLD. Het gaat erom een MAX II via JTAG te programmeren, een FPGA is inderdaad niet zo'n probleem.
Heb net nog even in de JTAG docs van de MAX II gekeken, IDCODE uitlezen gaat allemaal wel maar over de programmeerinstructies staat er alleen:
"IEEE 1532 ISC instructions used when programming a MAX II
device via the JTAG port."
These instructions are shown in the 1532 BSDL files, which will be posted on the Altera® web site at
www.altera.com when they are available.
Nou mooi niet dus, volgens mij belooft Altera wel vaker dingen online te zetten en doet het dan toch niet.
Er staan wel BSDL files maar deze gaan niet over de programmeerinstructies (alleen pre-configuration BST, IEEE 1149.1, geen IEEE 1532). Ook staat er:
You will need an IEEE 1532 BSDL file (programming algorithm) and an in-system configurable (ISC) file (programming data) to execute in-system programmability (ISP). Methods of generating the ISC file can be obtained from the Quartus® II Handbook.
ISC files zijn volgens de documentatie alleen beschikbaar voor oudere MAX types, niet voor de MAX II.
Al deze termen zijn ook nieuw voor mij maar zo te zien is er niets aan specificaties over bekend. JAM/STAPL werkt dan wel maar je hebt totaal geen controle over het proces, je kunt alleen bits doorgeven en uitlezen.
Overigens kunnen JAM/STAPL files automatisch gegenereerd worden door Quartus, gewoon onder programming files aanzetten.
Op 5 februari 2007 20:56:05 schreef madwizard:
[...]
Nou mooi niet dus, volgens mij belooft Altera wel vaker dingen online te zetten en doet het dan toch niet.
Je hebt het over IEEE 1532, dit is een IEEE standard, nu zullen er wel fabrikant specifieke instructies maar dit documentje
http://www.xilinx.com/bvdocs/appnotes/xapp500.pdf
(van Xilinx 
) vertelt over de IEEE 1532 compatible devices, alhoewel dit xilinx is zal ook Altera zich moeten houden aan deze standaard als hun devices compatible zijn met deze standaard 
Op 5 februari 2007 21:08:10 schreef surge_me:
Je hebt het over IEEE 1532, dit is een IEEE standard, nu zullen er wel fabrikant specifieke instructies maar dit documentje
http://www.xilinx.com/bvdocs/appnotes/xapp500.pdf(van Xilinx
Dat wel alleen de BSDL files die je dan blijkbaar nodig hebt missen dus. Het lijkt erop dat BSDL ook een soort beschrijving is van het programmeeralgoritme, net zoals JAM/STAPL. Die Jdrive interpreteert dat ook allemaal, net zoals die JAM/STAPL player interpreteert. In dat geval schiet je er ook weinig mee op.
Waar ik eigenlijk op gehoopt had is een of andere JTAG instructie waarmee je gewoon die POF file naar binnen kan shiften.
edit:
The IEEE 1532 standard is complementary to the JEDEC-approved Jam Standard Test and Programming Language (STAPL). The IEEE 1532 standard is a hardware standard that defines the actual ISP algorithm for each device, while Jam STAPL is a software standard that defines the file format that stores the programming information for the chain of devices.
Niet echt een oplossing dus.
[Bericht gewijzigd door madwizard op ]
Hum... Ik heb met die MAX II nog niet gewerkt, dus zal waarschijndelijk wel juist zijn. Maar anderzijds hebben ze toch een JTAG connectie en daar moeten ze zeker mee te programmeren zijn want dit kan via de byteblaster.
Maar voorlopig kan ik daar niet verder op antwoorden bij gebrek aan praktische ervaring met die chips.
Als je een parallel poort hebt is er geen enkel probleem met byteblaster MV maar er zijn er natuurlijk die op de laatste portables geen poort meer hebben. Hoewel ik vraag me af hoeveel CO gebruikers er dat vandaag al zijn. Ik heb 2 PC's en 1 portable en daar zit overal een parallelpoort op, nuja opa is opa hé ze zijn een paar jaar oud!
Nuja ik volg de zaak wel verder...
free_electron
Silicon Member
Professioneel ElectronenTemmer - siliconvalleygarage.com - De voltooid verleden tijd van 'halfgeleider' is 'zand' ... US 8,032,693 / US 7,714,746 / US 7,355,303 / US 7,098,557 / US 6,762,632 / EP 1804159 - Real programmers write Hex into ROM
inderdaad.
bdsl beshrijft het programing algoritme. ( cellen activeren , wiscommando gevne en dergelijke. )
je moet de bitstream pakken , die in stukken kappen en doorsturen. samen me tde correcte 'warpper'
bij ene fpga is dat gewoon een schuifregister wat je vult.
bij een cpld schrijf je de eeprom ...
dezelfde miserie heb je als je een AS device wilt flashen.
( dat zijn de configuratie geheugens voor fpga's ) das ook een flink stuk complexer dan gewoon 'schuiven ' ....
ik ga daar gewoon de printerpoort variant op zetten. al het nodige werk zit al in quartus.
Op 5 februari 2007 21:26:53 schreef free_electron:
ik ga daar gewoon de printerpoort variant op zetten. al het nodige werk zit al in quartus.
Ik denk dat het een goede oplossing is. Bijna iedereen heeft nog een printerpoort. Als je de 10 pins JTAG connector ook voorziet kun je toch altijd je plan trekken, desnoods met de duurdere USB blaster.
Toch denk ik dat het wel goed is op de toekomst te ontwerpen. Je ziet nu al af en toe topics voorbij komen over USB programmers voor AVR/PICs omdat mensen geen parallele poort meer hebben. Maar ik snap ook wel dat het lastig is iets te ontwerpen rond USB zonder veel support.
Ik zag trouwens net ook dat je nog SVF (serial vector files) kunt genereren, dat ziet er ook erg interessant uit! Het lijkt een lijst JTAG instructies voor erase/program/verify. Als dat bruikbaar is scheelt dat enorm in de mogelijke optimalisaties.
!
!
!
!BULK ERASE
!
!
!
SIR 10 TDI (203);
RUNTEST 53 TCK;
SDR 13 TDI (0011);
SIR 10 TDI (2F2);
RUNTEST 5000003 TCK;
SIR 10 TDI (203);
RUNTEST 53 TCK;
SDR 13 TDI (0001);
SIR 10 TDI (2F2);
RUNTEST 5000003 TCK;
SIR 10 TDI (203);
RUNTEST 53 TCK;
SDR 13 TDI (0000);
SIR 10 TDI (2F2);
RUNTEST 5000003 TCK;SIR -> shift instruction, SDR -> shift data. Allemaal standaar JTAG spul. Dit lijkt echt ideaal.
[Bericht gewijzigd door madwizard op ]
Ganzz
-
Van de 6 PC's hier heeft er 1 hier een parralle poort, mijn pc/laptop heeft dat niet, en mijn laptop ook geen serieel.
Iets anders dan parrallel lijkt mij beter
[Bericht gewijzigd door Ganzz op ]
Het is me gelukt met die SVF file een MAX II te wissen, het werkt allemaal vrij eenvoudig alleen die RUNTEST is nog een beetje tricky (edit: ook opgelost, was een buffering foutje van me). Ik denk dat je hiermee de FTDI bitbang nog wat mee kunt optimaliseren, en met een kleine microcontroller ertussen zou je het allemaal nog sneller moeten kunnen maken (verzonden data kan dan praktisch one-way worden).
free_electron
Silicon Member
Professioneel ElectronenTemmer - siliconvalleygarage.com - De voltooid verleden tijd van 'halfgeleider' is 'zand' ... US 8,032,693 / US 7,714,746 / US 7,355,303 / US 7,098,557 / US 6,762,632 / EP 1804159 - Real programmers write Hex into ROM
leg uit !
wat doet dat spul . met andere woorden waar is de documentatie van die svf file ?
bijvoorbeeld : wat betekent dit :
SIR 10 TDI (203)
schuif een instructie van 10 bits met combinatie 203(hex)
zou dus 10 0000 0011 schuiven ?
heb je daar ergens ene documentje wat uitlegt wat die commandos zijn en hoe de overenekomstige golfvormen op tck tms tdi en tdo zijn ?
als ik dat hebt kan ik ene progje maken wat een 245 gebruikt om het transport te doen.
Hier is een goed document:
http://www.asset-intertech.com/support/svf.pdf
Het werkt allemaal direct op de JTAG state machine. Je initialiseert de boel in idle/run_test. Van daaruit werken de instructies. Grotendeels is dat alleen maar SIR, SDR en RUNTEST.
SIR schuift inderdaad een JTAG instructie naar binnen (via SHIFT_IR etc.), je moet daarna weer uitkomen in de idle state. SIR 10 TDI (203) betekent schuif een instructie van 10-bits naar binnen via TDI, instructie zelf is 0x203 (10 0000 0011). Least significant eerst.
SDR 13 TDI (0011) is hetzelfde voor het dataregister: 13 bits (0x11, is altijd hex) via shift_dr naar binnen. Output via tdo kun je negeren.
Dan heb je nog dit soort dingen:
SDR 16 TDI (FFFF) TDO (4A82); Hier wordt ook gewoon 16-bits (FFFF) naar binnen geschoven in het data register, maar wordt ook de output vergeleken, die moet dan 0x4A82 zijn. Dit klopte bij mij inderdaad allemaal.
RUNTEST 53 TCK; Dit is een delay van 53 TCK cycles. Ergens bovenin de file wordt TCK als 10MHz gedefinieerd, zo kun je dus de delays uitrekenen. Deze worden tijdens erase (halve seconde delays) en tijdens programmeren (100uS) gebruikt.
Programmeren heb ik nog niet getest maar het lijkt me dat dit moet lukken.
De delays tijdens het programmeren zijn elke 16 bits, das jammer voor de optimalisatie. Maar je zou deze delay in het bitbangen kunnen doen (gewoon loze bytes sturen). Dan kan je het programmeren in 1 lange stream bitbangen zonder iets te hoeven uitlezen.
Verify moet ook de output verifieren maar met de synchronous mode kun je dit dan per buffer doen. Buffer sturen, buffer terughalen, op PC vergelijken.
Met een microcontroller ertussen zou je dat laatste nog lokaal kunnen doen en hoeft de PC eigenlijk alleen maar data naar de controller te sturen, niet andersom.