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
In comp.arch.fpga Roland Paterson-Jones <rpjones@hursley.ibm.com> wrote: : brian_n_miller@yahoo.com wrote: :> rolandpj@bigfoot.com wrote: :> > I like to to view the problem as an extension of HotSpot/JIT. :> > ... Why not do the same thing, but right down to the hardware? :> :> Reliability. If an FPGA fails to reconfigure itself properly, :> then how to recover? : Forgive my innocence, but why is this perceived to be a problem? Component reliability is a general problem with all parallel computers; the main idea is that there are more components: if each has a fixed probability of failure then the chances of failure occurring in a parallel computer are greater than in a serial one - due to there being more components to fail. : It might be the case that reconfigurability is flaky at the moment but : this just has to be fixed to make dynamic reconfigurability viable. Well, perfect reliability is not practically attainable, and the more components the computer has the more likely failures become. FPGAs generally have high component counts, though x86 processors aren't exactly low... Pesonally I think the problem is best dealt with by mainly through the use of fault-tolerant software, though attempts to make the hardware more resilient obviously have a role to play. What appears to be needed to trigger the long-awaited programmable logic revolution, is the proverbial 'killer application' - where people are prepared to buy programmable logic components in order to run particular software. Current the nearest thing to this is circuit design and prototyping - which will probably remain something of a minority activity. The application can't be too specialised; people buy purpose-build graphics and sound cards, rather than a component which is capable of being programmed to do anything. At one point I wondered if speech recognition would provide such an application. These days I think any vendors who offered a hardware solution (and these appear to be uncommon these days) would offer specialised DSP hardware, rather than an FPGA-based solution. I am still not sure whether Java will be terribly pivotal in this area. It /may/ be good, because it's fairly general purpose. Would a partly FPGA-based approach be the best way to achieve maximum speed? I'm not yet convinced - it may be that a vaguely conventional design oriented towards Java bytecodes would be faster, at least on your 'average' Java application. Reconfigurability will probably always have a certain performance cost associated with it - and I'm not sure whether running Java is a general-purpose enough application for it to be able to make use of that reconfigurability fully enough to justify its costs. If much of the programmed circuitry winds up being the same old "execute bytecode" program, then having this in programmable logic will only slow things down. The best way of using FPGAs to accelerate Java /may/ be to use them to prototype chips specifically designed to run Java bytecode. -- __________ |im |yler The Mandala Centre http://www.mandala.co.uk/ tt@cryogen.com Where there's a will, I want to be in it.Article: 16526
rrohatgi@kendra.com wrote: > > In article <3744ADBA.9E5F4A96@yahoo.com>, > In my experience, product limitations are analog or power supply > related more than something I can put into an FPGA. I plan to deal with the analog limitation by making the analog I/O a daughter board. There will be diffferent add ons for different needs. With two daughter board sites, that should provide a lot of flexibility. I don't understand what you mean about power supply limitations. Do you mean the board requires too much current from the supply or too many voltages? > > it. That is why I am building this board. I think there will be a > number > > of people who would like to use the DSP in conjunction with a good > FPGA. > > Sounds like you've already made up your mind :-) Acutally, I am building the board because a customer is paying me to build it. But I am trying to put in useful extra features so that I can sell it generally. So the tradeoff depends on how useful a feature is. I can shave a good $50 to $100 off the price of the board if I leave off the big FPGA. I am sure that $100 cheaper price is a useful feature. So the choice is based on whether the big FPGA will be more useful than $100. > > using a Lucent ORCA part instead of a Xilinx part. It would appear > that > > Altera, last I checked, had free software for entry-level parts like > EPF8282A. Plus their software works and is easy to use. Right now the choice is between the Lucent OR3T or the Xilinx Spartan, XC4000XLA, or Virtex. The Lucent gives me the best trade off between price, performance and I/O pins. The Xilinx is certainly a more familiar name. But the Lucent software is only $100 (or free if you beg) for a package that supports up to 30K gates and VHDL. So I haven't made up my mind. But I am looking for compelling arguments on either side. > Good luck, > -rajeev- Thanks. I'll let you know when it is done. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 16527
Austin Franklin wrote: > > > Austin Franklin wrote: > > > > > > I just thought of one SMALL problem... I don not believe Virtex > supports 5V > > > PCI??? > > > > XAPP 133 (dated Oct 21, 1998) claims so. Is it incorrect? > > They may claim it does....but.... They don't provide a VCCIO pin, which is > to be used for the clamp diodes...and it can't technically meet spec if > they don't. PLX has the same problem with the 9054...it's a 3.3V part, > with no VCCIO pin... > > Any PCI interface that is NOT 5V powered, and is used in a 5V environment, > has to have VCCIO...and same is true for any other voltage variants... > > Austin I get email from the PCI SIG. They were discussing just this aspect of the PLX9054 chip. I believe that the consensus was that you are not required to clamp in a 5 volt environment, while you are in a 3.3 volt environment. The issue was whether you had to clamp in a 3.3 volt environment. One poster quoted the spec saying you had to clamp. A PLX representative posted a quote that said you didn't. A third poster claimed that the PLX quote refered only to 5 volt operation. In any case, PLX seems to think their chip is fully compliant with the spec. I haven't verified any of this. So perhaps you can tell me who is right. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 16528
Try using a guide file. Look for a file with extension .gyd. Edit it with your pinout and save it on a different directory. Then go to Design Manager menu Design->Implement->Options and choose custom guide file and browse your new gyd file (I am using F1.4M but I think 1.5 must be similar.) Tximo wrote: > > Hi all, > > I am trying to synthsise a design with Xilinx Foundations F1.5, with > some inputs and outputs. I have a constraint file to locate every > signal in a pin, but I get the error message: > > ERROR:baste:263 - The LOC constraint "P68" (a IOB location) is not valid > for > symbol "linea_lect.PAD" (pad signal=linea_lect), which is being > mapped to the > following site types: > CLKIOB > > My signal is fixed at PIN 68, a normal IOB, but the synthesis tool map > the signal to a clock, and I don't know why. > > Anyone has any idea? > > Thanks to all for reading my message and sorry for my english.Article: 16529
tt@cryogen.com wrote: > > What appears to be needed to trigger the long-awaited > programmable logic revolution, is the proverbial 'killer > application' - where people are prepared to buy > programmable logic components in order to run particular > software. Pure fantasy. There won't ever be such an application. > These days I think any vendors who offered a hardware > solution (and these appear to be uncommon these days) would offer > specialised DSP hardware, rather than an FPGA-based solution. Exactly. And DSPs sequentially execute software instruction streams like any other processor. > Would a partly FPGA-based approach be the best way to > achieve maximum speed? Which part? --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---Article: 16530
I've been using FPGAs for several years now in applications where a rack
of DSP processors is outperformed by a single board with a couple
FPGAs. Some examples:
A doppler weather radar demodulator and pulse pair processor - was a
rack of DSP cards (approx 20), couldn't keep up with data in real-time.
Replaced by one annapolis board with 4 4013's. Operates in real time
A radar simulation system. Impossible to do with just DSP
processors due to 40 MHz data rate and complicated processing
requirement. System implemented in 8 4025's, runs in real time
QAM demodulator. DSP TMS320C50 barely capable of baseband half
duplex. FPGA (4020) simultaneously handles both modulation and
demodulation, has better filtering and does downconversion from IF.
In each of these cases, an ASIC would have also worked, but the volumes
did not support the cost of an ASIC solution. Now, I'm not sure a
'killer' app is going to fall on us, but the fact is that FPGAs are
finding their way into products as DSP processors more and more. This
is mostly because there are more and more applications that a DSP
microprocessor can't hack the processing throughput requirements. A
killer app would necessarily be one with large volumes, which would make
an ASIC solution attractive unless there was a need for the
reconfigurability that could not be satisfied more economically by an
ASIC capable of handling multiple operational modes. Personally, I find
the 'killer app' to be the scores of onesy-twosy DSP applications that
are pushing the envelope of DSP microprocessor capability. There's lots
of those out there (look how many players there are in the DSP micro
board market), and each one has a different algorithm, a different
application or a different set of requirements.
brian_n_miller@yahoo.com wrote:
> tt@cryogen.com wrote:
> >
> > What appears to be needed to trigger the long-awaited
> > programmable logic revolution, is the proverbial 'killer
> > application' - where people are prepared to buy
> > programmable logic components in order to run particular
> > software.
>
> Pure fantasy. There won't ever be such an application.
>
> > These days I think any vendors who offered a hardware
> > solution (and these appear to be uncommon these days) would offer
> > specialised DSP hardware, rather than an FPGA-based solution.
>
> Exactly. And DSPs sequentially execute software instruction
> streams like any other processor.
>
> > Would a partly FPGA-based approach be the best way to
> > achieve maximum speed?
>
> Which part?
>
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---
--
-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
Article: 16531Hi, I am working on the translation of C to EDIF file format for synthesis to FPGAs/ASICS. In this respect I need to write a Translator from a subset of C (say only mathematical operations) to EDIF. Please do let me know EVEN if you have a hint or know something vaguely. Any references will be of great use. ALso If there are any commercial tools in the industry/research community , I am interested . Price is not a constraint. Thank you all, Pranav R. --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---Article: 16532
Zoltan Kocsi wrote: > Rickman <spamgoeshere4@yahoo.com> writes: > > > Perhaps there is a third choice which simply has to do with marketing > > and cost. If I had the choice of selling one system to say 40% of the > > market or increasing my market share to, say 45%, by selling two systems > > and doubling my development costs, I think I would choose the one > > platform approach. > > Well, this explains why would a company go Windows only and ask good money > for the Windows SW. However, when you have a Windows version *and* a > unix version (that is, dev. cost is doubled) then what's the business > behind giving away the Windows version (which costed you a lot) and > not doing the same with unix ? If you want increased chip sales, then > you would give away the unix one too - every chip sold creates money. > In fact, you would port the unix version to Linux (this would cost you > virtually nothing), put on your web site with big red letters screaming > NO SUPPORT - AS IS or YOU CAN PURCHASE SUPPORT FOR LOTS OF $$$ (which is > already the case with the downloadable Windows version anyway) thus > selling even more chips (Linux die-hards will all buy *your* chips for > you are the only one supporting them). It ain't happening, somehow. A chip vendor has to put TONS of money into every variation of the software they produce. When we talk about Unix versions, that is not one version of the software that runs on every machine. A new version is required for each variant of Unix and a new binary is required for each type of CPU. And most EDA under UNIX is done for the big buck, high speed platforms. That is why the Unix versions cost more. And all that is on top of the fact that the vendor most likely sells more Windows copies than the Unix copies. > > My guess is that in the last 3 years or so, the vendors are seeing that > > customers who at one time were Unit die-hards, are now willing to use > > Windows. > > Because they have to. Vendors (IMHO) don't *see* the situation, they > *create* it. Last year on DAC on the Linux vs. NT shootout (which turned > to a unix vs. NT one) the audioence seemed to very much favour unix over > NT - of course they may have been a very biased audience. I don't agree with that. If the vendors told you they were only going to sell systems that you had to use standing on your head, you would say... NO THANKS! They would sell a lot less and they would very quickly change the software back. I can't say anything about the audience, but I know you can still buy most any EDA tool you wish to run under Unix. So competition will determine which system is "better". > > I would also expect that a lot of potential Windows customers > > would not be willing to go to Unix. > > This is probably true. > > > Whenever the vendors are asked about Linux versions of their software, > > they say they will do it when the customer demand is there. The bottom > > line is that they will sell what customers are most likely to buy. > > Well, if they are asked about it, then there must be some demand ? > Customers buy what they are sold. > You want to buy a gray hat. You ring the vendor, they say they do not > make gray ones, you should buy a blue one. You *need* that hat, so you > buy the blue one. The hat vendor can see that hat sales is not hurt by > selling blue ones only (all in all, everybodey buys a hat) so they will > tell everyone who rings them about gray (or green or red) hats, that the > customer demand is blue, buy that one. They will because they have no > choice. If they are very desperate, they can go to the other hatshop, > which would sell them the same blue hat with an albeit not grey, but > yellow or brown overcoat, for 3 times as much. A few engineers asking about Linux is not a bunch of companies saying they want to buy copieS of Linux software. No you can't buy what they don't sell, but if enough people go to several stores asking about gray hats, the guy who has the dullest shade of blue will get most of the sales. I don't need to explain how this will get everyone into making the gray hat if that is what people really want to BUY. > > I would also point out that Unix development is more expensive. The > > machines cost more, the software costs more, and perhaps the developers > > cost more (not sure about this last one). > > Well, not necessarily true. A PC running unix costs the same as a PC > running NT, an Alpha costs the same running either. Machines which > cost more may not run NT (for Microsoft does not supply NT for them) but > it is not the problem with the machine, it's a problem with NT. Refer to the first paragraph. Not many EDA vendors are pumping out Unix to run on a Wintel type platform. The main excuse for going Unix is the power of the hardware. That is what drives the cost. > The development software cost is a non-issue. On one hand, you have > a plethora of free tools for the unix world, (which, incidently, have been > ported to Windows) but even if you didn't, a multi-billion dollar company > would not choke on the one-off cost of buying the devtools. Whether a > compiler is more expensive for unix than it is for Windows, I don't know, > maybe. Still, I don't think that price differences would be so high that > a big EDA company couldn't fork it out. You seem to think that once you buy the software, you are done paying. Even the free software has support costs. Isn't that how companies stay in business giving away software? I know from experience that most every tool costs MUCH more on a non-Wintel platform. I was once quoted $1500 for ABEL (I'm showing my age) on a Unix machine vs. $500 on a PC. > Since Linux came up: well, I don't want to go into a Linux vs. NT argument, > USENET is full of it anyway. However, it is a fact that Linux supports all > architectures NT does plus a lot more, the system comes for free, all the > dev. tools come for free and even some commercial unix vendors support > (or anounced that they will support) running Linux binaries on their > native version of unix. These all mean that doing Linux development is > actually cheaper than Windows. Maybe I am showing my ignorance, but how do you run a non-native binary? If this is done via emulation, like running PC software on a MAC (or vice versa) I don't think that would be very workable for most tools. But I am not sure what you mean here. But again, the cost of the software is not the cost of business. Support and hardware is what costs, and costs, and costs. If you are talking about running your tools on a PC under Linux, then you most likely could get by cheaply. But that is not how they are doing it for now I as far as I know. They run the large expensive platforms with high dollar software. Perhaps you might want to give this a try yourself. I am a beliver in the Ayn Rann philosophy that if you can do something better than the other guy, you should be rewarded. That is why I am consulting now instead of working for a paycheck. > In addition, I fail to understand why a C programmer who can program say > a synthesis engine under windows would be much cheaper than one which > can crank out the same C code under unix. GUI-wise I doubt that X would > be inherently harder to work with than the Windows GUI or that it would > be less supported by GUI-generators and stuff. I might be wrong, of course. If you check the want ads, you will find that a company is hiring either Windows programmers (under many other fancy names), or Unix programmers. They are not interchangable. I am neither type of programmer, to much of an extent, so I won't try to explain the difference. I just know that maybe you could be both perhaps, but the two are not interchangable. But like I said, I don't know if the programmers cost more. I have never done a salary survey. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 16533
micheal_thompson@my-dejanews.com wrote: > Incidentally, is a schematic-viewer an essential tool in an HDL -> FPGA > environment, or can seasoned designers dispense with it? The answer to this question depends on what result you need. If you want correct logic and are not pushing the tool set for smaller and/or faster, it is not at all essential. If you need to push the tool set for smaller and/or faster you may need to understand a lot about what the synthesis tool is doing, a lot about how the map/placement/routing works, a lot about the details of the FPGA in question, and a fair amount of time needs to be spent to make it all work well. Time being money, it is also important not to do more of this detail work than what is really needed. -- Phil Hays "Irritatingly, science claims to set limits on what we can do, even in principle." Carl SaganArticle: 16534
Ray Andraka wrote: > > A killer app would necessarily be one with large volumes, which would make > an ASIC solution attractive unless there was a need for the > reconfigurability that could not be satisfied more economically by an > ASIC capable of handling multiple operational modes. One such need would be packet switching in the rapidly changing telecommunications industry. Upcoming protocols will allow for dynamically routed switches whose subsequent actions will be changed by the content of the packets themselves. Such a scheme seems like a natural fit for a reconfigurable computer. If the design were placed in an ASIC, a new ASIC would need to be produced as soon as additions were made to the protocol to eke out the last bit of throughput. A lot of new modems can be reconfigured for this very reason. This is not an example of a 'killer app' but rather another benefit of using a reconfigurable computer. Jonathan -- Jonathan F. Feifarek Consulting and design Programmable logic solutionsArticle: 16535
Since price is no object .... CLevel Design has two tools C2Verilog and C2VHDL (it's Verilog or VHDL out not EDIF). These tools are bundled and sell for $125K US. Get yourself a synthesis tool to get your EDIF out. Regards. GeneArticle: 16536
Peter Sels wrote in message <374AD7E5.D7A8493E@easics.be>... >Jean-Francois Richard wrote: >> I missed the original posting. Are you Jean-Francois Richard from Montréal, Canada? Martin FilteauArticle: 16537
Hi Tximo,
If you are using the foundation tools open the file using the HDL
editor. Look under TOOLS > Language Assistant > Synthesis Templates >
Global Clock Buffer in the menu bar. There you will find the following
cut and paste Bufg instantiation.
-- Shown Below
--Instantiating BUFGP on Input Port
-- INPUT_PORT: std_logic;
-- CLK_SIG: std_logic;
--**Insert the following between the
-- 'architecture' and 'begin' keywords**
component BUFGP
port (I: in std_logic; O: out std_logic);
end component;
--**Insert the following after the 'begin' keyword**
signal CLK_SIG: std_logic;
U1: BUFGP port map (I => INPUT_PORT,
O => CLK_SIG);
I hope this helps.
Best Regards
Terry
Tximo wrote:
>
> Hi all,
>
> I am trying to synthesize a VHDL design in the Xilinx Demonstration
> Board using Xilinx Foundations F1.5. This board has a XC3020A-PC68 and
> a XC4010E-PC84, although I am only using the XC4010E-PC84.
>
> In my design, I have a clock line, and my problem is that I want to
> assign this clock line to a Global Buffer (GCLK), but I don't know how.
>
> Anyone can help me?
>
> Thanks in advance.
Article: 16538Hi Michael, FPGA Express 3.1 has a schematic viewer in it. Can you upgrade to this? Best Regards Terry micheal_thompson@my-dejanews.com wrote: > > Hi, > I'm using Viewlogic's FPGA express (V3.00) for VHDL synthesis and I'd > really like to see the synthesised result in schematic form, at least > at the pre-fitted stage, so that I can develop a VHDL coding style > appropriate for synthesis - I'm neither a VHDL or FPGA guru. > > I don't have Viewlogics VISTA tool, which might be just the ticket, so > instead I'm wondering can I do it with Viewlogic's EDIF converter (EDIF > -> WIR) and its VIEWGEN utility ( WIR -> SCH)? > > Alternatively, do any of the FPGA vendor's fitting tools (Maxplus 11 > etc) provide a schematic view of the input EDIF file? > > Incidentally, is a schematic-viewer an essential tool in an HDL -> FPGA > environment, or can seasoned designers dispense with it? > > regds > Mike > > --== Sent via Deja.com http://www.deja.com/ ==-- > ---Share what you know. Learn what you don't.---Article: 16539
The code in your example also synthesizes correctly to a dual port RAMwith Exemplar Logic's Spectrum synthesis tool. I might suggest that amore compact way to write the line :> if CLK_IN'event and CLK_IN = '1' thenmight be to write it as :> if RISING_EDGE (CLK_IN) thenThis takes into account the the things you'd like to exclude fromtriggering this "if" clause, like transitions from X->1, for example. -**** Posted from RemarQ, http://www.remarq.com/?a ****- Search and Read Usenet Discussions in your Browser - FREE -Article: 16540
Rickman <spamgoeshere4@yahoo.com> writes: I got your arguments. I have to admit, they sound plausible, which, of course, does not change the fact that I'm pissed off for the unix tools being more expensive and Linux tools not being available. I am still not convinced about the business advantage of giving away the Windows tool for free - do they want to make money or not ? > Maybe I am showing my ignorance, but how do you run a non-native binary? > If this is done via emulation, like running PC software on a MAC (or > vice versa) I don't think that would be very workable for most tools. No, it's different. You have say Linux running on some Intel box. Then you get a SCO (Intel) binary. The actual userland code is the same, the system calls are different. You install iBCS and then Linux will serve SCO calls -> you can run SCO binaries under Linux without significant speed penalty. What I referred to was that AFAIK Sun stated that they'll support Linux binaries under Solaris. I don't know if it's only for Intel or they'll run Linux-SPARC binaries on Solaris-SPARC machines too. I've heard the same about SGI. > If you are talking about running your tools on a PC under Linux, then > you most likely could get by cheaply. But that is not how they are doing > it for now I as far as I know. They run the large expensive platforms > with high dollar software. Yes, the big boys do that. Little boys have to run Windows on Intel. My eternal problem is that I'm a little boy but I don't want to run Windows. I'd be happy with Linux on a higher-end Pentium box - all in all, I don't design multi-million transistor ASICs, I'm here in the sand playing with FPGAs. I bought an old Sun machine so that at least I can run tools under unix but you see a 7-year old MicroSPARC is just not in the same league as a Pentium-II or III. By the way, if you take a look at the Altera tool under Solaris SPARC or the Actel P&R under the same platform, you will see that these tools are actually Windows tools (they didn't even bother to change the 'for Windows' in the About box), coming full with Windows help and alike. So then what's exactly which makes these so expensive ? The fact that unix users are suckers, they got used to pay big bucks ? > Perhaps you might want to give this a try yourself. I am a beliver in > the Ayn Rann philosophy that if you can do something better than the > other guy, you should be rewarded. That is why I am consulting now > instead of working for a paycheck. I do have my own company, for the same reason. However, I know that I lack the knowledge necessary to crank out a high-quality FPGA synthesis tool therefore I don't try to be a EDA vendor. Not to mention the P&R, which I couldn't do even if I was the One and Only for obvious reasons. I am just a poor user who would like to use unix rather than Windows and not pay for extra hardware nor to pay too much extra for the software. I might very well be the only pervert who wants to design chips and run Linux in the same time, though. Zoltan -- +------------------------------------------------------------------+ | ** To reach me write to zoltan in the domain of bendor com au ** | +--------------------------------+---------------------------------+ | Zoltan Kocsi | I don't believe in miracles | | Bendor Research Pty. Ltd. | but I rely on them. | +--------------------------------+---------------------------------+Article: 16541
Xilinx made a press release which said they will support STAPL http://www.xilinx.com/prs_rls/staplspt.htm Best Regards TerryArticle: 16542
brian_n_miller@yahoo.com wrote: > rolandpj@bigfoot.com wrote: > > > > (The aim is) performance, of course. JVM is just an example. > > *yawn* Indeed. > But which functions or aspects of JVM operation would > clearly benefit from reconfigurability. As stated above, the JVM is merely an example. (IMHO from here onwards) The applicability of reconfigurable hardware to standard programming languages lies in its ability to maximally implement the inherent parallelism in every piece of code. Also, I suspect that you can fit more action into a single clock-cycle when you know exactly what you're going to do. The real question is how much inherent parallelism there is to exploit. As Tim Tyler has pointed out, JVM bytecode is not an ideal target, since fine-grained parallelism is not part of the architecture. However, empirical research seems to suggest that there is a large amount of inherent parallelism in serial programs (SPEC C benchmarks in that case - see a previous posting). This study ignores the speculative parallelisation (e.g. execute both branches of a conditional at the same time as evaluating a condition, then ignore one) that is possible with massively parallel hardware. Moreover, I believe it only makes sense to use this approach on computational performance bottlenecks (aka 'hotspots'). These tend to be inner loops, where parallelisation often inheres. > Time spent pondering reconfigurable > bytecode execution is likely wasted while the mainstream > continues to advance the speed and capacity of static chips. In the short-term, yes, and as you've guessed already, I just don't care. I'd prefer to waste time on an interesting project, even if it turns out to be an evolutionary dead-end, than to pore over the Pentium III circuit diagram looking for path optimisations. The proof is in the pudding. Let's cook. RolandArticle: 16543
----- Original Message ----- From: Zoltan Kocsi <root@127.0.0.1> Newsgroups: comp.arch.fpga Sent: Wednesday, May 26, 1999 10:59 PM Subject: Re: Xilinx M1.5 Crash > > By the way, if you take a look at the Altera tool under Solaris SPARC > or the Actel P&R under the same platform, you will see that these tools > are actually Windows tools (they didn't even bother to change the > 'for Windows' in the About box), coming full with Windows help and alike. > So then what's exactly which makes these so expensive ? The fact that > unix users are suckers, they got used to pay big bucks ? Ah yes the text in the 'about box' is a very definitive method of determining the native platform a tool was developed on. Unfortunately, at least for the Actel P&R I know for fact (I get to visit with the developers quite regularly) that the tools are all developed on Solaris first then ported to the PC environment. Sorry, but just could'nt let that go without a correction. Daniel K. Elftmann Actel Field Applications EngineerArticle: 16544
Hello, I have been looking for the CFI webpage but unfortunately most web sites that point to is www.cfi.org which is "College Foundation,Inc" instead. Does anyone knows the correct web page or where I can get a full documentation of the CFI - DR (Design representation). Thanks in advance. email: csoolan@dso.org.sgArticle: 16545
Rickman <spamgoeshere4@yahoo.com> writes:
> Austin Franklin wrote:
> > They may claim it does....but.... They don't provide a VCCIO pin, which is
> > to be used for the clamp diodes...and it can't technically meet spec if
> > they don't. PLX has the same problem with the 9054...it's a 3.3V part,
> > with no VCCIO pin...
> >
> > Any PCI interface that is NOT 5V powered, and is used in a 5V environment,
> > has to have VCCIO...and same is true for any other voltage variants...
I always thought the clamp to 5V is optional?
> I get email from the PCI SIG. They were discussing just this aspect of
> the PLX9054 chip. I believe that the consensus was that you are not
> required to clamp in a 5 volt environment, while you are in a 3.3 volt
> environment.
>
> The issue was whether you had to clamp in a 3.3 volt environment. One
> poster quoted the spec saying you had to clamp. A PLX representative
> posted a quote that said you didn't. A third poster claimed that the PLX
> quote refered only to 5 volt operation. In any case, PLX seems to think
> their chip is fully compliant with the spec.
>
> I haven't verified any of this. So perhaps you can tell me who is right.
Good Question.
I've slways thought you neede diodes to 3.3V/VCCIO in a 3.3V
signalling environment. Looking through the spec again, I see now that
it some parts open to interpretation.
Anyway, I haven't seen a 3.3V universal part yet that has more than
ONE VCCIO pin.Its supposed to be used for clamping only. The output
buffers are still driven by the 3.3V only, even in the 5V
environment.
Homann
--
Magnus Homann Email: d0asta@dtek.chalmers.se
URL : http://www.dtek.chalmers.se/DCIG/d0asta.html
The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html
Article: 16546Hi, Because of the high speed requirements to the designs I have implemented in FPGAs I mostly used schematic entry for sequential parts. I recognized the benefits of VHDL only for coders or state machines (maybe also some other parts) that had after compilation the same performance as schematic solutions. My question is: How can I constrain the compiler to make the results most similar to that I found with schematic ? Thanks Heinrich Fonfara fonfarah@ibmt.fhg.de http://www.ibmt.fhg.de/Article: 16547
In article <374C4E98.F6525DBD@yahoo.com>, Rickman <spamgoeshere4@yahoo.com> wrote: <...> > I don't understand what you mean about power supply limitations. Do you > mean the board requires too much current from the supply or too many > voltages? Too much current. <...> -rajeev- --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---Article: 16548
In comp.arch.fpga brian_n_miller@yahoo.com wrote:
: tt@cryogen.com wrote:
:> What appears to be needed to trigger the long-awaited
:> programmable logic revolution, is the proverbial 'killer
:> application' - where people are prepared to buy
:> programmable logic components in order to run particular
:> software.
: Pure fantasy. There won't ever be such an application.
Well, there /already/ are applications for which people are prepared to
purcahse FPGA boards: prototyping circuit design and evolutionary
computation spring to mind.
Running the s/w associated with these applicatoins /without/ hardware
acceleration is *possible*, but somewhat tiresome. However, these are
niche applications - something with more consumer volume would be good...
:> These days I think any vendors who offered a hardware
:> solution (and these appear to be uncommon these days) would offer
:> specialised DSP hardware, rather than an FPGA-based solution.
: Exactly. And DSPs sequentially execute software instruction
: streams like any other processor.
True, although I associate more parallelism with DSPs than conventional
general-purpose processors. Graphics-oriented hardware has more
parallelism still - while even a conventional processor generally has a
pipeline and is decoding one instruction, while predicting a branch on
another, while executing a third.
:> Would a partly FPGA-based approach be the best way to
:> achieve maximum speed?
: Which part?
/* Parallelisable parts - like this, for example */
Widget[] array;
for (int i=0; i++ < MAX; ) {
array[i] = new Widget();
}
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ tt@cryogen.com
May all your PUSHes be POPped.
Article: 16549Ray Andraka <randraka@ids.net> wrote: > > I've been using FPGAs for several years. But probably not ones which reconfigure during operation, which is what this discussion is about. > A rack of DSP processors is outperformed by a single board > with a couple FPGAs. Some examples: > A doppler weather radar demodulator, ...a radar simulation > system, ...QAM demodulator. Those are freakish niche applications. I thought we were talking about the applicability of reconfigurable hardware to mainstrean software systems. > I find the 'killer app' to be the scores of onesy-twosy DSP > applications that are pushing the envelope of DSP microprocessor > capability. There's lots of those out there. But you're not arguing for on-the-fly reconfigurability, are you? --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.---
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