creating HARD MACROs broken in ISE 7.1 SP3 ?

Antti,

I had all your open webacases reviewed.

Since you have only the most basic service level, the webcase goal is to respond in less than two days.

So far we are keeping within that goal. Except the time you went on vacation, and we couldn't get to you for a week.

A couple of your cases have been escalated further, as you are doing things yourself, instead of using Impact tools (eg the flash programming), and we have to find out what other things are happening...and we will to help find out if you are doing something wrong, or if we just didn't document all the steps that our software performs.

If you are dissatisfied with this level of service, you may always sign up for something other than webcase support, and get less than 2 day max turnaround.

I accept you have issues, and get frustrated, but it looks like our support folks here are doing a great job supporting you at the most basic (ie free) level of service, and well within our service goals.

So, I know you are not happy right now, but, we are on your side, and we are providing the support you require, in a timely fashion.

Austin

Hard

hard

copy

So

Thanks, I actually did not mean to sound so negative - and I have to admit private problems have 'charged' me with negative charge, so that comes out in the wrong way. I understand that the WebCase people are doing their best, but, hm maybe I better not discuss my view on that in public.

As from the open WebCases actually only one is that is relevant to me all other will only help Xilinx to improve the tools. I have taken great time to open the webcases in the issues that i have encountered also in the cases where the problem is not so critical for me or where I can wait or workaround. But the issues are all real, and it is to the best of Xilinx to fix them. I assume many more people see and find bugs and problems and are silent about them.

ok, my "NO HELP" was overstatement, I should have read my posting second time, and I would most likely have done self censoring.

BTW I was not on vaccation, in the matter of fact I have not taken a paid vaccation in all my life (I am 40). The WebCase person did go to vaccation, then I had to send the same files to another person all over, then other case was delayed because of Bank holiday in Ireland, etc.

What said about 'platinum' services is possible true. The base level support people have very little experience with xilinx devices and tools and internal clearance to conctact the Xilinx experts himself those they have to apply to fab FAE who then in turn will contact the experts. If we add the time zone delay then it all ends up in a 2 week response time til solution, that is the very same time I have said to apply loong time ago. On the base level webcase no help is to be expected sooner as in 2 weeks unless the problem is really trivial.

So in short: I appologize, and withdraw my 'NO HELP' - I agree that the webcase people are doing their best (what isnt much as they dont have the required experience and as I am not paing then the people with experience are not involved at least in early stages of the webcases).

The only important (client waiting) issue, I really hope that will be cleared - to my understanding it would be quite good thing for Xilinx too - because to my understanding this issue prevents any and all 3rd parties to program the XCFxxP parts with other tools than impact, that is the XCFxxP can not be programmed on the factory floor at all, as impact doesnt qualify for production programmer.

Antti PS I actually think it would be the best of all of us if I would withhold ALL my public comments on Xilinx products and services and work more closely with Xilinx in order to fix them to the benefit of all of us. But that work should in that case be compensated to me. It doesnt make sense to pay premium support deal just to be able to help Xilinx to fix their problems better.

Hard

hard

copy

So

Hi Austin,

I did review my webcases as well - there was one case where it was flagged as waiting files from me, but on that case the files are actually sent and I have received notification that the case has been duplicated by the Xilinx engineer. So in that case the WebCase status was wrong.

On the other case there was status waiting customer call, this is something I dont understand at all, I have never selected phone as contact method or promised to call back.

On this case I have not only sent all info TWICE to Xilinx I also sent to xilinx a snapshot of our internal ipcores developed to test Xilinx software. If Xilinx is not interested fix their tools then its not my problem. I have done more then enough already. I closed this case on my behalf as I feel that I can not longer spend my time in thise case to help Xilinx to finally fix S3e support in Impact.

So there are no WebCases on hold because of my delayed responses. Just to clarify.

Antti

P.S. You did take time to comment my attitude, but did not comment the actual issue at all - is it possible to use 7.1 for Hard Macro development or not? If not then its very strange, it basically means that there are no advanced users of Xilinx tools at all? someone should have trapped that issue?

