System ACE equivalent for CPLDs

I know this isn't exactly comp.arch.cpld...

does anyone know of a COTS solution for programming a (Xilinx) CPLD without using PC + Windows + Impact etc etc. (a stand alone chunk of hardware with a way for me to give it a set of bit files and a Program button would be nice)

I want to load one bit-file into a device to run a test, then once the test is finished load a second bit-file - but i'm investigating a stand alone solution not using a PC + Cable + Software etc etc.

Any pointers are welcome. Thanks! Ben Benjamin TODD

ABCOIN

CERN - European Organisation for Nuclear Research,

Accelerator and Beam Controls - Infrastructure division.

Building 864:1A01, Meyrin

Geneva 23, Switzerland, CH-1211.

Reply to
Benjamin Todd
Loading thread data ...

"Benjamin Todd" schrieb im Newsbeitrag news:djkmeg$mdo$ snipped-for-privacy@sunnews.cern.ch...

without

a

nice)

test

Hi Ben,

as usually YES/NO. :)

1) if you badly want then you can use SystemACE to program PLDs in the way you described. its not very reasonable but its sure is possible.

2) there is no direct COTS solution I think. you can use any small MCU to re-configure the PLDs solutions for that exist.

reloading an PLD with test conf each time at power up isnt very nice thing todo in generic. sure it depend on the PLD in use.

I think with machXO you have an option to load the flash or the PLD (what is actually ram based)

antti

Reply to
Antti Lukats

Ah, before I investigate the system ACE are you sure it can be hacked to work for PLDs?

formatting link
Page 2... I also read the uP ideas... But it seams like a lot of work on my own...
formatting link

I was hoping someone had commercialised this.. Hmm, anyways, thanks for your input Antti. Ben

Reply to
Benjamin Todd

The problem with programming CPLDs and PROMs using SystemACE is that the programming algorithm for these devices is non-deterministic and require branch on condition flows to work reliably. SystemACE does not provide this capability. That is the reason that the uP flow detailed by XAPP058 is needed.

As also indicated, an interesting question to ask is why do you want to configure your CPLD every time you power up? Is your design pattern changing all the time? Is this some sort of demo board?

Benjam> I know this isn't exactly comp.arch.cpld...

Reply to
Neil Glenn Jacobson

Not exactly, maybe i'm being a little ambitious...

I'm just doing some research into making a test apparatus for some designs using various CPLDs. The idea was to make a discrete piece of hardware that the UUT would be plugged into, and then a little report saying whether it passes or fails - this needs to be rugged, and industrialised.

Using boundary scan I can only verify about half the board, and the less critical half at that, so i'm wondering whether I could use one bit file to run a sequence of test vectors in conjunction with the external tester, and then once all the interconnects are established as correct, load the proper bit file.

I guess you're wondering why I don't just go for a PC running impact... well i'm trying to avoid having to maintain a PC with the manufacturer, including the OS, the test software etc etc.

Ben

Reply to
Benjamin Todd

OK. Fair enough. And you could use SystemACE to do all that except for programming the CPLD. Why use a CPLD and not just a small, cheap FPGA like a Spartan3 or a variant?

Benjam>>As also indicated, an interesting question to ask is why do you want to

Reply to
Neil Glenn Jacobson

Ah, the board is already in the pre-series stage, there are a couple of reasons why we chose a 9500 CPLD (yes I know, very old!)...

5V internal = only one PSU needed & whole board at 5V which is excellent for reliability, our radiation campaigns showed that it's highly immune to soft-errors (TID was much more effective), It's active almost as soon as it is powered up whereas FPGAs must wait whilst they are being programmed. And we simply don't need the complexity of an FPGA. Don't get me wrong, we use all manner of Xilinx stuff in the lastest project (95288 95144XL XC2C128 XC2S400 XC3S1000) just depends on the exact nature of the application. I think I might investigate the Microprocessor alternative, just then have to figure out how to get the .bit file into some flash near the microprocessor in a reliable and easy manner. Ah well. Ben

"Neil Glenn Jacobson" wrote in message news:djrarf$ snipped-for-privacy@cliff.xsj.xilinx.com...

Reply to
Benjamin Todd

Benjamin, I have made/written tools to program some of the Coolrunner CPLDs, I have them running on either a CPU32 (683xx) or PPC based system. Please feel free to contact me directly if you think I might be of some help.

Regards, Dimiter

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

formatting link

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

Reply to
dp

Reply to
Neil Glenn Jacobson

Having written the tools from scratch starting with the logic compiler and ending with the JTAG access hardware & software, thus my design chain being 100% self supplied - I would have thought I knew that. I wonder based on what experience you thought I did not know. I offered the guy my help simply because I do have knowledge way above average on the subject and I might be of some help at some stage - he would probably know if and when.

Dimiter

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

formatting link

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

Reply to
dp

"Benjamin Todd" schrieb im Newsbeitrag news:djkmeg$mdo$ snipped-for-privacy@sunnews.cern.ch...

small uclinux modules sell for less than 100EUR. it takes a few hours to get XSVFplayer to work there. I use it in desing to program the XC9572XL, the mdoule we used was from

formatting link
coldfire based, but the production has not changed to use small fpga linux modules (microblaze uclinux)
formatting link

antti

Reply to
Antti Lukats

Reply to
Neil Glenn Jacobson

Reply to
Benjamin Todd

Thanks for the nice message. No offence taken, I guess I overreacted a bit. Certainly no need to apologize.

Reply to
dp

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.