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
Does resource sharing also apply for a + sign in different states? It appears the synthesizer doesn't like my code then. "Andy Peters" <Bassman59a@yahoo.com> wrote in message news:1142615703.883972.125680@j33g2000cwa.googlegroups.com... > Leow Yuan Yeow wrote: >> Hi, I was doing that before but I found that each + that I use generates >> a >> 32-bit adder under the synthesis report which increases the LUT usage by >> quite a fraction. After that I tried to multiplex them to a addsub >> component >> and the LUT usage went down from 90+% to 80+% (I'm using the old RC100 >> board >> with spartan II so I have limited resources :( ). > > It may be that the rest of your design precludes resource sharing. > Every time I've needed an adder or subtractor, I write code similar to > what Weng describes. > > For example, the following code will create only one adder: > > if (add) then > result <= a + b; > else > result <= a - b; > end if; > >> I was wondering if there are any other components that I can instantiate >> for >> comparators as well? > > Why instantiate? > > -a >Article: 98976
Chauhan wrote:
> Special Thanks to Ralf Hildebrandt
> who ignored the formalities and helped with his valuable
I do _not_ ignore the formalities! Reading this group is really hard.
1) high traffic
It seems to be uninteresting? Ignore thread.
2) seldom minimal examples
No time for such a bunch of code.
3) gimme code fast!!!!
Should I do your homework?
4) plz can u adv?
What? I am not a native English speaker. (Look at the email
addresses. I am not the only one.) Although I can understand this, it
makes "eye cancer".
5) I have that problem ...
Did you try to solve it? What are your ideas?
...
O.k. the OP's posting was to that hard to read, but it may have been the
the last straw that breaks the camel's back. Netcopping is not nice, but
sometimes necessary. Here in this particular case it was an additional hint.
So it may be a good idea to form a clear and easily readable question
and provide as much as information as required (but not more) to get an
answer.
This is not a problem of the "generation gap". (I am 27.)
And at last: There are some real experts here in the group that give
often very useful hints (regulars). I would recommend to think about,
what they write, because otherwise you may hit soon the bottom of a
killfile or the experts will leave.
I have seen newsgroups with much more strict formalities, that are much
more readable. Here is the "wild west".
Ralf
Article: 98977let me know if you manage to get any SATA PHY AnttiArticle: 98978
Austin Lesea schreef: > Andy, > > The only proof is in the orders, and the shipments, and what I was told. > > That you, and others do not believe me is just fine. I didn't need your > approval to ship the parts. > > Does anyone honestly think I am making this up? I have no time for > fantasies: I have real work to do. The announcement was made (and the > part briefly shown at the press conference) for 65 nm. Busy doesn't > really describe my shop right now. 'Frantic' is more accurate. > > A very happy, and pleasing kind of frantic. > > Austin No, I do not think you make it up. I think the FPGA could perhaps be used in the dashboard displays. IIRC for example Toyota used one big LCD display, for all instuments :-) In such a case you need many many IO (to drive each segment), and using FPGA could also make it possible to do speed / tacho conversion, temp sensor linearization, basically any sensor processing, either digital or analog, all in one chip on the back of that big LCD panel. Now with mega cell FPGA, add the radio, GPS, and what not. So, yes, and a couple of million cars sold. But this is not for the reason you mentioned, but simply for the one I just stated. Does GM do something like that these days? Ford? They will have to perhaps. Posted from planet PArticle: 98979
On Fri, 17 Mar 2006 13:25:59 -0800, J Silverman wrote: > Hi All, > > I was able to get a bunch of Xilinx XC3042 FPGAs from a dealer and am > trying to find if there is any support software out there still for the > chip. I looked at the current ISE offerings from Xilinx, but none state > they support the XC3042. Does anyone know of anything for the XC3042? > > Thanks, J Silverman The tools that you are looking for never existed. The only thing that was available at the time were crude schematic entry tools which ran on DOS or maybe Windows 3.1, I don't remember which. I wrote my own synthesis tools in Gnu Lisp which converted ABEL (a now dead language for PALs) into XNF format (the old Xilinx Netlist Format), rather then use the schematic tools. Take Peter's advice and get a modern development board.Article: 98980
Eric Smith ha scritto: > If you're using ISE Foundation (the paid version), your key should work > for both 32-bit and 64-bit. I was trying to install the Foundation one, but our Xilinx consultant gave us a serial id only for 32 bit version :-( After a lot of phone calls and emails, I got the right code, and now it works fine on a debian dual AMD64 machine! But... there is not chipscope for that architecture, I found Chipscope available only for 32bit computers :-( I tryed to install chipscope for linux 32 with then official 64bit java virtual machine from Sun Microsystem, but the coreinserter hangs just on starting :-( Hoping chipscope will be released very quickly for 64 bit architecture... Thank you very much. -- MarcoArticle: 98981
Hi, I'm interfacing Micron's DDR with PowerPC using OPB DDR SDRAM controller available in EDK. The problem I face in simulation is that during a single read operation CAS signal extends to two full (consecutive) clock cycles. Thus for a burst length 2, I get 2 back to back identical burts. However During single write the CAS signal is asserted properly for 1 clk cycle. The DDR I use is micron mt46v16m16. I have tried with both 7.1 and 8.1 versions of EDK. Can anybody suggest me the possible reason for this problem?Article: 98982
i mean that pin assignments from the FPGA to the I/O pins at FLEX_EXPAN_X.Article: 98983
Hello Everyone, I am currently investigating my options for designing the power supply part for an imaging application. The FPGA that I had in mind, because of its small footprint and its availibility was the XC3S400. Because I can't and don't want to make any assumptions about the utilisation of the device at this point, I will probably have to design for the worst case. >From http://www.xilinx.com/products/design_resources/power_central/ I figured that I will probably need around 3A for the core, something like 2A for the I/O and a low-ripple 0.3A for the auxilliary rail. Because I am a software engineer gone electronics, my knowledge on power supply design is rather limited at this stage. The device itself will be battery powered at around 11.6V, and I would like the power supply part to be as small as possible. The efficiency is also not that crucial, as long as I won't have to provide cooling. Because its only a prototype cost is not an issue (within reason). Also I might need to add, that the 11.6V could be quite noisy as there are DC motors connected to it. My first shot was the TPS75003 from TI as it has all three rails integrated. However, it only operates on <6.5V Vin. I've had a look at the other manufacturers and feel a bit lost know. Because some other parts of my design will also require 5V, should I step down from 11.6V to 5V and then use something like the TPS75003? Or would it be better to have four rails all going down from 11.6V. What are my best options to keep the design small? Which bits do I need to be careful about? Any suggestions on the design or where I could get some additional information would be greatly appreciated. cheers, JakobArticle: 98984
On Sat, 18 Mar 2006 05:05:20 -0800, marcobuffa wrote: > Eric Smith ha scritto: >> If you're using ISE Foundation (the paid version), your key should work >> for both 32-bit and 64-bit. > I was trying to install the Foundation one, but our Xilinx consultant > gave us a serial id only for 32 bit version :-( After a lot of phone > calls and emails, I got the right code, and now it works fine on a > debian dual AMD64 machine! But... there is not chipscope for that > architecture, I found Chipscope available only for 32bit computers :-( > > I tryed to install chipscope for linux 32 with then official 64bit java > virtual machine from Sun Microsystem, but the coreinserter hangs just on > starting :-( > > Hoping chipscope will be released very quickly for 64 bit > architecture... > > Thank you very much. The basic 32 bit tools run fine on 64 bit Linux, I'm running them on 64bit FC4. I'm also running 32 bit NCVerilog on 64 bit FC4 instead of 64 bit NC because the 32 bit version is faster. The only reason to run 64 bit applications is if you need > 4G of memory which isn't necessary with any of the current parts. CAE applications are all integer so they slow down if you double the size of all of your integers and pointers which is why you should use the 32 bit versions if you can. As for ChipScope, you only need that on your lab machines. There is no reason to put a 64 bit OS on a lab machine. In my experience lab machines tend to be older boxes but even if you have a brand new A64 system out there it can still run a 32 bit OS. AMD64 systems don't need a 64 bit OS, they work fine with 32 bit OSes. I run 32 bit FC4 on my single core A64 desktop and laptop machines, and 64 bit FC4 on my dual core 4G server box. There is 0 difference in performance between 32 bit FC4 and 64 bit FC4, the only reason that I'm using 64 bit FC4 is so that I have the option of running a 64 bit app if I ever need to.Article: 98985
fpga_toys@yahoo.com wrote: > Jim Granville wrote: > >> So, that means the Tools have to be defect-literate, and be able to >>read a device ID and then find that device's defect map ? > > > Having a unique serial number for identification might be nice, but is > certainly not necessary to apply defect mapping to a particular well > known FPGA device. Two likely environments exist ... the fpga device, > or devices are mounted on a pci card and installed in a traditional > system. The installation process for that card would run extensive > screening diagnostics, and develop and error map for it. The driver for > that device, interfaced to the tool chain would make the map available > as a well known service. In addition the device/card would be sold with > either media or internet access to the more accurate testing done prior > to sale by the mfg. > > The other likely RC environment, are FPGA centric processor clusters, > built arround a mix of pure logic FPGA's (like XC4VLX200's) coupled > with cpu core FPGAs (II-Pro and SX parts) possibly coupled to 32/64bit > traditional risc processors. These have been my research for the last 5 > years. These super computers would be targeting extereme performance > for mostly high end simulation and processing applications > traditionally found doing nuke simulations, heat/stress sim's, weather > sims, genetic sim and searches, and other specialty applications. > Machines doing this in various degress exist today in both research and > production environments. The software for controlling these machines > and ground up vendor specific designs .... and defect management is a > trivial task for that software. > > >> I suppose that is do-able, but it does not sound cheap, and the SW >>teams are struggling with quality now, do we really want them >>distracted with defect mapping ? > > > Defect mapping is an integral part of every operating system, and you > will find it to cover for faults on floppy media, optical media, and > even hard drives .... it's part of most filesystems. > Providing defect mapping generated keep out zones on the fpga for place > and route is rather trivial. That is a very small price to pay to have > access to large numbers of relatively inexpensive FPGA's. Anything that > will allow effectively higher yields will lower the prices for RC > computing based on defect management, AND lower the price for zero > defect parts where the design and deployment infrastructure is unable > to handle defect mangement due to fixed bitstreams. > > >> How long can you tolerate running a Place/Route, for just one device ? > > > For RC ... not long at all. Which is why different strategies which are > baed in fast acceptable placement and routing, with dynamic clock > fitting are better for RC, while extensive optimization for fixed > bitstreams used in embedded applications need the tools used today. RC > has very very different goals .... bitstreams whose life may be > measured in seconds, or hours, maybe even a few days. Embedded is > trying to optimize many other variables, and for the goal of using > bitstreams with lifetimes in years. > > >> There might be long-term potential, for some FPGA vendor to >>make their Tools and Silicon Defect-map-smart, but the P&R would have >>to be way faster than present - and anyway, why not just fix it in >>silicon, with some redundancy and fuse re-mapping ?. > > > Much easier said that done, and loaded with the same problems that > dynamic sparing has in disk drives. To access a spared sector requires > a seek, and rotational latency loss TWICE for each error .... huge > performance penalty. Ditto for FPGA's when you have to transparently > alter routing to another LUT in an already densely routed design. > > Defect tollerant is a completely different strategy where place and > route happens defect aware. It's actually not that difficult to edit a > design on the fly .... using structures similar to todays cores, which > are linked as a block into an existing netlist. That can happen both > quickly and distort the prelinked/routed object during the load process > to effect the remapping around the failed resources. > > Anyway ... zero defect designs need zero defect parts, systems designed > around defect tollarent strategies are built from the ground up to > edit/alter/link the design around defects to avoid them. > This could be done using a soft core or a $1 micro on board with the > fpga for embedded designs that do not want to suffer the zero defect > price premium. > > >> Seems only a tiny portion of users could tolerate the custom P&R's ? > > > With todays ISE tools ... that is certainly true. Using custom JBits > style loaders, such as found in JHDL and JHDLBits, really a piece of > cake using mature tools that have been around for many years on the > educational side, with some small tweeks for defect mapping. All the > same tools the FpgaC project needs for compile load and go to an FPGA > coprocessor board. > > Tiny relative to the size of the FPGA universe today ... sure. Tiny in > terms of dollars and importance certainly not. Completely disjoint to > embedded fpga design today ... different customers, different designs, > different cost structures, different applications. > A few points: 1) The routing structure is many times larger than the LUT structures. A defect in the FPGA is far more likely to show up in the routing structure, and it may not be a hard failure. 2) The testing only identifies bad devices. It does not isolate or map the exact fault, to do so would add considerably to the tester time for a part that can't be sold at full price anyway. 3) Defect map dependent PAR is necessarily unique to each device with a defect, so you wind up not being able to use the same bitstream for each copy of a product. Fine for onesy-twosy, but a nightmare for anything that is going into production. The administration cost would far exceed the savings even if you get the parts for free. 4) Each part would need to come with a defect map stored electronically somewhere. Since the current parts have no non-volatile storage, that means a separate electronic record has to be kept for each part. This is expensive to administer for everyone involved from the manufacturer, the distributors, and the end user. Again, the administration costs would overshadow any savings for parts with a reasonable yield. 5) Timing closure has to be considered when re-spinning an FPGA bitstream to avoid defects. In dense high performance designs, it may be difficult to meet timing in a good part, much less one that has to allow for any route to be moved to a less direct routing.Article: 98986
Hello group, I have an issue with porting my high-speed DDR interface to Altera Cyclone II device. As far as datasheet says, Altera Cyclone II device does not have any dedicated circuitry to support DDR signaling in its Input/Output blocks for DQ pins. The only thing present in hardware is the clock delay circuitry on DQS pins. All other DDR logic is implemented using LUT's and triggers from adjacent Logic Array Blocks. So, it seams that we have only DQS pins location fixed, whenever all other DDR pins may float within the selected IO bank. Is that right? If yes, then what is the reason to denote certain pins on the Altera Cyclone II package as dedicated pins for DQ input/outputs? With best regards, Vladimir S. MirgorodskyArticle: 98987
What historical resources do we have for preserving early FPGA development? What web sites and peoples blogs are archiving this information? Prior generations left a rich legacy of paper records, but so much of the early digital generation is being lost. We were lucky to get early Unix sources archived in the public domain. What should be we tring to get released and archived to preserve the legacy of early FPGA tools? Has someone managed to get sources reconstructed for early Altera and Xilinx tools and possibly released since they have little to no commercial value these days, and great historical value?Article: 98988
Good points Ray. Ray Andraka wrote: > A few points: > 1) The routing structure is many times larger than the LUT structures. > A defect in the FPGA is far more likely to show up in the routing > structure, and it may not be a hard failure. Intermittant failures on all mediums have been a difficult testing problem, but is something that can reach closure if part of the system design includes regular testing. This would have to be part of idle activity for a reliable RC system design. > 2) The testing only identifies bad devices. It does not isolate or map > the exact fault, to do so would add considerably to the tester time for > a part that can't be sold at full price anyway. I suspect that this would not be a tester project, but more like specialized board fixturing that would facilitate loadable self tests under various voltage and temp corner cases. That is significantly cheaper to implment for the RC board vendor. > 3) Defect map dependent PAR is necessarily unique to each device with a > defect, so you wind up not being able to use the same bitstream for each > copy of a product. Fine for onesy-twosy, but a nightmare for anything > that is going into production. The administration cost would far exceed > the savings even if you get the parts for free. That was addressed initially. For RC using incremental place and route for fast compile, load and go operation a keep out zone is really no different than an existing utilized resource that can not be used. For more mainstream production use, I suggested that the go-nogo testing of the part look for errors in 16 sub quadrants, and bin parts failing to each. That would allow purchasing a run of parts which all had different failures in the same sub quadrant, and the rest of the die was known good and usable. That is much more manageable, without creating too many sku's. > 4) Each part would need to come with a defect map stored electronically > somewhere. Since the current parts have no non-volatile storage, that > means a separate electronic record has to be kept for each part. This > is expensive to administer for everyone involved from the manufacturer, > the distributors, and the end user. Again, the administration costs > would overshadow any savings for parts with a reasonable yield. For RC systems that would have to be addressed on a system by system basis, as part of the host development software ... not a big deal. individual resources faults at a detailed level for embedded applications is quite unrealistic, which is why I suggested subquadrant level sorting of the parts. > 5) Timing closure has to be considered when re-spinning an FPGA > bitstream to avoid defects. In dense high performance designs, it may > be difficult to meet timing in a good part, much less one that has to > allow for any route to be moved to a less direct routing. Certainly. I've suggested several times that RC applications may well need to actually assign clock nets at link time based on the nets linked delays, and choose from a list of clocks that satisfy the timing closure. I have this on my list of things for FpgaC this spring, along with writing a spec for RC boards suggesting that derived rising edge aligned clocks be implemented on the RC board covering a certain range of periods. That would allow the runtime linker (dynamic incremental place and route) to merge the netlist onto the device, and assign reasonable clocks for each sub-block in the design. This is necessary to be able to reuse libraries of netlist compiled subroutines for a particular architecture, across a number of host boards and clock resources. A very different model of timing closure than embedded designs today.Article: 98989
<fpga_toys@yahoo.com> schrieb im Newsbeitrag news:1142694775.663304.303780@e56g2000cwe.googlegroups.com... > What historical resources do we have for preserving early FPGA > development? > What web sites and peoples blogs are archiving this information? > > Prior generations left a rich legacy of paper records, but so much of > the early digital generation is being lost. We were lucky to get early > Unix sources archived in the public domain. > > What should be we tring to get released and archived to preserve the > legacy of early FPGA tools? > > Has someone managed to get sources reconstructed for early Altera and > Xilinx tools and possibly released since they have little to no > commercial value these days, and great historical value? > hm what you mean 'reconstructed' those historical tools still exist. they are just harder to get, as example XACT was on sale on ebay just two days ago, I was going to buy it, but as I wanted to bid on last second, and I selpt trough (I as sick that day and a sleep most of the day) - the final price was 12USD !! I would have bidded up to 50 AnttiArticle: 98990
The DQS signal is usually associated with a group of data (DQ) pins; so = where ever the DQS singal is you want the associated DQ pins located in = close proximity. Also, some DDR2 I/O standards, like SSTL-18 class II, = are only supported on two sides of the chip.Article: 98991
> Again, I apologize if you found my posting objectionable. I do realize > that there are some (not implying you) that have absolutely no sense of > humor whatsoever, and for them, all I can say is: don't waste your time > reading my posts, you won't like them (as I do have a sense of humor, and > I do enjoy life and its challenges). > AMEN! A little humor, some sarcasim, and even a little pretention (ambitious is a better word) can all make for interesting diaglogue. Take care, Rob "Austin Lesea" <austin@xilinx.com> wrote in message news:dvf4vc$atv6@xco-news.xilinx.com... > Rick, > > If I have offended you, I apologize. In fact, if I have offended anyone, > I apologize. I intended to poke fun (gently) at Metal's posting. > > I am an engineer, and I am not in marketing. If that means I am not > politically correct: I never pretended to be anything other than honest. > > Again, I apologize if you found my posting objectionable. I do realize > that there are some (not implying you) that have absolutely no sense of > humor whatsoever, and for them, all I can say is: don't waste your time > reading my posts, you won't like them (as I do have a sense of humor, and > I do enjoy life and its challenges). > > Austin > > > > rickman wrote: > >> Austin Lesea wrote: >> >>>Metal, >>> >>>Pessimists always claim they are just observing reality. >>> >>>You must be working for one of those companies "circling the drain?" >>> >>>Really hard to be positive about anything. >>> >>> >>>I see (our) business increasing (a lot), and I see margins that are >>>good, and getting better, and I see new opportunities popping up all >>>over the place. And I see the financials that support it. >>> >>>You have told all of us how we will need food, shelter, and a few sticks >>>to burn here in the not so distant future. >>> >>>Austin >> >> >> >> Austin, it is hard to believe that no one at Xilinx has ever reigned >> you in. Often your posts are useful and technically sound. But >> concepts of customer interaction and company representation seem to be >> lost on you. I was not even involved in this thread and I find your >> post to be insulting as well as totally inappropriate. Your "ad >> hominem" attacks seem to occur anytime someone makes a technical >> argument that might be hard to dispute. >> >> To be honest, my impression of Xilinx has changed a lot over the last >> few years, partly due to your postings here. Initially I did not pay a >> lot of attention to your comments to me or others until I realized that >> you are actually fairly influential in the company. Now I realize that >> Xilinx as a whole is not a lot different than the image you present and >> it bothers me. It bothers me enough that I now have a strong >> preference for any other FPGA manufacturer. >> >> I think the fact that no one at Xilinx seems to have a problem with >> your posts like this one says a lot about the company. >>Article: 98992
Hi all, i am designing a circuit for a cryptogrpahy application based on elliptic curve cryptography.I want to know one thing when i implement the same circuit on different devices from different families results are as follows. with spartant3 i m getting max. frequency as 89 Mhz with virtex2 i am geting max. frequency as 123 MHz but to my surprise with vortex-e-2000 i am getting max. frequency as 48MHz. can anyone explain why performance of virtex-e-2000 is like this. thanks. Regards Ramakrishna BachimanchiArticle: 98993
Pszemol@PolBox.com posted on Thu, 23 Feb 2006 14:36:34 -0600: ""Robert F. Jarnot" <jarnot@mls.jpl.nasa.gov> wrote in message news:dtl22v$73q$1@nntp1.jpl.nasa.gov... > quickcores has become SiliconLaude -- www.siliconlaude.com -- and > interesting 8051 cores with real-time JTAG debug are available. I have just visited their website and could not find IP cores available. Instead they offer radiation-hardened silicon... I am looking for an IP core to be put into a generic FPGA device." After Mr. Jarnot's post I contacted Silicon Laude as a radiation-hardened 8051 would be very useful for me, and in under a week was given a very reasonable offer. Silicon Laude does not make silicon, it sells its intellectual property as an FPGA chip programming file for a specific radiation-hardened FPGA. As any non-radiation-hardened device would be suitable for you, you could ask Silicon Laude to produce a netlist for a common FPGA.Article: 98994
Colin Paul Gloster posted on 18 Mar 2006 17:04:18 GMT: "[..] Silicon Laude does not make silicon, it sells its intellectual property as an FPGA chip programming file for a specific radiation-hardened FPGA. As any non-radiation-hardened device would be suitable for you, you could ask Silicon Laude to produce a netlist for a common FPGA." Indeed, Silicon Laude already mentions that it does this on its webpage WWW.SiliconLaude.com/products.html : "[..] SL80C051-AX001 Functionally equivalent to the SL80RT051-AX001 except that it is implemented in a commercial grade Actel Axcelerator FPGA and plastic 208-pin PQFP package. SL80C051-AF001 Functionally the equivalent to the SL80RH051-AF001 except that it is implemented in a commercial grade QuickLogic Eclipse FPGA and plastic 208-pin PQFP package. [..]"Article: 98995
Jakob, http://www.xilinx.com/products/design_resources/power_central/ scroll down to "Power Partner Websites" All of these excellent vendors products have been reviewed for use for Virtex, and Spartan products. They have fully integrated packaged solutions (for example, TI POLA series which we use on our ML series of boards), or components, and most have eval pcb's, too. My lab has tested many of these to be sure they work (such as the advanced Bellnix super fast point of load supplies which don't require any high value capacitors, and one uses fewer bypass caps -- really!), and all have been thoroughly reviewed. Any questions or comments on any power supply information should be directed BOTH to the vendor directly, and please cc me. Vendors have their own FAEs and engineers who will supply you with complete designs, layouts, and a bill of materials. I started this service, and I take it very seriously that we recommend only those products that will work without any difficulties. Austin Jakob wrote: > Hello Everyone, > > I am currently investigating my options for designing the power supply > part for an imaging application. The FPGA that I had in mind, because > of its small footprint and its availibility was the XC3S400. Because I > can't and don't want to make any assumptions about the utilisation of > the device at this point, I will probably have to design for the worst > case. >>From http://www.xilinx.com/products/design_resources/power_central/ I > figured that I will probably need around 3A for the core, something > like 2A for the I/O and a low-ripple 0.3A for the auxilliary rail. > Because I am a software engineer gone electronics, my knowledge on > power supply design is rather limited at this stage. > The device itself will be battery powered at around 11.6V, and I would > like the power supply part to be as small as possible. The efficiency > is also not that crucial, as long as I won't have to provide cooling. > Because its only a prototype cost is not an issue (within reason). Also > I might need to add, that the 11.6V could be quite noisy as there are > DC motors connected to it. My first shot was the TPS75003 from TI as it > has all three rails integrated. However, it only operates on <6.5V Vin. > I've had a look at the other manufacturers and feel a bit lost know. > Because some other parts of my design will also require 5V, should I > step down from 11.6V to 5V and then use something like the TPS75003? Or > would it be better to have four rails all going down from 11.6V. What > are my best options to keep the design small? Which bits do I need to > be careful about? > > Any suggestions on the design or where I could get some additional > information would be greatly appreciated. > > cheers, > > Jakob >Article: 98996
People really want that stuff? Really? email me.......Article: 98997
Antti, You do know that we have an archive of the 'last' supported versions, for customers use when they have to make a change to an ancient design? I had the web link, but I can't find it now. If anyone is interested, I will go find it again. You will also need an ancient operating system to go with it, and possibly an ancient computer, too. Austin Antti Lukats wrote: > <fpga_toys@yahoo.com> schrieb im Newsbeitrag > news:1142694775.663304.303780@e56g2000cwe.googlegroups.com... > >>What historical resources do we have for preserving early FPGA >>development? >>What web sites and peoples blogs are archiving this information? >> >>Prior generations left a rich legacy of paper records, but so much of >>the early digital generation is being lost. We were lucky to get early >>Unix sources archived in the public domain. >> >>What should be we tring to get released and archived to preserve the >>legacy of early FPGA tools? >> >>Has someone managed to get sources reconstructed for early Altera and >>Xilinx tools and possibly released since they have little to no >>commercial value these days, and great historical value? >> > > > hm what you mean 'reconstructed' those historical tools still exist. > they are just harder to get, as example XACT was on sale on ebay > just two days ago, I was going to buy it, but as I wanted to bid > on last second, and I selpt trough (I as sick that day and a sleep > most of the day) - the final price was 12USD !! I would have > bidded up to 50 > > Antti > >Article: 98998
Peter Alfke wrote: > rickman wrote: > Now I realize that > > Xilinx as a whole is not a lot different than the image you present and > > it bothers me. It bothers me enough that I now have a strong > > preference for any other FPGA manufacturer. > > > > I think the fact that no one at Xilinx seems to have a problem with > > your posts like this one says a lot about the company. > > Rickman, Austin is not alone in posting outspoken comments. You are no > slouch yourself ! Now an ad hominem from Peter... how exactly do my posts relate to Austin's? If I commit a crime does that mean it is ok for Austin to do the same? When I post I don't represent a company. If I make a comment, it does not reflect on my employer and I don't claim to be offering anything but my opinion. I think it is interesting that you fail to see the difference and that failure is part of what concerns me about Xilinx. > Luckily, Xilinx is not a monolithic dictatorship, and the company > trusts its senior employees to post in this newsgroup without > censorship and without reprimands. All companies are monolithic dictatorships to one degree or another. I think if upper management saw all of the posts that Austin makes they would likely not be pleased by the way the company is presented. Or maybe they wouldn't have a problem, I can't say. I do know that the apperence is that Xilinx is a rather arrogant company, not unlike Intel in the early days. > Austin and I give fast response, to the best of our knowledge (which is > quite extensive), but we are not always politically correct, and both > of us have a temper that can indeed be provoked by certain stupidities > repeatedly voiced on this newsgroup. We handle complex and sometimes > controversial subjects with engagement and also some humor. > We are not the official "Voice of Xilinx". You get that from Marketing > and in press releases. Having knowledge is not the only criterion for a good FAE or company representative. I thnk you both know that. I also think that you two have had a lot of leeway in these groups that you would not normally have in typical business forums. > I would be amazed if any smart engineer would base his component choice > on Austin's typing style. We would, however, appreciate if you base it > on the technical information you get in this newsgoup. Typing style... I like the way you trivialize the issue. That is the other part of my problem with the way that Xilinx is represented in the newsgroups. Even when a problem is pointed out to you and Austin, it is often trivialized rather than dealt with. That includes both customer interface issues as well as technical issues. I have been reading here for some years now and I have seen many, many times Xilinx claim that a given techical issue is not a problem only to deal with the problem in their next chip family and do a "1984" type reversal to brag about solving the problem as if they had never said the issue was not a problem. Other FPGA vendors add block memory and Xilinx claims that is not a good idea, then the Virtex parts come out with block memory. The power on surge currents are not a problem and can be dealt with easily with by a few extra parts on the board and the next Spartan generation is designed for no heavy power on surge current. The latest Xilinx families require three power supply voltages and I fully expect Xilinx to deal with this in following families by returning to just two supply voltages. So the problem is not just "typing style" and it is not just Austin. When someone from Xilinx trivializes an issue that is pointed out to them, I assume that means, like a teenager ignoring their parents, they just aren't ready to deal with it.Article: 98999
Ramarishna, Virtex E is .18 micron technology. Spartan 3 is 90nm. Virtex II is 150nm. Depending on how the resources are used, larger technologies are generally slower, and smaller are faster. If a resource is targeting that doesn't exist in hardened form (like the 18x18 multiplier is not in Virtex E), then it will be implemented in fabric, and the design may be even slower. Austin bachimanchi@gmail.com wrote: > Hi all, > i am designing a circuit for a cryptogrpahy application based on > elliptic curve cryptography.I want to know one thing when i implement > the same circuit on different devices from different families results > are as follows. > with spartant3 i m getting max. frequency as 89 Mhz > with virtex2 i am geting max. frequency as 123 MHz > but to my surprise with vortex-e-2000 i am getting max. frequency as > 48MHz. > can anyone explain why performance of virtex-e-2000 is like this. > > > thanks. > > > Regards > Ramakrishna Bachimanchi >
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