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
yyqonline wrote: > I have found that there is "clock high time violation" while timing > verification using Altera QuartusII, with device "flex10K". I wonder > whether this is caused by the pulse width, depending on gate delay, not > long enough for driving FSM. > Best Regards, > YuQing, Youth Yes, see my earlier comment about CLK_min, that meant not FREQ, but the HI and LOW minimum times that all clocks have. Such a circuit will generate needle pulse clocks, so you will need to watch the Min pulse widths. -jgArticle: 95776
Kevin Morris wrote: > So, I have a question regarding the assertion that the datasheet LUT > count is "important information." > > Why? What is the real-world utility of that number? Do some people > know up-front how many LUTs their design is gonna use, and then they > just need an accurate LUT count to pick the best FPGA? > > The problem with programmable logic datasheets is that it's almost > impossible to put any real, relevant information on them. A FEW things > - number of SerDes transceivers, maybe user pin count, marginally > available block RAM... are kinda useful, but for everything else, > don't you really need to just do the design and see what device the > tools tell you to use? > > I've written a couple of articles on/around this topic. My favorite > was: > http://www.fpgajournal.com/articles/20040706_tango.htm > > and people also seem to like: > http://www.fpgajournal.com/articles_2005/20050510_worldsbest.htm You may not know how large your designs are until you finish them, but there are many users who both have reusable IP with known sizes and need to actually *plan* their work rather than just letting it happen. Even if you don't know the size before you start, you can estimate it. I have never done a design without some form of estimate before I started. Kinda like the software guys estimating SLOCs. So why would I want to work with numbers that are already off by 12.5% when estimating a design? In reality I decided to ask what others thought about the inflation factor because the inflation factor ticked me off. I was comparing X to A and I couldn't just look at the data sheet, I had to do the calculations to get the accurate numbers for X. I am tired of vendors making more work for me with no point other than boosting the ego of some marketeer. I was curious about what others thought. Some don't mind it, others seem to hate it like I do. I have posted to this newsgroup about the inflation factor before and the response from the X guys was far less than supportive. Although many seemed to feel the inflated numbers are not appropriate for a data sheet, the only favorable response from X was to get the footnote added to the new data sheets so that you know they are making it up. But it seems that now the X guys have seen the light and are 100% behind truth in data sheets! Hazzah!!! Actually, it is good for X that we have a separate department for FPGAs under software. I am designing the board and would likely use a Cyclone II because of the simpler power supply required. But the FPGA guy is a former FAE and wants to use X, so we'll use X. This is such a simple design it doesn't matter much which way we go. Heck, we could do without the FPGA if we didn't want to use a DSP. We are doing CVSD on voice and they already have the code for a DSP. The DSP doesn't have UARTs, so we are adding an FPGA for some UART interfaces. If we were willing to port the CVSD code we could do it all in an MCU with 6 UARTs and a small CPLD since one interface is Manchester encoded. Or we could drop the DSP and do it all in the FPGA. The really ironic part is that everyone on the project is acting like this job is even remotely difficult. I had forgotten what it was like to work for a defense contractor, the only hard part is figuring out what the real requirements are... anyone have some spare work to throw my way? I need something to keep my mind active :-)Article: 95777
Joerg wrote: > Hello Chris, > >>> >>>Laws, regulations, more laws. One trait of engineers is or at least >>>should be that they know where their limits are. Not because they are >>>told by bureaucrats >> >> You keep going on about bureaucrats setting the rules and every reply >> has told you that the rules are set by qualified and experienced >> ENGINEERS. >> > > Huh? Maybe in the UK, not so much here. > > >> You seem to have a problem of being judged by your peers. > > > I don't. I do have a problem with overly restrictive regulations and so > does our industry. > > Regards, Joerg > > http://www.analogconsultants.com I wish i understood what you are complaining about. BSEE, PE (Electrical CA, USA) -- JosephKKArticle: 95778
If you really need to clock a flip-flop on both clock edges, the circuit described in the recent posting by Bob Perlman (and apparently originated by Gabor, whom I have contacted and congratulated) is really much better and cleaner than my frequency doubler. Maybe a bit more expensive, but flip-flops and XORs are cheap, and headaches are expensive. Peter Alfke, from homeArticle: 95779
Thanks! I use the circuit posted by Bob Perlman to construct a FSM just now and the performance of timing verification via QuartusII seems to be good. I think this may be a solution, but I whether I made the best choice to construct the module. Requirement: *the work freq is 640Khz *the expected datarate is 640K, 320K, 160K *since this chip will be passive (without battery), power consumption is very important *when datarate is 640K, either higher freq (at the cost of higher power consumption) or det(at the cost of larger area) have to be introduced; while datarate is lower than 640K, neither is needed. Then, I have three ways to choose from: *a whole module using det-FSM advantage: only one Fsm disadvantage: extra control part, to decide whether negedge of clk is active *a module consisting of a det-FSM part and a set-FSM (single-edge-trigged FSM) part advantage: easy to realize disadvantage: two groups of state registers *a module using higher freq, esp. 1.28Mhz advantage: small area disadvantage: higher power consumption I am now making a module consisting of a det and a set FSM, but I am not sure whether I am making the best choice. Every advice would be highly appreciated. Best Regards, Yuqing YouthArticle: 95780
> Flip-flop count, > I/O count (including required standards including bidirectional LVDS,) > gigabit serial I/O. > on-chip memory (width and depth), > multipliers/accumulators, > potential need for an on-chip microcontroller. That seems like a very reasonable approach. Thanks Peter.Article: 95781
Ed McGettigan wrote: > I take umbrage to your assertion that Xilinx is a leach and doesn't > contribute back to the open source communities. Xilinx has been a > contributing Corporate Patron of Free Software Foundation for many > years now https://www.fsf.org/donate/patron/index_html funding many > open source projects through the FSF with our donations. The value of open source tools to Xilinx, as compared to implementing your own GPL free tools and maintaining them is something in the ball park of $10-30M in NRE and an additional $1-3M/yr to maintain them. If Xilinx's contributions to open source are a significant fraction of that then clearly you have contributed back to the community. > In addition we funded, supported and developed the Virtex-II Pro and > Virtex-4 PowerPC405 ports that are the parent post of this thread and > then push for their release into the official Linux 2.4.x and 2.6.x > PowerPC trees so that everyone will have access to them easily. That hardly counts, as the PPC port project existed before Xilinx included PPC's in the Pro's, and the Xilinx platform specific work is self serving to press your own hardware sales. Nothing in your post, or any other Xilinx employees response, describes why Xilinx allowed several man years of open source development in the JHDLBits project to be simply squashed. Let's just say that trashing a half dozen young engineers expectations of contributing to the open source community with great pride in their support of Xilinx product, is pretty damn low. Umbrage in that would be an understatement.Article: 95782
Ray Andraka wrote: > Seems those who keep yelling for open bit streams aren't bothering to > look at what is available, or try working with pieces. They all seem to > want full open bitstream without even understanding what all it entails > to be able to successfully work with it. You could do pretty much > everything they seem to be looking to do within the existing XDL > framework, and it gives the ability to use parts of the existing tools > so you don't have to develop the entire tool chain from soup to nuts. > Pick a piece of it and plug it into the existing tools. It's not clear that XDL is in fact an official interface that will avoid a C&D order from Xilinx .... if it were completely documented, and the parts data bases behind it completely documented, then your assertion would be clearly true ... however, it isn't. Some reverse engineering in unavoidable to use it fully, and that has clear restrictions from Xilinx. So, given that the JHDLBits project bit the dust at Xilinx's hands, and it creaps into the same technology, and that Xilinx doesn't offically bless this interface to the degree of openess you suggest, let's just say it would be prudent to go a LOT slower in addopting it as the golden technology you suggest.Article: 95783
fpga_toys@yahoo.com wrote: > So, given that the JHDLBits project bit the dust at Xilinx's hands, and > it creaps into the same technology, and that Xilinx doesn't offically > bless > this interface to the degree of openess you suggest, let's just say it > would > be prudent to go a LOT slower in addopting it as the golden technology > you suggest. Prudent to the degree of if you are young or have any assets, stay the hell clear of it for open source projects - as you may not be able to work long enough in your life to pay off a judgement against you.Article: 95784
"Larry Doolittle" <ldoolitt@localhost.localdomain> wrote in message news:slrndtfapv.u3t.ldoolitt@localhost.localdomain... > 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 You obviously don't develop using any fpga or most dsps then ?Article: 95785
Ed McGettigan wrote: > I take umbrage to your assertion that Xilinx is a leach and doesn't > contribute back to the open source communities. Xilinx has been a > contributing Corporate Patron of Free Software Foundation for many > years now https://www.fsf.org/donate/patron/index_html funding many > open source projects through the FSF with our donations. First, if Xilinx had not been so heavy handed with the JHDLBits project, trashing the efforts of a half dozen young engineers, your umbrage might be half way valid. But the reality is that the economic value of gcc, GNU, and Linux is significantly more than $10M-30M NRE and $1m-3m/yr as the UNIX licenses and royalities would have cost you more. The real value of GPL tools that you ship, if the company had developed GPL free version is an order of magnitude or two more than that. *IF* your contributions to open software are a significant fraction of the equivalent UNIX license fees, then sure, Xilinx is paying it's way. > In addition we funded, supported and developed the Virtex-II Pro and > Virtex-4 PowerPC405 ports that are the parent post of this thread and > then push for their release into the official Linux 2.4.x and 2.6.x > PowerPC trees so that everyone will have access to them easily. That is completely self serving to generate revenues from the hardware sales. the PPC port existed long before Xilinx started shipping the IBM core in Pro's.Article: 95786
austin wrote: > They weave a web of untruths and half whispers with convenient > coincidences to explain their troubles. Xilinx's ommissions and the quest for that data is not a cultish movement. You still haven't explained just what the max currents are for the various power and ground rails are. Or the max power the chip can actually safely disappate without violating the die limits or seriously impacting the life of the die due to migration problems. There are a lot more undocumented things to discuss after these basics, like the dynamic power for LUT's, FF's, local routing, long routing, BRAM's and the like to get a handle at the front end of the design partitioning what the power requirements will be. These are serious engineering issues for anyone that wishes to actually USE a significant portion of the chips resources, rather than expect that 85% of the die will be idle. Not even on die measuring is enough without this data, as we can easily create a hot spot away from the diode that exceeds die temp specs by a factor of two or more. This is not a regligous debate ... this is real engineering up front for worst case loads, not tinking in the lab with missguided retrofit cooling.Article: 95787
My guess is that, Xilinx is more afraid of their tools being used by other FPGA vendors. Probably they don't want ISE to support Altera devices and the like!, if it is opensourced. That may be the biggest risk for them - not reverse engineering.Article: 95788
Jim Granville wrote: > So that indicates that 100% fabric usage is not an impossible task ? I certainly don't think it's impossible for some designs, it is however "difficult" with present tools. > It seems one 'stub' of an opensource project could be to handle this > Xilinx-User interface. Rather than try and rebuild their tools from the > ground-up, why not work with them to improve the tools ? > Yes, this is done a small detail at a time. something of a chicken and the egg problem. Getting major changes into the par design are VERY LIKELY to dribble out slowly over 5 years to avoid a major upset for the existing customer base. > Anyone doing an RC-FPGA array, should have strong thermal management, > even up to the copper heat pipe schemes of the extreme gamers ! :) Yep, in each of the large system design proposals I have made for the last year that is a milled 1/4" copper plate heat sink in direct contact with the fpga array, connected integral with a chilled water heat exchanger. Just can not handle the heat density of a large RC array with air. Austin may think that needing the max parameters for these devices is a joke, but when you propose to put several thousand of them in a 1M cube, your customers actually demand thermal and power data as diligent engineering. While the lack of these specs for the Xilinx product may sit will for some, it's a critical road block for serious hit the ceiling hard designs. Putting a significant fraction of a megawatt into a desktop box isn't childs play, or even a hobby project, it starts with a lot of engineering before the software design even is a dream.Article: 95789
yyqonline wrote: > Thanks! > I use the circuit posted by Bob Perlman to construct a FSM just now and > the performance of timing verification via QuartusII seems to be good. > I think this may be a solution, but I whether I made the best choice to > construct the module. > Requirement: > *the work freq is 640Khz > *the expected datarate is 640K, 320K, 160K > *since this chip will be passive (without battery), power consumption > is very important > *when datarate is 640K, either higher freq (at the cost of higher power > consumption) or det(at the cost of larger area) have to be introduced; > while datarate is lower than 640K, neither is needed. > Then, I have three ways to choose from: > *a whole module using det-FSM > advantage: only one Fsm > disadvantage: extra control part, to decide whether negedge of clk is > active > *a module consisting of a det-FSM part and a set-FSM > (single-edge-trigged FSM) part > advantage: easy to realize > disadvantage: two groups of state registers > *a module using higher freq, esp. 1.28Mhz > advantage: small area > disadvantage: higher power consumption > I am now making a module consisting of a det and a set FSM, but I am > not sure whether I am making the best choice. > Every advice would be highly appreciated. > Best Regards, > Yuqing Youth > What is your design actually doing? And is an FPGA actually the correct solution? When you are talking about relatively low frequencies, and very low power requirements, you might be better off using a microcontroller - depending of course on what the data is, and what you are trying to do with it.Article: 95790
int19h wrote: > > Flip-flop count, > > I/O count (including required standards including bidirectional LVDS,) > > gigabit serial I/O. > > on-chip memory (width and depth), > > multipliers/accumulators, > > potential need for an on-chip microcontroller. > > That seems like a very reasonable approach. Thanks Peter. yep, a reasonable approach to writing your proposal to be X vendor locked. Your customer may not be high enough up the food chain to get delivery of the product in a shortage, and doing a design specifically including sole sourced technology that goes on allocation is called Chapter 7. First, consider each of these functions carefully, are they a MUST HAVE for the product, and if so are there two vendors with parts that fit the bill. If they are MUST HAVE, do they need to be on chip ... would a multi-device design be safer for the product. Is the talent to actually complete the project inhouse already, or is it a specialized field that you may not be able to hire to meet schedule. The basic question about FPGA's, is there enough LUT/FF's to realize the design. Everything past that, needs to be carefully considered in regards to multi-source availablity should there be high demand and allocation for the parts.Article: 95791
:-) Back to the problem: I think I forgot to mention that I am running the tools on dual-core machines, which seems to be part of the problem. When I watch the _pn processes while starting in "top", I see that with one call of ise, there are two _pn started on the same CPU. One has a bit of CPU usage for a short time, the splash screen shows and then they both stand with 0.1 % CPU. After 4 Minutes, one _pn is moved to the other CPU and this process then takes 1% CPU. 10 seconds later the GUI is there. Still both processes take exactly the same amount of memory and live happily ever after. I don't know enough about multi-processor load distribution in Linux, but this behavior is reproducable. Could it be that those 4 minutes come from the time, the OS needs to find out that one process should be switched to the other CPU??? I would be curious to hear the experts about this topic! Cheers, JoachimArticle: 95792
<fpga_toys@yahoo.com> wrote in message news:1138206477.465109.299250@g47g2000cwa.googlegroups.com... > > 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. Open source is great for a lot of things and I use it where possible but for other areas its a long way from useable. > 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? Just wondering who did a lot of the work on the original ppc gcc ? IBM or freescale empoyees ? > 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 The JHDLbits ending so far isn't good. But I'd be very wary of doing any thesis project with a company I wasn't an empoyee of and even then I'd still be careful. You need to have a legal agreement on paper before you start, may take time and a lot of effort but these days if you do not cover your arse you are asking for trouble. Surely one problem is by the time you have the whole tool working correctly with a part, (or at least the initial part or two) there is a good chance that one or two new parts have been introduced and the people who may want to use that tool want to use the latest part. What tool is cray using for their reconfigurable computing systems ? If the parts are very similar it shouldn't be to much of a problem. How is a company using an open source compiler leaching from open source ? If the software is placed in/under license where it can be used, what is the problem as long as the company follows the license ? If you don't like it don't put the software under that license. Rather than openly attacking and abusing xilinx in a public forum, surely a better move would be to sit down and talk to them ? AlexArticle: 95793
Kevin Morris wrote: > Group disclaimer: After three years of carefully avoiding using this > group to gather article input, I've now done it twice in less than a > month. I promise not to make it a habit. In both cases, I needed > information beyond the reach of our normal PR and design team channels. > If you object, please let me know and I'll take your opinion into > consideration. Don't worry about it ... the other vendors here are pretty in your face anyway.Article: 95794
Thanks! At the end we will implement our design to a chip by asic tech, and now we are designing and verifying via Fpga. That is why the freq and power are always on our list. Best Regards, YuQing YouthArticle: 95795
<fpga_toys@yahoo.com> schrieb im Newsbeitrag news:1138257624.935300.25730@o13g2000cwo.googlegroups.com... > > Ray Andraka wrote: >> Seems those who keep yelling for open bit streams aren't bothering to >> look at what is available, or try working with pieces. They all seem to >> want full open bitstream without even understanding what all it entails >> to be able to successfully work with it. You could do pretty much >> everything they seem to be looking to do within the existing XDL >> framework, and it gives the ability to use parts of the existing tools >> so you don't have to develop the entire tool chain from soup to nuts. >> Pick a piece of it and plug it into the existing tools. > > It's not clear that XDL is in fact an official interface that will > avoid a > C&D order from Xilinx .... if it were completely documented, and the > parts data bases behind it completely documented, then your assertion > would be clearly true ... however, it isn't. Some reverse engineering > in unavoidable to use it fully, and that has clear restrictions from > Xilinx. > > So, given that the JHDLBits project bit the dust at Xilinx's hands, and > it creaps into the same technology, and that Xilinx doesn't offically > bless this interface to the degree of openess you suggest, let's just say > it > would be prudent to go a LOT slower in addopting it as the golden > technology > you suggest. > 1) XDL is official interface, any tools that parse and/or generate/modify XDL for any purpose are OK. 2) Xilinx can not make anyone or ar project to 'bit the dust' as you are saing. If some entity developes something that has real value, then Xilinx will buy that entity (not kill!). If some open source project has no interest and no funding then it dies eventually, all by itself. So that what has happened. All RE needed can arranged to be done by some untouchable entity if it really comes to it. But for Xilinx bitstream support there is a lot that can be done without any RE first as Ray has also said the XDL contains pretty much 100% of the physcial design info. the .LL files contains pretty much bit locations for purposes like post bitgen bitstream patching, etc.. there are so far no tools that actually do something useful with XDL and LL files, and I am sure Xilinx would welcome such open source projects. -- Antti Lukats http://www.xilant.comArticle: 95796
Kevin Morris wrote: > I'm finishing up an FPGA Journal article called "Stop. Go. Yield. - > Dude! Where's my Chip?" Hmm.. Not a title that travels internationally very well... -jgArticle: 95797
I got a reply back from Xilinx, it turns out that they are making a DVD available soon ( from the download page ). But no hope on getting a splitted download! I juest happened to visit QuickWorks (Quicklogic) download page, they nicely put a install.bat, p1,p2,p3,p4 (77MB x 4files).Article: 95798
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:43d897a9$1@clear.net.nz... > Kevin Morris wrote: >> I'm finishing up an FPGA Journal article called "Stop. Go. Yield. - >> Dude! Where's my Chip?" > > Hmm.. Not a title that travels internationally very well... > -jg > Hi Jim, Not sure it even travels out of CA! But I like it. I can see Jeff Bridges out of "The Big Lebowski" waiting for FPGAs. Maude Lebowski: What do you do for recreation? The Dude: Oh, the usual. I bowl. Drive around. Wait for V4 MGTs. The occasional acid flashback. As for delivery problems, I ask my FAE. He's pretty good at translating the 'official' availability into real numbers. HTH, Syms.Article: 95799
On Wed, 25 Jan 2006 12:38:18 +1100, "int19h" <tirath@replacethispartwithmynickname.com> wrote:
>Hi all,
>
>I need some advice on how to treat the "equivalent gate count" issue. I have
>to make a presentation on something soon, where FPGAs are the initial
>foundation of the project, and I anticipate having to provide some
>correlation between "slices" and "gates" as an estimate to the capacity of
>current-generation FPGAs.
>
>Ideally I would provide a slice and logic area estimate for the specific
>design, but the design is not nearly complete enough to provide such
>reliable estimates. For now, I have to arm-wave it. I don't need it to be
>vendor-neutral though, I can be Xilinx specific. Any suggestions anyone?
>
>-int
Since you don't mind being Xilinx specific, the following link:
http://www.fpga-faq.org/compare/build_form.cgi
may be of some help, as it allows comparisons of different devices,
and different product families, it does not have the insane Xilinx
logic cell inflation factor, it gives the formulas for converting
from LUTs/FFs to vendor neutral "Dog Gates" (sort of like Dog Years :-) .
Philip
===================
Philip Freidin
philip.freidin@fpga-faq.org
Host for WWW.FPGA-FAQ.ORG
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