Coolrunner in system programming - XAPP0058 - viable?

>  I wonder if this reply is more arrogant and rude than
> the one I got from their "support" department 5-6 years
> ago, then they wanted me to make the $20M/quarter revenue
> before they would consider talking to me.

My mistake, it has been $9M, not $20M.
I put my archived thread at
http://tgi-sci.com/misc/xiw.txt

Here is the cutest excerpt:

=======================================================================
To: <Caroline.Hughes@xilinx.com>
From: Dimiter Popoff <tgi@bulnet.bg>
Subject: Case # 293733 Coolrunner ZIA decoder bits
Date: Wed, 15 Mar 2000 14:58:39 +0200

Mrs. Hughes,

thank you for your reply - it answers my questions to a great extent.
What I still do not understand is:

>Our Major Accounts only have access to this information
>i) When they have generated approximately $9M of revenue per quarter
>with us.
>ii) If they specifically ask for this information.

Do only those comapnies get the information who cover both i) and
ii) ?

Does that mean that they all get access to the information only after
they have made the first $9M/quarter for you, wether they have asked
for this information before this or not?

Regards,
Dimiter Popoff

=======================================================================
From: "Caroline Hughes" <Caroline.Hughes@xilinx.com>
To: Dimiter Popoff <tgi@bulnet.bg>
Date: Wed, 15 Mar 2000 13:41:55 +0000
Subject: Re: Case # 293733 Coolrunner ZIA decoder bits

Mr. Popoff,

I'm glad I managed to answer part of your question. In answer to
the question below:


> Does that mean that they all get access to the information only after
> they have made the first $9M/quarter for you, wether they have asked
> for this information before this or not?
>

They will not get automatic access to this information, they must
first have made the $9M/quarter and then they must ask for it.
Some customers may generate more than $9M/quarter,
but if they do not ask for the information, they will not get it!

I hope this resolves your query fully.

Regards,
Caroline Hughes.

=======================================================================

Now we have them worried about our JTAG chain wellbeing.

 They are so hostile about these issues it is obviosly
not just about the data being kept secret, there is
more to it than that. I wish I knew what...

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