Antti,

All I will say is that we are working on all of your issues, and we take everyone of them seriously.

Clearly, if you will not use the phone, that will make things harder, as sometimes it is best to just talk to the customer.

Every hotline person is trained, and yes, the ones serving the basic service grade are newer than those who serve the premium service grade, but they are allowed to immediately escalate any issue directly to the next level. They do not have to go to the FAE for permission. It is encouraged to use the local FAE's just so that the customer has the best experience, and the local FAE stays in the loop, and is always aware of what his customer is doing.

As for the original Macro issue, if I new something about software, I'd say something, but I do not. The hotline is absolutely the best source for information on the software.

Unfortunately, it is postings like yours (that disparrage the webcase support) that encourage folks to email me directly with their problems, rather than open a webcase. That is terrible, as I can in no way compete with databases of tens of thousands of answers, 400 FAE's, and

200+ CAE's, and what they do very well.

If you look at my performance in answering webcases, I would be absolutely horrible!

So, do not email me with a specific case. Email me (or Peter) if a specific case is not being resolved to your satisfaction, or if you have been unable to get a question answered by the normal means.

If anything, emailing me first will delay the response to your problem.

Austin

"austin" schrieb im Newsbeitrag news: snipped-for-privacy@g14g2000cwa.googlegroups.com...

LOL, gosh I need a break. I do use and I am able to use phone, just my contact preferences is always set to email. And my mobile hasnt been switched off for some weeks, but I wasnt expecting any phone calls.

Shit, I did not mean to piss off anyone or discourage the WebCase use, for vast majority of case I belive the WebCase support is just proper and superior also in timely responses.

But I do not fall into the 'vast majority' category and in most/all cases where I encounter an issue its not trivial, so the WebCase response is not as immediate for me.

I do belive that Xilinx does take the WebCases (every each of them) seriously, its the best way to get feadback and found out problems.

As I have stated before the only BIG issue for me is the XCFxxP programming algorithm issue, I guess there is some weird silicon erratic behaviour that is compensated somehow in the impact internal programming algorithm, but that again makes the XCFxxP non programmable by any 3rd party tools.

All other webcases are mostly of interest to Xilinx as fixing the issues means fixing bugs and making the SW better.

Antti

This issue is covered by Answer Record 21615. A patch is available. It will also be fixed in SP4.

Bret Wade Xilinx Product Applications

Unfortunately, I gotta agree with this one.

Been using their software since ~1990 and everytime we update we go through the same thing.... the search for the newly broken function.

-- Ed

schrieb im Newsbeitrag news: snipped-for-privacy@g49g2000cwa.googlegroups.com...

Thank you Bret,

yes that tactical patch fixed the issue. I did not expect patches to be available for SP3 so did not even search for those.

suggestion - please please maintain a list of 'patches' for all SP's at some single location that would help finding them.

Antti

Xilinx is generally pretty good at setting up their site so google can find things. Can you find the patch from google?

-- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.

"Hal Murray" schrieb im Newsbeitrag news: snipped-for-privacy@megapath.net...

some

unsolicited

addresses.

I guess it may show up, but when trying normal queries

fpgaeditor crash extpin

then it the patch does not show up in xilinx google search

I only found it after searching by AR number given by Bret, otherwise I would not have found it all.

Antti PS Xilinx WebCase on this issue did not even contact my til now - so the c.a.f. response was WAY faster, thanks again Bret! Yes I did close the webcase as it was actually addressed by AR what I did not find until givent the correct number of the AR.

Hi Antti,

You would have had your solution a day earlier if you'd put a little more effort into the Answers search. Something like "7.1i add external pin" works for this case. You can't always depend on your posting being read by the person who wrote the Answer Record.

There is another FPGA Editor issue that you may run into:

_ans_display.jsp?getPagePath=21667

Regards, Bret

schrieb im Newsbeitrag news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

Hi Bret

yes you are absolutly right, I could have found the AR myself but I did not instead of spending more time in search for AR (what I did not know to exist) I opened a WebCase and yielled loud at caf - thats not very good, and does not always yield results.

