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
Steve Rencontre wrote: > > I've just received an info sheet on the Cypress Delta39k family. Guess > what? An SRAM CPLD and a flash memory in a 2-dice-per-chip package! > > This still isn't going to stop the bad guy with lots of money to spend on > disassembling the chip, but it's got to be a good thing for intermediate > security. > > -- > Steve Rencontre, Design Consultant > http://www.rsn-tech.demon.co.uk What does it take to dissolve some plastic? Twenty bucks? Fifteen pound sterling? Looks like a token security to me. Somewhat like the door-lock on my house... Peter Alfke, Xilinx ApplicationsArticle: 19801
In article <387A38D6.9C2C0EE9@xilinx.com>, peter.alfke@xilinx.com wrote: (snip) > > Spartan2 was officially announced today, Jan 10. > If you are interested in details, click on > > http://www.xilinx.com/products/spartan2/index.htm > (snip) I downloaded the data sheet, but all parts are shown as commercial temperature only. Any plans to offer industrial temperature grade? -- Greg Neff VP Engineering *Microsym* Computers Inc. greg@guesswhichwordgoeshere.com Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19802
We have an ISPLSI2128VE Lattice cpld. It keeps latching up. The chip gets really hot, intermittently. At first, I thought it was the fact that we have 2 different power supplies on the board 3.3V and 5V and that they were ramping up at different speeds. Now, I think maybe it is something with the chip. Any suggestions? Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19803
What are the differences between an XC2S50 (spartan 2) and a Virtex XCV50 other than packaging options? Mike Butts wrote: > Peter Alfke wrote: > > Spartan2 was officially announced today, Jan 10. > > Getting the Virtex features, especially the 4K > block RAMs, in a small, lower cost form is great. > > You can put a whole CPU and its memory inside > a Spartan2. This will be very desirable for > students and teachers of CPU design. Also for > anyone who wants an easily programmed controller > inside their FPGA design. > > So, Peter, when will Spartan2 be supported by the > Student Edition software? The whole family, > as with Spartan, right? > > Thanks! > > --Mike Butts -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19804
The tough part about doing it this way is capturing the count reliably, especially if the counted clock period is shorter than the ripple propagation time. In order to reliably measure the count, you need to gate the input clock and allow the counter to settle before taking a reading. Peter Alfke wrote: > Different people, different views... > > I would use 4 individual clocks, and even use ripple counters, since they offer > highest frequency resolution ( if needed ) and lowest power consuumption. > Obviously, you have to accomodate the ripple delay when the counter stops, but > that seems to be easily done in this design that looks like an event or frequency > counter. > > I am a fan of global clocks and synchronous design, but that's not the best method > > for everything. > > Once a year I may disagree with Ray. Would become boring otherwise. > > Peter Alfke, Xilinx Applications > ================================ > > Ray Andraka wrote: > > > The way to do this is to synchronize your independent inputs to the global > > clock then use the synchronized inputs to enable counters working on the global > > clock. You'll need a synchronizer circuit that generates a one clock wide > > pulse for each 0 to 1 transition of the input clocks. Your local clock will > > have to be at least as fast as the fastest incoming clock, and if you can do 2x > > it makes the synchronizing a whole lot easier. The whole local counter doesn't > > have to work at 2x, only the first few bits. For that matter, you could > > prescale the input clocks using small counters and then synchronize the > > prescaled clocks to the global clock. The prescalers should not be more than 2 > > bits (in the same slice or CLB) so that you can run them with a clock that is > > routed on the general routing rather than on a global clock net. If you are > > careful about it, you can run the prescaler at a considerably higher frequency > > than the global clock tree is capable of. I think Peter Alfke did an app note > > to this effect for a 400MHz freq counter a couple years ago (before virtex). > > > > "Kresten Nørgaard" wrote: > > > > > Andy Peters skrev i meddelelsen <85d9lj$18d7$1@noao.edu>... > > > >Kresten Nørgaard wrote in message <857h4h$96j$1@news.inet.tele.dk>... > > > >>Hi group! > > > >>I'm looking into a new design, consisting of 4 pcs. of 32-bit 100 MHz > > > >>asynchronous counters. When stopped, the counters are emptied into a FIFO > > > >>(common to all counters - 32 kbyte size total). The FIFO's will be read > > > >>through an ordinary 8 MHz CPU interface. > > > > > > > >Question: why an async counter? Especially at 100 MHz? you'd better off > > > >with a synchronous counter and some logic that generates count enables. > > > > > > Quite right, but I figured, that I would need 4 "global" clocks to make 4 > > > counters, and not all FPGA families features so many distributed clocks. > > > > > > Another issue is power consumption. I reckoned, to lower the power > > > dissipation, if a chose a ripple counter, but I might be wrong on that? > > > > > > Kresten > > > > -- > > -Ray Andraka, P.E. > > President, the Andraka Consulting Group, Inc. > > 401/884-7930 Fax 401/884-7950 > > email randraka@ids.net > > http://users.ids.net/~randraka -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19805
Peter da Silva wrote: > I just checked around my net and while most systems were rebooted the weekend > of 1/1/00 for political reasons, there's a few who escaped. I haven't found > a UNIX box with an uptime below 10 days, and most are 50-150 days including > some that are 10 year old 386 boxes. I have to ask out of curiosity: what exactly do you do with those computers? They must consume an awful lot of power... I'm all for retro-computing and putting old hardware to good use, but I draw the border where the cost of operating the old systems is so high that replacing several of them with a single new system makes sense. -mjyArticle: 19806
On Tue, 11 Jan 2000 21:54:04 -0800, Phil Hays <Spampostmaster@sprynet.com> wrote: >Are there any users of big parts that care to share a better way to assign pins? >In the past, I handled pin assignments in the three ways listed below. <snip explanations> Can anyone explain to me why we still have to spend gigabucks to get an EDA environment in which there is at least a teeny weeny little bit of a relationship between schematic/PCB layout software and FPGA software, so that FPGA pinning could be an integral part of the PCB layout backannotation process? :-) Jonathan BromleyArticle: 19807
Greg Neff wrote: > > I downloaded the data sheet, but all parts are shown as commercial > temperature only. Any plans to offer industrial temperature grade? > > Xilinx will be offering Industrial grade in the -5 speed grade, but we are still deciding on part/package combinations. We are interested in knowing which parts have the highest demand for I-grade. The low price of Spartan is partly due to manufacturing efficiencies and inventory management. We could easilyt hurt that cost structure by being too generous with Industrial options. Peter Alfke, Xilinx ApplicationsArticle: 19808
"Marinos J. Yannikos" wrote: > > Peter da Silva wrote: > > I just checked around my net... I haven't found a UNIX > > box with an uptime below 10 days, and most are 50-150 > > days including some that are 10 year old 386 boxes. > > I have to ask out of curiosity: what exactly do you do with > those computers? They must consume an awful lot of power... > I'm all for retro-computing and putting old hardware to good > use, but I draw the border where the cost of operating the > old systems is so high that replacing several of them with > a single new system makes sense. The break even point on 'old' super-micros (as opposed to normal-micros like Apple IIs or IBM PC-XTs) can be pretty obscure. Anything that can run a unix-derivative and can be connected to ethernet at nominal cost, can still be pretty usefull. I run an old 486-66 as my firewall at home, and we are using some 486-50s as secure X-Terminals (you run X linux on them and 'tunnle' X through ssh) at my work. In both cases, it wouldn't make a whole lot of sense to replace thoses machines with new, low-cost computers (much less with new, high-cost ones) since the tasks they are doing don't demand any more processing power than they provide, they don't consume any more electricity than a modern machine, and they cost almost nothing to aquire. (my firewall cost me $15 and the psuedo-X-terminals at work were just sitting in a closet gathering dust) It's not as if we're talking about running an old work- station or a minicomputer (my PDP-11/44 and Sun 3/60 stay powered off unless I need to get something off old media) where wattage alone would be prohibitive. - Jeff DutkyArticle: 19809
In article <85gbbu$n2h$1@agate.berkeley.edu>, ying@soda.CSUA.Berkeley.EDU (Ying C.) wrote: > Nothing will happen. 10K20 simply can't be configured with 10K10 > bitstream. > Since they are pin to pin compatible, the device will try to configure > and then get > stuck in the error out mode. (ie. nStatus goes high) > > Ying > > In article <387B0CFA.FBFC56FE@dotcom.fr>, > Nicolas Matringe <nicolas@dotcom.fr> wrote: > >Hi > >One of our engineers who doesn't know much about FPGAs just told me > "All > >right(, I replaced the 10K10 with a 10K20, this should work fine". I > >stopped him, telling that it's not because they are pin to pin > >compatible that they can be programmed with the same bitstream. > >Any of you knows what would happen if we tried? Just curious... Since the '10 bitstream is shorter than the '20, I'd personally expect the latter just to hang expecting more bits. -- Steve Rencontre, Design Consultant http://www.rsn-tech.demon.co.ukArticle: 19810
Simon D. Wibowo <simon.wibowo@infineon.com> wrote in message news:85etg6$964$1@mosquito.HL.Siemens.DE... > What, do you think, is the best FPGA for SDRAM controller ? Say, up to PC100 Xilinx has a pretty large number of applicaion notes for interfacing their Virtex parts to various flavors of high speed RAM, including SDRAM. It's pretty impressive how fast Virtex can fly, especially the Virtex-E parts. The application notes usually describe relatively simple-minded controllers that are more suitable for applications such as data logging rather than as processor/RAM bridges, but they're a good starting point. I couldn't really say about "best." I can say that Xilinx works. ---Joel KolstadArticle: 19811
Simon D. Wibowo <simon.wibowo@infineon.com> wrote in message news:85etg6$964$1@mosquito.HL.Siemens.DE... > What, do you think, is the best FPGA for SDRAM controller ? Say, up to PC100 Xilinx has a pretty large number of applicaion notes for interfacing their Virtex parts to various flavors of high speed RAM, including SDRAM. It's pretty impressive how fast Virtex can fly, especially the Virtex-E parts. The application notes usually describe relatively simple-minded controllers that are more suitable for applications such as data logging rather than as processor/RAM bridges, but they're a good starting point. I couldn't really say about "best." I can say that Xilinx works. ---Joel KolstadArticle: 19812
What is the reliability of the PROM based download programming as opposed to FLASH based devices or antifuse devices? I am looking at using a Xilinx Virtex device, but I need to have 100% reliability in the functionality after the download ends, passes CRC, and comes out of tristate. I understand that if the CRC is bad, the device will shut down, and that's OK. RichArticle: 19813
From what I've seen it's pretty good. The registers that hold the configuration are pretty robust, and hold the configuration to some amazingly low supply voltages. You are not likely to see problems with the FPGA losing its marbles if that is what you are asking. For space applications, you will probably be concerned about upset due to radiation etc. In that case, you need to monitor the configuration somehow and reconfigure if the thing breaks. As far as the configuration itself goes, as long as you keep the configuration clock clean and follow the recommended sequence and timing in the databooks, you shouldn't have any problems. Richard Lamoreaux wrote: > What is the reliability of the PROM based download programming as > opposed to FLASH based devices or antifuse devices? I am looking at > using a Xilinx Virtex device, but I need to have 100% reliability in > the functionality after the download ends, passes CRC, and comes out > of tristate. I understand that if the CRC is bad, the device will shut > down, and that's OK. > > Rich -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email randraka@ids.net http://users.ids.net/~randrakaArticle: 19814
"Larry Elmore" <ljelmore@montana.campuscw.net> writes: > "Ketil Z Malde" <ketil@ii.uib.no> wrote in message > I think you just answered your own question. If Redhat et al "are hurting > pretty bad from their rushing out unfinished products," then they've got a > real incentive to be more conservative and do it right next time, don't > they? Well, maybe not. Microsoft and a lot of others do this all the time. Interesting point, but irrelevant. Red Hat isn't rushing development of open source software, only packaging and sales. And Red Hat is in many ways the enfant terrible here, Debian and S.u.S.E seems to be a lot more careful. Basically, I find that it is commercial software that gets features at the expense of bug fixes, and that gets rushed out the door unfinished or at least poorly tested. >> If you want to live on the cutting edge, use >> "unstable", and deal with it. > Like the first two versions of almost any MS product... Sorta. Of course, if you run unstable, you're expected to help stamp out the bugs. Debian has a pretty good system with package maintainers and bug-squash parties on IRC and so on. Are we still within the scope of any of these groups? :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giantsArticle: 19815
Ray Andraka wrote: > > From what I've seen it's pretty good. The registers that hold the > configuration are pretty robust, and hold the configuration to some > amazingly low supply voltages. I sopmetimes encounter a problem with an Altera Flex10K which is on an ISA extension card. It sometimes loses its configuration after an electrostatic discharge on the computer case. I must reckon the decoupling of the Vcc pins is quite poor, too :o) Nicolas MATRINGE DotCom S.A. Conception electronique 16 rue du Moulin des Bruyeres Tel 00 33 1 46 67 51 11 92400 COURBEVOIE Fax 00 33 1 46 67 51 01 FRANCEArticle: 19816
Not that I like being the bearer of bad news, but you may be far more hosed than you realize. If your intent is to take this old design and put into a current fpga then your only challenges are the ones you are currently facing. (which arent trivial. see notes on libraries below) But... If you are going to be updating/changing the design and then loading it into existing XC3000 chips on boards (Not XC3000A or XC3000L or 3100A or 3100L) then you are in much more trouble, because NONE of the Mx.y software knows how to create valid bitstreams for XC3000 devices (or XC2000 or XC4000 or XC4000H or XC4000A). The last version of Xilinx software that knows how to do this is XACT V5.2.1/V6.0.1 See more notes below. In article <85hu8h$tk2$1@nnrp1.deja.com>, <himalayas@my-deja.com> wrote: >Thanks Philip, > in fact the true problem I am facing is that , >my design project(XC3000) is based on a design someone developed >years ago using workview office 4.3(under dos),now my box runs on >win98,and I can only open the design project using WVO7.53(just as >you have said,xilinx foundation 2.1i cannot import the project),and to >implementation the design I have to use Foundation 2.1i. During the >implemetation(yes,the target netlist file is exported from WVO753 with >the "level" property set to "Xilinx"),the software(flow engine) window >shows "Writing the design to ....ngo",then "Reading ....ngo",then >"Reading component libraries for design expansion...",then it >stops,after some minutes,it bursts out lots of error messages such as >"ERROR:NgdHelpers:312 - logical block "$1I1\$1I1\$1I1\$1I1" of type >"DFF" is unexpanded." , The problem here is pretty convoluted. The library you must be using is a non-unified library. Since your design obviously has DFF symbols in it, this is the right library, but Oh dear ..... This stuff must be about 1991 vintage or earlier. It was around this time that the unified libraries were created, and among the casualties was the DFF symbol, which I believe was replaced by the FDCE symbol. This lives on to the current libraries that work with the M2.1i/F2.1i software. There never was an easy way to migrate these old designs to work with unified libraries. Last time I did this, I ran Viewdraw with the pre-unified libraries, and printed out everything. Then I started a new design, using current libraries, and re-drew everything. (there were a few black-belt secrets I used to make the job not too hard, but "easy" it wasn't). >"ERROR:NgdHelpers:312 - logical block "$1I1\$1I1\$1I2\$1I17\$1I1" of >type "DFF" is unexpanded.",etc. of course the software exits. > >It seems that Foundation 2.1i doesn't recognize the component libraries >(builtin,mx3000,x3000,xblox,xpal,xttl..)used in the design with WVO 4.3 >under DOS?And how can I port the project onto the current EDA >environment? See above. > >Would anyone help me?:-) > Not a fun project :-( >Thanks again, >Jimmy > > > >Sent via Deja.com http://www.deja.com/ >Before you buy. PhilipArticle: 19817
Hai, Unless you use one time coding FPGA, there will not be any possibility of getting high security. The SRAM based FPGA are good for performing exercise, such that whether the FPGA meets our necessary requiremnts. Once u go for One time coding FPPGAs(Altera.....), ur design have High security, unless the FPGA is stolen or Mal functioning. This is my view for Design security....... In SRAM based, FPGAs the PROM contents can be occupied erased, by any power full magnetic filed. This is one of the major disadvantage of SRAM based FPGA's. Satish... In article <3878359A.69D0@DesignTools.co.nz>, jim.granville@DesignTools.co.nz wrote: > Hal Murray wrote: > > > > In article <3870B679.D84288FD@ids.net>, > > Ray Andraka <randraka@ids.net> writes: > > > The problem with putting an OTP key in the device, is that the non-volatile > > > cells can't be fabricated without additional process steps. The FPGA > > > process is essentially the same as DRAM, which lets it be done with bleeding > > > edge process. Put PROM cells on there, and you lose the speed. > > > > I'm not a silicon guru. This case is different from a normal > > PROM in that we don't need a lot of bits. > > But you do - the whole config memory needs to go on chip, not just the > security bit(s), and you'll want the config memory re-writable as well, > otherwise the anitfuse devices are equivalent. > > A few bits of write-once is not a big problem - you just arrange a > kill-able element. > > Gatefield/Actel have FLASH FPGA, but the very leading edge will always > be > RAM based. > > A design option for the security paranoid is to split the design > between > the FPGA, and a sister CPLD - the FPGA can be cloned, but the system > cannot. > In a QFP44 you can get 64/72 Macrocells, which can be quite a 'lock' > > - jg > > Sent via Deja.com http://www.deja.com/ Before you buy.Article: 19818
Here some additional information concerning our Retry problem: We are using the Philips SAA 7164 Multimedia Chip as PCI Master. The main question I have is: Why is the PCI Target not abel to accept my Burst for such a long time (answering my request with retries). Is there a deadlock situation? I suppose there is a problem with the Target (Intel 82443LX Chip) on our motherboard in comination with the used DisplayController (S3 ViRGE GX2) thanks for any hints ... peterArticle: 19819
Hi, OpenIPCore Project tries to define set of openhardware design methodology and concepts we currntly have some designs and ideas we would like to ask from you to give us some comments on our ideas and designs Thanks Jamil Khatib OpenIP Organization http://www.openip.org OpenIPCore Porject http://www.openip.org/oc OpenCores Project http://www.opencores.orgArticle: 19820
I do not know the max speed available in current technologies, but I simulated a 32 bit ALU and a 32 bit barrel shifter on an Atmel 40K FPGA architecture which is similar to the Xilinx architecture. The critical path was around 250-300 ns for both. Since in a real 32 bit processor, this is just part of single stage in a processor, you will find that high MHz processors are hard to find. I doubt that you can get 50 Mhz with an FPGA implementation. If you are lucky You might get 10-15 Mhz in very advanced technology. Also they will be quite expensive. Just the ALU and the barrel shifter is 30 kgates in itself. I have seen data on a fullblown 32 bitter indicating about 120k gates for a RISC processor. An off the shelf ARM7 will be soo much cheaper. Pretty soon, you can get silicon with a processor integrated with the FPGA and then you will have low cost 40-50 MHz. The 8 bit AVR RISC + FPGA (FPSLIC) will soon do 40 MHz. -- This is a personal view which may or may not be shared by my employer Atmel Sweden Ulf Samuelsson ulf 'a't atmel 'd'o't com Damjan Lampret skrev i meddelandet <85clgf$o03$1@planja.arnes.si>... >Hi everybody, > >does anyone know how fast (in terms of clock speed or/and in terms of >performance) and how big is the fastest 32 bit RISC in FPGA (not restricted >to any particular FPGA vendor). Processor can be commercial or open source. >It would be best if it is with caches and MMU. Thanks. > >regards, Damjan > > >Article: 19821
In article <85evl4$a9f$1@news01.btx.dtag.de>,
Peter Lang <Peter.Lang@rmvmachinevision.de> wrote:
>Hi to all,
>I am not shure this is the right newsgroup for my problem, but maybe
>someone can give me a hint or the name of a better fitting newsgroup.
>We are designing PCI-Framegrabber cards using standard PC-platforms and
>Windows98 The problem is that the Video Data DMA Burst via PCI-Bus
>sometimes stopps for about 30 microsec. While that time alle PCI
>Data-Transfers are aborted with a RETRY termination. As a consequence our
>Video Fifos get a Data Overflow!
I think you need a frame buffer on your card. There are no bandwidth
guarantees with PCI.
--
/* jhallen@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}
Article: 19822Hi, you may want to ask PCI folks, there is a mailing list, to subscribe send a SUBSCRIBE(subject) message to pci-all-request@znyx.com .... As pointed out by Joseph, you probably need a larger FIFO (as large as 1 MByte ??). BTW, I don't think the 7164 is the rigth bridge in such design. rgds Tom Peter Lang schrieb: > > Here some additional information concerning our Retry problem: > We are using the Philips SAA 7164 Multimedia Chip as PCI Master. > > The main question I have is: Why is the PCI Target not abel to accept > my Burst for such a long time (answering my request with retries). > Is there a deadlock situation? > I suppose there is a problem with the Target (Intel 82443LX Chip) > on our motherboard in comination with the used DisplayController (S3 ViRGE > GX2) > > thanks for any hints > ... peterArticle: 19823
In comp.arch Marinos J. Yannikos <mjy@pobox.com> wrote: > Peter da Silva wrote: >> I just checked around my net and while most systems were rebooted the weekend >> of 1/1/00 for political reasons, there's a few who escaped. I haven't found >> a UNIX box with an uptime below 10 days, and most are 50-150 days including >> some that are 10 year old 386 boxes. > I have to ask out of curiosity: what exactly do you do with those > computers? They must consume an awful lot of power... I'm all for They consume no more than "modern" computers and may well consume less power than the desktop computers presently sold. > retro-computing and putting old hardware to good use, but I draw It's not retro-computing. There are lots of embedded 386 based computers, intel still sells 386s, and I don't think it is "not suggested for new designs". > the border where the cost of operating the old systems is so high > that replacing several of them with a single new system makes sense. Operating a 386 based computer in which say one of the *BSD runs is no more costly than operating say a pentium on which one of the *BSD runs. The same applies to say Sun IPX 8-) > -mjy -- Sander There is no love, no good, no happiness and no future - these are all just illusions.Article: 19824
Sander Vesik wrote: > > computers? They must consume an awful lot of power... > > They consume no more than "modern" computers and may well consume less > power than the desktop computers presently sold. But if the CPU cycles are put to any use, dozens of old 386 boxes can be replaced by a modern system, eliminating much power consumption. I won't even switch my old P133 on, since CPU-intensive stuff can run better on my newer systems and the P133 would make too little of a difference to justify the power consumption and noise. -mjy
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