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
> Don't confuse 8kHz sampling rate with 8kb/s data rate. They are very > different concepts! Rigth . it is just a typo .. 8x8 = 64kbps at least. thanksArticle: 95701
Hello Brian! Brian Drummond wrote: > On Sat, 14 Jan 2006 23:00:05 +0100, Holger Blum <usenet0106@kennsch.net> > wrote: > > >>Hello! >> >>While working with a MAC-FIR I came across an equation in Xilinx' >>DSP-book (http://www.xilinx.com/publications/books/dsp/dsp-book.pdf) >>which seems to be wrong in my eyes. >> >>On page 65 equation 4.4 for the generic saturation level says >>Output width = ceil(log2(2^(b-1)*2^(c-1)*N))+1 >>Where b/c are the numbers of data/coefficient bits and N is the filter >>length. >> >>This formula is, apart from a missing parenthesis, ok, but the next one >>for known coefficients says >>Output width = ceil(log2(2^(b-1)*abs(sum(coef))*N))+1 >> >>Again missing right parenthesis and the N is in my eyes wrong, because >>it is already included in the sum of coefficients. Could anyone approve >>this? I have to cite this paper in a thesis in lack of another source >>for this equation (though it seems to be obvious, but I have to be sure). > > > The coefficients can be both positive and negative, and (for a unity > gain filter) will typically sum to 1, not N. I know. But this formula uses already scaled and quantized coefficients, so they sum up to a much higher number which then can be taken to determine the actual width of the output signal (for a DC input signal). In my design I have achieved unity gain by scaling the coefficients for an integer number of used bits and picking the desired active bits from the full-precision output. I am new to DSP on FPGA, but I think, that this is the right way. > Incidentally, counting the parentheses, I make it 5x( and 5x) in the > above equation; where is the missing one? I felt so free to correct these mistakes. In the .pdf you could see the wrong equation. Regards, HolgerArticle: 95702
allanherriman@hotmail.com yazdi: > And the low noise preamp, and the low pass filter and power amp for the > speaker, and the DSP-based acoustic echo cancellation, and the analog > noise generator (for the keys) and the controlling microprocessor (if > not using the DSP chip for this) and the power supply components, and > ... and ... and. > > Naturally, one leaves out some irrelevant details. > > Regards, > Allan > P.S. how did you know it was a sunny day here? Device has its own speaker (and related dsp functions, power, power amp etc). LNA, analog LPF, no need to control it is freee running continuous process. How to enter encryption keys still thinking about it..Article: 95703
<yusufilker@gmail.com> schrieb im Newsbeitrag news:1138205581.867274.248620@g43g2000cwa.googlegroups.com... > > Antti Lukats yazdi: >> <yusufilker@gmail.com> schrieb im Newsbeitrag >> news:1138197217.486165.248730@z14g2000cwz.googlegroups.com... >> > thanks for your replies, I have to give more details >> > >> > It is not analog channel . It is digital and it is not easy to access >> > to software/hardware , may be only to hardware that mic-A/D conv >> > part.) >> > The device encrypts data BUT i do not trust encrypted data. becouse it >> > is already listened (like internet = do you trust in your IE :) >> > If I encrypt data in the device's microprocessor it can be recognized >> > or at least overwritten by an software upgrade remotely etc... >> > >> > So I will add external circuit if i can.those A/D and D/A s required >> > for this. >> > >> > Crosstalk can be a problem but how much i can not guess. i will insert >> > a small circuit between mic and host A/D conv. >> > I am aware multiple A/Ds will generate too much noise but it is >> > acceptable. >> > >> > >> > voice like signal = same freq with original voice, same data dept, but >> > just scrambled / I will feed encrypted voice like signal into device's >> > A/D. I will remove the original mic/ sorry for bad english. >> > >> > >> > no need for compression, bandwidth is ok. voice is 8kbps\ scrambled >> > voice is also 8kbps \ device can send both of them without caring. >> > >> >> this is exactly the most complicated case. if you want the encrypted >> voice >> to be transmitted over the same analog channel, (eg feed it into AD) then >> it is VERY VERY complicated to get it done right. >> >> in other words you can forget doing it. >> >> -- >> Antti Lukats >> http://www.xilant.com > > Hi Antti, > > everything is naturally analog. > > But I did not say the channel is analog. It is digital channel. > > I use very small part of the device = just want to insert my circuit > between microphone and A/D conv. > > my circuit = A/D+fpga+D/A it seems very simple to me. > > (ok I pass LNA, LPF, etc but still simple) > > transmitting and receiving done by the device. every kind of noise > reduction, crosstalk issues already handled by the device. > OR do not I understand what you mean? > receiving voice converted from analog domain, encrypting in digital domain and converting into analog domain to be transmitted over an analog channel of the same bandwidth is not trivial at least. It is not something I would call 'simple'. Our mileage may vary, but I doubt there are anyone who would say 'simple' about transmitting encrypted voice over low bandwith analog media. If you think its simple go ahead and do it. Why wasting timing talking about something that is simple? My advice still is that it is of such complexity that you should forget it. If you do it wrong then it will be either not secure or not reliable. Doing it possible isnt so complex, but being secure, reliable without quality loss or analog bandwidth increase is REALLY complex task. -- Antti Lukats http://www.xilant.comArticle: 95704
Eli Hughes wrote: > Don't waste your time. Vendor's spend a *VERY* long time working out > bugs in their software. With the level of complexity of an FPGA, you > don't want to waste time with buggy software that is developed in > someone else's spare time. All of the actually chip programming, > routing stuff is vendor locked(for good reason), so your out of luck on > that. > > That being said, Xilinx does offer their software for Linux. It is not > opensource but it does give you a non-windows alternative. Eli ... the open source community does as well. It's rather an insult against those of us that do volunteer our time toward open source project to brashly brand open source that way. Consider that Xilinx believes the Linux is a stable platform for it tools, is it not? Consider thart Xilinx uses the GCC compiler for it's PPC support, does it not? Consider that Xilinx uses the GNU libraries on the PPC, does it not? The only thing here that is wrong, is that Xilinx leaches off the backs of open source developers, then asserts prioprietary rights to open source efforts to do a BETER job at place, route, and bit steam generation. At least other mainstream corporations have the good sense to both embrace open source in their product offerings, and give back to the open source community at the same time. See the what happened to JHDLBits thread. John FpgaC developerArticle: 95705
Chris You might want to have a look at our product Raggedstone1. It has the much larger XC3S400-4FG456C part fitted. Programming cable is included and card can be used in a PCI slot or stand-alone with the optional PCI I/O Header. Details here http://www.enterpoint.co.uk/moelbryn/raggedstone1.html. John Adair Enterpoint Ltd. - Home of Raggedstone1. The Low Cost Spartan-3 Development Board. http://www.enterpoint.co.uk <Chris.Gammell@gmail.com> wrote in message news:1138199130.162720.321920@g44g2000cwa.googlegroups.com... > Hey All, > > Just wondering if anyone has tried out the Spartan-3 starter board > offered on Xilinx's website (the 99 dollar one). I am a student > developing a project on an FPGA and that seemed like the most cost > effective option for me. Has anyone tried it? If so, how is the > speed/capacity for your needs? How about the simplified JTAG interface, > does that perform OK? Thanks in advance and I look forward to hearing > from you. > > Chris >Article: 95706
"Antti Lukats" <antti@openchip.org> wrote in message news:dr88pm$kcp$01$1@news.t-online.com... > > receiving voice converted from analog domain, encrypting in digital domain > and converting into analog domain to be transmitted over an analog channel > of the same bandwidth is not trivial at least. It is not something I would > call 'simple'. Our mileage may vary, but I doubt there are anyone who > would say 'simple' about transmitting encrypted voice over low bandwith > analog media. If you think its simple go ahead and do it. Why wasting > timing talking about something that is simple? My advice still is that it > is of such complexity that you should forget it. If you do it wrong then > it will be either not secure or not reliable. Doing it possible isnt so > complex, but being secure, reliable without quality loss or analog > bandwidth increase is REALLY complex task. > > -- > Antti Lukats > http://www.xilant.com > Antti, Why can't you use this scheme? Rx voice -> digitise -> MP3 compression -> encrypt -> a plain old 56 kbps dial-up modem ? Cheers, Syms.Article: 95707
"Symon" <symon_brewer@hotmail.com> schrieb im Newsbeitrag news:43d7a88d$0$15784$14726298@news.sunsite.dk... > > "Antti Lukats" <antti@openchip.org> wrote in message > news:dr88pm$kcp$01$1@news.t-online.com... >> >> receiving voice converted from analog domain, encrypting in digital >> domain and converting into analog domain to be transmitted over an analog >> channel of the same bandwidth is not trivial at least. It is not >> something I would call 'simple'. Our mileage may vary, but I doubt there >> are anyone who would say 'simple' about transmitting encrypted voice over >> low bandwith analog media. If you think its simple go ahead and do it. >> Why wasting timing talking about something that is simple? My advice >> still is that it is of such complexity that you should forget it. If you >> do it wrong then it will be either not secure or not reliable. Doing it >> possible isnt so complex, but being secure, reliable without quality loss >> or analog bandwidth increase is REALLY complex task. >> >> -- >> Antti Lukats >> http://www.xilant.com >> > Antti, > Why can't you use this scheme? Rx voice -> digitise -> MP3 compression -> > encrypt -> a plain old 56 kbps dial-up modem ? > Cheers, Syms. > you can - but doing that with an PLD isnt something I call simple ;) -- Antti Lukats http://www.xilant.comArticle: 95708
On 2006-01-25, Eli Hughes <emh203@psu.edu> wrote:
> Dave Feustel wrote:
>> Are there any open source programs for programming fpgas?
>
> Don't waste your time. Vendor's spend a *VERY* long time working out
> bugs in their software.
"There are two ways of constructing a software design. One way is
to make it so simple that there are obviously no deficiencies
and the other is to make it so complicated that there are no
obvious deficiencies."
- C A R Hoare
> With the level of complexity of an FPGA, you
> don't want to waste time with buggy software that is developed in
> someone else's spare time. All of the actually chip programming,
> routing stuff is vendor locked(for good reason), so your out of luck on
> that.
In other words, "shut up and get back on the couch".
> That being said, Xilinx does offer their software for Linux. It is not
> opensource but it does give you a non-windows alternative.
"I won't run software written by cowards."
- Adam Stiles, referring to software provided without source code
- Larry
Article: 95709"Antti Lukats" <antti@openchip.org> wrote in message news:dr89le$mo5$01$1@news.t-online.com... > "Symon" <symon_brewer@hotmail.com> schrieb im Newsbeitrag >> Antti, >> Why can't you use this scheme? Rx voice -> digitise -> MP3 compression -> >> encrypt -> a plain old 56 kbps dial-up modem ? >> Cheers, Syms. >> > you can - but doing that with an PLD isnt something I call simple ;) > > OK, I understand! And I agree. :-) Cheers, Syms.Article: 95710
fpga_toys@yahoo.com wrote: > So, Xilinx let this team proceed, gained a lot of publicity from it as > marketing > collaterial, and then dashed the teams hopes of taking it open source. > I doubt > the team would have partnered with Xilinx had the outcome been clearly > stated > up front. They put a lot of energy into the project, then were told to > shutup and > walk away. > > Much of what the FpgaC project needs to support compile, load, and go > for Xilinx > product is trapped in this project, with a clear warning from Xilinx to > stay clear. > The likely outcome is to focus on other vendors which are more willing > to allow > open source investment in RC technologies which support their products. I should probably add that Xilinx leaches a hell of a lot of value off open source by using Linux as a host platform for it's tools, GCC at the main production compiler for PPC core software, GNU for the libraries for PPC, and Linux in several forms as host operating systems for it's product offerings. It's probably worth writing Austin, Peter, and the other regular usenix posters from Xilinx and making it clear just how much Xilinx benefits from open source, the Xilinx market created by open source, and the developers which frequently volunteer their time supporting Xilinx open source use. And then suggest that they take their thumb off the JHDLBits project, and start doing a better job of contributing back to the open source community. If that isn't enough to get their attention, maybe switching design wins to Altera and letting them know why.Article: 95711
Jan Panteltje wrote: > On a sunny day (25 Jan 2006 05:28:15 -0800) it happened > allanherriman@hotmail.com wrote in > <1138195695.581945.80890@g44g2000cwa.googlegroups.com>: > > >And the low noise preamp, and the low pass filter and power amp for the > >speaker, and the DSP-based acoustic echo cancellation, and the analog > >noise generator (for the keys) and the controlling microprocessor (if > >not using the DSP chip for this) and the power supply components, and > >... and ... and. > > > >Naturally, one leaves out some irrelevant details. > > You wrote: > <quote> > This would be the minimum required to make a "professional-grade" voice > encryptor: > <quoted> > So tha twas not very professional, as i tshows no knowledge of signal processing. > > > > >Regards, > >Allan > >P.S. how did you know it was a sunny day here? > I only know you reply to me because of the headers, you forgot to qute > what and who you are replying to. > Not very professional either. > > As for the sunny day, try a suitable reference frame. Hi Jan, I don't understand these personal attacks. What did I do to you? As for your "no knowledge" comment, my body of work in a number of fields (incl. signal processing) speaks for itself and needs no defending. Have you considered switching to decaf? Regards, AllanArticle: 95712
Hi, Read/Write processes are generated by Xilinx EDK when I used create/import peripheral wizard. I only modified the write process, and wrote an adding function. Sorry I removed the comments when I posted the code. But here it is: -- Bus2IP_WrCE or Memory Mapped -- Bus2IP_RdCE Register -- "1000" C_BASEADDR + 0x0 -- "0100" C_BASEADDR + 0x4 -- "0010" C_BASEADDR + 0x8 -- "0001" C_BASEADDR + 0xC slv_reg_write_select <= Bus2IP_WrCE(0 to 2); slv_reg_read_select <= Bus2IP_RdCE(0 to 2); slv_write_ack <= Bus2IP_WrCE(0) or Bus2IP_WrCE(1) or Bus2IP_WrCE(2); slv_read_ack <= Bus2IP_RdCE(0) or Bus2IP_RdCE(1) or Bus2IP_RdCE(2); I know I have both reg0 and reg1 values correct from the terminal. But I can't get the sum. Thanks!Article: 95713
ramesh wrote: > Hi All, > Iam new to xilinx platfrom. > > I was trying to port open source linux on Ml403 board. i tried to I should probably note that Xilinx leaches a hell of a lot of value off open source by using Linux as a host platform for it's tools, GCC as the main production compiler for PPC core software, GNU for the libraries for PPC, and Linux in several forms as host operating systems for it's product offerings. It's probably worth writing Austin, Peter, and the other regular usenet posters from Xilinx and making it clear just how much Xilinx benefits from open source, the Xilinx market created by open source, and the developers which frequently volunteer their time supporting Xilinx open source use. And then suggest that they take their thumb off the JHDLBits project, and start doing a better job of contributing back to the open source community. If that isn't enough to get their attention, maybe switching design wins to Altera and letting Xilinx sales know why. The JHDLBits team boldly set out to provide open source Xilinx tools before getting shut down by Xilinx. References are a dead sourceforge project, and some papers: http://www.ccm.ece.vt.edu/papers/poetter_2004_ERSA04_jhdlbits.pdf http://www.ccm.ece.vt.edu/papers/poetter_2004_FPL04_jhdlbits.pdf Plus see the teams thesis work: http://www.ccm.ece.vt.edu/papers/ The wire data base, router, fpga simulator, and the main JHDLBits tools are a valuable reconfigurable computing resource for the open source community ... many hours of effort by this team squashed by XilinxArticle: 95714
fpga_toys@yahoo.com wrote: > > you are not the only one that is suggesting that derating Xilinx parts > 50% is the minimum rational target for an RTL based RC system on > those platforms. I don't think this is acceptable long term, and very > hard to justify. That Xilinx actively prevents alternative P&R and bit > stream tools to improve an this, simply means they are not interested > in better fit for their product line ... IE go away, we don't care > about > that market. > > Thanks for clearly expressing this. > Why is it so hard to justify. One could argue that you can't use 100% of a microprocessor either. Any given instruction leaves part of the microprocessor idle: it is impossible to use all of the features all of the time. Why should you have different expectations of an FPGA? As I pointed out before, you can get to the high utilization and high performance corner, but you are not likely to get there while also pushing the fast to compile and easy to use buttons. FPGA design, at the core is digital logic design no matter how many fancy tools you throw at it. The fact of the matter is that FPGAs offer many more degrees of freedom in the design than what is offered by a conventional computer. The added degrees of freedom make them very powerful for efficient processing, but it also means that the design space has more things to trade-off to get to a particular corner of the design space (not to mention more ways to approach a particular problem which makes it harder for automated construction). Getting into the density and performance corners requires more design effort. No amount of wishing is going to change that fact. Designing to hit the high performance and high density corners is possible, but it isn't likely to happen when trying to also stay in the minimal effort and fast time to compile corners. If you want to call that de-rating the FPGA, that's your perogative. I don't see it as de-rating the FPGA, as the FPGA can and does meet the performance and density you are seeking, but at the price of design effort. That is not de-rating, that is weighing the design trade-offs. If you want to play in a particular corner, you need to make the concessions to get you there. You can't cover all the corners at once, and that certainly isn't unique to FPGA design. Which do you want more: fast compile times, ease of use, performance, density? You can reasonably get two of these, any more than that is not going to get you into the corner.Article: 95715
Ray Andraka wrote: > Why is it so hard to justify. One could argue that you can't use 100% > of a microprocessor either. Any given instruction leaves part of the > microprocessor idle: it is impossible to use all of the features all of > the time. First, apples and oranges and cow pucky comparison. It's not about leaving unused resources idle, it's about not idling used resources, which is exactly the problem here. Good compilers get well inside of 99.x% efficiency for code to hardware fit in terms of the application for most architectures. Even poor compilers tend to get better than a 90% fit. When it's only possible to get a 50%, or less fit, by your standards in an fpga for the primary execution path netlist, that is a HUGE derate. Most good compilers pack pipelines with very, very, very few wasted cycles for nearly 100% hardware effieciency for the application. The goal, is to reach similar efficient pipeline packing on FPGA's, and waste few if any resources in the process. I agree with your argument, that the existing Xilinx fpga's and tools will not yeild close to 100%, and we need to derate that expectation that we carry forward from traditional instruction set pipeline packing experience. You are the Xilinx expert here, and if you claim less than 50% packing efficiency with Xilinx product ... I'm not going to stand here and argue with you about that. I will argue, that given better integration to a different place and route tool, such as that contained in JHDLbits, that FpgaC can do significantly better than "less than 50% efficiency/utililization" of LUT/FF based resources for a large number of unrolled loop applications, such a finite difference modeling, RC5 code cracking, and other dense unrolled loop pipelines which are common in the industry as threaded/MPI/PVM multiprocessor applications.Article: 95716
Does anyone have experience using any oscillators for the MGTs on the V2Pro other than the two listed in Xilinx's app note (Epson and Pletronics)? We've always used the Epson part (100, 125, or 156.25 MHz) in the past but now need an extended temp version which they don't have, and unfortunately the Pletronics part, which does have an extended temp version, has a 3.3V supply instead of the 2.5 supply like the Epson. Ideally, we want a drop in for the Epson, which is a 6 pin 5x7 package, pin 1 enable, 2.5V supply. Issues or concern are termination and jitter. ------------ Ron Huizen BittWareArticle: 95717
fpga_toys@yahoo.com wrote: > Ray Andraka wrote: > > So my point is, the FPGA vendors give you the information they can about > > power dissipation. They can't know your design to provide you better > > numbers without you actually simulating the post PAR design with vectors > > that accurately reflect the actual usage. For a general purpose board, > > the board designer can limit the FPGA dissipation to whatever is safe > > for the board cooling environment by using thermal diodes or power > > supply current limits to avoid damage to the FPGA or board, and he can > > do that without knowing anything about your design. Isn't that a better > > tree to bark up? > > So, my point is, and nobody seems to disagree, that it's unrealistic to > assume that the devices can be 100% packed, use the marketing numbers > for system design clock speeds, at a modest toggle rate, and not blow > right thru the power the device can handle. Disagree? > > If not, then the device HAS TO BE DERATED from marketing numbers for RC > use. Disagree? I fail to understand how, as an FPGA application, "reconfigurable computing" is somehow different (more resource intensive, more "high performance," whatever) from an "application-specific" FPGA design. After all, every FPGA engineer wants the best of everything: lowest-cost part (which implies smallest/least amount of logic/best use of resources), lowest power dissipation and of course the least amount of engineering effort to meet those goals! -aArticle: 95718
fpga_toys@yahoo.com wrote: > Eli Hughes wrote: > >>Don't waste your time. Vendor's spend a *VERY* long time working out >>bugs in their software. With the level of complexity of an FPGA, you >>don't want to waste time with buggy software that is developed in >>someone else's spare time. All of the actually chip programming, >>routing stuff is vendor locked(for good reason), so your out of luck on >>that. >> >>That being said, Xilinx does offer their software for Linux. It is not >>opensource but it does give you a non-windows alternative. > > > Eli ... the open source community does as well. It's rather an insult > against those of us that do volunteer our time toward open source > project to brashly brand open source that way. > > Consider that Xilinx believes the Linux is a stable platform for it > tools, > is it not? Consider thart Xilinx uses the GCC compiler for it's PPC > support, does it not? Consider that Xilinx uses the GNU libraries on > the PPC, does it not? > > The only thing here that is wrong, is that Xilinx leaches off the backs > of open source developers, then asserts prioprietary rights to open > source efforts to do a BETER job at place, route, and bit steam > generation. At least other mainstream corporations have the good > sense to both embrace open source in their product offerings, and > give back to the open source community at the same time. > > See the what happened to JHDLBits thread. > > John > FpgaC developer > My aim was not to insult. I am aware of alot of quality open source applications. I agree that Xilinx does use open source tools like GCC and what not because of their quality but I think open source FPGA tools may be a little different. For it to work out, Xilinx would have to give away the gut of the parts so people could write applications properly. This would pose an issue with other companies such as brand 'A' to just take their IP. That is their business, to develop the best guts. Sorry for the insult. -EliArticle: 95719
Andy Peters wrote: > I fail to understand how, as an FPGA application, "reconfigurable > computing" is somehow different (more resource intensive, more "high > performance," whatever) from an "application-specific" FPGA design. > > After all, every FPGA engineer wants the best of everything: > lowest-cost part (which implies smallest/least amount of logic/best use > of resources), lowest power dissipation and of course the least amount > of engineering effort to meet those goals! In two ways ... it will be one to three orders of magnitude larger than a hand written hardware design, and as such will not benefit normally from low level optimization, placement, packing, routing enhancements that a typical hardware design will get. It WILL depend on the tools to do a better than average fit automatically. Second the life of an RC design will frequently be very short, and will evolve. Hardware designs tend to live "forever" from a typical software perspective ... as such hardware designs have a very strong incentive to invest manual labor up front to get the best fit to hardware for cost management .... that labor cost will then be amortized over the life of many units. A typical RC program will have a total life span a fraction of that, and is not likely to be frozen in time with large scale hardware shipments so there is no large incentive to invest effort toward optimizing a particular RC applicaion on hardware. There is EVERY incentive to optimize tools to do a better job at hardware fit, as those tools will have a long life and the effort amortizedf over MANY RC applications. The same argument, in analogy, is very few people invest the effort to hand optimize assembly language fit for applications ... but it is worth putting effort into optimizing the tool chain ... compilers, etc until diminishing returns is reached. Other than that, gates are gates.Article: 95720
Peter Alfke wrote: > The circuit is reliable, although the generated pulse width is > determined by gate delays. But it is self-compensating, since the clock > pulse will not end until the flip-flop has toggled. It's kind of > clever, if I am allowed to say so... > Peter Alfke Peter, Newbie question - I remember seeing an edge detector made up from a single XOR gate and a few inverters to add a propagation delay, but no registers. Would such a circuit be equivalent to yours? Any pros/cons either way? Regards, PaulArticle: 95721
Ron, Look for an LVDS output oscillator. Then the matter of supply voltage does not matter. LVDS is LVDS: does not matter if it runs off of 2.5V, or 3.3V. Austin Ron Huizen wrote: > Does anyone have experience using any oscillators for the MGTs on the V2Pro > other than the two listed in Xilinx's app note (Epson and Pletronics)? > > We've always used the Epson part (100, 125, or 156.25 MHz) in the past but > now need an extended temp version which they don't have, and unfortunately > the Pletronics part, which does have an extended temp version, has a 3.3V > supply instead of the 2.5 supply like the Epson. > > Ideally, we want a drop in for the Epson, which is a 6 pin 5x7 package, pin > 1 enable, 2.5V supply. Issues or concern are termination and jitter. > > ------------ > Ron Huizen > BittWare > >Article: 95722
Eli Hughes wrote: > I agree that Xilinx does use open source tools like GCC and what not > because of their quality but I think open source FPGA tools may be a > little different. For it to work out, Xilinx would have to give away > the gut of the parts so people could write applications properly. This > would pose an issue with other companies such as brand 'A' to just take > their IP. That is their business, to develop the best guts. Gcc wasn't the greatest compiler in it's early days either, Nor was linux or the gnu libraries. Over time things get better with use and community commitment. Open source EDA will too. FPGA EDA tools have been high dollar revenue producers ... $10K to $100K per seat license. Xilinx uses that revenue to pay programmers, which have every incentive to protect their jobs by blocking competitive development of similar tools. At the same time, they have very limited resources, and can not respond to all users needs, such as a totally different placement, router, and bitstream tool set for reconfigurable computing because there are not established high volume users asking for this feature set. I can, and will, continue to say that the existing tool chain is horrible for FpgaC to interface to as it's a huge bottle neck for compile, load and go ... and it's utilitization of hardware resources really sucks unless you are willing to let it work for several days ... and often even then the results suck because it makes some poor choices very early that it will not rip up and replace. FpgaC tends to produce lots of very regular mesh structures, which using very different placement/cost algorithm can be routed fast, on the fly, to a bit stream to support compile, load and go operations on the order of seconds, not hours -- with a substantially better fit than par simply by retaining the mesh relationships rather than abandoning them. The compiler by it's very nature, tends to produce a few types of structures, which are emitted with very little change, over, and over, and over. By carefully optimizing those emitted structures, and fine tuning the place and route process to be optimized for them, it a much simplier problem than xilinx par is optimized for, and much, much easiter get better utilization as the end result is something similar to dynamically generated cores which are just replicated and routed togather. The big difference, is that these structures are not pure macros/cores ... but are logic blocks which the complier merges with adjacent blocks into packed LUTs. So what is output are not fixed regular structures in terms of pure macros/cores, but mesh structures of optimized logic pipelines. Xilinx par isn't tuned to recognize these mesh structures, and breaks them apart ... and other poor choices. Some things which FpgaC does as clear optimizations, also just drive par nuts ... like clock enables to reduce the depth of LUT based multiplexors and the need for FF feedback for idle states. The result is that par separates the LUT and FF from each other, then wastes another LUT for pass thru, and burns routing resources/dynamic power in the process. Greatly complicating the FpgaC to optimize around par's faults is a goose chase, since it may do something completely different the next release and we will waste a lot of time optimizing FpgaC for each and every ISE release ... with a growing number of divergent hacks. Simply taking something like the JHDLBits wire database and router and fine tuning it for FpgaC is MUCH MUCH easier, and decouples us from having a different hack for every change in ISE. Plus we get compile, load, and go times down to seconds, instead of the minutes or hours that it takes par to do a poor job. We will put our efforts into supporting FPGA vendors that want our help, and appreciate the long term investment we are making into their products future, and their companies sales.Article: 95723
Hi Ramesh, you might want to have a look at the following documents: - XAPP765 (http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf). This document describes on how to get started with EDK and the ML300 board. The approach for the ML403 board is the same - UG080, pg. 37 (http://www.xilinx.com/bvdocs/userguides/ug082.pdf). This document contains a brief description on how to rebuild the Linux kernel for the ML403 board. Start with rebuilding the reference design and Linux kernel for the ML403 board. All the necessary information can be found in the documents above and on http://www.xilinx.com/products/boards/ml403/reference_designs.htm The Xilinx software drivers for the Linux peripherals have been released into the open source repository for the Linux PPC 2.4 kernel tree. This tree is picked up by various Linux distributions. Further, the MLD technology in EDK helps you to customize the Linux kernel for your particular hardware design. At this time I recommend staying with the 2.4 Linux kernel as the support for ML300 (and the ML403) in the 2.6 kernel is very basic (UART only). Another good source of information is the linuxppc-embedded mailing list (see http://ozlabs.org/mailman/listinfo). The latest developments wrt Linux kernel for the MLxxx boards is discussed there. - Peter ramesh wrote: > Hi All, > Iam new to xilinx platfrom. > > I was trying to port open source linux on Ml403 board. i tried to > follow the instructions in the below link. > http://www.klingauf.de/v2p/index.phtml > i was getting errors when i was running bZimage. the .elf file was not > getting created. > > Is there an alternative way of acheiving my goal. > Kindly suggest. > Thanks in advance. > > Ramesh >Article: 95724
Chris, I bought the S3 starter board last year for a VHDL senior class project. I implemented a 32-bit CPU in it, and demonstrated a program which detected prime numbers on the 8-segment display. The whole design took about 90% of the chip, but it went smoothly, and for $99, how can you beat it?! However, like Antti said, today I would spring for the S3E for $149. It has a larger FPGA, more RAM, and a couple more goodies on the board. The only downside is that they are newly released and you may have trouble getting ahold of one. Cheers, -Jeff
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