I can certainly see the argument that reverse engineering is appropriate when it comes to checking for IP infringement.
But if someone kills themselves designing anything and someone else comes along and reverse engineers it and then creates and sells copies of it -- I cannot see how that is in any way not considered to be stealing.
On the other hand ... as an end user in the 1980s ... I do remember liking the fact that a lot of the components I used were "second-sourced" -- I just don't recall thinking about what that actually meant.
"Stealing" someone else's design as you describe it is not RE, it is chip piracy. Chip piracy was always unethical and it is illegal since 1984. Second sourcing in pre-1984 style was practiced by the semiconductor companies but its questionable ethics unfairly tainted the entire business of RE. That is the image I wanted to clear.
RE is fundamentally about learning. I never forget the amount of knowledge I gained by dissecting and Bob Widlars' LM10, in the early 80s. The knowledge I gained about his new design concepts such as the use of merged PNP/NPN structures, the use of controlled amounts of positive feedback in a real-to-GND output stage and so on, was worth a few semesters of university lectures. It took me about three weeks to do all that learning. From there I went on to create my own patented opamp architecture that was much smaller in die area. That allowed me to place ten opamps on a single chip in 1982. Granted, no big deal now, but it was much harder to do that in those years. This is what RE is all about.
Now, I can happily agree with the use of RE as a learning tool -- if I take myself away from the semiconductor industry and consider a mechanical contraption, for example, I can well see myself wanting to take it to bits to see how it works.
Reincarnation? Mental masturßbastion perhaps? I suppose there may be a turd option.
There again perhaps a 4th, speaking as a Buddhist, messed it up in this life so reincarnation is high on the Natures hand of cards, preferance Snow Tiger, Snow Leopard or Peregrine, Ladakh would be lovely.
I have no experience in that regard, but I find natural RE to be an area of real potential. These kinds of techniques can reap a true reward, and do not run the risk--unlike other forms of RE--of being deemed illegal or unethical, at least I hope not.
Reverse engineering is a fun, whatever be the legality or illegality behind it.
Way back in 1988, as a free lance assignment, i really enjoyed the reverse engineering of the MS-DOS "debug "program . I used the "debug" program itself to understand its working, its data structures and successfully ported it onto a locally made 8086 development kit.
In my opinion, reverse engineering is a very good learning tool for engineers!
Reverse engineering must also be used when you are making modifications, improvements, additions to an existing hardware or software product with poor or no documentation (or designers) available. One time I needed to know something, and one designer was on pregnancy leave and the other one was on a honeymoon in Tahiti! At least I knew who the designers were, but I still had to reverse engineer the system to get the answer I needed.
In some sense, reverse engineering is about keeping the system model in sync with the implementation. Or creating a system model if you can't find one.
Absolutely! Reverse engineering is often an essential skill when you are tasked with modifying your own company's existing product or re-using IP. Designers come & go, and documentation often lacks important details that another designer needs to know in order to successfully modify a product or IP block.
Black box reuse (don't change anything) is a luxury you don't always have on a new product. As soon as you hear the words "reuse with a few changes," it's time to bring out those reverse engineering skills!
@HankWalker: Reverse engineering must also be used when you are making modifications, improvements, additions to an existing hardware or software product with poor or no documentation (or designers) available.
Good point. Early in my carear I spent a lot of time writing functuional test programs for PCBs. I was given a PCB that was claimed to be "known-good" (but after wasn't) and a schematuc that was said to be at the same revision level as the board (but often wasn't) and ... that was it.
It was up to me to try to determine what the board was supposed to do and how it did it, and then write a test program that fully exercised the board. Of course this wa sback in the very early 1980s when boards were much simpler than they are today, but it still gave me a lot of mental exercise.
As a by-product, this was quite possibly the best training I ever received LOL
Sounds like "sometimes" RE occurs beneficially far more often than many may beieve. Not a bad thing.
Aside from doing it with your own products when there's missing info, technologists must invest in staying highly aware of what competitors are doing...obeying Sun Tsu's rule: "Know your enemy." DIY RE now is likely far beyond many internal engieering teams' abilities or time capacity. So a few highly focused businesses offer very specialized expertise and services.
I remember when I had to make an RTOS (which we had licensed) interoperate with our code. The RTOS documentation for the particular instruction architecture was incomplete. You were supposed to use a "board support package", but if your board wasn't on the list -- e.g., if it was your product rather than a standard development board -- the documentation was simply not there. (This particular RTOS at one time had excellent, complete documentation for a different architecture, but they had been acquired by a Large Company who obviously felt that complete documentation was unprofitable.)
So I had to disassemble the task switch machine language so that I could see how it was using and saving registers. Once that was clear, the rest was pretty easy.
My very first task working in Product Engineering at Analog Devices (1980 and fresh out of college) was to compare an ADC module (yes module at that time) with one from the arch competitor, Analogic. I had samples of both and copies of the ADI schematic so I traced them both. They were identical so I asked the department manager "Who copied who?"
His response: "We copied Bernie."
We never mentioned Analogic by company name, just "Bernie."
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...