There's a partial list of fabs at Wikipedia. There are more than just those three.

Sure, process optimization per fab is an issue. We would probably need to start on the very conservative side.

A lot of the time, building a custom ASIC rather than using an FPGA just isn't an option. Most of the products I'm concerned with need to be programmable.

David Rowe makes a point about echo cancellers and voice codecs, which he's written in Open Source, working alone. They were supposed to be magic. They were supposed to take big expensive research labs to make. When he actually got down to the work, he found there wasn't really magic there. Codec2 can get clear speech into 1200 Baud, and OSLEC (the echo canceler) is part of every Asterisk system and other digital telephony platforms.

Steve Jobs also told me this when I was leaving Pixar. He didn't believe that the Linux guys could make a decent window system, because it had taken a Billion dollar research lab at Apple. Two years later he unveiled Safari, which was derivative of KDE.

There is no question that we can make a good gate array. The technology is very well known. Can we make one that is on the absolute leading edge of the technology? We don't really have to. Making a good one that was open would be enough. But maybe we can make a great one. That depends upon what makes it great. We have a collaborative advantage as far as the software tools are concerned, the same as with compilers. Can we design a really good logic element and fabric? Probably. Can we prototype a gate-array in a gate-array? Sure! Can we use the various devices that OpenCores has developed? I don't think there would be a problem. So we could have on-chip peripherals, CPUs, etc. Once we're sure of it, can it be well-tuned to a fab? Probably, but even if we are conservative about using the fab's capabilities it would work.

Yes. And looking at the way things have gone previously in JEDEC, we would have to be very aware of manufacturers desire to embed their patents in standards.

An Open gate-array is one of those "if you build it, they will come" sort of things. Chinese fabs would compete with each other to drive the price down. It would become the standard low-end part and gate-array manufacturers would have to compete on high-end only.

So I am really interested in doing it, and so is Chris. We just can't ignore our current business in order to do it.

Yes, we feel your pain. Indeed, it's our pain. Proprietary tools, and you get told how to load the bitstream but it's an opaque blob. We would like to work on this problem next. How far off that is I can't say, if we can establish a profitable land-mobile radio business (we don't expect to make much off of hams alone) it would help to fund such an effort.

Chris and I would like to do an Open gate array as our next project. Sufficient patents have expired, etc.

If you ever write a means of describing digital logic designs in Lua we can compare it. Just describing data structures is not sufficient, you need to describe parallel boolean algebraic operations and macrocells such as multiply. At the moment no such thing exists and it would take a long time to duplicate the work of the MyHDL project.

Not sure you understand. The OO model is useful for representing a 4-input device with a logical output determined by a look-up table, which is the fundamental logical element. At least it's useful to do it elegantly. Lua is a small embedded language, but the purpose of MyHDL in this case is not to execute Python at runtime but to generate VHDL or Verilog describing an inherently parallel implementation of an algorithm.

Chris can explain this much better than I, but we are definitely conscious of the gate-array resource use. Currently we are running within the space of the least expensive SmartFusion II chip, which I think you can get for $18 in quantity. Smartfusion 1 was more of a problem as it didn't have any multiplier macrocells and we had to make those out of gates. SmartFusion II provides 11 multipliers in the lowest end chip, and thus the fixed-point multiply performance of a modern desktop chip for a lot less power.

We are also aware of algorithmic costs. For example we were using Weaver's third method and will probably go to something else, maybe a version of Hartley.

HackRF is designed to be test equipment rather than a legal radio transceiver. It doesn't meet the FCC specifications for spectral purity, especially when amplified. You could probably make filters to help it produce a legal output.

Whitebox is meant to meet FCC specifications for spurious signals that are required when amplification of 25 watts or higher is used. Amplifiers also contribute spurious signals and will usually incorporate their own filters.

HackRF is something that sticks on your laptop via USB. Whitebox is meant to be a stand-alone system or one that is controlled from your Smartphone via a WiFi or Bluetooth link.

Whitebox is optimized for battery power. Using a FLASH-based gate-array rather than the conventional SRAM one makes a big difference.

HackRF is designed to be test equipment rather than a legal radio transceiver. It doesn't meet the FCC specifications for spectral purity, especially when amplified. You could probably make filters to help it produce a legal output.

Whitebox is meant to meet FCC specifications for spurious signals that are required when amplification of 25 watts or higher is used. Amplifiers also contribute spurious signals and will usually incorporate their own filters.

HackRF is something that sticks on your laptop via USB. Whitebox is meant to be a stand-alone system or one that is controlled from your Smartphone via a WiFi or Bluetooth link.

Whitebox is optimized for battery power. Using a FLASH-based gate-array rather than the conventional SRAM one makes a big difference.

It's a sensitive clod, you marathoner.

No, wait, that's not right.

In soviet marathon, natalie porter grits you!.

No, that's not it.

hmm.

hawk

If I put an apple in the oven at 340F, I"m not wasting the effort on a computer.

(pass the cinnamon! )

hawk