I agree that all AR's can be found by entering some 'good' keywords into the search, but its very often that you dont find the AR even if it exists. Maybe its only my dis-ability to find the Xilinx AR's, but it is really not the first time I have not found the specific AR until pointed out by AR number by some Xilinx FAE.

Maybe all other people are more talented finding Xilinx AR's, can be.

--
I am not seeing problems as described in AR21667, but before the patch
for exptpin fix I did see another error during translate, maybe that is
fixed
with the exptin patch, I still need to check that.

Antti
PS yes I will try to search more hard on AR and errata stuff in the future,
maybe
one day I learn the trick to find proper ARs quickly without help from
others.

Ed,

That is why I don't like to see these kinds of complaint sessions here on comp.arch.fpga.

1) Antti would have received his answer through the hotline, but as he is an frieend of a friend, things were done to get a response back faster than it would have otherwise.

This may have been a mistake. With 250,000 active seats of software out there making designs, we have to support all of them, and try to do so with the same high level of quality. As much as I feel for Antti's situation, I can't respond to everyone. Peter and I would make a terrible hotline response team.

Instead, he and I act as "quality assurance" to make sure our responses are meeting the mark, and succeeding.

2) It opens the door for everyone who ever had an issue to add their two cents.

Of course we test the new software. In fact, we are adding test cases, and whole new test requirements with every service pack that goes out. Are we absolutely perfect? Not yet (one can hope). Is our software getting more, or less buggy? I think in goes in cycles. Virtex 4 added 100 (that we talk about) new features and capabilities. All of those had to get supported. That is a significant development of new software. For every X lines of code written there is a bug. For every Z bugs fixed, there is a new bug created.

Best thing you can do for software is stop adding new features to it, but unfortunately, we can't do that. Moore's Law has three of four more turns of the wheel left in it (in its present form - as far as we can see), so we must continue to do what has made us so successful, innovate.

(After 10 nm, no one really knows where we go, but we are certain that programmable logic becomes more valuable, not less, regardless of the technology. Carbon nanotube, organic self assembly, etc. are merely the means to implement the FPGA.)

I am not providing you with an excuse, just letting you know what the reality is. We test, and we test a lot. But, with new products, and new features, we can't be perfect, and we provide the fixes on a very timely basis (usually every bug found is fixed in the next service pack, or sooner by a tactical patch).

Austin

The things that bug me are the simple things that work with one version and with the next update they have been "improved" and no longer work.

For example (going from memory here...) - after upgrading to ver 7 when you get a compile error - you used to click on the error code and it would give you an explanation of the error. Now when you click on the error code - it goes off and does a Xilinx websearch for the error - and the search includes my application specific variable names. Naturally, everytime it comes back with 'error not found'. Now how in the heck did a function such as that break?

Another example - I have an older design written in Abel (OK - it was written long, long ago). Recently I modified the code to change the revision number within the CPLD. Compiled it with version 7.1... it gives no errors and appears to compile just fine. Download it to the part and nada.... nothing works. I look at the JEDEC file and it's half blank. Strange as the compiler didn't give any errors. Compiled the old, unmodified code with 7.1 - same results. Compiled both old and new with version 6.1 and it all works just fine.

But, hey, to tell the truth - there really isn't a whole lot to complain about regarding Xilinx sotware now that I've tried Atmel's Prochip Designer. Phew! Brings back memories of the old XACT days with DOS!!!

Suggestion.... I use lots of Xilinx Vertex and XC9500xl parts. Hey, these are good parts. But due to selection, for one of my projects, I often have to go with Atmel. They have the ATF150x series CPLD's which are DIRT cheap, operate from 5 volts and come in a PLCC package. Closest thing would be the Xilinx XC9500 series but they cost far, far more. I can easily fit the design in an ATF1504 which costs about $5. To get the same design to compile within a Xilinx part - I had to keep bumping it up in density until I got to the XC95288... and these cost many times the $5 price. It would be real nice if Xilinx would also supply CPLD's with this increased density, operate from 5 volts, be much cheaper like the Atmel parts and be in a large PLCC (MUST be socketable) package. Heck, I can forgo the 5V with an LDO but still MUST retain 5V I/O interface like the XC9500XL's.