On Nov 20, 4:05 pm, Didi <didi...@gmail.com> wrote:
> Jim,
>
> > Do you have the xsvf file size handy, for your XC2C64 design ?
> > That would give Didi some info on the svf pathway.
> > (to go with the player info you've given)
>
> I am quite sure I can reproduce the entire chain of hoops
> in xapp058. It would allow me to eventually reverse engineer
> their jedec -> jtag mapping in a matter of days or may be
> weeks if I want to include more devices.
>  The "impact" tool Antonio is using is not available on the
> xilinx website, but I am sure I could find it as well, it
> must be out there.
>  Yet the question remains - _why_ do they keep the mapping
> data secret? I predicted we may wait for a century or so
> for a plausible answer - the first one we got from their
> CPLD support is more arrogant than it is ridiculous. Who
> does this person think is talking to, housewifes? Their
> JTAG interface is too complex for us to handle, yeah,
> in fact some of us have handled the coolrunner jtag interface
> before xilinx had a clue what the coolrunner was.
>  I wonder if this reply is more arrogant and rude than
> the one I got from their "support" department 5-6 years
> ago, then they wanted me to make the $20M/quarter revenue
> before they would consider talking to me. I'll dig that
> message and post it here as well, this is the least their
> arrogance deserves.
>
> Dimiter
>
> ------------------------------------------------------
> Dimiter Popoff               Transgalactic Instruments
>
> http://www.tgi-sci.com
> ------------------------------------------------------
>
> On Nov 20, 11:54 am, Jim Granville <no.s...@designtools.maps.co.nz>
> wrote:
>
> > Antonio Pasini wrote:
> > > Il 20/11/2007 0.06, Didi ha scritto:
>
> > >>> 3) use Impact (free download) to translate the jedec in a XSVF binary
> > >>> file. You can do on GUI by hand, or by makefile as I prefer; syntax is:
>
> > >> Now this is a hoop I can do without. XAPP058 actually states you have
> > >> to do jedec -> svf -> xsvf, and I see only the svf->xsvf tool freely
> > >> available. Is the tool for doing jedec->svf also freely available?
> > >> Can you point me to it please?
>
> > > Impact makes the jedec -> svf OR jedec ->XSVF translation, with the
> > > commands of my previous posts.
> > > At the time of XAPP058, it wasn't able to.
> > > Now you can just go stright from jedec to XSVF with Impact alone.
>
> > > Impact is free with the Webpack
> > > (http://www.xilinx.com/ise/logic_design_prod/webpack.htm).
>
> > > (I remember that there's also a "production" package with just the
> > > Impact tool, but I don't find the link).
>
> > Do you have the xsvf file size handy, for your XC2C64 design ?
> > That would give Didi some info on the svf pathway.
> > (to go with the player info you've given)
>
> > (the XC2C64 has 3226.5 Bytes of fuse info.)
> > Usually svf have quite an overhead :
> > (eg an Atmel device with 2101.75 bytes of fuse info,
> > spawns a 110925 byte SVF file ~ 50:1 )
>
> > I have not tried to compress the SVF, but I'd guess 5-10
> > simple compression should be easy, esp for a known brand.
> > So that brings it down to 10-20K bytes, for a 2K binary image.
>
> > I also notice the Atmel tools can create a PCF via SVF2PCF,
> > for an even larger file, but one that is a logic analyser
> > storage - 191K lines, to JED pgm the 2KB fuses.
>
> > -jg

On Nov 19, 4:19 pm, Didi <didi...@gmail.com> wrote:
> > > Well the fact of the matter is that there is no CPLD on the market
> > > to compete with all the coolrunner parameters at the same time - and
> > > I do use them.
>
> > Across the size range, you may be right.
> > But at the highest volume end Atmel and Lattice have good low power
> > offerings. Actel may start to impact > 128MC CPLDs
>
> I would be really happy to see an alternative to the coolrunner,
> especially if its documentation is less secretive. Until then,
> we are all stuck with xilinx for CPLDs above a certain complexity
> and below some power, which is why I am still trying to get some
> way to use them (notice I even accept to use their software to
> produce the jedec file, something unprecedented here).
>
> > My understanding there is the parts were not externally foundry fab'd
> > and when the plug was pulled on the fab line, that then killed the
> > product line. ...
>
> Well I do not find it very plausible - making a new coolrunner line
> from scratch cannot have been easier than repeating an existing
> product, mask sets and all being available.
>  But whatever, their agreement with Philips was to support all
> existing customers the way Philips had supported them.
>  This has not been the case with us - we do have the jedec -> jtag
> maps from Philips and we do not have these from Xilinx.
>
> Dimiter
>
> ------------------------------------------------------
> Dimiter Popoff               Transgalactic Instruments
>
> http://www.tgi-sci.com
> ------------------------------------------------------
Hi Dimiter,

Could you elaborate why you can't use other low power CPLD's, Lattice
4000Z, for example? I'm asking this question because in Lattice case
there is C code supplied for you to make the kind of CPLD programming
discussed in this thread very easy.

Alex

> Could you elaborate why you can't use other low power CPLD's, Lattice
> 4000Z, for example? I'm asking this question because in Lattice case
> there is C code supplied for you to make the kind of CPLD programming
> discussed in this thread very easy.
>
> Alex

I cannot - have not checked them recently, will do and will
report :-).

Dimiter

On Nov 20, 4:38 pm, Alex <engin...@gmail.com> wrote:
> On Nov 19, 4:19 pm, Didi <didi...@gmail.com> wrote:
>
> > > > Well the fact of the matter is that there is no CPLD on the market
> > > > to compete with all the coolrunner parameters at the same time - and
> > > > I do use them.
>
> > > Across the size range, you may be right.
> > > But at the highest volume end Atmel and Lattice have good low power
> > > offerings. Actel may start to impact > 128MC CPLDs
>
> > I would be really happy to see an alternative to the coolrunner,
> > especially if its documentation is less secretive. Until then,
> > we are all stuck with xilinx for CPLDs above a certain complexity
> > and below some power, which is why I am still trying to get some
> > way to use them (notice I even accept to use their software to
> > produce the jedec file, something unprecedented here).
>
> > > My understanding there is the parts were not externally foundry fab'd
> > > and when the plug was pulled on the fab line, that then killed the
> > > product line. ...
>
> > Well I do not find it very plausible - making a new coolrunner line
> > from scratch cannot have been easier than repeating an existing
> > product, mask sets and all being available.
> >  But whatever, their agreement with Philips was to support all
> > existing customers the way Philips had supported them.
> >  This has not been the case with us - we do have the jedec -> jtag
> > maps from Philips and we do not have these from Xilinx.
>
> > Dimiter
>
> > ------------------------------------------------------
> > Dimiter Popoff               Transgalactic Instruments
>
> >http://www.tgi-sci.com
> > ------------------------------------------------------
>
> Hi Dimiter,
>
> Could you elaborate why you can't use other low power CPLD's, Lattice
> 4000Z, for example? I'm asking this question because in Lattice case
> there is C code supplied for you to make the kind of CPLD programming
> discussed in this thread very easy.
>
> Alex

Alex,

> Could you elaborate why you can't use other low power CPLD's, Lattice
> 4000Z, for example? I'm asking this question because in Lattice case
> there is C code supplied for you to make the kind of CPLD programming
> discussed in this thread very easy.

just had a look at the datasheet and I see no technical reason at all
not to use these - the devices are good.
 Can you please point me to the programming info available for them?

If I can adopt them and thus forget about Xilinx I would be a happy
man.

Thanks,

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

On Nov 20, 4:38 pm, Alex <engin...@gmail.com> wrote:
> On Nov 19, 4:19 pm, Didi <didi...@gmail.com> wrote:
>
> > > > Well the fact of the matter is that there is no CPLD on the market
> > > > to compete with all the coolrunner parameters at the same time - and
> > > > I do use them.
>
> > > Across the size range, you may be right.
> > > But at the highest volume end Atmel and Lattice have good low power
> > > offerings. Actel may start to impact > 128MC CPLDs
>
> > I would be really happy to see an alternative to the coolrunner,
> > especially if its documentation is less secretive. Until then,
> > we are all stuck with xilinx for CPLDs above a certain complexity
> > and below some power, which is why I am still trying to get some
> > way to use them (notice I even accept to use their software to
> > produce the jedec file, something unprecedented here).
>
> > > My understanding there is the parts were not externally foundry fab'd
> > > and when the plug was pulled on the fab line, that then killed the
> > > product line. ...
>
> > Well I do not find it very plausible - making a new coolrunner line
> > from scratch cannot have been easier than repeating an existing
> > product, mask sets and all being available.
> >  But whatever, their agreement with Philips was to support all
> > existing customers the way Philips had supported them.
> >  This has not been the case with us - we do have the jedec -> jtag
> > maps from Philips and we do not have these from Xilinx.
>
> > Dimiter
>
> > ------------------------------------------------------
> > Dimiter Popoff               Transgalactic Instruments
>
> >http://www.tgi-sci.com
> > ------------------------------------------------------
>
> Hi Dimiter,
>
> Could you elaborate why you can't use other low power CPLD's, Lattice
> 4000Z, for example? I'm asking this question because in Lattice case
> there is C code supplied for you to make the kind of CPLD programming
> discussed in this thread very easy.
>
> Alex

Didi wrote:
> Jim,
> 
> 
>>Do you have the xsvf file size handy, for your XC2C64 design ?
>>That would give Didi some info on the svf pathway.
>>(to go with the player info you've given)
> 
> 
> I am quite sure I can reproduce the entire chain of hoops
> in xapp058. It would allow me to eventually reverse engineer
> their jedec -> jtag mapping in a matter of days or may be
> weeks if I want to include more devices.
>  The "impact" tool Antonio is using is not available on the
> xilinx website, but I am sure I could find it as well, it
> must be out there.
>  Yet the question remains - _why_ do they keep the mapping
> data secret? 

With the SVF pathway, it is not entirely secret.

The info IS all there, in an ASCI file,
just not in the most uC-friendly way.

A middle pathway could be a ' uC compressed SVF', where
you get the revision pathway of SVF, but not
so much of the size penalty ?.

Or even a stripped SVF, that has only the data in the
transport-order, but that loses revsion features,
and hard codes the device into your uC.

The code sizes quoted for players were not huge,
and a simple token-compressed player could be smaller.


> I predicted we may wait for a century or so
> for a plausible answer - the first one we got from their
> CPLD support is more arrogant than it is ridiculous. Who
> does this person think is talking to, housewifes? 

:))))) !!!  ROFL

