ASIC vs FPGA and In-Circuit Reconfigurability (ICR)?

In reviewing a specific requirement, my design team is debating the benefits of in-field hardware upgradability. In the communications space, wondering if most system developers require and use ICR in production when implementing FPGA (instead of ASIC)?

Craig

Reply to
CraigR
Loading thread data ...

benefits

wondering

Reply to
Rotund Phase

Nope. I did see that posting though. I am weighing cost benefits of ASIC for field upgradability.

Reply to
CraigR

Craig,

In my 26 years in telecom systems manufacturing, I was not a happy camper until I could design, sell, and supply FPGA based products.

Almost every RFQ to FRP to product cycle had at least one class A recall (everything had to be field or factory retrofitted). The pain of this was so high, that I had a rule, called "Austin's rule of tens."

Sell ten, recall, fix the bug.

Sell a hundred, find and fix the next bug.

Sell a thousand, find and fix the next bug.

And so on, and so forth.

One time I made it to 100,000 sold of one system, and sure enough, we had a bug that required a huge changeout of eproms (thank god it was the microprocessor code, and could be fixed by this method).

The interesting thing about the phone business, is that eventually someone will do something you never thought of, and break it. And suddenly everyone will say "how could you have missed that?"

With FPGAs, we could now reconfigure over the network, so if there was a bug, we could download a new FPGA image, and we were back up and running with minimum (or no) down time.

Of course, many operating companies decided not to connect their systems to any network at all, so they still cost a lot of money to retrofit, as someone had to go to each system, and plug in their personal computer, and reload an image.

Good news is that they did not have to take it apart (as we had to in the 'old days').

The one time we used an ASIC (as the requirement was slam dunk, no issues) we ended up throwing all the ASICs away because the (bell) operating company notified us that the requirements doc had a patented technique that they did not know of at the time. So rather than get a license for it ($$$), they removed it from the requirements document. Guess who paid for it? Right, not the op company. Read the contract.

Back to FPGAs.

As for writing reconfigurability into a product requirement, after awhile, it became pretty obvious that money could be saved, downtime could be avoided, by having such a feature. You just had to network everything in your network (not an easy task at all).

Aust> In reviewing a specific requirement, my design team is debating the benefits

Reply to
Austin Lesea

Reply to
Rotund Phase

If you're implementing different protocols on the same electrical lines I would thing FPGAs would be very attractive.

However, I'm struggling with how to support new I/O requirements (i.e. technology didn't exist at time of initial development) without opening up our boxes to modify the line drivers/receivers.

My domain is not 'strictly' communications, but we frequently have new requirements to add another RS422 channel or Ethernet or wiZbang I/O of-the-day. So how do you get drivers that have programable voltage swings, rise times, polarity, etc. so that you don't have to send the box back to the factory to make changes.

Short of putting in DACs/ADCs on each signal line with waveform memory, it's tough to figure out a good solution for the ultimate in I/O flexibility. Perhaps rather than waveform memory, using opamps and just having a DAC that sets the voltage for the rails and receive threshold might work???

I've also been thinking about a special type of tiny connector 'insert' that plugs in (almost like a multi-terminal fuse) which provides translation from LSVD to real-world signal levels. This might work would be tough for signals that have to be transformer coupled.

How is this problem solved?

-bh

benefits

wondering

Reply to
bh

I learned that rule over 15 years ago. I was babysitting for a large (for the time) email system that had just been hit with that sort of bug. (Fortunately, the guys who did the initial work were good friends of mine.)

The rule was something like: "Every time the installed base goes up by a factor of 10 another fatal bug will crawl out of the woodwork."

I think it's been true for any system I've worked on. For most sytems, you can get 10 in your lab and 100 with friendly customers. Then it gets interesting... (Scale by 10 one way or the other if that fits your system better.)

Interesting point. I remember a time when an FPGA saved my bacon. Yup. Spec change. Just one bit. Trival to fix.

So if you are considering FPGA vs ASIC, add the stability of your requirements to the decision process. Don't forget to consider bugs in the spec. Committees are great at writing complicated documents that don't work in obscure corner cases. Or don't specify what happens and 3 people make incompatible assumptions.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray

Hal,

Amazing. This 'rule of tens' must be a universal systems rule.

Probably a corollary to Murphy's Law.

Aust>

Reply to
Austin Lesea

He is a friend who uses the same ISP when he is in town.

Reply to
CraigR

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.