FPGA Central

Hi

I wonder if Xilinx does any testing of their releases at all - creating Hard
Macros seems to be impossible in 7.1 as the FPGAeditor self terminates
itself on any attemp to add extpin. Well it seems to be that 6.3 made hard
macros are compatible and useable in 7.1 but its very awkward to keep a copy
of 6.3 only for that purpose.

Antti
PS to Xilinx, yes I did open a WebCase. I have plenty of webcases open. So
far NO HELP.

Antti Lukats wrote:
> Hi
>
> I wonder if Xilinx does any testing of their releases at all - creating Hard
> Macros seems to be impossible in 7.1 as the FPGAeditor self terminates
> itself on any attemp to add extpin. Well it seems to be that 6.3 made hard
> macros are compatible and useable in 7.1 but its very awkward to keep a copy
> of 6.3 only for that purpose.
>
> Antti
> PS to Xilinx, yes I did open a WebCase. I have plenty of webcases open. So
> far NO HELP.

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

"austin" <[email protected]> schrieb im Newsbeitrag
news:[email protected] oups.com...
> Antti Lukats wrote:
> > Hi
> >
> > I wonder if Xilinx does any testing of their releases at all - creating
Hard
> > Macros seems to be impossible in 7.1 as the FPGAeditor self terminates
> > itself on any attemp to add extpin. Well it seems to be that 6.3 made
hard
> > macros are compatible and useable in 7.1 but its very awkward to keep a
copy
> > of 6.3 only for that purpose.
> >
> > Antti
> > PS to Xilinx, yes I did open a WebCase. I have plenty of webcases open.
So
> > far NO HELP.
>
> 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
>

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.

"austin" <[email protected]> schrieb im Newsbeitrag
news:[email protected] oups.com...
> Antti Lukats wrote:
> > Hi
> >
> > I wonder if Xilinx does any testing of their releases at all - creating
Hard
> > Macros seems to be impossible in 7.1 as the FPGAeditor self terminates
> > itself on any attemp to add extpin. Well it seems to be that 6.3 made
hard
> > macros are compatible and useable in 7.1 but its very awkward to keep a
copy
> > of 6.3 only for that purpose.
> >
> > Antti
> > PS to Xilinx, yes I did open a WebCase. I have plenty of webcases open.
So
> > far NO HELP.
>
> 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
>
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" <[email protected]> schrieb im Newsbeitrag
news:[email protected] oups.com...
> 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
>

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.

http://www.xilinx.com/xlnx/xil_ans_d...PagePath=21615

Bret Wade
Xilinx Product Applications

"Antti Lukats" <[email protected]> wrote in message
news:[email protected]...
> Hi
>
> I wonder if Xilinx does any testing of their releases at all -

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


> creating Hard
> Macros seems to be impossible in 7.1 as the FPGAeditor self terminates
> itself on any attemp to add extpin. Well it seems to be that 6.3 made hard
> macros are compatible and useable in 7.1 but its very awkward to keep a
> copy
> of 6.3 only for that purpose.
>
> Antti
> PS to Xilinx, yes I did open a WebCase. I have plenty of webcases open. So
> far NO HELP.
>
>
>

<[email protected]> schrieb im Newsbeitrag
news:[email protected] oups.com...
> This issue is covered by Answer Record 21615. A patch is available. It
> will also be fixed in SP4.
>
> http://www.xilinx.com/xlnx/xil_ans_d...PagePath=21615
>
> Bret Wade
> Xilinx Product Applications
>

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

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

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" <[email protected]> schrieb im Newsbeitrag
news:[email protected]...
> >suggestion - please please maintain a list of 'patches' for all SP's at
some
> >single location that would help finding them.
>
> 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.
>

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:
http://www.xilinx.com/xlnx/xil _ans_display.jsp?getPagePath=21667

Regards,
Bret

