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
>even a 'relatively fat' 10% gate trigger time, will slash the power needs > from just under 1A to under 100mA That point is very important. Triac specifications don't usually quote a minimum gate time to start conduction, but 5us (and maybe much less) seems to give reliable operation and is less than 0.1% of the half-cycle time (at 50Hz or 60Hz), so the saving in PSU drain can be enormous. MikeArticle: 125551
MikeShepherd564@btinternet.com wrote: >>even a 'relatively fat' 10% gate trigger time, will slash the power needs >>from just under 1A to under 100mA > > > That point is very important. > > Triac specifications don't usually quote a minimum gate time to start > conduction, but 5us (and maybe much less) seems to give reliable > operation and is less than 0.1% of the half-cycle time (at 50Hz or > 60Hz), so the saving in PSU drain can be enormous. True, we have done some CMOS Triac designs, powered from a dropper, and there power matters a lot. With a zero cross the gate trigger pulse can be required wider than 5us, as it need to be applied until past the Triac Holding current. That's also why burst trigger is sometimes used - saves power and tolerates some current phase shifts, and you can be lazier around zero cross. The OP is using a FPGA, so going from 1A to 100mA makes good sense, but chasing much under 100mA is pretty pointless, given the static FPGA Icc figures ;) -jgArticle: 125552
Hi I've gone through the ISE Quick Start Tutorial and can get its 4 bit counter downloaded and working on a Digilent board with an xc3s200-4ft256. (BTW: the Quick Start Tutorial is located at http://toolbox.xilinx.com/docsan/xilinx9/books/docs/qst/qst.pdf) My question how can I use xflow from the command line to build the .bit file? For example, after setting the project up with ISE, I'd like to try moving one of the LED locations in the .ucf file and rebuild without going into the GUI. Here is the command I tried and the results I get with it: > mkdir -p work > xflow -wd work -p xc3s200-4ft256 -synth xst_mixed -implement fast_runtime -config bitgen tutorial.ise Release 9.2.03i - Xflow J.39 Copyright (c) 1995-2007 Xilinx, Inc. All rights reserved. xflow -wd work -p xc3s200-4ft256 -synth xst_mixed.opt -implement fast_runtime.opt -config bitgen.opt tutorial.ise .... Copying flowfile /home/Xilinx92i/xilinx/data/fpga.flw into working directory /home/bsmith/tutorial/work .... Copying option file /home/Xilinx92i/virtex/data/fast_runtime.opt into working directory /home/bsmith/tutorial/work .... Copying option file /home/Xilinx92i/virtex/data/bitgen.opt into working directory /home/bsmith/tutorial/work .... Copying option file /home/Xilinx92i/virtex/data/xst_mixed.opt into working directory /home/bsmith/tutorial/work Using Flow File: /home/bsmith/tutorial/work/fpga.flw Using Option File(s): /home/bsmith/tutorial/work/fast_runtime.opt /home/bsmith/tutorial/work/bitgen.opt /home/bsmith/tutorial/work/xst_mixed.opt Creating Script File ... xflow done! The xflow command doesn't actually do anything. What do I need to to to get it to build the .bit file? thanks in advance Bob SmithArticle: 125553
On Oct 25, 4:20 pm, sendt...@gmail.com wrote: > > Since the OP seems to have disappeared to wherever OPs go, I > > suspect we will never find out. > > I didn't disappear, I posted a reply but for some reason it didn't > show up... I didn't want to accidentally spam the newsgroups by > reposting and figured I'd wait to make sure it wasn't just my > newsreader or ISP causing the problem. > > Anyway, I guess I'll answer the reason why I want to do this in the > same post. > > I'm trying to characterize a DRAM device in certain environmental > (radiation) conditions and see how that effects the retention > characteristics. I'm not sure if there tests the industry uses to do > this, but I needed to evaluate it realtime. > > I'm using the core Altera provided but all the code is there (except > for the NIOS II cpu). So I have direct access to the SDRAM > controller. I think it would be really tough to do what you want to do. The reason is that DRAM cell retention time charcteristics are not always deterministic. Some cells will retain data for hundreds of milliseconds, while other cells will retain data for tens of seconds, and they don't always stay in the "hundreds of millisecond" bit or the "tens of seconds" bin. Ravi Venkatesan's paper has some numbers of DRAM cell retention time characteristics [Venkatesan2006]. What this paper doesn't talk about, and what will hurt you is the Variable Retention Time (VRT) characteristics of DRAM cells. That is, a given DRAM cell can retain data for tens of seconds most of the time, but once in a while, it can become a leaky cell that only retains data for tens of milliseconds. End users sometimes refer to this as being a "weak bit". [Yaney1987,Restle1992,Ueno1998,Mori2005,Kim2004] Now, if you're trying to use the DRAM device as a SEU detector of some sort, it depends on how much radiation you expect. If there are a lot of radiation in your environment, then you don't need to do a lot of work beforehand to prepare your sample. If, however, you want to measure something that's very subtle, and maybe someone that would occur no more frequent than once per X minutes, then you'd really have to spend a couple of months with a DRAM device and a tester in a cave 50 feet below ground (need to make sure that there are no neutrons hitting the DRAM while you're characterising it), then characterise it to the level so that you'll be able say with some level of mathematical confidence that you know where all the weak bits in the DRAM device are. Then, once you know what your device looks like, then you take it to the environment where you want to use it to measure your SEU rate, then you'd be able to (to some degree) distinguish between a cell that failed "early" because it has some built-in VRT characteristic, as opposed to a cell that failed because of a SEU. Good luck David @INPROCEEDINGS{Venkatesan2006, author = {Ravi K. Venkatesan, Stephen Herr, Eric Rotenberg}, title = {Retention-Aware Placement in DRAM (RAPID):Software Methods for Quasi-Non-Volatile DRAM}, booktitle = {Proceedings of the 12th International Symposium on High Performance Computer Architecture}, year = {2006}, pages = {157-167}} @INPROCEEDINGS{Yaney1987, author = {D. S. Yaney, C. Y. Lu, R. A. Kohler, M. J. Kelly, J. T. Nelson}, title = {A Meta-Stable Leakage Phenonmenon in DRAM Charge Storage - Variable Hold Time}, booktitle = {International Electron Devices Meeting Technical Digest}, year = {1987}, pages = {336-338}} @INPROCEEDINGS{Restle1992, author = {P. J. Restle, J. W. Park, B. F. Lloyd}, title = {DRAM Variable Retention Time}, booktitle = {International Electron Devices Meeting Technical Digest}, year = {1992}, pages = {807-810}} @INPROCEEDINGS{Ueno1998, author = {S. Ueno, T. Yamashita, H. Oda, S. Komori, Y. Inoue, T. Nishimura}, title = {Leakage Current Observation on Irregular Local Pn Junction Forming the Tail Distribution of DRAM Retention Time Characteristics}, booktitle = {International Electron Devices Meeting Technical Digest}, year = {1998}, pages = {153-156}} @INPROCEEDINGS{Mori2005, author = {Yuki Mori, Kiyonori Ohyu, Kensuke Okonogi, Ren-ichi Yamada}, title = {The Origins of Variable Retention Time in DRAM}, booktitle = {International Electron Devices Meeting Technical Digest}, year = {2005}, pages = {1057-1060}} @INPROCEEDINGS{Kim2004, author = {Y. I. Kim, K. H. Yang, W. S. Lee}, title = {Thermal Degradation of DRAM Retention Time: Characterization and Improving Techniques}, booktitle = {Proceedings of the 42nd Annual International Reliability Physics Symposium}, year = {2004}, pages = {667-668}}Article: 125554
Here is a .bat file I use to build from Verilog source to a .bit file. I invoke by typing : make_xst_FPGA_NAME.bat FPGA_NAME 01 The first command line parameter is the root name for fpga ... For instance, the .ucf file would be named with this prefix, all the resultant files named with this prefix, etc. Second command line is the rev level for the build. Note that I use this in the bitgen command line to specify the user ID. This is helpful in that when a rogue board shows up, the current revision can be determined via reading this parameter with the JTAG programming pod. *********************************************************************** cd .. rmdir /s /q synth mkdir synth cd synth xst -ifn ..\scripts\xst.txt -intstyle xflow ngdbuild -p xc3s250e-4-vq100 -uc ..\files\%1.ucf %1 map -k 6 -detail -pr b %1 rem pause par -ol med -w %1.ncd %1_r%2 copy %1.pcf %1_r%2.pcf trce -e -o %1_err.twr %1_r%2 trce -v -o %1_ver.twr %1_r%2 rem ************************************************** rem * first make bitgen for rom, then remake for JTAG rem ************************************************** rem bitgen -w -g UserID:555500%2 %1_r%2 %1_r%2 bitgen -w -g UserID:55550%2 -g DonePipe:yes -g UnusedPin:Pullup %1_r%2 %1_r%2 ------------------------------------------------------------------- The contents of xst.txt is : run -ifn ..\code\flist_FPGA_NAME.v -ifmt Verilog -ofn FPGA_NAME.ngc -ofmt NGC -p xc3s100e-4-vq100 -opt_mode Speed -opt_level 1 -top FPGA_NAME ------------------------------------------------------------------- The contents of flist_FPGA_NAME is : `include "..\code\FPGA_NAME.v" `include "..\code\FPGA_NAME_SUB_MOD1.v" `include "..\code\FPGA_NAME_SUB_MOD2.v" ------------------------------------------------------------------- Lastly ... yes .. this is a DOS batch file. But the point is it can easily be ported to a script for whichever OS you are currently using. ... One more thing. Under Xilinx/Doc/usenglish/book/docs/ are various subdirectories with .pdf files. Check the /dev for the developers reference guide, /lib for the library guide, /xst for info on xst. Regards, John Retta Owner and Designer Retta Technical Consulting Inc. Colorado Based Xilinx Consultant email : jretta@rtc-inc.com web : www.rtc-inc.comArticle: 125555
John Retta wrote: > Here is a .bat file I use to build from Verilog source to a .bit file. > I invoke by typing : > make_xst_FPGA_NAME.bat FPGA_NAME 01 < snip > Thanks, John. I had found your .bat file with google but was a little intimidated by all the references. I shouldn't have been -- it wasn't really that difficult. Without worrying about Makefiles or scripts, here is the list of command required to build and install the counter to the board for rev# 123..... xst -ifn xst.txt -intstyle xflow ngdbuild -p xc3s200-4ft256 -uc counter.ucf counter map -k 6 -detail -pr b counter par -ol med -w counter.ncd counter_r123 cp counter.pcf counter_r123.pcf trce -e -o counter_err.twr counter_r123 trce -v -o counter_ver.twr counter_r123 bitgen -w -g UserID:55550123 -g DonePipe:yes -g UnusedPin:Pullup counter_r123 counter_r123 impact -batch impact.bat I used your xst.txt file modified for the FPGA on the Digilent board. The commands loaded into "impact.bat" I got by running the download tool in ISE and grepping out "BATCH CMD" from the log file. I consider this the "hello world" of FPGA so now I can go back and figure out what each command is doing. One final question, what command would make a prom image (.mcs) for this? thanks Bob SmithArticle: 125556
Hello VLSI Engineers. Its is true that FPGA boots its program from an external PROM. How external eproms are connected to FPGA. Is there any requirement in making PCB with FPGA. ThanksArticle: 125557
On 29 Okt., 11:46, vlsi_freak <clickonjas...@gmail.com> wrote: > Hello VLSI Engineers. > > Its is true that FPGA boots its program from an external PROM. > How external eproms are connected to FPGA. Is there any requirement in > making PCB with FPGA. > > Thanks 1 yes 2 read the documentation 3 yes read the documentationArticle: 125558
"Frank Buss" <fb@frank-buss.de> wrote in message news:u8etjj60fgai.1h043wvfleasn$.dlg@40tude.net... > Nevo wrote: > >> Each opto will draw a maximum of 7mA. The FPGA will be sinking the >> current >> from the opto, not sourcing current. > > Why not using an additional driver transistor? Like at page 7 in this > datasheet described: > > http://www.fairchildsemi.com/ds/MO/MOC3051-M.pdf > > Could be a small SMD transistor, which costs only cents and limits your > control current to 0.5mA without problems (but I think in figure 11 of the > datasheet a resistor in the base of the transistor would be good) or even > a > small signal FET, which draws nearly no current. Maybe you should use an > additional 0.1uF capacitor from Vcc to GND for each driver to avoid high > current peaks for the voltage regulator and using a separate voltage > regulator for the drivers can help. The main reason is board space. With the hobbyist version of Cadsoft Eagle, I can just barely squeeze in my phyiscal components at the program's maximum 100mm x 160mm board size. The second reason is cost, but with the board space constraint the cost issue is moot. There's just no room on the board for 128 transistors.Article: 125559
>> The FPGA is essentially a very long serial shift register. The computer >> clocks in 128 channels * 8 bits/channel of data over a DATA and a CLK >> line, >> then loads the data into latches with a STROBE line. (Basically, a >> really >> long 74HC595 chip.) I haven't measured the data rate, but I estimate the >> incoming data is ~1MHz. > > Why 1MHz? You have 128 channels and 8 bits per channel. You need to update > it 60 times per second (in European countries: 50 times per second). This > results in a data rate of 61,440 bits per second. > > I would use RS232 with 115,200 baud, which is more than enough, including > some control bytes and checksumming. If it is a long line, use RS485, with > converters at the PC side, maybe an electrically isolated RS485 driver. > I'm using a freeware program (www.vixenlights.com) to drive the data from the host computer to the FPGA board. The host program is bit-banging the parallel port. Since the software side was already written, I designed the hardware around the pre-existing data format.Article: 125560
>Hello VLSI Engineers. > > Its is true that FPGA boots its program from an external PROM. >How external eproms are connected to FPGA. Is there any requirement in >making PCB with FPGA. > >Thanks First make sure you have a stable 6.3V AC heater supply (50Hz or 60Hz is fine). The configuration bit stream is modulated onto this using QPSK (http://en.wikipedia.org/wiki/Phase-shift_keying). You don't need HT during configuration, but a negative grid bias will keep down leakage currents.Article: 125561
"Rob" <robnstef@frontiernet.net> wrote in message news:1z4Vi.19792$ya1.17182@news02.roc.ny... > Do yourself a favor and at least design in the capability of populating a > snubber. I would also add a hi-feq filter cap at the gate of the TRIAC. > Doing these two things will give you recorse to deal with noise at the > gate and any transient dv/dt acorss the TRIAC, both which could > inadvertantly turn the TRIAC on. And when you're picking components > remember that you're dealing with 120V AC. > > I don't think you mentioned anything about how much load the TRIAC's will > be switching. Make sure that you heat sink the TRIAC's, if need be. > If I were designing the circuit board, I'd put in pads for snubbers. I'm buying from a 'group buy' on a DIY Christmas lights forum and the existing boards don't have snubbers designed in. I'll provide this feedback for next year's designs. :) The load for each TRIAC is typically going to be one string of mini Christmas lights at ~0.33A. I don't plan on heatsinks for these loads.Article: 125562
>>>even a 'relatively fat' 10% gate trigger time, will slash the power >>>needs >>>from just under 1A to under 100mA >> >> >> That point is very important. >> >> Triac specifications don't usually quote a minimum gate time to start >> conduction, but 5us (and maybe much less) seems to give reliable >> operation and is less than 0.1% of the half-cycle time (at 50Hz or >> 60Hz), so the saving in PSU drain can be enormous. > > True, we have done some CMOS Triac designs, powered from a dropper, and > there power matters a lot. > With a zero cross the gate trigger pulse can be required wider than 5us, > as it need to be applied until past the Triac Holding current. > > That's also why burst trigger is sometimes used - saves power and > tolerates some current phase shifts, and you can be lazier around > zero cross. This is definitely on my list of improvements to make in the future. I'm going to build the first unit with the brute force approach and add in refinements. (Christmas 2008 should be killer!) :) Not only will this change reduce total power through the circuit, it'll allow me to use a smaller transformer, which is one of the costliest parts in the design.Article: 125563
330mA should be fine w/o heatsinks. "Nevo" <nevo_n@hotmail.com> wrote in message news:MgjVi.5888$%r.2428@trnddc01... > > "Rob" <robnstef@frontiernet.net> wrote in message > news:1z4Vi.19792$ya1.17182@news02.roc.ny... >> Do yourself a favor and at least design in the capability of populating a >> snubber. I would also add a hi-feq filter cap at the gate of the TRIAC. >> Doing these two things will give you recorse to deal with noise at the >> gate and any transient dv/dt acorss the TRIAC, both which could >> inadvertantly turn the TRIAC on. And when you're picking components >> remember that you're dealing with 120V AC. >> >> I don't think you mentioned anything about how much load the TRIAC's will >> be switching. Make sure that you heat sink the TRIAC's, if need be. >> > > If I were designing the circuit board, I'd put in pads for snubbers. I'm > buying from a 'group buy' on a DIY Christmas lights forum and the existing > boards don't have snubbers designed in. I'll provide this feedback for > next year's designs. :) > > The load for each TRIAC is typically going to be one string of mini > Christmas lights at ~0.33A. I don't plan on heatsinks for these loads. >Article: 125564
On 26 oct, 15:28, Antti <Antti.Luk...@googlemail.com> wrote: > XMD is actually itself a server, so it can sure be accessed over > network > the gizmo you mention would not work, check the list of supported > devices > > Antti Yes but then XMD has to run on the lab machine, and I want to avoid installing all the Xilinx software on lab computers (which takes forever, having to install ISE + EDK + Chipscope + all related service packs and IP upgrades). I have found a solution that works well, it's called "USB to Ethernet Connector": http://www.virtualserialport.com/products/usb-over-network/ It's a software solution that basically shares a USB port over the network. I can then map that remote USB port locally and Xilinx tools think that the JTAG cable is connected locally on my machine. It seem to work well so far. PatrickArticle: 125565
On Oct 26, 2:51 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Andy wrote: > > On Oct 25, 4:18 pm, Jim Granville <no.s...@designtools.maps.co.nz> > > wrote: > > >>tago...@gmail.com wrote: > > >>>Hello all > > >>>Does anyone have a Signetics data sheet / data book with this part? > > >>>Thank you > > >>Did you mean the 82S101 ? > >>Google has more luck with that more correct part number :) > > >>-jg > > > IIRC, Signetic's P/N was 82f101, for an equivalent part to the 82s101 > > from someone else? > > > But, Jim is right, you will probably get more hits on 82s101... > > Signetics 'owned' the N82S pefix, and I note someone very recently > 2nd sourced the N82S123 bipolar promhttp://www.eeproductcenter.com/memory/brief/showArticle.jhtml?article... > > -jg- Hide quoted text - > > - Show quoted text - The part was 82S101 not 82F101 - somewhere in a chain of phone calls the S was turned into an F Yes I just saw the QPsemi web site - good site to know about Anyone know inexpensive testing equiment for PLA's - there's an elaborate functional test procedure THanksArticle: 125566
On Oct 25, 7:19 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > Andy wrote: > > (snip) > > > The TRS-80 Color Computer (Moto 6809 based) refreshed during the > > vertical retrace. But there was a bit in the system controller that > > could be set to turn it and video access off, while doubling the > > processor clock. > > I thought it was the display memory access that did the refresh. > I probably still have the service manual around somewhere. > > > As long as your Basic code was running, and not > > waiting on a keyboard input or other event, the ROM interpreter's RAM > > accesses managed to keep the RAM (at least the part of it being used) > > refreshed. But if/when the code hit an error (and thus waited for user > > response) you could watch the screen go from random pixels to all > > white. Once the coding errors were eliminated, it was a reliable way > > to double the processing speed when you did not need video. > > If I remember, there were three modes. Normal mode, one that doubled > the clock speed some of the time, and one that doubled it all the time. > I never tried turning the display off, though. > > -- glen The video and processor were synchronized to access memory on opposite clock cycles. In the mode that doubled the frequency some of the time, the controller (address decoder too) checked to see whether RAM was being accessed or not (as opposed to ROM or other resources), and if not RAM, the clock was doubled for that access (the 6809 was a completely static design, capable of even stopping the clock). We called that the "1.5x poke". The DRAM refresh was done separately by the controller in between video frames. The always-doubled mode ("2x speed poke") doubled the processor clock regardless, and the video displayed the pixels for whatever memory the processor was accessing when those pixels were scanned. There were usually some binary counters visible on the screen, but most of it was random bits. In this mode the dram was not refreshed by the controller, so processor accesses had to do it, which like I mentioned, as long as the basic interpreter was running your code, would keep it alive. Dang, that was a fun machine.. I think it is still in my attic somewhere. AndyArticle: 125567
Hello, I implemented an ARM1176JZFS on a Virtex 5 FPGA, but it seems that the cache memories of the processor are not behavioring correctly and I must make sure that the caches are turned off for application programs to run correctly on the processor. Just wondering whether it is possible to check whether the processor memories have been mapped correctly onto the block rams on fpga. Also, links and references to processor memory integration on fpga would be helpful if you could kindly point me to. Thanks, //WeiArticle: 125568
Bob Smith wrote: > John Retta wrote: >> Here is a .bat file I use to build from Verilog source to a .bit file. >> I invoke by typing : >> make_xst_FPGA_NAME.bat FPGA_NAME 01 > < snip > > > Thanks, John. I had found your .bat file with google but was > a little intimidated by all the references. I shouldn't have > been -- it wasn't really that difficult. Without worrying about > Makefiles or scripts, here is the list of command required to > build and install the counter to the board for rev# 123..... > > xst -ifn xst.txt -intstyle xflow > ngdbuild -p xc3s200-4ft256 -uc counter.ucf counter > map -k 6 -detail -pr b counter > par -ol med -w counter.ncd counter_r123 > cp counter.pcf counter_r123.pcf > trce -e -o counter_err.twr counter_r123 > trce -v -o counter_ver.twr counter_r123 > bitgen -w -g UserID:55550123 -g DonePipe:yes -g UnusedPin:Pullup > counter_r123 counter_r123 > impact -batch impact.bat > > I used your xst.txt file modified for the FPGA on the Digilent > board. The commands loaded into "impact.bat" I got by running > the download tool in ISE and grepping out "BATCH CMD" from the > log file. I consider this the "hello world" of FPGA so now I > can go back and figure out what each command is doing. > > One final question, what command would make a prom image (.mcs) > for this? > > thanks > Bob Smith Hi Bob - After bitgen, promgen -w -s 512 512 -p mcs -u 0 %1_r%2 There are lots of reasons to use a script approach. The biggest are that your synthesis is now easily portable (give someone the source, the synth script, and the same ise revision of tools, and the bitfile that is generated will diff. Of course this is possible in the gui flow ... just an order of magnitude more difficult. Other point is that the whole synthesis flow is defined with a few small ascii files. Easy for configuration control. Good luck. -- Regards, John Retta Owner and Designer Retta Technical Consulting Inc. Colorado Based Xilinx Consultant email : jretta@rtc-inc.com web : www.rtc-inc.comArticle: 125569
On 29 Okt., 16:33, Petter Gustad <newsmailco...@gustad.com> wrote: > Patrick Dubois <prdub...@gmail.com> writes: > > Yes but then XMD has to run on the lab machine, and I want to avoid > > installing all the Xilinx software on lab computers (which takes > > forever, having to install ISE + EDK + Chipscope + all related > > service packs and IP upgrades). > > I've done a network based programmer, but it can program only. Are the > functions required by ChipScope and the JTAG/UART interface documented > anywhere so that 3rd parties can interface to them? > > Petter > -- no they are not. there has been some reverse engineering done, but its not complete so 3rd parties can not use these services (unless doing RE on the protocol)Article: 125570
Hi there, currently I am designing an FPGA board, featuring two Xilinx Virtex-4 FPGAs. It should be possible to program them with onboard Xilinx Platform FLASH PROMs as well as via JTAG with the IMPACT software. For ease of use and debugging all components should be part of one coherent JTAG chain. Now I'd like to know HOW to connect two FPGAs and two Platform FLASH devices in one JTAG chain so that each FPGA can be programmed through the associated FLASH? How is the identification done (i.e. which FLASH is associated with which FPGA?!)? Thanks alot in advance... Regards ToniArticle: 125571
Patrick Dubois <prdubois@gmail.com> writes: > Yes but then XMD has to run on the lab machine, and I want to avoid > installing all the Xilinx software on lab computers (which takes > forever, having to install ISE + EDK + Chipscope + all related > service packs and IP upgrades). I've done a network based programmer, but it can program only. Are the functions required by ChipScope and the JTAG/UART interface documented anywhere so that 3rd parties can interface to them? 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: 125572
I think we should give any new poster more than only a single chance to make a fool of himself, before we start giving funny non-advice. Peter Alfke On Oct 29, 4:13 am, MikeShepherd...@btinternet.com wrote: > >Hello VLSI Engineers. > > > Its is true that FPGA boots its program from an external PROM. > >How external eproms are connected to FPGA. Is there any requirement in > >making PCB with FPGA. > > >Thanks > > First make sure you have a stable 6.3V AC heater supply (50Hz or 60Hz > is fine). The configuration bit stream is modulated onto this using > QPSK (http://en.wikipedia.org/wiki/Phase-shift_keying). > > You don't need HT during configuration, but a negative grid bias will > keep down leakage currents.Article: 125573
On 29 oct, 11:28, "Toni Merwec" <mistertorp...@freenet.de> wrote: > Hi there, > > currently I am designing an FPGA board, featuring two Xilinx Virtex-4 FPGAs. > It should be possible to program them with onboard Xilinx Platform FLASH > PROMs as well as via JTAG with the IMPACT software. For ease of use and > debugging all components should be part of one coherent JTAG chain. > > Now I'd like to know HOW to connect two FPGAs and two Platform FLASH devices > in one JTAG chain so that each FPGA can be programmed through the associated > FLASH? How is the identification done (i.e. which FLASH is associated with > which FPGA?!)? > > Thanks alot in advance... > > Regards > > Toni The two proms can be considered as one big prom twice as large. No prom is exclusively dedicated to one FPGA in particular. For example, the bit file for FPGA #1 might take 2/3 of the first prom and the bit file for FPGA #2 might be half in prom #1 and half in prom #2. This is handled for you when you create your mcs files for the proms. For the hardware connections, refer to the platform flash guide, page 18 http://direct.xilinx.com/bvdocs/publications/ds123.pdf PatrickArticle: 125574
Antti wrote: > On 27 Okt., 12:51, Walters <hps...@gmail.com> wrote: >> Assuming a scenario that I have a bit file built for a particular >> FPGA, but i don't have a that FPGA device to download it to, Is there >> a way to check it works on that particular FPGA? >> >> Thanks in advance >> Water > > no > I'm not sure that I would answer no to this universally. The bitstream format should enable you to determine if was made for a Xilinx, Altera or Lattice device. In the case of Xilinx devices, you should also be able to determine what family and die it was intended for, but not the package, by parsing the bitstream and looking for specific fields. Even, the bitstream file size itself should be a good indicator of what device it should work. Now, whether or not it actually works is a completely different question. Ed McGettigan -- Xilinx Inc.
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