You know what would be real neat -- if somebody were to come up with a generic 5 volt, 40-PIN DIP CPLD in a high enough density to emulate a 6502 or 6800 processor or the myriad of support parts that are no longer available. Ohhhh.... I'd give an arm and a leg for a cheap and reliable source of this type of part!

-- Ed

Did you check the created files, to see if the fitter, or front end tools, dropped the ball ?

ABEL is like assembler - there are still some designs where it is be best tool. Did you send Xilinx this example, so they can fix it ?

With over 6x the MC's, the price delta is not suprising. The ATF15xx series are usually ~2x, and in rare cases, up to 3x, more efficent so I'm surprised you need to go to 288MC in the 9500 to get a fit. Sounds more like a tool issue - did you show that to Xilinx ?

Lattice ispMACH4000 series show 5V I/O tolerance, but no PLCC. PLCC packages ( esp the smaller ones ) are usefull, but the trend is to TQFP and MLF, so socketing is going to get harder....

I can understand killing PLCC68 and PLCC84, but PLCC44 is still usefull.

Their new MachXO is Spec'd to 4.25V max.

The volumes for this might kill it as a product - I have seen BGA packages put onto DIP40 headers, which could solve your problem ?

-jg

Never did see what happened. Once I got it to compile with 6.1 - I just left it at that. While doing the initial compiles - I looked thru the log files cursively - never did see anything odd with them. NEver went into any detail, though.

Probably should have. It was weird that it gave no errors yet wouldn't compile right.

I believe it wasn't really a macrocell count issue in this case but rather a routing issue. Can't remember details at this time - I'll rerun it since I now have design done..

Yeah, I saw those. It's the PLCC that gets me. Gotta be socketable and I don't have access to SMD equipment for this type of effort.

I hope they keep the larger PLCC's especially the 84! The PLCC44 isn't very usefull due to the large number of pins used for power and JTAG. Only end up with roughly 30 usefull pins when done.

Oh, I dunno if demand will be real small - but probably not big enough for the incredibly huge volumes everybody wants, though. There's still a lot of demand out there for some of the old stuff. Have you seen what the prices for the good old 6821 PIA's have done in the past year or so since the last mfr (ST) discontinued them? And, just in the past two years, 6800 CPU's have gone from ~$2 each to $6 each for NOS ones. Rockwell RIOT's have gone from $1.89 each to $6.50 each in the same amount of time. I imagine this will escalate qutie quickly.

Unfortunately, them adapters are usually extremely expensive and often more than the IC itself. That tends to be another issue. And having to attach the BGA -- that's another issue.

I have two jobs -- #1 -- the real one which produces plenty of high density boards with SMD, etc. #2 -- the hobby which sells parts/assemblies to a rather limited audience. It's this hobby job that requires no SMD for several reasons - first being I don't own SMD equipment at work. Second being that my customers frown... no make that loudly curse - at SMD components.

Just for the heck of it - I redesigned one my high demand boards to use a single Spartan-3 to perform the task of a 6502 plus three 6532's and a bunch of glue logic. It fit and worked beautifully. These Spartan's are cheap considering I would only need one. Problem is - I have no way to install a PQFP-208 (or could ahve been a PQFP-240) on my board. These boards are used in relatively harsh environment and gotta be - MUST be user replaceable with no custom tools. I'd love to see an inexpensive way to do this! Anybody have any ideas?

-- Ed

Wierd yes, rare no....

The cheapest way to get this, is to piggy-back on someone elses volume ?

- ideal here would be Pentium PGA ZIFF sockets. Many pins at low costs. [ Pentiums are actually modules, with caps included ]

Design the FPGA onto a carrier PCB, add caps, and reflow them at your work.

-jg

Would be my first choice... but we now contract out the assembly....

-- Ed

In their latest data, with the move to lead-free, Atmel are dropping the PLCC68, and the PLCC84 is restricted to only non "L" and industrial grade. -jg