<[email protected]> schrieb im Newsbeitrag
news:[email protected] ups.com...
> 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:
> http://www.xilinx.com/xlnx/xil _ans_display.jsp?getPagePath=21667
>
> Regards,
> Bret
>

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

"austin" <[email protected]> wrote in message
news:[email protected] ups.com...
> Ed,
>
> 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

GPE wrote:
> "austin" <[email protected]> wrote in message
> news:[email protected] ups.com...
>
>>Ed,
>>
>>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
<snip>
>
> 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.

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

> 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.

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 ?


> 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.

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 ?


> 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.

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.


> 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!

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

"Jim Granville" <[email protected]> wrote in message
news:[email protected]...
> GPE wrote:
>> "austin" <[email protected]> wrote in message
>> news:[email protected] ups.com...
>>
>>>Ed,
>>>
>>>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
> <snip>
>>
>> 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.
>
> Did you check the created files, to see if the fitter, or front end tools,
> dropped the ball ?

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.

>
>> 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.
>
> 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 ?

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

>
>
>> 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.
>
> 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 ?

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..

>
>
>> 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.
>
> 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....
>

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 can understand killing PLCC68 and PLCC84, but PLCC44 is still usefull.

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.

>
> Their new MachXO is Spec'd to 4.25V max.
>
>
>> 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!
>
> The volumes for this might kill it as a product - I have seen BGA packages
> put onto DIP40 headers, which could solve your problem ?
>

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



> -jg
>

GPE wrote:
> "Jim Granville" <[email protected]> wrote in message
> news:[email protected]...
>
>>GPE wrote:
>>>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.
>>
>>Did you check the created files, to see if the fitter, or front end tools,
>>dropped the ball ?
>
>
> 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.
>
>>>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.
>>
>>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 ?
>
>
> Probably should have. It was weird that it gave no errors yet wouldn't
> compile right.

Wierd yes, rare no....


<snip>
> 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?

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

"Jim Granville" <[email protected]> wrote in message
news:[email protected]...
> GPE wrote:
>> "Jim Granville" <[email protected]> wrote in message
>> news:[email protected]...
>>
>>>GPE wrote:
>>>>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.
>>>
>>>Did you check the created files, to see if the fitter, or front end
>>>tools, dropped the ball ?
>>
>>
>> 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.
>>
>>>>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.
>>>
>>>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 ?
>>
>>
>> Probably should have. It was weird that it gave no errors yet wouldn't
>> compile right.
>
> Wierd yes, rare no....
>
>
> <snip>
>> 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?
>
> 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.

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

-- Ed


>
> -jg
>
>

GPE wrote:
> 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.

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

[email protected] wrote:
> 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:
> http://www.xilinx.com/xlnx/xil _ans_display.jsp?getPagePath=21667

I've opened a handful of web cases where the response was, "In Answer
Record 655321, you'll find your answer ..."

Which is all well and good, but I still find it tough to hit on the
magic search incantation that will lead me to the pot of gold at the
end of the rainbow.

-a

On 15 Aug 2005 09:58:49 -0700, "Andy Peters" <[email protected]>
wrote:

>[email protected] wrote:
>> 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:
>> http://www.xilinx.com/xlnx/xil _ans_display.jsp?getPagePath=21667
>
>I've opened a handful of web cases where the response was, "In Answer
>Record 655321, you'll find your answer ..."
>
>Which is all well and good, but I still find it tough to hit on the
>magic search incantation that will lead me to the pot of gold at the
>end of the rainbow.
>
>-a

Same here. I make a serious effort to find things in the Answer
Record database before filing a web case. And yet sometimes I'm told
that the answer, or something in the neighborhood, was already written
up.

Those offering support on the web--and by no means am I limiting
myself to Xilinx--would profit from periodic useabiliity studies.
Having someone come to your place of business and search for things on
your web site while you watch would be a useful way to improve data
organization and search capabilities. Just make sure there's nothing
near the computer that the subject can throw.

Bob Perlman
Cambrian Design Works