No, but I suspect students ?

They must have the mapping info, as part of their JED2SVF
pathways, in a compilable (likely C tables?) form.

So, perhaps they could release that ?
They release the SVF player source code ?
Treat this as an optional piece ?

-jg

> > I predicted we may wait for a century or so
> > for a plausible answer - the first one we got from their
> > CPLD support is more arrogant than it is ridiculous. Who
> > does this person think is talking to, housewifes?
>
> :))))) !!!  ROFL
>
> No, but I suspect students ?
>
> They must have the mapping info, as part of their JED2SVF
> pathways, in a compilable (likely C tables?) form.

Of course they do. I have it for the Philips Coolrunner.
And I still have my extraction scripts - I used to edit/copy
each of a few excel pages and turn them into text, then
the text got processed by a DPS script into something I could
simply put somewhere within a source file.

> So, perhaps they could release that ?
> They release the SVF player source code ?

It is generally irrelevant which they will release - the excel,
the source lookup table, whatever.
 They are not after the cash they make on having these data secret,
it is negligible for their size.
 It must be something else - the answer to the _why_ question
from above, next answer they have may be good enough for
students (I disagree with you, the first one was only good
for housewives :-) ). Which will bring us 2 answers closer to the
century it will take them to come up with a plausible answer.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

On Nov 20, 9:13 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Didi wrote:
> > Jim,
>
> >>Do you have the xsvf file size handy, for your XC2C64 design ?
> >>That would give Didi some info on the svf pathway.
> >>(to go with the player info you've given)
>
> > I am quite sure I can reproduce the entire chain of hoops
> > in xapp058. It would allow me to eventually reverse engineer
> > their jedec -> jtag mapping in a matter of days or may be
> > weeks if I want to include more devices.
> >  The "impact" tool Antonio is using is not available on the
> > xilinx website, but I am sure I could find it as well, it
> > must be out there.
> >  Yet the question remains - _why_ do they keep the mapping
> > data secret?
>
> With the SVF pathway, it is not entirely secret.
>
> The info IS all there, in an ASCI file,
> just not in the most uC-friendly way.
>
> A middle pathway could be a ' uC compressed SVF', where
> you get the revision pathway of SVF, but not
> so much of the size penalty ?.
>
> Or even a stripped SVF, that has only the data in the
> transport-order, but that loses revsion features,
> and hard codes the device into your uC.
>
> The code sizes quoted for players were not huge,
> and a simple token-compressed player could be smaller.
>
> > I predicted we may wait for a century or so
> > for a plausible answer - the first one we got from their
> > CPLD support is more arrogant than it is ridiculous. Who
> > does this person think is talking to, housewifes?
>
> :))))) !!!  ROFL
>
> No, but I suspect students ?
>
> They must have the mapping info, as part of their JED2SVF
> pathways, in a compilable (likely C tables?) form.
>
> So, perhaps they could release that ?
> They release the SVF player source code ?
> Treat this as an optional piece ?
>
> -jg

