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
Frank Buss wrote: > austin wrote: > > >>The 65nm V5 family is only second to Intel's 65nm product offering in >>complexity and process sophistication (and perhaps we are, in fact >>first, since Hi-K is only in their 45nm line). They have dual core, we >>have dual core. They have neat IP, we have neat IP. They have some >>large die (with > 1 billion devices), and so do we. > > > The difference between Xilinx and Intel chips is that the decimal point for > the price of the Xilinx parts is at the wrong position :-) Intel's new Atom series looks interesting - good horsepower and very important : FANLESS - so they are back on the radar for embedded applications. > I would like to use more FPGAs, but most of the time a fast CPU or > microcontroller and maybe a small external FPGA, is cheaper and solves the > problem, too. > > The PSoC concept from Cypress looks interesting: Lots of high-level analog > and digital blocks, which can be connected at runtime and a fast CPU, all > in a cheap and low power package: > > http://tinyurl.com/43qz49 > > Of course, you can't compare this to a Virtex, with which you can do high > speed and parallel calculations, but for many products a small FPGA with a > small CPU, some integrated analog components and standard interfaces, like > I2C, USB, ethernet etc., would be nice. Atmel & Triscend tried that, and flopped. The real problem is not technical, it is commercial : You cannot nail-down three resource sets, and still have a large enough market footprint. FpSLIC for example, you HAVE to hope the small AVR is going to be enough (Code,Mips) for the life of the product, and hope that the FPGA is large enough for the added stuff. Miss on any one of those 3, and you are a dead-duck. Small uC do not tend to _need_ FPGA support, so that's another miss-match. Then the process is generations behind the point solutions... Too many compromises = market flop. The Atmel AT91CAP series is much smarter : It has a larger core (ARM7, ARM9), and is lower power than FPGA, and targets highish volume downstream-feeder off FPGA designs. So, it's smarter to choose the best commercial microcontroller, and then mop-up what else you need, in a FPGA. If your market is large enough, someone will craft a chip, with your extras included, and the fpga can be discarded. -jgArticle: 130951
On Apr 6, 2:53=A0pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Frank Buss wrote: > > austin wrote: > > >>The 65nm V5 family is only second to Intel's 65nm product offering in > >>complexity and process sophistication (and perhaps we are, in fact > >>first, since Hi-K is only in their 45nm line). =A0They have dual core, w= e > >>have dual core. =A0They have neat IP, we have neat IP. =A0They have some= > >>large die (with > 1 billion devices), and so do we. > > > The difference between Xilinx and Intel chips is that the decimal point = for > > the price of the Xilinx parts is at the wrong position :-) > > Intel's new Atom series looks interesting - good horsepower and > very important : FANLESS - so they are back on the radar for embedded > applications. > > > I would like to use more FPGAs, but most of the time a fast CPU or > > microcontroller and maybe a small external FPGA, is cheaper and solves t= he > > problem, too. > > > The PSoC concept from Cypress looks interesting: Lots of high-level anal= og > > and digital blocks, which can be connected at runtime and a fast CPU, al= l > > in a cheap and low power package: > > >http://tinyurl.com/43qz49 > > > Of course, you can't compare this to a Virtex, with which you can do hig= h > > speed and parallel calculations, but for many products a small FPGA with= a > > small CPU, some integrated analog components and standard interfaces, li= ke > > I2C, USB, ethernet etc., would be nice. > > Atmel & Triscend tried that, and flopped. The real problem is not > technical, it is commercial : You cannot nail-down three resource sets, > and still have a large enough market footprint. > > FpSLIC for example, you HAVE to hope the small AVR is going to > be enough (Code,Mips) for the life of the product, and hope that > the FPGA is large enough for the added stuff. > Miss on any one of those 3, and you are a dead-duck. > > Small uC do not tend to _need_ FPGA support, so that's another > miss-match. Then the process is generations behind the point > solutions... =A0Too many compromises =3D market flop. > > The Atmel AT91CAP series is much smarter : > It has a larger core (ARM7, ARM9), and is lower power than FPGA, > and targets highish volume downstream-feeder off FPGA designs. > > So, it's smarter to choose the best commercial microcontroller, and then > mop-up what else you need, in a FPGA. > If your market is large enough, someone will craft a chip, with your > extras included, and the fpga can be discarded. > > -jg Jim, you hit the nail on the head. That's the dilemma in our product planning. There are thousands of interesting ideas, but we need to always hit a market of a few hundred million dollars, otherwise we are just diluting our efforts and miss the better opportunities. But that leaves openings for the "little guys", the Actel and Atmel, who can (and must) go after smaller fry. It is often very frustrating when neat ideas get shot down by "where is the multi-million dollar market ?". But on the other hand, the standard FPGA has grown into many new markets, just by its fundamental versatility. Peter AlfkeArticle: 130952
From my experience you may need to increase your heap/stack in the linker script.Article: 130953
why all this fuss about the need for new system level languages and higher abstraction...systems were also heterogeneous in the past but only few experts did implement them...hardware and software designers were working apart. partitioning was done from the start. despite this engineers were still delivering the required products. why people are becoming so desperate and obsessed to have higher and more abstract languages, to perform *pure* software-hardware codesign. is it because of time to market issue? the complexity of and difficulty in designing the modern applications with their required constraints? the complexity of the hardware? limit of mono-core processors and von Neumann model? the nature of the current applications being computation intensive? the high revenue market of the modern applications such in video and gaming industry ? lack of and expensive qualified hardware designers? complexity of the proposed hardware platforms and need for concurrent hardware and software expertise? minimising the design cost...?what are in your opinion the main factors were there not tools to implement hybrid heterogeneous architectures in the past? how people use to simulate them? why not maintaining the same approach and methodology without PANICKING the EDA community to develop urgently more abstract System level languages and associated tools as it is happening nowadays. i am keen in the evolution but just can't understand why all such rush is about thanksArticle: 130954
"maverick" <sheikh.m.farhan@gmail.com> wrote in message news:6ec2919f-5f49-4ed6-88f7-3b2741de5651@24g2000hsh.googlegroups.com... > Thanks everyone for your replies. I think I need to add some more info > here. Infact, I am not trying to secure my FPGA design or bitstream > here. I am trying to prohibit generation of multiple copies of the > same system. Add a 0402 pullup resistor to an unused pin or just short two FPGA pins. Either of these is hard to see on the board if done properly, but easy to detect from inside of the device if you know what you are looking for. Not as secure as the methods Antti mentioned, but much easier to implement. Which PCI bridge is the card using? Are you sure that there is no EEPROM attached to it? /MikhailArticle: 130955
On Apr 4, 9:19 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Nico Coesel wrote: > > craig.tay...@xilinx.com wrote: > > >>Hello all, > > >>I am a Quality manager atXilinx, and I have asked to provide > >>specific > >>guidance on the question of counterfieting. I would like to start by > >>saying that the ONLY way to protect yourself is to purchase your > >>devices from an authorizedXilinxdistributor. A list can be found > >>at > >>this link.http://www.xilinx.com/company/sales/ww_disti.htm > > >>If you a buying outside of this channel you are taking on a fair > >>amount of risk. Over the past 1.5 yearsXilinxalong with the Dept > >>of > >>Homeland Security have become aware of an escalatng issue out of SE > >>Asia, whereXilinxcomponent are being marked up for sale into grey > >>market channels. We currently are looking into how to limit this > >>activity. > > > Simple, burn the batch code (fabrication date) and speedgrade into the > > die and make them readable through JTAG. > > Speed is not known until final test, so that would require OTP fuse > capability, but that may already be there, at least at the factory level ?. > Now, a really clever counterfeit will clone this too, but it would > catch slippage,easypath, and really dumb (wrong die) attempts. > > Unique ID is another natural spin off, for expensive IP. > > -jg Please note, there is no way for an EasyPath device to be mistaken for an FPGA device. EasyPath devices are marked with a custom part number that is unlike any standard Xilinx FPGA part number. Cheers, PatrickArticle: 130956
pdorsey@gmail.com wrote: > > Please note, there is no way for an EasyPath device to be mistaken for > an FPGA device. > EasyPath devices are marked with a custom part number that is unlike > any standard Xilinx FPGA part number. ..and you think clean/re-labeling the package is a high-tech operation ? Quite routine in the far east.... -jgArticle: 130957
Hi I am trying to squeeze some read speed out from CF using systemACE and xilinx standard libraries, but the performance is really really bad read using xilfats 400KB/s read using systemace low level (direct sector reads) 1MB/s I have found NO information in any Xilinx documentation what speeds can be excpected to be achived with systemACE the 400KB/s looks like really miserable :( i am using the CF card supplied by Xilinx, that is have not yet done testbenching with other better CF cards, but i would like to know if such testing has been done, and if there is hope of BIG speed improvment when using some high-speed CF cards. if i look at the spec of the CF card supplied by Xilinx it has 2ms controller overhead (command to data ready delay) this would limit access to maximum 500 sector reads commands sent to the CF, but we need to add time for data transfer too, but this could explain the 1MB/ s measured speed AnttiArticle: 130958
Jim Granville wrote: > The Atmel AT91CAP series is much smarter : > It has a larger core (ARM7, ARM9), and is lower power than FPGA, > and targets highish volume downstream-feeder off FPGA designs. The downside is the high setup cost and you can't update the programmable logic part with a firmware update. The FPSLIC looks interesting, but the CPU and peripherals are a bit limited. > So, it's smarter to choose the best commercial microcontroller, and then > mop-up what else you need, in a FPGA. Yes, maybe this is the best idea. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 130959
dalai lamah wrote:
> Un bel giorno David Brown digiṭ:
>
>> The reason (I presume) they don't use bittorrent is basically because it
>> would not work for this sort of software. Only a small proportion of
>> users would be interested in using bittorrent downloads in a
>> professional setting, and only a few of these would be allowed by their
>> IT department, and even fewer would leave the torrents running with fast
>> enough upload capacity for other downloaders to see decent download
>> speeds. Add to that the common misunderstandings of bittorrent ("How do
>> we know we are getting the proper software - maybe the file is corrupt,
>> or it's picked up a virus from some sharer's PC?" and "Isn't bittorrent
>> only for (sic) pirated files?") and some ISP's brain-dead
>> anti-bittorrent schemes to cheat users out of their bandwidth, and you
>> get a very poor choice of distribution method for this kind of software.
>
> BitTorrent would be an alternative way, not the only way for the download.
> Then everyone would choose their preferred way, and I bet that at least a
> half of the users would choose the torrent. Many companies distribute their
> professional software with either http/ftp and BitTorrent (OpenOffice and
> most Linux distributions are the first that come to mind).
>
I am a good example of a professional user of OpenOffice and several
Linux distributions. Most professional users of this sort of software
use it both at home and at work. When downloading at home, I use
BitTorrent. It's my bandwidth - if I want to spend my upload bandwidth
sharing the torrent with other people, and saving the disto some network
bandwidth costs, that's my choice. When downloading at work, I don't -
no sane IT manager allows P2P networking on their office LAN, and even
if it *were* allowed, no sane IT manager would let their upstream
bandwidth fill up with torrent uploads that are not of benefit to the
company.
There is the middle area of SOHO users who might use bittorrent even
though they are "at work" - on a very small LAN it might be appropriate
to allow some controlled P2P. But even there, you'll find very few
professional users who are happy to leave the bittorrent uploading for
days on end, which is needed to make a positive contribution to such
large torrents at typical ADSL speeds.
That's why broad-target Linux distributions like Fedora are available
with bittorrent, while strictly professional target distributions like
RHEL are not - while some people would try using bittorrent, the rates
would be so slow because the philosophy of bittorrent does not work for
that kind of software.
Article: 130960On 7 Apr., 03:08, Karl <karl.polyt...@googlemail.com> wrote: A similar thought: While I think it is benefitial to design in higher abstraction level, I currently do not see the need for new languages. The tools are far from exploiting the capabilities of the exisiting languages. * where is VHDL2006/VHDL2008 support? * why does XST change the type of all ports to std_logic when creating timing models? How am I supposed to create abstract interfaces? * where is synthesis of multiple wait statements per process? (think about it: This is a major abstraction step when designing state machines) * Why does XST discourage the use of records, arrays, etc. in ports? Even std_ulogic is discouraged! (Hello, there are no resolved signals in modern FPGAs anymore) * How about evaluating processes that only have a singe infinite wait statement at the end during compile time? This is a nice way to compute lookup tables an initial value assignment. So, why does the industry believe it can do all this with a new language if it is apparantly impossible to implement for the existing languages that can specify this bahaviour for decades. Kolja SulimmaArticle: 130961
> I currently do not see the need for new languages. The tools are far > from exploiting the capabilities of the exisiting languages. But, the tools could do a better job if they had a better language that more easily allowed you to specify what you really want to do. > snip * stuff about XST * XST isn't the only synthesis tool you know ;-) JonArticle: 130962
On 7 Apr., 12:41, Jon Beniston <j...@beniston.com> wrote: > XST isn't the only synthesis tool you know ;-) Indeed. But half of the issues are dictated by the backend tools. I hear that Leonardo supports multiple wait statements. I will eventually have a look at that. KoljaArticle: 130963
"Kolja Sulimma" <ksulimma@googlemail.com> wrote in message
news:9bb25b03-43c3-4b8e-b27b-4128e855f809@59g2000hsb.googlegroups.com...
> On 7 Apr., 12:41, Jon Beniston <j...@beniston.com> wrote:
>> XST isn't the only synthesis tool you know ;-)
>
> Indeed.
> But half of the issues are dictated by the backend tools.
>
> I hear that Leonardo supports multiple wait statements.
> I will eventually have a look at that.
Make that Precision.
process
begin
wait until clk'event AND clk='1';
output_signal <= 0;
while (input_signal < 6) loop
wait until clk' event AND clk='1';
output_signal <= output_signal +1;
end loop;
end process;
Hans
www.ht-lab.com
>
> Kolja
>
Article: 130964David Brown wrote: > > some network bandwidth costs, that's my choice. When downloading at > work, I don't - no sane IT manager allows P2P networking on their > office LAN, and even if it *were* allowed, no sane IT manager would > let their upstream bandwidth fill up with torrent uploads that are > not of benefit to the company. > Who are these mythical sane IT managers? :-)Article: 130965
Symon wrote: > David Brown wrote: >> some network bandwidth costs, that's my choice. When downloading at >> work, I don't - no sane IT manager allows P2P networking on their >> office LAN, and even if it *were* allowed, no sane IT manager would >> let their upstream bandwidth fill up with torrent uploads that are >> not of benefit to the company. >> > Who are these mythical sane IT managers? :-) > Me :-) Draconian rules (such as no Internet Exploder allowed, no P2P, no skype, no email that hasn't passed through our virus scanner and exe-file killer mail server, no Vista, and preferably no MS software other than Windows), enforced by threats with wire cutters, are the key to keeping a network secure and reliable with minimal time and effort. Of course, it's possible that all other IT managers are insane...Article: 130966
It is true that it is fairly simple for the current markings to be easily removed and remarked. I have seen several examples of where this has happened. The issue is that we can really not provide tools that would allow legitimate users to validate the materials they purchased outside of our sales channels without providing that same information to the counterfieters. The new generations of Xilinx component are seeing the beginnings of factory level in chip security features. There is no viable way to test components to determine authentcity in the field. There are some visual aspects in the marking but that too can be replicated. These are the reason why I suggest purchasing through a Xilinx authorized distributor. I personally do not know how to answer the question on how to deal with excess inventory. It is more of the planning question. I know that there are situations where folks sell this material into an independent distributor, or other broker businesses. I am saying from the perspective of care custody and control, that Xilinx is unable to support materials purchased from this type of transaction. I am not saying that all independent distributors or brokers deal in counterfiet materials. If you have a source that has historically performed well for you, please consider staying with trusted sources. Over the next year Xilinx is planning to make several security enhancments to our device marking that will make counterfieting much more difficult.Article: 130967
Hi! everyone I have a very basic problem. I know that the 6-position DIP switch on the ML403 board can control the configuration address and FPGA configuration mode. On the ML310 board, I am not sure where can set the FPGA configuration mode. I want to set the configuration mode of my ML310 borad as the SelectMAP mode. Please tell me how to set its FPGA configuration mode. Thanks very much!Article: 130968
On 7 Apr., 16:17, grant0920 <grant0...@gmail.com> wrote: > Hi! everyone > > I have a very basic problem. I know that the 6-position DIP switch on > the ML403 board can control the configuration address and FPGA > configuration mode. On the ML310 board, I am not sure where can set > the FPGA configuration mode. I want to set the configuration mode of > my ML310 borad as the SelectMAP mode. Please tell me how to set its > FPGA configuration mode. Thanks very much! try reading the manuals! AnttiArticle: 130969
On 4$B7n(B7$BF|(B, $B2<8a(B10$B;~(B51$BJ,(B, Antti <Antti.Luk...@googlemail.com> wrote: > On 7 Apr., 16:17, grant0920 <grant0...@gmail.com> wrote: > > > Hi! everyone > > > I have a very basic problem. I know that the 6-position DIP switch on > > the ML403 board can control the configuration address and FPGA > > configuration mode. On the ML310 board, I am not sure where can set > > the FPGA configuration mode. I want to set the configuration mode of > > my ML310 borad as the SelectMAP mode. Please tell me how to set its > > FPGA configuration mode. Thanks very much! > > try reading the manuals! > > Antti Hi! Antti I have read the manuals. I think the configuration mode can be setted by using the SYSACE CFG SW3. But the result doesn't seem to my expectancy so that I want check if the setting is correct. Is my setting right?Article: 130970
On Sun, 6 Apr 2008 04:53:23 -0700 (PDT), Antti <Antti.Lukats@googlemail.com> wrote: >On 5 Apr., 19:37, Antti <Antti.Luk...@googlemail.com> wrote: >> On 5 Apr., 14:41, Brian Drummond <brian_drumm...@btconnect.com> wrote: >> Hi Brian, >> >> the story goes even more fascinating (or frustrating)... > >status: ALL ISSUES SOLVED > >I wonder how many guesses what the problem really was? :) >sure, pure human error, there WAS dependancy on the data being pushed >into FPGA >there should not have been but it was, because some signal had wrong >name. So we were all looking in the wrong place... it happens! >Antti >hope the thread wasnt so entirely boring :) Not at all ... Glad you got it sorted. - BrianArticle: 130971
austin wrote: > I am aware of a lot of work by the XST folks, as well as by our > partners, to recognize things like FIFO's, DSP48's, etc. automatically > without having to specifically instantiate the blocks. I wasn't aware of any such initiative. I'd be interested in how this would work. A FIFO seems complex enough that it would be pretty hard to infer. It can't really be described simply without coding the pointers and flag logic. The only really abstract way I could think of describing a FIFO is through a function call like push() and pop(), which would be a nice abstraction but would preclude the code from working on other synthesizers. -KevinArticle: 130972
Un bel giorno David Brown digiṭ: > When downloading at work, I don't - > no sane IT manager allows P2P networking on their office LAN, and even > if it *were* allowed, no sane IT manager would let their upstream > bandwidth fill up with torrent uploads that are not of benefit to the > company. > > There is the middle area of SOHO users who might use bittorrent even > though they are "at work" - on a very small LAN it might be appropriate > to allow some controlled P2P. But even there, you'll find very few > professional users who are happy to leave the bittorrent uploading for > days on end, which is needed to make a positive contribution to such > large torrents at typical ADSL speeds. We use BitTorrent in a controlled, request-based way. Only one PC is allowed to connect in/out to high ports, and only the administrator (and some chosen ones) can run BT and start a download. I think that a lot of small companies do that. Of course for medium and big organizations it can't work, but I repeat - this would be an *additional* option for the download, almost at zero cost, and without any drawback. If you don't want to use it, then don't, and vice versa. -- emboliaschizoide.splinder.comArticle: 130973
John_H wrote: > Jon Elson wrote: > >>This was a very small batch of parts, so it doesn't make much sense to >>spend a lot of money on it. I still have no idea whether there was any >>funny business, or these parts were just mishandled in some way to cause >>them to deteriorate. A number of them would not do the master mode >>configuration, so that can't be a speed grade problem. But, half of >>them work! I still don't know if I have some kind of process problem >>here in my shop, but I am coming around to think it is not something I >>caused here. >> >>Jon > > > Some ideas: > Did you bake the parts before assembly? > Are you hand-soldering the deviecs? I did not bake the initial run of parts before IR reflow. They were "pretty" dry, however. I did hand solder the replacements, and had one dead chip that way, too. I don't think this is a moisture problem. I have had such a low rate of possible ESD problems in the past (maybe 3 chips in 10 years) that I doubt I suddenly have ESD. Anyway, I have made enormous progress on migrating to Spartan 2E, so I won't be buying any more of these 5V Spartan parts. It means throwing away some unpopulated boards, but it is worth it to not have to deal with these failures and rework. JonArticle: 130974
Jim Granville wrote: > Jon Elson wrote: > >> This was a very small batch of parts, so it doesn't make much sense to >> spend a lot of money on it. I still have no idea whether there was any >> funny business, or these parts were just mishandled in some way to >> cause them to deteriorate. A number of them would not do the master >> mode configuration, so that can't be a speed grade problem. But, half >> of them work! I still don't know if I have some kind of process >> problem here in my shop, but I am coming around to think it is not >> something I >> caused here. > > > That reminds me of another scam : Quantity padding. > > Someone in the supply line decides to 'pad the numbers', and > the report I remember had lower failures on the end of tubes, and > higher failures (non blank OTP devices) in the centres. > They hope the user will shrug it off. > > Can you pop the top on some failures and look at the die ? I've never been very successful at opening up Xilinx pacakges. The epoxy is harder than steel (well, at least really abrasive) and I don't have something that will dissolve it. These are TQFP's, so there's no metal lid. They come in waffle trays, so there are a lot of "ends" to start from. What you say MAY make some sense, however, as the first batch of boards I did used about half the tray without any bad ones! Then, the second batch I got 50+% bad. Very curious! Jon
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