Xilinx ISE 8.2
in [FPGA]
|
From: Eric Smith on 26 Jan 2007 14:10 I wrote: > I do my editing in Emacs, but I despise vhdl-mode. I normally use > the GUI for everything but editing. Martin Thompson <martin.j.thompson(a)trw.com> writes: > Interesting - could you say any more about what makes vhdl-mode so > bad? My experience has been more of people thinking Emacs sucks, but > they wish their editor did all that vhdl-mode does! Completion/templates get in the way of my typing. I know what I want to write, but if the editor starts inserting stuff for me, I have to think about the typing much more, so it slows me way down. Eric
From: steve.lass on 26 Jan 2007 16:07 Sean, The first service pack is actually about 5 weeks after we freeze the DVD image and release the software to manufacturing. After we feeze it, we give it to the FAEs and train them on the new capabilities. Some customers may get it during this timeframe if they have a specific need that is addressed in that release. We also don't allow any changes in the two weeks prior to RTM to allow for full testing. So even though it looks like the first service pack comes out a couple of days after you get the software, it's about 7-8 weeks after we lock down the release. Regardless, because of these types of comments and the fact that we need to better coordinate the releases of the other Xilinx tools, expect some positive changes in 10.1 release cycle. Steve "Sean Durkin" <news_jan07(a)durkin.de> wrote in message news:51rd6fF1lppelU1(a)mid.individual.net... > Hi Steve, > > first of all, I appreciate your comments. I think I can say that actual > Xilinx employees with an insight reading and posting here is really a > "feature" most of us appreciate. :) > > steve.lass(a)xilinx.com wrote: >> Actually, for the 9.1i release, feature freeze was in June 2006 and the >> release to manufacturing was in December. We spend about 6 months fixing >> bugs >> and improving quality. > Then why do you release the first service pack days after the software? > Why not just push back the release for a few weeks and ship something > that is usable right away? > I can't comment on other customers, but in our case it's not like we're > desperately waiting for new ISE releases. It's not like we're waiting > for those new features (because we usually don't have any idea what > these new features might be, except the usual promised 30% increase in > speed). It's not like we're waiting for bugs to be fixed... we have our > workarounds, because we can't just wait until Xilinx fixes it, we need a > solution now. > It really is of no importance or relevance to us when a new ISE is > coming out. When it's there, it's there, and we'll give it a try to see > what's been changed/improved, hoping that some of the issues I had with > earlier versions are resolved. > As stated in my earlier post: I know of no other EDA software vendor who > handles the release cycle like Xilinx does (and Xilinx didn't always do > it like that either). And you really can't claim other vendors don't > have the same problems with dependencies between different products and > 3rd party software etc. > >> Yes, 7.1i had a new database and 8.1i had a new ProjNav GUI. The >> database was created in 1990 and needed to be rewritten and so did the >> GUI. > I agree. The switch to QT (or whatever it is you're using now) was long > overdue and made the GUI finally usable under Linux (be gone, WindU!). > >> It's not as simple as saying we will release when its ready because of >> other >> dependencies. We need to make sure all of our other software products >> (ChipScope, PlanAhead, System Generator, EDK, etc.), all of our IP, and >> 3rd party tools all work together. > Yes, you have to, but they don't. A new EDK version is usually not > released for weeks or months after the corresponding ISE, so in most > cases I can't use the latest ISE anyway because it won't work with my > older EDK. Same applies for some IP (like MiG, for example): Those > usually don't work right away as well, but they will be released > sometime later in a version compatible with the latest ISE (BTW, the > later IP-updates are a friggin' 600MB in size, helloooo?). So in what > way does the fixed (and too early, quality-wise) release date help the > integration of other products, IP and 3rd party tools? > >> Defining a release date and sticking to that >> date is the best way to accomplish this. So instead, we define a feature >> freeze date. If a feature can't be done by that date, it gets pushed to >> the next >> release. > I don't really understand this. Feature freeze date, yes. But why a > fixed release date? > Just to compare, look at the Debian Linux project (or any other bigger > open source project). There's a feature freeze date, and a projected > release date. At the feature freeze date, there's a certain number of > release-critical bugs, and a number of not-so critical bugs. The release > date usually will be pushed back until the number of release-critical > bugs drops below a certain threshold, or is 0. Only then is it more or > less guaranteed to work when it's released. > I had assumed it is similar at Xilinx, but with a release date fixed > well in advance, this can never work. > I realize that software can never be bug-free, but that's beside the > point. Why release a software that you *KNOW* has a bunch of critical > bugs (you already have the first service pack ready!), just so the > release date fits your regular release cycle? > 3rd party tools as well as your other products and IPs are being worked > on long before ISE is released, so the actual release date is of no > relevance to those either. > >> I agree with all of this. To be honest, no customers told us they were >> using >> partial reconfig in ISE 4 - 7, so we did not make it a priority. > Well, I did. John Williams initiated a whole separate mailing list just > for the topic. The subject regularly pops up in this very newsgroup. So > you can't say noone told you. But I guess noone "important" told you, > since all the people who used it until very recently were students or > researchers, not high-volume-customers. But I totally understand that, > this is not meant to be critizism. I guess it's pretty complicated to > implement it in the software, and you can't expect a huge company doing > all the work to fix it just for a handful of academic customers. Again, > this is not meant to be sarcastic, I wouldn't do it any other way if I > were in charge at Xilinx. > > The thing that bugs me is just that if it's not a priority for you to > fix, why not just tell people? From ISE4 through ISE7, I was told "This > is going to be fixed in the next service pack/release", but it never > was. And after every new release, I invested a couple of days "porting" > my designs to the new software, only to find out that it's still not > working. A lot of time I could've spent smelling the roses or hugging > trees or generally doing something useful if only I would've been told > what's up right away. > >> Don't be shy about reporting bugs to us and don't >> complain about bugs not being fixed if you don't report them. > Most of the time I run into known problems. I first check your website > and find that someone else has already reported it and "it will be fixed > in the next service pack". But if you say duplicate reports might help > prioritizing things, I'll start reporting. > >> Steve Lass >> One of those Marketing guys. > I apologize if my post read like I had something against marketing. :) > > It's just my experience that priorities and ways of thinking simply > differ between "techies" and "marketing". I see it in our projects, too. > Sometimes we have to implement features that are complete nonsense that > no customer will ever use, but it looks good in the brochure and the > competition has it in their brochures as well, so it's gotta be > implemented; just in case a crazy customer decides to check if the > brochure is totally accurate (which occasionally does happen)... > > I've had some interesting (and funny) chats with engineers from the > competition at trade shows about the very same subject, and it's the > same everywhere. The problem is that the people who decide which product > will be bought often aren't "techies" and hence rely only on the > brochures to compare, so it's gotta be in there. The question is who > started it in the first place, who put it in the first brochure. :) > > And I'm not so sure how many of the new features are actually things > customers need or want. I can't imagine any customer requesting the > format of the project files to be switched to binary, or requesting the > feature to send detailed information about my designs to Xilinx after > synthesis... And I don't think a lot of customers need the "feature" of > a new ISE release for christmas every year. > > cu, > Sean > > -- > My email address is only valid until the end of the month. > Go figure what the address is going to be after that...
From: Daniel O'Connor on 27 Jan 2007 18:10 Martin Thompson wrote: >> Sure that's VHDL mode? I can't see anything in the docs about >> simulation.. >> > > Yep, definitely... It's in the compilation section as none of it is > simulation specific, I just target the Modelsim compiler. OK. >> Hmm, it looks very interesting but I use Verilog :) >> > > Ahh, in that case, sorry, you're out of luck I think. Unless verilog-mode > is > as far on as vhdl-mode... Apparently not :) It is still very useful though. > See my makefile I posted elsewhere on this thread... Yeah I found a few links, thanks! -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
From: Martin Thompson on 29 Jan 2007 04:30 Eric Smith <eric(a)brouhaha.com> writes: > I wrote: >> I do my editing in Emacs, but I despise vhdl-mode. I normally use >> the GUI for everything but editing. > > Martin Thompson <martin.j.thompson(a)trw.com> writes: >> Interesting - could you say any more about what makes vhdl-mode so >> bad? My experience has been more of people thinking Emacs sucks, but >> they wish their editor did all that vhdl-mode does! > > Completion/templates get in the way of my typing. I know what I want > to write, but if the editor starts inserting stuff for me, I have to > think about the typing much more, so it slows me way down. > Ahh, yes I can understand that - I had a similar problem except that when I started, I was very rusty at VHDL, so it helped. I'm now so used to the templates that inserting a new process becomes: proc<tab><s><type a name for process><clk>then type in s docunmmentation comment if I feel like it and prod enter a few times to get rid of any extraneous prompts. That sounds like a right palaver, but honest, it helps me :-) I wrote a new piece of code the other day and it compiled first time, because the templates and tab-completion of variables/signals meant my customarily inaccurate typing hadn't caused any syntactical problems. Cheers, Martin -- martin.j.thompson(a)trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.html
From: dimtey on 14 Feb 2007 16:43
On Fri, 26 Jan 2007, doug wrote: > Just to be clear in this case here are the differences in 7.1 and 8 or > 9 for the same project. > ISE 7.1 max memory useage about 120mB and 5 minutes > ISE89 crashes at 2GB after an hour. > > This is definitely the memory leak category. The other question, of > course is how they managed to write bad enough code to take 50 times > as long (when 8 or 9 crashes, it is about 25% done). Even if it did > not crash, this would be a major pain as it implies a xst process time > of around four hours. I had a similar problem with a project where memory usage exploded between 7.1 and 8.2. I traced that to the way XST infers SRL16. I have a number of 640x8 shift registers. When coded according to XST manual they are synthesized right away as SRLs in 7.1. In 8.2 XST produces a large number of flip-flops which are optimized to SRLs later on. I had to rewrite my shift registers to instantiate SRL16E directly. -- Dmitry Teytelman |