Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
John, I like your idea of using PNP trsistor with a -1.3V pulldown but I donot know how exactly I should be biasing the transistor. Especially the Base resistor and collector resistor values. It will be great if you can provide some details. Thanks. AlbertArticle: 121226
hi Xilinx, i had a look at ISE 9.2 today. It's supporting Vista 32 bits. When should we have a Vista 64 bits support ? regardsArticle: 121227
<Albert Nguyen> wrote in message news:eea7b1c.9@webx.sUN8CHnE... > John, > > I like your idea of using PNP trsistor with a -1.3V pulldown but I donot > know how exactly I should be biasing the transistor. Especially the Base > resistor and collector resistor values. It will be great if you can > provide some details. > > Thanks. > > Albert Please give an idea of your knowledge base. Are you a hardware engineer? Are you a software guy coming over to the "dark side?" Are you a hobbyist putting together your first "big" system? Do you have a soldering iron on the toolbelt you wear 10 hours a day? The concepts of current gain, RC time constants, and transistor saturation work into the proper configuration along with cost and compliance issues. You might be able to get by with a 2mA drive from a 1.2V rail depending on the common mode range you need to support. The signals are single ended, aren't they?Article: 121228
Ulrich Bangert wrote: > Jim, > > thanks for your remarks! Because I did not want to make it too difficult I > simplified my explanation a bit and left out some things that I regarded not > significant for the problem: It is NOT the cpld's xor output directly that I > am trying to integrate, which would be really very difficult with the > intended precision. > > Instead this output merely drives an precision high speed diode based switch > built from some HSMS-2812 which connects an summing rc-element alternating > with two reference voltages that are indeed of highest quality in terms of > precicion, tempco and 'clean-ness' and yes, low impedance. While this > analogue circuitry has been suspected to be the source of problems it has > now (where the direct comparison with the TIC based measurments was > possible) turned out to work like charming. > > >>So, do not use a CPLD as the Phase Comparitor, but use an LVC Exor gate, >>preferable with Schmitt. eg LVC1G97, with analog Supply decoupling. > > > Using an external xor will be the next thing that I am going to try. > However, even this external xor will only drive the switch described above > and therefore its supply will be less critical than you suggest. Because I > am out for speed (10 MHz may not be the highest frequencies to compare) I > ordered some 74AHC1G86 from Farnell. Do you think that the LVC part could be > the better performer due to the Schmitt trigger? The LVC devices have lower impedances, so would be able to drive Analog-out more easily. (but you can get AHC/HC versions too, so easy to try both ) You may be able to dispense with the down stream analog complexity, by moving the precision ref supplies to the XOR. Try both. > > >>You may even find, you cannot have both non-locked frequencies in the >>same package, so may need separate /4 blocks > > > This will be the next-next thing to do. Again I simplified a bit: The divide > by 4 flip-flops are the things that provide symmetrical quadrature outputs. > In front of them are programmable predividers that enable the circuit to > compare two signals of not the same frequency. However for the experiment > described these predividers were de-activated. These predividers are the > reason for using the 'big' 75108. With two separate packages I will be able > to use smaller cplds. > > >>Also XOR gates will be quite good at 90' output, but will not be linear >>at needle pulse phase outputs, so if you need 360' phase with linearity, >>I would suggest look at dual quadrature XOR phase comparisons. >>(so one is in mid scale, when the other hits the edges) > > > Basically that is the reason for dividing by 4 but I did not mention the > additional quadrature outputs. The circuit is indeed exactly as you suggest. > It has an small microcontroller that looks at the voltages of two quadrature > phase comparators with an LTC2402, chooses which is the more appropiate one > to use and automatically corrects for the 'jump' in phase when switching > between the quadrature outputs. All of this works even better than expected. > It is just that the cpld which has not been suspected at all as an possible > source of problems now turnes out to be the true beast. Think of digital sigals as having finite edges, and ALL edges as generating threshold shifts due to the common mode inductances, and you can see the ease with which jitter/crosstalk can get into a system. > > >>This stuff is NOT on the chip designer's radar :) > > > Surely not! Nor has it been on the radar of the designers of the MECL gates > that HP used to build their K34-5991A linear phase comparator from! But > sometimes using digital stuff for analogue purposes and vice versa can be > very funny and shows that the difference is sometimes not that strict. > > >>Any edge that is very close to another, WILL move the threshold, and >>so cause phase non-linearities. > > > Yes, from some earlier experiments I would have suspected & accepted THIS. > But the error function that I tried to describe covers the COMPLETE range of > phase-relationships that the two signals can have and that is what makes me > wonder. If you supply an address to where I can send something I will be > glad to send you an image of it. should make interesting viewing : jim dot granville at designtools d o t co d o t nz > > Best regards > Ulrich Bangert > > "Jim Granville" <no.spam@designtools.maps.co.nz> schrieb im Newsbeitrag > news:46839488$1@clear.net.nz... > >>Ulrich Bangert wrote: >> >>>Gents, >>> >>>please allow me to confront you with some strange timing behaviour which > > I > >>>have measured with an Xilinx XC95108 cpld. >>> >>>Consider two well conditioned clock signals of 10 MHz (both having > > EXACTLY > >>>the same frequency) entering the cpld. Inside the cpld each clock signal > > is > >>>divided by 4 by means of two d-flip-flops. The two resulting 2.5 Mhz > > signals > >>>enter an exclusive-or-gate which delivers an output signal where the >>>pulse/pause-relationship directly depends on the phase relationship of > > the > >>>two input clocks. >>> >>>If some of you feel reminded to something that you have seen before: > > Yes, > >>>basically this is the principle of an so called linear phase comparator >>>which has been used to compare high stability clocks (for example cesium >>>clocks) against each other before high resolution time interval counters >>>like the HP5370 or the Stanford Research SR620 were available. >>> >>>Now imagine one of the two clocks is de-tuned by exactly 0.001 Hz. It is > > a > >>>bit beyond the discussion HOW this is achieved but you may believe me > > that > >>>this is possible and that THIS is not part of the discussed problem. Now > > the > >>>phase relationship of the clocks changes slowly in time as does the >>>pulse/pause relationship behind the xor gate. The pulse/pause > > relationship > >>>of the xor's output can be measured by two completely different methods: >>> >>>a) by generating an dc voltage which is directly proportional to the >>>pulse/pause relationship (again a bit tricky if you want it to be an > > really > >>>high resolution measurement, but it can be done) >>> >>>b) by directly measuring the output pulse width with an high resolution > > time > >>>interval counter like the SR620 having a 25 ps single shot resolution > > for > >>>time interval measurements. >>> >>>It is important to note that both methods to measure can be applied at > > the > >>>same time and that both methods (although based on completely different >>>physical laws) deliver results that despite some statistical > > fluctuations > >>>are basically the same. That is why I am pretty sure that what I measure > > is > >>>really an property of the signal itself and not one of the measurement >>>apparatus. >>> >>>If I record the pulse width over time using the two methods and display > > it > >>>graphically it looks like an pretty linear relationship at the first > > glance. > >>>If however some math is applied to make it evident how good the linear >>>relationship really is met then the result is that there are > > fluctuations in > >>>the pulse width in the order of some +/-450 ps from the expected values. >>> >>>About these fluctuations the following facts are known: >>> >>>1) They are not existent in the inputs clocks >>> >>>2) Expressed in time units as well as expressed as an dc voltage the >>>fluctuations are orders of magnitude bigger than the resolution and >>>precision of the time/dc measurement. >>> >>>3) The fluctuations are by no means of stochastical nature. Instead, If > > an > >>>positive fluctuation is noticed at an certain phase between the clock >>>signals, an fluctuation of the same magnitude and sign will be noticed > > the > >>>next time when the clock signals have the same phase relationship. Or in >>>other words: The pulse width is an direct function of the phase > > relationship > >>>of the clocks + an error function which is an direct function of the > > phase > >>>relationship between the clocks. >> >>How often do you see this, 4 or 8 times per 2.5MHz cycle ? >> >> >>>It seems as if the phase state of one of the signals can have an linear > > like > >>>modulating effect on the phase state of the second signal (and perhaps > > vice > >>>versa). Some of you may come to the conclusion that +/-450 ps is not an >>>number to cause real world troubles but in my case: The whole > > arrangement > >>>has the intention to measure phase fluctuations of the input clocks that > > ARE > >>>REALLY THERE but that are smaller at least one order of magnitude than > > the > >>>noticed errors. And that is why +/-450 ps is an real annoying number for > > me. > >>>Any hint will be highly appreciated >>>TIA, Ulrich Bangert >> >>I think I have followed this. >>If you are trying to 'zoom into' the phase to high precisons, using >>analog Phase integration, there are some rules to follow. >> >>Vcc and Gnd must be VERY clean. >>That means no other clocks, and /4 is going to cause more edges and >>bounce, plus Vdd impedance noise is usually quite bad on CPLDs. >>Any edge that is very close to another, WILL move the threshold, and >>so cause phase non-linearities. >>Normally, these are so small, well under Tpd, so in the digital domain >>they do not matter much. [Some CPLDs will show Tpd delta, vs outputs > > loded ] > >>This stuff is NOT on the chip designer's radar :) >> >>So, do not use a CPLD as the Phase Comparitor, but use an LVC Exor gate, >>preferable with Schmitt. eg LVC1G97, with analog Supply decoupling. >> >>You may even find, you cannot have both non-locked frequencies in the >>same package, so may need separate /4 blocks >> >>Also XOR gates will be quite good at 90' output, but will not be linear >>at needle pulse phase outputs, so if you need 360' phase with linearity, >>I would suggest look at dual quadrature XOR phase comparisons. >>(so one is in mid scale, when the other hits the edges) >>( or even more phases, 4 would be simple from 10MHz, and use 4 ADC >>channels - then 3 of the 4 would be low-error ) >> >>-jg >> > > >Article: 121229
gamer <csanjay@gmail.com> writes: > My goal is to implement a bit-error counter targeting 1GHz. The > datawidth is parametrizable. I started off this way, How much resources do you have available and how often do you want to process the counters? If you have lots of registers available and just want to sample the counters at some point in time (e.g. after one hour of operation) and present the result on a PC or whatever you could: Use datawidth X linear feedback shift registers (of sequence length error count, or some more optimal length for the LFSR sequence) as counters. This is only a single XOR delay between two registers. Then sample all the counters. Transfer the results to your PC. Convert the LFSR sequences and add the values before you present the result. However, you can't do this if you have to continuously present the result. You haven't provided enough details about this in your specification. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 121230
Albert Nguyen wrote: > John, > > Thanks for you input. I looked at the ADUM1401 datasheet. So you are suggesting that on the FPGA side of this device, I connect the Vdd1 to 2.5 and Gnd1 to ground but on the other side of this device I connect the Vdd2 to +1.2 and GND2 to -1.3V. Is that correct? > > Albert That was my suggestion, and yes. - but note the isolator is a 2.7V-5.5V device, so +ve could go to a slightly higher + rail in both cases. Transistors are also usable, but they will struggle to get to your 20MHz, whilst the ADi devices spec 90MHz. -jgArticle: 121231
Hi, you can find the source code here : http://www.teolabs.net/?page_id=21 MatteoArticle: 121232
On Jun 27, 9:34 am, gamer <csan...@gmail.com> wrote: > My goal is to implement a bit-error counter targeting 1GHz. The > datawidth is parametrizable. I started off this way, How is the input data created? If the register values come from bit set/clear operations, you can keep track of the number of ones with a separate counter that is updated appropriately when the register is updated. For example, suppose that you'd like to know the number of ones in a shift register. If the input bit and the bit shifted off (and thus removed from the register) are the same, the separate counter is unchanged. If the input is 1 and the bit shifted off is 0, the counter is incremented. If the input is 0 and the bit shifted off is 1, the counter is decremented. When the register as a whole is cleared, the counter is also cleared. It's easy enough to extend this to any update scheme where the number of bits that can change each cycle is small, even if those can be in arbitrary positions.Article: 121233
<SWAmdata@gmail.com> wrote in message news:1182956538.814375.274750@q69g2000hsb.googlegroups.com... > > In the architecture I added the following internal signals: > signal iLED1 : std_logic := '1'; > signal iLED2 : std_logic := '0'; > signal iLED3 : std_logic := '0'; > > An also in the architecture under begin I added: > > LED1 <= iLED1; > LED2 <= iLED2; > LED3 <= iLED3; > > > No matter what I default the internal signals to the LEDs do not > change state. Does anybody see what I am doing wrong or do you need > more information? I am not sure if the initialization of this sort is synthesizable. It might be for clocked signals, but certainly not for combinatorial as is the case in your code. Just do explicit assignment and see if that works... Something like: iLED1 <= '1'; iLED2 <= '0'; or directly: LED1 <= '1'; LED2 <= '0'; /MikhailArticle: 121234
Does anyone know which cpu do they use in the d-link router/adsl modem dsl-g624t ? Aparently, they are running linux inside. How did they do that, scaling down the whole thing into only what they need, and writing device drivers for their ethernet and adsl interfaces, sounds like quite a bit of work. Is there schematics and source free to view some where?Article: 121235
<len> wrote in message news:46843cd4$1_2@mk-nntp-2.news.uk.tiscali.com... > Does anyone know which cpu do they use in the d-link router/adsl modem > dsl-g624t ? > Aparently, they are running linux inside. How did they do that, scaling > down the whole thing into only what they need, and writing device > drivers for their ethernet and adsl interfaces, sounds like quite a bit > of work. Is there schematics and source free to view some where? Are you aware this is a forum for Field Programmable Gate Arrays? Why do you believe we would know about a for-profit commercial product? Why would d-link care to disclose the schematic and source for their product? Hey - while I have your ear, do you have any idea why the cup holders for the BMW Z-4 are so shallow? Do you know where I can find mechanical drawings on them?Article: 121236
On 2007-06-28, Albert Nguyen <> wrote: > > I am not able to see your picture clearly. Select a fixed-width font like courier. It's just a PNP transistor. The FPGA 0-3.3V swing can swing both high and low of the target's Vcc. You just have to scale the pulldown on the target side to the load capacitance of the receiving chip (that's why I showed a 10p "load"). Download LTspice and simulate it. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 121237
<len> wrote in message news:46843cd4$1_2@mk-nntp-2.news.uk.tiscali.com... > Does anyone know which cpu do they use in the d-link router/adsl modem > dsl-g624t ? > No. No-one knows. It's a secret. When they were designing it, each engineer was only allowed to see one transistor. My friend accidentally saw two, but now he's disappeared. I blame the Duke of Edinburgh. > > Aparently, they are running linux inside. How did they do that, scaling > down the whole thing into only what they need, and writing device > drivers for their ethernet and adsl interfaces, > Very carefully. I think they must've done quite a bit of work. > > sounds like quite a bit > of work. > I agree. > > Is there schematics and source free to view some where? > > Maybe in Xanadu. Or perhaps Nirvana? One of those utopias, I'm sure. If you find said S&S, why not post them to a totally random usenet group. That'll make you really popular. HTH, Syms.Article: 121238
John_H wrote: > Hey - while I have your ear, do you have any idea why the cup holders for > the BMW Z-4 are so shallow? Because the people who drive them are? ;) Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 121239
Does any one know how to set the search path so my modelsim pe 6.0c will find the .mif file associated with my coregen blocks? I get the following error: # Loading C:/Xilinx/vhdl/mti_pe/XilinxCoreLib.cordic_v3_0(behavioral) # ** Error: (vsim-7) Failed to open VHDL file "dds_SINCOS_TABLE_TRIG_ROM.mif" in rb mode. # No such file or directory. (errno = ENOENT) # Time: 0 ns Iteration: 0 Instance: /ddr_9479_tb/uut/bfo_g1/nco/bu273 # ** Fatal: (vsim-7) Failed to open VHDL file "dds_SINCOS_TABLE_TRIG_ROM.mif" in rb mode. # No such file or directory. (errno = ENOENT) # Time: 0 ns Iteration: 0 Process: /ddr_9479_tb/uut/bfo_g1/nco/bu273/dp_primitive File: C:/Xilinx/vhdl/mti_pe/XilinxCoreLib/XilinxCoreLib_source.vhd # Fatal error at C:/Xilinx/vhdl/mti_pe/XilinxCoreLib/XilinxCoreLib_source.vhd line 80173 If I copy the .mif to the root directory it works okay, but I want to keep my top module and test bench one directory up from the subblocks. Thanks, ClarkArticle: 121240
Same experience on my machine. Luckily I kept a backup of the old
Modelsim XE-III 6.2c. If you still have 6.2c laying around, you can try
this 'hack' to XE-III 6.2g:
simple copy over 6.2c's \modelsim_xe_starter\sv_std\* directory
to your new 6.2g installation.
So far, 6.2g compiles and simulates simple Systemverilog simulations,
but whether it'll crash on sims using more complex Systemverilog
syntax, who knows.
"Xilinx User" <anonymous@net.com> wrote in message
news:esOgi.7913$bP5.6493@newssvr19.news.prodigy.net...
> "HT-Lab" <hans64@ht-lab.com> wrote in message
> news:x_Jgi.5846$nE2.2947@newsfe3-win.ntli.net...
>>> Anyway, Modelsim XE-III 6.2c starter-edition ran
>>> Systemverilog simulations just fine. So did Xilinx remove
>>> this feature from XE-III 6.2g? Nowhere in Xilinx's
>>> online documentation, does Xilinx claim to support
>>> Systemverilog. But I'd like to get a definitive/official
>>> answer.
>> ...
>> Do you have the sv_std folder in your installation directory? (I have it
>> on my PE installation).
>
> I checked my \modelsim_xe_starter dir, and the sv_std subdir is there.
> From what I can tell, the 6.2g installer puts the files there, but the
> simulator refuses to load them if the simulation contains any
> Systemverilog modules/submodules.
>
> Mentor's free Modelsim PE Student Edition (6.3p1) runs Systemverilog
> simulations just fine...though I hope there isn't some kind of weird
> interaction when multiple Modelsims are installed on the same
> PC!
>
Article: 121241Execute from SPI flash has always appealed as one way to reduce the PCB cost of the Code memory needed by Soft CPUs. Winbond have had Double rate SPI devices at 150MBd, and I see they plan to release Quad-SPI devices, that target Execute of code direct from the Flash. http://www.eeproductcenter.com/memory/brief/showArticle.jhtml?articleID=200001582 News : ["To address this need, Winbond will introduce a new class of high-performance serial flash memories later this year. The new family features Quad-SPI with six times the transfer rate of standard serial flash and greater performance than most parallel flash memories. This new line is targeted at applications that execute code directly from the SPI bus to significantly reduce system costs. Winbond will initiate this Quad-SPI family with a 16-megabit flash memory."] Natural next step, is to tweak Soft-CPUs to take advantage of this type of memory. -jgArticle: 121242
Jim Granville wrote: > Execute from SPI flash has always appealed as one way to > reduce the PCB cost of the Code memory needed by Soft CPUs. > Winbond have had Double rate SPI devices at 150MBd, and > I see they plan to release Quad-SPI devices, that target > Execute of code direct from the Flash. More info: Advance data is here http://www.winbond.com.tw/NR/rdonlyres/4C63AD62-967C-4B72-AF85-1F5984E8B199/0/W25Q80.pdf Still an 8 pin package (or SO16 where die is too large ) Best speed is from Fast Read Quad I/O opcode Looks like the first byte is 1-bit SPI (8Ck), then the 32 bit address is loaded 4 bits wide (8Ck), then 4 wait clocks, and then bytes stream out two Ck per byte, so the latency to first byte is 8+8+4+2 = 20-22clks, and the Speed-Equivalent-Skip is 10 bytes - ie for short forward jumps, of up to 10 bytes, you are better to simply skip, than re-address. Clock is 80MHz, gives 320MBd, or 40 MBytes/s memory bandwith. Enough for some serious uC programming, and you can split into 2 SPI devices, and double that again, or perhaps x3, for 18-24 bit opcode cores ? -jgArticle: 121243
"Brian Drummond" <brian_drummond@btconnect.com> wrote in message news:5qi4839e54srnmkocb6h43f638hekvo0di@4ax.com... > > But often when PAR crashes for no good reason, re-running with a > different cost table seed (-t 3 for example) gets past the problem. > Another thing to try is to delete all the generated files, sometimes something gets stuck there... If that doesn't help either just change something substantial in the synthesis and/or map and/or par options, e.g. toogle keep hierarchy switch or timing driven mapping, etc.. In most cases it "fixes" the problem. /MikhailArticle: 121244
"Perry" <lipeng.net@gmail.com> wrote in message news:1182928882.882676.134330@e9g2000prf.googlegroups.com... > > DeleteInterpProc called with active evals Apparently this problem is a known issue: http://tinyurl.com/yof2hf /MikhailArticle: 121245
neilla@pipstechnology.co.uk wrote: > I'm looking at adding an embedded USB JTAG programmer onto our latest > board, and am just looking for a bit of advice. The board has on it > an Spartan 3, and an XCF08P Platform Flash prom, the main processor on > the board is a Compulab computer on module. We need to be able to > program the flash in system using the Compulab CoM. We currently do > this using the LPC interface on the CoM, and an extra CPLD, using the > xilinx JDrive software. Currently doing an erase, program, and verify > of the XCF08P takes ~60 seconds. I was thinking it might be a nicer > solution to use a USB device like the FTDI 2232 to give us JTAG > access, but would like a bit of advice as to how easy it is to use > these things, and is the programming time likely to be any quicker. > > Neill. > Amontec has designed a generic SVF Player for the JTAGkey. We can run any SVF for programming any FPGA/CPLD/FLASH from Altera Lattice Xilinx Cypress ... Amontec JTAGkey is based on FT2232. If you send me your XCF08P.svf file, I can play it (à vide) and found how much time it takes for doing the JOB. (please zip before sending) email to laurent.gauch@REMOVE_THIS_ANTI_SPAMamontec.com Regards, Laurent Gauch www.amontec.comArticle: 121246
For example, signal A is an inout signal of certain IP and connected to an external pin of the FPGA with a net(let's call it net_A). What I want to do is to add another pin just for output, and connect net_A to it. When I did this in EDK, I always got an MDT error message: ERROR:MDT - ....connector is connected to both uni and bi-directional ports! 1. What should I do if I want to connect net_A to the two ports? Maybe FPGA_editor can do this work, what about EDK? 2. Can the error above be supressed by certain configuration to EDK?Article: 121247
"cpope" <cepope@nc.rr.com> wrote in message news:46846fca$0$30640$4c368faf@roadrunner.com... > Does any one know how to set the search path so my modelsim pe 6.0c will > find the .mif file associated with my coregen blocks? I get the following > error: > > # Loading C:/Xilinx/vhdl/mti_pe/XilinxCoreLib.cordic_v3_0(behavioral) > # ** Error: (vsim-7) Failed to open VHDL file > "dds_SINCOS_TABLE_TRIG_ROM.mif" in rb mode. > # No such file or directory. (errno = ENOENT) > # Time: 0 ns Iteration: 0 Instance: /ddr_9479_tb/uut/bfo_g1/nco/bu273 > # ** Fatal: (vsim-7) Failed to open VHDL file > "dds_SINCOS_TABLE_TRIG_ROM.mif" in rb mode. > # No such file or directory. (errno = ENOENT) > # Time: 0 ns Iteration: 0 Process: > /ddr_9479_tb/uut/bfo_g1/nco/bu273/dp_primitive File: > C:/Xilinx/vhdl/mti_pe/XilinxCoreLib/XilinxCoreLib_source.vhd > # Fatal error at > C:/Xilinx/vhdl/mti_pe/XilinxCoreLib/XilinxCoreLib_source.vhd line 80173 > > If I copy the .mif to the root directory it works okay, but I want to keep > my top module and test bench one directory up from the subblocks. > The mif file might be specified as a generic in your vhd wrapper file, change the path, recompile and bob's your uncle :-) Hans www.ht-lab.com > Thanks, > Clark > >Article: 121248
On 28 Jun, 21:05, Teo <vit.mat...@gmail.com> wrote: > Hi, > you can find the source code here :http://www.teolabs.net/?page_id=21 > > Matteo Matteo, Thanks for the link, it sounds very interesting, I think I'll get one of those demo boards so at least I can then give it a go. NeillArticle: 121249
On 29 Jun, 07:20, "Amontec, Larry" <laurent.ga...@ANTI- SPAMamontec.com> wrote: > nei...@pipstechnology.co.uk wrote: > > I'm looking at adding an embedded USB JTAG programmer onto our latest > > board, and am just looking for a bit of advice. The board has on it > > an Spartan 3, and an XCF08P Platform Flash prom, the main processor on > > the board is a Compulab computer on module. We need to be able to > > program the flash in system using the Compulab CoM. We currently do > > this using the LPC interface on the CoM, and an extra CPLD, using the > > xilinx JDrive software. Currently doing an erase, program, and verify > > of the XCF08P takes ~60 seconds. I was thinking it might be a nicer > > solution to use a USB device like the FTDI 2232 to give us JTAG > > access, but would like a bit of advice as to how easy it is to use > > these things, and is the programming time likely to be any quicker. > > > Neill. > > Amontec has designed a generic SVF Player for the JTAGkey. > We can run any SVF for programming any FPGA/CPLD/FLASH from Altera > Lattice Xilinx Cypress ... > > Amontec JTAGkey is based on FT2232. > > If you send me your XCF08P.svf file, I can play it (=E0 vide) and found > how much time it takes for doing the JOB. (please zip before sending) > > email to laurent.gauch@REMOVE_THIS_ANTI_SPAMamontec.com > > Regards, > Laurent Gauchwww.amontec.com Larry, The main problem with using an SVF file for programming the XCF08P is the erase time. The file from the xilinx tools has the erase time set to 140 seconds, this is actually the time needed for the larger platform flash, with the XCF08P the this can be reduced to 50 seconds. This is the maximum time needed to gurantee it is erased correctly. The problem with SVF is that it just sits and waits for this time, at least with the jdrive software after an erase it sits polling a bit in a register to see when the erase is really completed, which is normally much less than the 50 seconds. This is also similar with the programming times. Neill
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z