Didi wrote:
> Alex,
> 
> 
>>Could you elaborate why you can't use other low power CPLD's, Lattice
>>4000Z, for example? I'm asking this question because in Lattice case
>>there is C code supplied for you to make the kind of CPLD programming
>>discussed in this thread very easy.
> 
> 
> just had a look at the datasheet and I see no technical reason at all
> not to use these - the devices are good.
>  Can you please point me to the programming info available for them?
> 
> If I can adopt them and thus forget about Xilinx I would be a happy
> man.

The only design oversight I recall from Lattice, is that they
do NOT have pin-configurable Pullups - the config is global.
[IIRC Xilinx and Atmel, do Pin-level select of Pullup, and also Schmitt]

So, for very low power designs, you'd set no-pull-ups, and selective
external resisitors ( a single pin held the wrong-way, adds up to 150uA )

Data:
["All of the I/Os and dedicated inputs have the capability to provide a 
bus-keeper latch, Pull-up Resistor or Pull-down
Resistor. A fourth option is to provide none of these. The selection is 
done on a global basis. The default in both
hardware and software is such that when the device is erased or if the 
user does not specify, the input structure is
configured to be a Pull-up Resistor."]

-jg

Didi wrote:

>>>I predicted we may wait for a century or so
>>>for a plausible answer - the first one we got from their
>>>CPLD support is more arrogant than it is ridiculous. Who
>>>does this person think is talking to, housewifes?
>>
>>:))))) !!!  ROFL
>>
>>No, but I suspect students ?
>>
>>They must have the mapping info, as part of their JED2SVF
>>pathways, in a compilable (likely C tables?) form.
> 
> 
> Of course they do. I have it for the Philips Coolrunner.
> And I still have my extraction scripts - I used to edit/copy
> each of a few excel pages and turn them into text, then
> the text got processed by a DPS script into something I could
> simply put somewhere within a source file.

So you would be quite happy with a portion of JED2SVF,
as a source table - for further 'rework' ?


> 
> 
>>So, perhaps they could release that ?
>>They release the SVF player source code ?
> 
> 
> It is generally irrelevant which they will release - the excel,
> the source lookup table, whatever.
>  They are not after the cash they make on having these data secret,
> it is negligible for their size.
>  It must be something else - the answer to the _why_ question
> from above, next answer they have may be good enough for
> students (I disagree with you, the first one was only good
> for housewives :-) ). Which will bring us 2 answers closer to the
> century it will take them to come up with a plausible answer.

