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
I wanted to generate a set of .MCS files for a Xilinx XC2V3000
design, the board uses three XC18V04 PROMs in serial mode, the PROMs
and the FPGA are on the same chain. I entered the prom config into
Impact in File Generation mode, but my design is small (bit file is 1.5
MB in size), so the utility informed me that only one .MCS file is
actually generated. Now back in JTAG mode, when I initialize the JTAG
chain, it asks me to associate a file with each device, so I can put in
the first MCS file into the first PROM, but what about the others? Can
I just BYPASS them or do I need to do something else to make this work?
I'm a bit paranoid about burning up the device, so I didn't want to try
anything without asking here first. Thanks!
-Jim
Article: 86576jimgeorge at gmail dot com wrote: > I wanted to generate a set of .MCS files for a Xilinx XC2V3000 > design, the board uses three XC18V04 PROMs in serial mode, the PROMs > and the FPGA are on the same chain. I entered the prom config into > Impact in File Generation mode, but my design is small (bit file is 1.5 > MB in size), so the utility informed me that only one .MCS file is > actually generated. Now back in JTAG mode, when I initialize the JTAG > chain, it asks me to associate a file with each device, so I can put in > the first MCS file into the first PROM, but what about the others? Can > I just BYPASS them or do I need to do something else to make this work? > I'm a bit paranoid about burning up the device, so I didn't want to try > anything without asking here first. Thanks! > -Jim > Yes. Put the generated MCS file into the PROM closest to the FPGA and skip the other PROMs. Should work just fine. -- ----------------------------------------------- Johan Bernspćng, xjohbex@xfoix.se Research engineer Swedish Defence Research Agency - FOI Division of Command & Control Systems Department of Electronic Warfare Systems www.foi.se Please remove the x's in the email address if replying to me personally. -----------------------------------------------Article: 86577
Hi Dave, for the DVI digital Interface, you will need an additional interface chip, ie. the TI TFP 401, because the DVI LVDS is a little bit special. I have built a DVI to LVDS (display-panel) converter, without buffering the complete image. It was a little bit tricky to keep the dvi and lcd panel synchronized, because I only use a fifo (that can take 4 lines) as buffer. If you want to do image processing, you probably need the entire image inside ram, so your ram must be fast enough to write and read an image in real-time. A while ago I did this calculation and I figured, that a DDR400 will do it for that refresh rate and resolution. regards, BenjaminArticle: 86578
Pierre schrieb: > Hello > > I use a Virtex-II Pro with PowerPC at 300 MHz, 8 kB IOCM, 32 kB DOCM and > external 32 MB SDRAM (connected on PLB ) > > When I read 10 times 32 MB on my SDRAM, that takes 3.7'' and when I write > the 320MB on the SDRAM it takes 9.6'' without burst support and 6" with > burst support. > > Did someone knows why the read rate is 85 MByte/s and 53 MB/s(maximum ) for > writing? For one thing, the PLB runs at 100MHz maximum frequency, even if the processor runs much faster. So that's one limitation, only a third of the maximum rate. Another is the data bandwidth on your SDRAM: is it really 64 bit or only 32bit? On most eval boards it's 16 oder 32bit, so that's another factor of 2 or 4 less (if it's SDR-DRAM). Then you have to think about refresh and all that. Even if you do bursts, the controller has to refresh the memory regularly, so that takes away even more performance. Then you have to consider that the PLB is a bus structure. So even if there's only one component on the bus, there's always a few clock cycles for bus arbitration when you start a transfer. Then it depends on your program. For example, if you use a for-loop to write to and read from every address one after another, then what you actually do is single 32bit-accesses, meaning that for each 32bit-data-word you read there's bus arbitration, DRAM latency, maybe you have to wait a few clock cycles because the DRAM is currently refreshing and so on. This added up maybe gives you as much as 8 clock cycles (at 100MHz) to read a mere 4 bytes, multiplied by 3 gives you 24 CPU clock cycles (at 300MHz) for one single access, if all goes really bad, and there you have your ~50MB/s, assuming your RAM is a 32 bits wide SDR-DRAM. I don't know how bursts are handled in the DDR-core for the PLB, so I can't comment on that. But in DDR-SDRAM burst can only be as longs a 8 ticks, then the whole SDRAM-latency-thing starts again. Neither can I give any useful guesses as to why writing should be slower than reading, could be some issues with caching. In cases like this it could also be useful to debug the generated ELF-file to see how your code maps to assembly instructions. cu, SeanArticle: 86579
In article <1120134238.598357.287620@g14g2000cwa.googlegroups.com>, jimgeorge@gmail.com says... > I wanted to generate a set of .MCS files for a Xilinx XC2V3000 > design, the board uses three XC18V04 PROMs in serial mode, the PROMs > and the FPGA are on the same chain. I entered the prom config into > Impact in File Generation mode, but my design is small (bit file is 1.5 > MB in size), so the utility informed me that only one .MCS file is > actually generated. Now back in JTAG mode, when I initialize the JTAG > chain, it asks me to associate a file with each device, so I can put in > the first MCS file into the first PROM, but what about the others? Can > I just BYPASS them or do I need to do something else to make this work? > I'm a bit paranoid about burning up the device, so I didn't want to try > anything without asking here first. Thanks! > -Jim > > I think you must have made some other mistake. Having a small design and not using the whole FPGA does not give you a smaller configuration file. If the bit file is for a XC2V3000 then it should hold always the full 10.494.368 bits and will never fit in a single XC18V04. You can check this in IMPACT after the PROM generation, where you see in the upper part the chain of PROMs and the target with the bit file. Go with the mouse over the single devices and a yellow window should pop up with information about the contained bits and bytes. Are you shure you did specify a chain of 3 XC18V04 PROMs when generating the MCS-files? Hope this helps Klaus FalserArticle: 86580
You should be able to upload bit files to single elements of JTAG chain. So, yes, you can skip the ones you do not need. As someone has already mentioned, the file size is a defined number of bytes for each FGPA type.Article: 86581
In article <MPG.1d2e0eb07a5eff02989690@news.inet.it>, kfalser@durst.it=20 says... > In article <1120134238.598357.287620@g14g2000cwa.googlegroups.com>,=20 > jimgeorge@gmail.com says... > > I wanted to generate a set of .MCS files for a Xilinx XC2V3000 > > design, the board uses three XC18V04 PROMs in serial mode, the PROMs > > and the FPGA are on the same chain. I entered the prom config into > > Impact in File Generation mode, but my design is small (bit file is 1.5 > > MB in size), so the utility informed me that only one .MCS file is > > actually generated. Now back in JTAG mode, when I initialize the JTAG > > chain, it asks me to associate a file with each device, so I can put in > > the first MCS file into the first PROM, but what about the others? Can > > I just BYPASS them or do I need to do something else to make this work? > > I'm a bit paranoid about burning up the device, so I didn't want to try > > anything without asking here first. Thanks! > > -Jim > >=20 > >=20 > I think you must have made some other mistake. > Having a small design and not using the whole FPGA does not give you a=20 > smaller configuration file. > If the bit file is for a XC2V3000 then it should hold always the full=20 > 10.494.368 bits and will never fit in a single XC18V04. >=20 > You can check this in IMPACT after the PROM generation, where you see in= =20 > the upper part the chain of PROMs and the target with the bit file. > Go with the mouse over the single devices and a yellow window should pop= =20 > up with information about the contained bits and bytes. >=20 > Are you shure you did specify a chain of 3 XC18V04 PROMs when generating= =20 > the MCS-files? >=20 > Hope this helps > Klaus Falser >=20 Since Johan Bernsp=E5ng said it will work by using only the first PROM I=20 have to add that my experience is limited to Spartan-3, where I have=20 seen always bit-files and MCS-files of the same (full) size. Should this be different for Virtex-2 I apologize for having given a=20 wrong information. Best regards Klaus FalserArticle: 86582
Which makes it a little embarrassing when it catches you out, I guess. ;-) Syms. "Austin Lesea" <austin@xilinx.com> wrote in message news:d9v22s$1vs1@cliff.xsj.xilinx.com... > Ray, > > Nice thing about and old well known behavior. It is old, and well known! > > Austin > > Ray Andraka wrote: > >> Austin Lesea wrote: >> >>> Marc, >>> >>> Contact your FAE for information. >>> >>> The information packet on this subject states the shift in Vt is >>> reversable. >>> >>> Austin >> >> >> As does everything I found in general on NBTI by searching google with >> "NBTI" >>Article: 86583
I assume in your board, push button is tied to some pin on FPGA. In constraints file (.UCF), specify that input PORT of your top level Verilog module, corresponding to your pushbutton SIGNAL, should be connected to specific input PIN of FPGA. Example in constraints file NET "prtPUSH_BUTTON1" LOC = "P17"; You'll have to determine location LOC from board schematics. Sometimes they'll print it right on surface of the board. Look around pushbutton. Hope that helpsArticle: 86584
plz touch me more detail if u need the following ip. brahms_view@yahoo.it ******************************=AD******************************=AD**** 1>Ethernet MAC: 10M/100M/1G/10G 2>USB:1.0/2.0/OTG/PHY/software stack 3>JPEG2000 4>PCI/PCI-X/PCI-AHB 5>SATA 6>SDMMC 7>1394 and PHY 8>mp3 9>motion jpeg 10>ARC605 DSP 11>ARM PL110(LCD controller)/PL080(DMA controller)/PL176(Universal Memory Controller)/PL130 (smartcard)/ARM9/ARM11 12>8051/CAN/Z80/6811/AMBA/PCMC=ADIA/T1E1/IEEE/1284/G711/G726/80=AD86/80186/= 68000 13>MPEG4 14>802.11a/b/g 15>PCI-Express and PHY ******************************=AD******************************=AD**** note: 1> all core are silicon proven and verilog 2> they are not free or exchange.Article: 86585
Hello, Is there any way of converting an .mcs file into a bit file....in Xilinx FPGAs Any help would be greatly appreciated... Regards, - ShaileshArticle: 86586
Since you admitted last time that they were stolen, why do you think that anyone would take you up on this offer? http://groups-beta.google.com/group/comp.arch.fpga/browse_thread/thread/a7d741bf6616c879/2cdbe34225753d86 Ed Minimum wrote: > plz touch me more detail if u need the following ip. > > > brahms_view@yahoo.it > **************************************************************** > 1>Ethernet MAC: 10M/100M/1G/10G > 2>USB:1.0/2.0/OTG/PHY/software stack > 3>JPEG2000 > 4>PCI/PCI-X/PCI-AHB > 5>SATA > 6>SDMMC > 7>1394 and PHY > 8>mp3 > 9>motion jpeg > 10>ARC605 DSP > 11>ARM PL110(LCD controller)/PL080(DMA controller)/PL176(Universal > Memory Controller)/PL130 (smartcard)/ARM9/ARM11 > 12>8051/CAN/Z80/6811/AMBA/PCMCIA/T1E1/IEEE/1284/G711/G726/8086/80186/68000 > > 13>MPEG4 > 14>802.11a/b/g > 15>PCI-Express and PHY > **************************************************************** > note: > 1> all core are silicon proven and verilog > 2> they are not free or exchange. >Article: 86587
Hi Peter, Thank you for your great support, now am able to run standalone applications on both PPC's simultaneously and trace the PC. Now I am trying to run linux on 1 st PPC and standalone program on 2nd ppc. Iam facing one problem, linux booting hangs in middle, the reason I suspect is FIFO collects the instructions adresses , when the full flag is raised ,my module raises DBGC405DEBUGHALT pin to '1' which breaks the processor execution, after collecting FIFO data through 2nd PPC , my logic places DBGC405DEBUGHALT in '0', I found here my 1 st PPC doesn't runs (expected to run Linux)...it just hangs. I get message processor stopped at adress .... do I need to take care of something else ...to start and stop processor execution under linux...apart from raising and lowering DBGC405DEBUGHALT signal...? thanks for your time and consideration,plz do support me to resolve this... regards JagguArticle: 86588
Klaus Falser wrote: > Since Johan Bernspćng said it will work by using only the first PROM I > have to add that my experience is limited to Spartan-3, where I have > seen always bit-files and MCS-files of the same (full) size. > Should this be different for Virtex-2 I apologize for having given a > wrong information. > > Best regards > Klaus Falser > Well, you are absolutely right about that. The MCS-file should be larger than one XC18V04 PROM. I should've thought about that. =) However, if the board has more PROMs than needed for a specific device (which the board I'm using at the moment has) then it is possible to program the PROMs the way I mentioned earlier... Sorry for the confusion.. /Johan -- ----------------------------------------------- Johan Bernspćng, xjohbex@xfoix.se Research engineer Swedish Defence Research Agency - FOI Division of Command & Control Systems Department of Electronic Warfare Systems www.foi.se Please remove the x's in the email address if replying to me personally. -----------------------------------------------Article: 86589
On Thu, 30 Jun 2005 15:11:17 +0200, Sean Durkin <smd@despammed.com> wrote: >Pierre schrieb: >> Hello >> >> I use a Virtex-II Pro with PowerPC at 300 MHz, 8 kB IOCM, 32 kB DOCM and >> external 32 MB SDRAM (connected on PLB ) >> >> When I read 10 times 32 MB on my SDRAM, that takes 3.7'' and when I write >> the 320MB on the SDRAM it takes 9.6'' without burst support and 6" with >> burst support. >> >> Did someone knows why the read rate is 85 MByte/s and 53 MB/s(maximum ) for >> writing? I have no knowledge of this implementation, but common sense should tell you that reads are inherently slower than writes when both are optimally implemented... For a write, you can throw the address & data at the RAM at the same time, and let the RAM and controller get on with it while you go do something else (other than reading from the same RAM). For a read, you have to wait until the RAM gives you the data you asked for. e.g. in a processor running from a local cache, the write will be happening in parallel with the fetching of the next instruction(s), but the read must wait for the data to come back from the RAM.Article: 86590
OK, thanks all, I found the mistake (this happens because Impact seems to maintain several "current directory" entries internally, and I was picking up a bit file for an XC2V1000) BTW, this is out of curiosity, if I have a board with an FG676 footprint, designed to use either an XC2V3000-FG676 or an XC2V1000-FG456, and I have three XC18V04 PROMs, what should I do if I have an XC2V1000-FG456 soldered onto the board? I'm guessing Johan's suggestion may work then, but correct me if I'm wrong. Thanks!Article: 86591
All Does anyone know whether with aurora framing mode you HAVE to assert end_of_frame ever (I can see why you might want it but I don't). It seems that the only point from the aurora cores perspective is that the data_remainder flags are active. regards KatherineArticle: 86592
Nick, No one has asked for what you mentioned. Probably for the reasons you mention. My biggest problem is that whatever we do for security needs to be so incredibly well thought through, that adding something in the next generation becomes a real issue. An added feature may bring on a whole new set of issues that have to be thought through again! I am happy that I received a response from a professor to supply a V2 Pro security pcb. One by one I will get these boards out there into the hands of graduate students looking for fame (if not fortune). AustinArticle: 86593
Marc, The "degradation lock-in" at higher temperatures for NBTI must be something that happens beyond 125C. We do not see any signs of irreversable Vt shift. Then again, how can they tell it isn't hot carrier injection (HCI)? The two causes of Vt shift are similar, but are from different physical processes. Austin Marc Randolph wrote: > Ray Andraka wrote: > >>Austin Lesea wrote: >> >> >>>Marc, >>> >>>Contact your FAE for information. >>> >>>The information packet on this subject states the shift in Vt is >>>reversable. >>> >>>Austin >> >>As does everything I found in general on NBTI by searching google with >>"NBTI" > > > Howdy Ray, > > Google had found me a few mentions of it sometimes being irreversable > under certain conditions - hence the question. Perhaps I'm > misunderstanding it, or it doesn't apply to the problem that the V4's > have. Here's the best reference: > > http://www.reed-electronics.com/semiconductor/article/CA602829?spacedesc=webex > > Best regards, > > Marc >Article: 86594
Amr, No apology necessary. Some further notes on SOI (that I can share): In order to remove or minimize the variation in timing in SOI from the floating wells, one needs to add taps. The addition of the taps to every well, results in the area increasing dramatically. That makes the FPGA cost too much, hence the process is not commercially viable. This has been one of the reasons for its non-use. SOI is also heralded as being more robust for atmospheric neutrons. But it is only twice to five times better than bulk substrates. A factor of two to five is not considered good enough to warrant its use. SOI also does little to increase the LET for heavy ion strikes, unless the design has a lot of taps to collect charge (which adds area again). Xilinx pioneered a major process development with the introduction of triple oxide (now running in two completely different fab lines: UMC and Toshiba). This allowed us to reduce the leakage current of our devices substantially, as well as provide an almost two times better SEU time to upset (over the previous generation technology, or other 90nm FPGA competition). We do consider process techology where it can provide the most benefit. In this case, SOI would increase area, not do anything for leakage, and cause all kinds of other problems. Triple oxide solves a number of known problems, by using masks and steps that are standard to the semi industry. Austin Amr Ahmadain wrote: > Peter and Austin, > > Again, please do accept my apologies. I asked this question just out of > curiosity and maybe out of naiveness !! > > Amr >Article: 86595
I've seen people use an mcs2hex utility then a hax2bin. The Xilinx tools *can* natively produce a .bin file which is the way I've been doing things since I discovered the option. "Shai" <shailesh.radhakrishnan@gmail.com> wrote in message news:1120139780.286445.107720@z14g2000cwz.googlegroups.com... > Hello, > > Is there any way of converting an .mcs file into a bit file....in > Xilinx FPGAs > > Any help would be greatly appreciated... > > Regards, > - ShaileshArticle: 86596
Shai wrote: > Hello, > > Is there any way of converting an .mcs file into a bit file....in > Xilinx FPGAs > > Any help would be greatly appreciated... Ummmm, PROMgen? Ummm, the last step in the ISE GUI? Look under "Generate Programming File." The second option is "Generate PROM, ACE or JTAG file." =aArticle: 86597
Andy Peters wrote: > I guess this is more of a Xilinx question than a VHDL question. > Anyways, once again, I find myself wanting to set the value of a > generic on the top-level of my chip design from the synthesis tool -- > XST, in this case -- either from the GUI or from the command line. > > I know I can do this in Precision ... > > So what's the magic incantation? > > Thanks, > -a > (devel (at) latke dot net) Replying to myself ... I received the following from Xilinx Support: ----------------------------------------- ----------------------------------------- "*** EMAIL OUT AND STATUS CHANGE 06/30/2005 03:08:55 xud Action Type: External email Send to: [External Contact] Dear Andy Peters, Thank you for choosing Xilinx Customer Support! My name is Sally Dong and I will be helping you to resolve your issue. I can be reached via email at External Contact. I have tried searching for the XST function of changing generics at synthesis time and I can not find such one. The XST may not support it. Please let me know if this did not address your concern, or if you have any questions on this issue. ----------------------------------------- ----------------------------------------- So XST doesn't support a language feature that all of the other synthesis tools (including, BTW, Altera Quartus') support and in most cases have supports since they started using FPGAs for logic synthesis? I'm rather amazed that few people use this feature. Hey, Peter and Austin -- kick someone's ass over at the XST Features Department. -a PS: for my current problem, my solution is to simply create a stupid little outputs-only entity; each output corresponds to the generic I wish to set. If I have two version of my design, I have two different files, each containing a different version of the entity. The entity is given the same name in both files, so when it's used to build the design, nothing has to change in the main sources, and my XST script for each version uses only one of the two files.Article: 86598
Does anybody know where I can buy FPGA PC104 development board with FPGA that have embedded PLL, syncronius 32Megabit (desired organization 32bit x 1M) SRAM device and at least 70 I/O. Instead of SRAM it can be Dual port RAM (desired organization 32bit x 1M) Regards, AmirArticle: 86599
I usually get this "Send error report... " error message from bitgen when there is a write lock on the bit file that I want to write to (using -w option). After multiple overwrites to the bit file, the bit file somehow gets a write lock. Choosing a different bit file removes that error. -Love
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