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
That's an interesting thought. But how will you record which CLBs/LEs are defective? At one bit per CLB, you're approaching 100Kbits of programmable data. And you need to store this at test time, via one-time programmable fuses or NV memory of some sort. How much impact will you have on your test times? - Paul "Jerry" <nospam@nowhere.com> wrote in message news:v8i3rii71fhq6a@corp.supernews.com... > With scan one can get above 99% fault coverage so detecting defective logic > shouldn't be a problem. > > > Otherwise if there are defects that are detected during the manufacture > > process, would it be possible to store a defect list that could be > retrieved > > by the tools ? > > Yes thats what I'm getting at. During test the defective CLBs and routes are > stored in on chip memory. At power on > time the on chip router takes the defective list in to consideration to do > the palce and route. > > Maybe whats stored is the results of the Xilinx mapping process. > > "Robert Finch" <robfinch@sympatico.ca> wrote in message > news:Bg6ia.1407$DD6.332428@news20.bellglobal.com... > > > place and router could map around defective silicon thereby boasting > > yield. > > > Anyway its a thought, maybe a thread, maybe > > > a product? > > > > > > > How would it be possible to know whether or not there is a defect in the > > FPGA until the application is actually run ? > > > > Surely in a multi-mega gate FPGA it's not possible to test every possible > > combination of programming pattern that could be used ? > > > > Otherwise if there are defects that are detected during the manufacture > > process, would it be possible to store a defect list that could be > retrieved > > by the tools ? > > > > Rob > > > > > > > >Article: 54051
Jerry wrote: > > With scan one can get above 99% fault coverage so detecting defective logic > shouldn't be a problem. > > > Otherwise if there are defects that are detected during the manufacture > > process, would it be possible to store a defect list that could be > retrieved > > by the tools ? > > Yes thats what I'm getting at. During test the defective CLBs and routes are > stored in on chip memory. At power on > time the on chip router takes the defective list in to consideration to do > the palce and route. That's still a layer of complexity that's not needed. Altera claim redundancy - so are doing something. They also noted it has a significant die impact, then go on to say that's offset by yield gains, so they then claim 'a smaller effective die size'. One simple way to implement that is with a row bypass scheme, where a swap mux allows a spare, good row to replace a failed one. It needs a laser-fuse or similar at-die-test method to set the MUX, which is only needed on a fail. ( so good chips test faster ) Once done, it looks 100% identical in logic, so does not need fix-adaption. -jgArticle: 54052
How about just allowing the design tools to run defect tests on an FPGA ? That way nothing in the FPGA would have to change? Does production testing check the entire FPGA or does it quit once a defect is detected ? Is there a way to tell how defective the part is ? It wouldn't be that useful for production, but for prototyping it might be handy. It seems a bit of waste to throw out FPGA's when there's only a single bad route or LUT, when a lot of the time that resource doesn't even end up getting used anyway. RobArticle: 54053
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:Z2%ha.215$Iz6.14915853@newssvr14.news.prodigy.com... > In order to maximize access speed I'm thinking of using both edges of the > uP's WE pulse to run these SelecRAM ports. The idea is to capture the data > byte on the leading edge and use the trailing edge to increment the address > counter that is driving the SelectRAM block. With this, all the uP has to > do is present new data and pulse WE until it fills the memory bank. > I'm looking for feedback on this technique. Any problems? Any reason for > not taking this approach? Any other approaches that might warrant > consideration? I've used this kind of "autoincrement" mechanism successfully in the past, but you must pay attention to the details. I'm guessing that your FPGA system clock is way faster than the CPU I/O write cycles, so it's reasonable to run some kind of state machine inside the FPGA, controlled by activity on WE. That way you can schedule your memory writes and address updates in whatever way is most appropriate. You could even do address pre-increment (instead of post-increment) if you wanted. Look out for data setup and hold times relative to WE edges. Like I said, it's all in the detail. Watch out, too, for the comparatively long delays through FPGA I/Os - particularly if you're relying on timing relative to the CPU clock, and you generated that CPU clock inside the FPGA. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 54054
Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0303311512.2a51334e@posting.google.com>... > "Garrett Mace" <g.ryan@macetech.com> wrote in message news:<v8d6qmog6fr357@corp.supernews.com>... > > Simple question, for those who've done it before: > > > > How many I/O's are required to implement an interface to PLX9054? > > > > I'm running pretty tight on I/O right now, and this may not be a high-volume > > project, so the customer may prefer $18 extra per board as opposed to $2000 > > for a Xilinx core (still fuzzy on that, you can use and sell the $2000 IP on > > one project, right?). > > > > I can get by with the ~50 pins needed for in-FPGA PCI; do I need much more > > than that to use a PLX chip? > > Well, for starters, you could look at the PLX documentation and count > how many pins are used by the local bus. > > You have to choose the PLX local bus mode, either "C" (non-muxed > address and data bus) or "J" (muxed address and data bus). There's > another dozen or so control lines you'll need. If you only require an > 8-bit local bus, you can save some pins. If you need all 32 data > pins, and need to decode all 32 address bits, AND don't want to use > the "J" mode (does ANYONE use the "J" mode?), then you'll need maybe > 80 pins. > We use J mode exclusively in all our newer designs. We feel really sorry that we used C mode earlier. For the systems like ours which have nothing, but FPGA, on the PLX local bus, C mode is pure wast of pins with zero advantage. The complete J mode 32bit interface (no support for local bus mastering) requires only 41 pins in the FPGA - LAD[31:0], LBE[3:0], ADS#, BLAST#, LW/R#, READY# and LCLK. DT/R# and DEN# are not necessery. If you don't need byte/word wide writes, you don't have to connect LBE[3:0]. For the demand-mode DMA - connect DREQn#. You can do fine without DACKn#. For the interrupt to host - connect LINT#. + There is a way to configure your FPGA with PCI9080/54/54 signals witout PROM and additional PLDs. Think a little and you would find it yourself. I'm not going to tell you how :)Article: 54055
Kevin, thanks very much! this is exactly what I was after!!! Mike "Kevin Neilson" <kevin_neilson@removethistextattbi.com> wrote in message news:w70ia.321601$sf5.300503@rwcrnsc52.ops.asp.att.net... > Here are the methods I use: > > o Do a 'print screen' to copy the image to the paste buffer. Then you can > paste it into Word. This is quick, but the image is big. > > o Do the same thing, but paste it into a program like Paint, and then you > can crop it and save it as JPEG if you wish. > > o Use the Adobe Acrobat (the one you have to buy) PDF distiller function. > You print the image, but use the PDF Distiller instead of a printer driver. > The result is a small, clean, B&W image that you can put in docs or just > print out by itself. > > -Kevin > > "Michael Nicklas" <michaeln@nospam.slayer.com> wrote in message > news:b6927n$6sp$1$8300dec7@news.demon.co.uk... > > Hi > > > > does anybody know if there is a way to export the wave file created during > a > > simulation to a Word document or other package instead of just taking a > > screen capture?? > > > > I honestly cant seem to find anything about this in the pdf documentation > or > > release notes etc. > > > > Thanks in advance. > > > > -- > > Cheers! > > > > Mike > > > > > >Article: 54056
Hello Sirs/Friends, I am designing a PCI core in which i have parity checker module. I wanted to know how can design a parity checker which can meet the PCI specification. I will have registered AD[31:0] and C/BE[3:0] signal whose parity should be checked and PAR signal come in the next clock and i have signal the PERR the next clock itself. How to design this. Waiting for ur reply PraveenArticle: 54057
A+B+C can't be done with one LUT deep logic unless C is a single bit carry in,
in which case Altera does this too. The advantage Xilinx offers on arithmetic
is that it can handle adds with more complex controls on them than Altera can
because they have a 4 input LUT available for the sum function, where Altera has
a 3 input LUT. Altera adds some dedicated logic around the LUT in Cyclone to
permit an add-subtract or an add-mux, which improves the usability relative to
older Altera devices.
sanjay wrote:
> Hi Matt,
> what Ray says is perfect.
> There is no competition to Spartan-IIE when it comes to arithmatic
> operations.
> Apart from SRL [ which according to Ray is biggest plus point of Xilinx ],
> LUT can be configured as Distributed RAM which may be useful to you.
> This you can't do with Cyclone.
> Also 3 operand arithmatic Function [Sum = A+B+C] goes in one Logic Block in
> Spartan-IIE, which takes two Logic Blocks with Cyclone.
> Apart from that Spartan-II E has Mult-AND for doing Fast Multiplications.
>
> So I don't think there can be a any substitute for Spartan-IIE for your app.
> --Sanjay
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 54058(i meant to say J mode *was* attractive...obviously) -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =-----Article: 54059
OK...this is bad. Switch ISP's today and now my news server's got a stupid banner after every post. "Garrett Mace" <g.ryan@macetech.com> wrote in message news:3e8999b4$1_4@corp.newsgroups.com... > (i meant to say J mode *was* attractive...obviously) > > > > > -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- > http://www.newsfeeds.com - The #1 Newsgroup Service in the World! > -----== Over 80,000 Newsgroups - 16 Different Servers! =----- -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =-----Article: 54060
John, Martin, Linux is already ported for Virtex-II Pro including device drivers for our most often used peripherals. The Linux distribution is available through licenses from MontaVista (http://www.mvista.com) or from the open source repository in the linuxppc_2_4_devel tree (http://www.penguinppc.org). The same drivers can also be used for any uClinux port for MicroBlaze. John, if you don't mind, keep me posted on how the uClinux port goes. - Peter John Williams wrote: > Martin wrote: > > > Also I'm looking for an operation system for the hardcore PPC 405 in > > the virtex 2 pro. > > Is there an open source projekt which have ported linux for the PPC > > for the virtex 2 pro? > > Hi Martin, > > Does the PPC in V2pro have an MMU (I think it does?)? If so, you should > be able to get standard PPC linux up and running pretty quickly. This > won't be like installing linux on a PC from a red hat distro, but it's > feasible to get something up and running reasonably quickly. You'll > have to do all the hardware interfacing stuff (interrupts, MMU setup etc > etc). At least the deep kernel source should work unchanged. > > If it does not have an MMU, then you'll need to look into uClinux > (www.uclinux.org). There is no PPC_nommu branch in the uclinux source, > so you'd have to do the port yourself. Not trivial, but a great > learning exercise. I'm busy porting uClinux to the microblaze - I've > just about got a complete kernel image ready to bring into the debugger! > > The two books you simply *must* have for this project are "Understanding > the Linux Kernel" by Bovet & Cesati, and "Linux Device Drivers" by > Rubini & Corbet, both published by O'Reilly. The 2nd one is available > freely as PDFs from somewhere on O'Reailly's website. > > Regards, > > JohnArticle: 54061
already5chosen@yahoo.com (Michael S) wrote in message news:<f881b862.0304010021.1e95769b@posting.google.com>... > We use J mode exclusively in all our newer designs. We feel really > sorry that we used C mode earlier. For the systems like ours which > have nothing, but FPGA, on the PLX local bus, C mode is pure wast of > pins with zero advantage. > The complete J mode 32bit interface (no support for local bus > mastering) requires only 41 pins in the FPGA - LAD[31:0], LBE[3:0], > ADS#, BLAST#, LW/R#, READY# and LCLK. > DT/R# and DEN# are not necessery. > If you don't need byte/word wide writes, you don't have to connect > LBE[3:0]. > For the demand-mode DMA - connect DREQn#. You can do fine without > DACKn#. > For the interrupt to host - connect LINT#. Now that I've thought about it, "J" mode is probably perfect if you are implementing an SDRAM controller in the FPGA. It boils down to: "do I need to have the local bus give me an address every cycle?" > + There is a way to configure your FPGA with PCI9080/54/54 signals > witout PROM and additional PLDs. Think a little and you would find it > yourself. I'm not going to tell you how :) ummm, use an ISP CPLD? Seriously, tho', I guess you would use the FPGA's parallel config mode. --aArticle: 54062
Austin Lesea <Austin.Lesea@xilinx.com> wrote > I think you can make a good educated guess at what the core voltage is > for 90 nm, however. You fab with IBM, so it looks like 0.7V to 1.3V, probably 1.0V ??? http://www-3.ibm.com/chips/products/asics/products/stdcell.html Kolja SulimmaArticle: 54063
"Tony McKay" <tonym@gallagher.co.nz> ha scritto nel messaggio news:927d5a5c.0303311221.29028391@posting.google.com... > > 'f2407 is a fixed point DSP and has something between > > 100 and 200 MIPS, > > while c67xx family is floating point and some models go > > beyond 2000 > > MFLOPS. They aren't exactly equivalent. ;) > > Its worse than that, the 240X are 40MIPS tops. You are right, I was thinking to the 28x family instead of 24x... > Mybe the 240X could be used with the 67XX. The 2402 has 6 > PWMs and the > 2407 has 12 as well as heaps of other peripherals that > maybe handy, > like I/O, in-circuit writable flash, and serial commms. > This may free > up the 67XX to do other tasks. If cost is a big factor > then mybe a > cheap micro to run the peripherals? You could send it a > command then > leave it to accomplish its job. There is a big drawback: while the FPGA development tools are free, developing for 24x will cost you $4000 (Code Composer Studio for 2000 family) plus $2000 (JTAG interface for emulation). -- LorenzoArticle: 54064
Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0303311531.415ad136@posting.google.com>... > > Your comparison, > > if (fstate >= 50) > > may not do what you want. I would guess that fstate is not declared > an integer. However, Verilog helpfully considers the constant 50 to > be an integer, which is a 32-bit signed value. What happens is that > fstate is sign-extended to a 32-bit integer, and a bit-for-bit > comparison is made. While it is possible that some tool does this, it would be wrong to do so. The IEEE Verilog-1995 standard does not specify what happens with mixed signed and unsigned values, but Verilog-XL, the de facto standard, does not do it this way. The IEEE Verilog-2001 standard isn't terribly clear in this area, but it tries, and the intent is known. If fstate is unsigned (not declared as an integer or a signed reg or wire), then both operands will be converted to unsigned before any width extension. So fstate will be zero-extended to 32 bits, not sign-extended. Then an unsigned compare will be done. There will be some unexpected results for signed arithmetic under the Verilog-2001 rules. But they will be from converting everything to unsigned whenever there is anything unsigned in the expression, not from unexpectedly converting things to signed. It is still good advice to avoid mixing signed values (such as unsized decimal constants) and unsigned ones. The rules in the standard for such situations are difficult to understand, both for users and for tool implementors. Even if we get the wording in the standard clarified, it still won't match what many people will expect based on experience with other languages.Article: 54065
"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message news:b6cqqa$mof$1@news.tu-darmstadt.de... > Ralph Mason <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote: > : I have this device configured to use the 'low power' setting for all the > : macrocells. > > : I am using webpack and did this by right clicking on 'Implement Design', > : Properties, Basic, Macrocell Power Setting. > > : However I need 4 of the Macrocells in STD power mode (they drive leds, and > : won't in Low power mode) > > : How can I go about overriding the default setting for just those macrocells? > : Is there a vhdl attribute I can use on the pin? > > Look for the constraint guide. PWR_MODE should be the option that you want. Hmmmm.... I have done this and the chip viewer shows the output macrocells for the leds as STD power, and all the others as low. Exactly as expected. However the leds still don't work (they work if I set the powermode of the whole device to STD as above) - does it matter that a STD power marco cell is driven by a low power one? Does anyone have any ideas? Thanks RalphArticle: 54066
Ralph Mason <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote: : I have done this and the chip viewer shows the output macrocells for the : leds as STD power, and all the others as low. Exactly as expected. : However the leds still don't work (they work if I set the powermode of the : whole device to STD as above) - does it matter that a STD power marco cell : is driven by a low power one? : Does anyone have any ideas? The macrocells are inside the chip. The LEDs are drive by the output. Show us how you drive the LEDS. Only if you clock the LEDS well above perhaps 20 MHz, the powersetting of the Makrocells will affect the LED drive capability. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 54067
Peter Ryser wrote: > John, Martin, > > Linux is already ported for Virtex-II Pro including device drivers for our > most often used peripherals. The Linux distribution is available through > licenses from MontaVista (http://www.mvista.com) or from the open source > repository in the linuxppc_2_4_devel tree (http://www.penguinppc.org). > > The same drivers can also be used for any uClinux port for MicroBlaze. > > John, if you don't mind, keep me posted on how the uClinux port goes. Status is as follows: I can currently boot a primitive uClinux kernel on microblaze. Memory management, kernel threads and scheduling are all there. The uClibc C libraries are ported and more or less ready to go. Immediate development objectives are elf2flt and bin_flt loader support for userland executables. A bit more tweaking is required to get a root filesystem (romfs) up and running. Once these are done, we can boot a kernel properly and launch a shell etc. This will mark the end of the first stage of the port. There has been some interest from various people around the world on this. I'm looking into starting up a microblaze-uclinux specific mailing list, and preparing a set of patches so interested parties can get involved. In the meantime, uclinux-dev@uclinux.org (subscribe via www.uclinux.org) is active and I'm posting there on a daily basis. I'll report back in a couple of days when I have made the arrangements. Keep this frequency clear! JohnArticle: 54068
Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0304010937.79425738@posting.google.com>... > already5chosen@yahoo.com (Michael S) wrote in message news:<f881b862.0304010021.1e95769b@posting.google.com>... > > > We use J mode exclusively in all our newer designs. We feel really > > sorry that we used C mode earlier. For the systems like ours which > > have nothing, but FPGA, on the PLX local bus, C mode is pure wast of > > pins with zero advantage. > > The complete J mode 32bit interface (no support for local bus > > mastering) requires only 41 pins in the FPGA - LAD[31:0], LBE[3:0], > > ADS#, BLAST#, LW/R#, READY# and LCLK. > > DT/R# and DEN# are not necessery. > > If you don't need byte/word wide writes, you don't have to connect > > LBE[3:0]. > > For the demand-mode DMA - connect DREQn#. You can do fine without > > DACKn#. > > For the interrupt to host - connect LINT#. > > Now that I've thought about it, "J" mode is probably perfect if you > are implementing an SDRAM controller in the FPGA. > > It boils down to: "do I need to have the local bus give me an address > every cycle?" > No. It doesn't boil down to anything. If FPGA[s] is/are the only slave/sleeve sitting on the local bus, the J mode is superior to the C mode. Period. During the C mode burst transaction the address bus is incremented linearly, so it doesn't carry usefull information. > > + There is a way to configure your FPGA with PCI9080/54/54 signals > > witout PROM and additional PLDs. Think a little and you would find it > > yourself. I'm not going to tell you how :) > > ummm, use an ISP CPLD? > Nah. No CPLD. Just PCI9056, FPGA and one pullup resistor... > Seriously, tho', I guess you would use the FPGA's parallel config > mode. > No, I don't. Everything works with Passive Serial (speaking in A-terms).Article: 54069
Hi, You don't have to register the AD and C/BE for parity checker, that can save you 1 clk, but beware of timing. How fast you want it gonna be?Article: 54070
"Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it> wrote in message news:<CIIga.54210$7y3.1694665@twister1.libero.it>... > "Mike Shonle" <mike@psychonic.net> ha scritto nel messaggio > news:To-dndAX1_vqth6jXTWcrg@speakeasy.net... > > > Why not use one of the TI dsp chips with built-in PWM & > > encoder reading, > > like the 320F2407? > > 'f2407 is a fixed point DSP and has something between 100 and 200 MIPS, > while c67xx family is floating point and some models go beyond 2000 > MFLOPS. They aren't exactly equivalent. ;) > According to TI, the fastest C67 (TMS320C6713-225) has a _peak_ performance of 1350 MFLOPs: (4 FADD + 2 FMUL) * 225MHz. Sorry for nit picking, I couldn't resist.Article: 54071
"Paul Leventis \(at home\)" <paul.leventis@utoronto.ca> wrote in message news:<rH8ia.817$Mt1.69@news01.bloor.is.net.cable.rogers.com>... > Marc, > > If only comparing logic cells were that simple. > > Though Xilinx's data sheet shows 6912 logic cells for XC2S300E, there are > only physically 6144 logic cells in the part. Take the CLB array size (32 x > 48) and multiply it out (x4 LCs per CLB) = 6144. Or look at the distributed > RAM -- 98304/16 bits per LC = 6144 LCs. So this is much closer to the 5980 > logic elements in the 1C6. > > Why is this, you may ask? It's a creative piece of marketing where Xilinx > has decided their logic cell is worth 12.5% more than their past or Altera's > (I forget which) logic cell. This is due to all the goo that allows various > functions to be rolled into the LC in addition to a 4-input LUT. [...] Hello Paul, While I agree it is somewhat misleading for them to do this, I doubt someone would pick a 2S300E over a 1C6 based the LUT count difference between the two devices, especially if it is an estimated LUT count. IOW, I don't think you (Altera) have too much to fear. If the design is that close to the edge of not fitting, running the design through the place and route tools (as both you and I have suggested) is the only way to verify a fit. I have seen too much variability in the place and route tools to do anything otherwise. And THAT is why I was asking the original poster how/why he was choosing the device he did. MarcArticle: 54072
This might be a way to introduce the concept of a partially defective FPGA. Yes, allow the mapper/place/route tool set to either test/map around the defective CLB & route segments or read the bad map from the FPGA then take that information into account for bit pattern generation. It would work for prototyping and perhaps for very low quantity production. If you could read/test and record the defective logic then when field upgrades are required each unit would have a unique bit pattern. Not effecient but do able. Instead of bad mapping individual CLB perhaps the granularity could be adjusted to say 4 clbs per bad bit. Much the same way bad sector disk mapping is done. It doesn't tell you which bit is bad in the sector only that the sector is bad. Using this bad logic mapping could be introduced for the 90 nanometer process and then integrated into the 65 nanometer dies so its transparent to the user. Jerry "Robert Finch" <robfinch@sympatico.ca> wrote in message news:xwbia.1535$DD6.399329@news20.bellglobal.com... > How about just allowing the design tools to run defect tests on an FPGA ? > That way nothing in the FPGA would have to change? Does production testing > check the entire FPGA or does it quit once a defect is detected ? Is there a > way to tell how defective the part is ? > It wouldn't be that useful for production, but for prototyping it might be > handy. > It seems a bit of waste to throw out FPGA's when there's only a single bad > route or LUT, when a lot of the time that resource doesn't even end up > getting used anyway. > > Rob > > > >Article: 54073
"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> wrote in message news:b6d0oe$oi0$1@news.tu-darmstadt.de... > Ralph Mason <masonralph_at_yahoo_dot_com@thisisnotarealaddress.com> wrote: > : I have done this and the chip viewer shows the output macrocells for the > : leds as STD power, and all the others as low. Exactly as expected. > > : However the leds still don't work (they work if I set the powermode of the > : whole device to STD as above) - does it matter that a STD power marco cell > : is driven by a low power one? > > : Does anyone have any ideas? > > The macrocells are inside the chip. The LEDs are drive by the output. Show > us how you drive the LEDS. Only if you clock the LEDS well above perhaps 20 > MHz, the powersetting of the Makrocells will affect the LED drive > capability. Thanks for your help, it turns out that the CPLD wouldn't run in low power mode, until I feed a WR line into a global clock pin. There was a thread here a while back about feeding an input signal out a global clock pin and then using the global clock signal - thus letting any pin be a global clock. Does anyone have any idea how to get the syntheses to understand that? Thanks RalphArticle: 54074
I wrote a little artical for EETimes that proposed having a full wafer of FPGA fabric that included a purge map for defective resources. You could have an area on the FPGA die that got laser burned to record the defects. Once you have a "master" design rerouting around the defects would not be that hard or take that long. Of course you know of the Xilinx program where you give them a bitfile and they screen to that. But really someone will do the work to include a bitmap someday. Like I say it would be great for wafer sized FPGAs. Imagine a Billion gate device. You could put everything including the OS on something that size. Steve "Jerry" <nospam@nowhere.com> wrote in message news:v8kdtu3fs25le7@corp.supernews.com... > This might be a way to introduce the concept of a partially defective FPGA. > Yes, allow the mapper/place/route > tool set to either test/map around the defective CLB & route segments or > read the bad map from the FPGA then take that > information into account for bit pattern generation. It would work for > prototyping and perhaps for very low quantity > production. If you could read/test and record the defective logic then when > field upgrades are required each unit would > have a unique bit pattern. Not effecient but do able. > > Instead of bad mapping individual CLB perhaps the granularity could be > adjusted to say 4 clbs per bad bit. Much the > same way bad sector disk mapping is done. It doesn't tell you which bit is > bad in the sector only that the sector is > bad. > > Using this bad logic mapping could be introduced for the 90 nanometer > process and then integrated into the > 65 nanometer dies so its transparent to the user. > > Jerry > > "Robert Finch" <robfinch@sympatico.ca> wrote in message > news:xwbia.1535$DD6.399329@news20.bellglobal.com... > > How about just allowing the design tools to run defect tests on an FPGA ? > > That way nothing in the FPGA would have to change? Does production testing > > check the entire FPGA or does it quit once a defect is detected ? Is there > a > > way to tell how defective the part is ? > > It wouldn't be that useful for production, but for prototyping it might be > > handy. > > It seems a bit of waste to throw out FPGA's when there's only a single bad > > route or LUT, when a lot of the time that resource doesn't even end up > > getting used anyway. > > > > Rob > > > > > > > > > >
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