On Sun, 21 Mar 2004, J.C. Wren wrote: What parts do not have published programming algorithms? I you are buying your own parts, just avoid chips or manufacturers that don't provide this information. To make a universal programmer, yes, getting the programming algorithms for A wide range of chips and manufacturers is a problem, but the original question was about 32 pin EPROM/FLASH. These all have published programming algorithms since they are expected to be programmed in-circuit, so a programmer for this type of chip is easily done. Older GALs (Lattice at least) have a published programming algorithm. Most newer CPLDs that I am aware of have a published programming algorithm (for the same reason as above, they support in-circuit programming) Many microcontrollers have published programming specs... Peter Wallace

Tony> I have yet to find a reasomably complex PLD (that is something Tony> more than one of the ispGALs) that is 100% documented. That is Tony> to say that you can go from logic equations to chip without any Tony> proprietary software, either the logic compiler or the Tony> programming software. That's a good point though I think the big issue there is the early steps. The programming itself is often easy since it doesn't use odd voltages or timings, just a plain bitstream clocked in via a serial port. One of the FPGA vendors created a particularly clean setup called "Jaz" (forgot who -- Altera?), I wrote software to drive that which was quite painless. But the real issue is that NO ONE will tell you the internals of their FPGA, so you can't figure out the bit patterns that you need to perform a given logic function. Too bad really, because the logic synthesis software available from the chip vendors often sucks pretty badly. I have a bunch of battle scars coping with really stupid bugs in Lattice tools, which will not be fixed since they are apparently considered normal behavior. I think if you have infinite pull the situation is sometimes better -- I've seen some evidence that DEC was able to get Xilinx to tell it how to synthesize for those chips. And they did it much better... but those were research tools in the Palo Alto group only. paul

Ulf> Oh, they do tell you, but for a substantial fee, and an NDA to Ulf> go with that, just to make shure they can sue your pants off Ulf> when you happen to spill the secret... :) Ulf> There is rumor of a Verilog simulator/synthesiser that speaks Ulf> Xilinx. I have not yet tried it but here is the link: Ulf> http://www.icarus.com/eda/verilog/ Ulf> It is for free and as such it might suck, but at least it do Ulf> that for a moderate fee. Cool. But I was talking about the place & route and programming bit pattern generators. Those are still deep secrets. Place and route is the one that I find myself fighting with. Things like: (a) run a synthesis, with pins unlocked. (b) just to check things, run the exact same design with the pins locked to what (a) chose. Result: synthesis fails, not enough room. #&@$*(#@* so how is a person supposed to create a design that can be tweaked and still work on the same PCB layout? Answer: this is normal. Gronk. I guess it's a trick to make you buy bigger FPGAs... paul

On Sun, 21 Mar 2004, Tony Duell wrote: Programming is what I was talking about, the tools for generating config files for complex FPGAs and CPLDs is another subject altogether, though it would probably not be too difficult to do a few basic configurations and reverse engineer the internal architecture from the JEDEC or SVF file for a 9500 series CPLD for example... Peter Wallace

This still has many of the same problems as completely proprietary programming interfaces. Notably, it ties the user to x86 hardware (since you _know_ nobody's going to bother providing the proprietary part for anything else) and it requires placing a great deal of trust in the company, since it involves handing control over to foreign binaries. Also, you need a well-defined API not only for the layer interface _above_ the proprietary code but also the layer interface _below_ the proprietary code, or else you've not helped the OS situation any because you're stuck with whatever OS they've chosen to write their proprietary code atop. (And, as above, you _know_ that's going to be Windows.) I don't think even that would help much - see above. The only fixes I can see are (1) to scrap the whole proprietary software bit or (2) to use a p-code engine to run the proprietary portion of the software. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse(a)rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B