From: Andreas Ehliar on
On 2007-01-23, bgshea <bgshea(a)gmail.com> wrote:
> So, I ask Martin, as he posted a method of using build scripts, if you
> could even if in part, post some of what you use, that might benefit
> the community here. I would certainly build on those scripts and post
> them back.

Hi, I wrote some Makefiles that we use in a course here. The entire
lab skeleton is actually available for download but I have uploaded
just the Makefiles to my homepage if you are interested:

http://www.da.isy.liu.se/~ehliar/stuff/

It is not perfect but it works ok for me and most students in the
course seem to think so as well :) They have been tested in both
Linux and cygwin.

I wrote the Makefiles for the following reasons:
* Since they are text based, revision control is easy
* We can avoid the (for now) unstable Project Navigator
* Building a project will not spew lots of temporary files
in the project directory. (They will end up in the synthdir
directory.)

The Makefile has been tested with ISE 8.1 and 8.2.

I also have a small shell script which I use to build small projects where
I haven't bothered to create a Makefile. That is also available on the
web page. It is heavily inspired by the Makefile mentioned above.


Some things which would be nice to be able to handle:

* VHDL libraries (not everything should end up in work)
* Don't recompile all files when starting a simulation target
* Mixed VHDL/Verilog in the Makefiles


Tips and tricks for these Makefiles will be gratefully received :)
I know that they are a bit ugly at the moment.

/Andreas
From: Sean Durkin on
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: Martin Thompson on
Eric Smith <eric(a)brouhaha.com> writes:

> Martin Thompson <martin.j.thompson(a)trw.com> writes:
>> The best development environment I have ever used for Xilinx devices
>> is Emacs (with vhdl-mode) and a command-line build script :-)
>
> I do my editing in Emacs, but I despise vhdl-mode. I normally use
> the GUI for everything but editing.
>

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!

Thanks,
Martin

--
martin.j.thompson(a)trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html


From: Daniel O'Connor on
Martin Thompson wrote:
> Simulation I use vhdl-mode for, it scans my entire set of files and
> builds me a complete makefile. Anyone who hasn't spent 2 or 3 weeks

Sure that's VHDL mode? I can't see anything in the docs about simulation..

> attempting to get up the learning curve of emacs/vhdl-mode has missed
> out IMHO. Two of my colleagues (who are distinctly mouse and windows
> types) are converted to Emacs for vhdl writing (purely down to the
> power of vhdl-mode). I used to use Codewright, which I thought was
> pretty hot, but it's not a patch on emacs, especially for VHDL.

Hmm, it looks very interesting but I use Verilog :)

> The rest of my scripts are simple bat files in windows, I just make a
> "working directory", copy in the EDF, UCF and any other NGD files I
> might need, then run NGCbuild, map, par etc. I have a few other bits
> ont he end for our internal use which generate a C-file with the
> bitstream as an array, and embed the time of compile into the UserID
> register.

I need to know the commands.. I am software guy and all the "compile" steps
are confusing :)

--
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: Andy Peters on
On Jan 24, 4:06 pm, <steve.l...(a)xilinx.com> wrote:
> Doug,
>
> The case was created on December 6, 2006. We reproduced the problem in-house
> and
> created the CRs on December 13. This was after 9.1i was released.
>
> CR 430822 is a memory leak and has been scheduled to be fixed in 10.1 to
> coincide with
> an intiative we have to fix memory issues. We're going to try to fix CR
> 430823 in 9.2.

So a memory-leak bug that Doug tells us has been in the tools for like
FIVE major releases is now "scheduled to be fixed in 10.1," which will
ship ... when?

-a