Coolrunner in system programming - XAPP0058 - viable?

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

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

Dimiter

Alex,

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

------------------------------------------------------

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.

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

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.

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

------------------------------------------------------

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

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

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

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.

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

------------------------------------------------------

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

Oh I see, my mistake, thanks. I have not used their software yet, so I don't know it in much detail.

Dimiter

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

------------------------------------------------------