Big companies have their own inertias and procedures, so it is
best to figure out why, and find a way around that :)

In this case, I can see that a separate pgm-info PDF, has a separate
sign-off procedure, and also has a risk and support cost.

The JED2SVF and SVF itself is already released, so they are
happy with that level.

All I see it needs is either

a) The JED mapping table to be also released.
Advantage here is that is a proven table, as it is
already part of a proven & existing released flow (Impact/JED2SVF),
so there are no QC costs. The tables auto-revise with new devices.


A designer would take the SVF JEDEC state infos, and port those
into the uC, but be able to use the tables to morph a JED.

or
b) (take a little SW engineering)

Make the JED2SVF impact flow, so it can also create a
fuse-linear file.
Besides the Eng. time, this can get a little trickier,
as sometimes fuse arrays have 'don't care, or read-stuck'
gaps and portions in them. Getting thst info in there
could be a challenge.

If I were Xilinx, I'd choose a)  :)

Comments Peter / Jesse ?

PS : Did I see some comment earlier about Xilinx open-sourcing their
Impact programming flows ? [That also encompasses a) ]

-jg

> So you would be quite happy with a portion of JED2SVF,
> as a source table - for further 'rework' ?

Not sure - I have to see it. The lookup table would do, but
the utility - no, it would only provide a way to reverse
engineering the table, which can be pretty bulky.

> Besides the Eng. time, this can get a little trickier,
> as sometimes fuse arrays have 'don't care, or read-stuck'
> gaps and portions in them. Getting thst info in there
> could be a challenge.

Indeed so. This info is needed as well. The simplest way for
everyone would be just handing me the Excel files, no
more questions asked guaranteed by my signature, NDA
if necessary, too. I know my way from there.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

On Nov 20, 10:59 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> Didi wrote:
> >>>I predicted we may wait for a century or so
> >>>for a plausible answer - the first one we got from their
> >>>CPLD support is more arrogant than it is ridiculous. Who
> >>>does this person think is talking to, housewifes?
>
> >>:))))) !!!  ROFL
>
> >>No, but I suspect students ?
>
> >>They must have the mapping info, as part of their JED2SVF
> >>pathways, in a compilable (likely C tables?) form.
>
> > Of course they do. I have it for the Philips Coolrunner.
> > And I still have my extraction scripts - I used to edit/copy
> > each of a few excel pages and turn them into text, then
> > the text got processed by a DPS script into something I could
> > simply put somewhere within a source file.
>
> So you would be quite happy with a portion of JED2SVF,
> as a source table - for further 'rework' ?
>
>
>
> >>So, perhaps they could release that ?
> >>They release the SVF player source code ?
>
> > It is generally irrelevant which they will release - the excel,
> > the source lookup table, whatever.
> >  They are not after the cash they make on having these data secret,
> > it is negligible for their size.
> >  It must be something else - the answer to the _why_ question
> > from above, next answer they have may be good enough for
> > students (I disagree with you, the first one was only good
> > for housewives :-) ). Which will bring us 2 answers closer to the
> > century it will take them to come up with a plausible answer.
>
> Big companies have their own inertias and procedures, so it is
> best to figure out why, and find a way around that :)
>
> In this case, I can see that a separate pgm-info PDF, has a separate
> sign-off procedure, and also has a risk and support cost.
>
> The JED2SVF and SVF itself is already released, so they are
> happy with that level.
>
> All I see it needs is either
>
> a) The JED mapping table to be also released.
> Advantage here is that is a proven table, as it is
> already part of a proven & existing released flow (Impact/JED2SVF),
> so there are no QC costs. The tables auto-revise with new devices.
>
> A designer would take the SVF JEDEC state infos, and port those
> into the uC, but be able to use the tables to morph a JED.
>
> or
> b) (take a little SW engineering)
>
> Make the JED2SVF impact flow, so it can also create a
> fuse-linear file.
> Besides the Eng. time, this can get a little trickier,
> as sometimes fuse arrays have 'don't care, or read-stuck'
> gaps and portions in them. Getting thst info in there
> could be a challenge.
>
> If I were Xilinx, I'd choose a)  :)
>
> Comments Peter / Jesse ?
>
> PS : Did I see some comment earlier about Xilinx open-sourcing their
> Impact programming flows ? [That also encompasses a) ]
>
> -jg

Didi wrote:
>  The "impact" tool Antonio is using is not available on the
> xilinx website,

Sure it is!  It's part of WebPACK, which is avaiable for download at no
charge.