Slashdot Mirror
OpenCores.org ARM Clone Removed From Web
An Anonymous Coward writes: ""A clone of the ARM7 32-bit RISC processor core, previously available free for download from the Internet, has been taken down or hidden" pending discussions between the core's designer and a Chinese representative of ARM Holdings plc (Cambridge, England)."
Remember, this is a reverse-engineered "clone in the form of a synthesizable Verilog language description."
Does anyone happen to have a copy of the info in question? If so, spread it!
Here is the story of how a Chinese grad student developed the ARM7. this looks like yet another case of the Chinese government meatheads forcibly repressing free speech and damaging the natural development of Chinese culture.
remind me why the US still deals with the People's Republic?
If protocols and interfaces are IP, then free software is in trouble.
This sets a particularly tricky prescident for anyone writing emulators for any sort of processor.
I guess the big question that looms over my mind is "Why are they fighting this so hard?"
Besides, didn't AMD, Cyrix and such win becuase their clones of the x86 processors were legal?
Maybe I've missed the boat, here.
The (Hopefully) Great Slashdot Blackout
Oddly enough, I have a fab right across the hall from my office. Sure came in handy when I unlocked the bridges on my tbird. (good chemicals and tools, no I didnt open it up or anything stupid)
Actually, all you need is an Eval board from Xilinx, Altera, or any other FPGA vendor with a chip that's big enough to put it on. I have a few older ones lying around my office, but they probably aren't big enough.
These FPGA's can be a good platform for knowledgeable hobbyists, specifically because they can be re-programmed if you're working on something else. Of course, all the new ones are fine-pitch ball grids, which have so many small pins that you're not going to solder it onto your hobbyist's breadboard anytime soon.
Now if only they did their core in VHDL, I might be interested!
Having a synthesizable core does NOT mean that you can just drop it into any modern design. The deliverables for a commercially usable core are significant. Typically you need the following:
* Verilog code.
* TWO sets of timing constraints in Synopsys SDC format - one for synthesis, the other for static timing analysis and back-end physical design (i.e. defined clocks, high fanout nets like resets/selects, false/multicycle paths, case analysis statements for setting fastest propagation mode through the design).
* Synthesis scripts, which have specific mappings to the standard-cell libraries of the particular process (except if implemented in an FPGA).
* SRAM macro definitions and how they plug into the Verilog code (again, highly library/process specific and not relevant for an FPGA, assuming you can find enough on-board FPGA SRAM to equal the caches necessary for the ARM7)
* All JTAG-related files, including BSDL and tap controller specs.
* Scan and functional test vectors for Verilog VCS or NC-Verilog to show the core works.
I'm sure I've missed a couple of things, but you get all of that, PLUS implementation support from ARM engineers. Mere Verilog code is not going to threaten ARM, and the expense that a company would go to in supporting its own core implementation wouldn't justify the cost in development time. Especially when there are other competitors ready to do it faster and quicker.
So, IMO, I say SCREW ARM. Arrogant bastards who don't want people to learn about their own cores. Heck, big EDA companies give away their software to universities for education but that can't be used for commercial purposes (which was a big advantage in me getting a job in teh industry). Why can't ARM get their act together and do the same? It will only help to have engineers out of school who know their stuff.
Opencores.org is /.ed...
google cache here
Wow, I'm such a karma whore.
Seriously guys, cool site. FPGAs are dynamically reconfigurable logic circuitry that can emulate almost any other hardware, AT THE HARDWARE LEVEL. Tell it with software how to connect the transistors up, and that's what it does. OpenCores.org focuses on creating CPUs for FPGAs (verilogic being one of the two big manufacturers of FPGAs) that will run standard instruction sets, such as ARM or Intel (mostly focusing on embedded applications, because an FPGA emulating a core is SLOW... they can get up to about 50 MHz clock speed, but not much more)
Alright, now I don't feel like such a ho'...
I am disrespectful to dirt! Can you see that I am serious?!
long live the global network
What.. no bad "Attack of the Clones" jokes yet? I'm surprised /. :)
I must say that ARM are a pretty cool company not the usual nasty corporate bully that Slashdot likes to portray, it's nice to think a bit of the Acorn lives on in nearly every mobile phone and PDA's etc.
However... remember ARM are purely an IP company they don't manufacture stuff like Intel so IP is their sole source of income, if you remove that, they die, I don't blame them for defending it, whether is was 'reverse-engineered' or produced from original designs is beside the point... it implements the ARM instruction set and therefore infringes upon ARM's patents.
Of course people here will probably bleat on about how any company could have the audacity to creative new products and patent stuff, but they make good products and spent a lot of cash producing those designs, revenue is needed in order to produce better products, like X-Scale for example, Intel have a ARM architecture license due to numerous entangled lawsuits and cross licensing.
I don't think ARM has much to worry about anyway, if a fab actually started producing cores on this design then ARM en masse then they could sue the hell out of them or the companies that use them in final products, ARM designs permeate many chips and designs out here so gaining access to a legitimate design is not a monumental task, but fabbing millions of chips illegitimately is not easy to get away with since people would definitely notice.
> Reverse engineering protects OpenCores.org from
> being accused of corporate espionage, by proving
> that they legally obtained the information
> necessary to copy the core, but their posting of
> patented information to their website is what is
> being argued against.
There are NO rules against posting patented information. In fact, patenting REQUIRES full disclosure. Patents are NOT copyrights!
> Reverse engineering is nothing more than a
> legitimate way for engineers to steal the
> intellectual property of competitors and gain an
> unfair business advantage.
Using "legitimate" and "steal" in the same sentence just goes to prove that you have not understood the point of reverse engineerin, or
of patents for that matter.
You don't need to prevent reverse engineering if you are protected by a patent. A patent prohibits competitors from creating the same product, even if they reverse engineer it (which should not be necessary anyway, since the information is in the patent application anyway).
> ARM has invested millions of dollars and
> countless hours into developing their processor
> core, and they are completely justified in
> defending what is rightfully theirs against so-
> called "reverse engineering" patent theft.
Patents are not made to reward investment, but to reward products. It doesn't matter if you spent a billion on finding the result or it came to you in a dream.
> I'm pretty sure that without too much effort, I
> could figure out how that was made without
> looking at any of it's inventors design specs.
> Do I legally have a right to sell my own
> "reverse engineered" version of someone elses
> invention? I should think not!
And you would be right. That would be infringing on their patent. Now, if you found a radically different way to fry bacon in a microwave (more elaborate than putting it on paper tissue while cooking, which has lots of prior art), then you would not infrige on the patent, and would maybe even be eligable for your own patent.
/RS
The idea that a verilog description can infringe a patent is very problematic. Patents are supposed to teach an invention, but collect roalties on (or block) implementations. A verilog description is nothing more than a very detailed teaching of how to practice the art described in the patent. If the patent is valid (and you don't have any other objections to patent law in general) then there is no legal problem blocking someone from making a chip based on the verilog. But a patent holder has absolutely no right to block someone from teaching, in great detail, how to practice the art described in the patent (which after all was what the inventor was supposed to do when the patent was filed in the first place). Unless there is some trade secret misappropriation going on here, or unless ARM is claiming a copyright on their architecture that blocks any implementation of it, ARM appears to have no legal basis for what they are doing. As for the copyright theory, good luck getting that to stand in the US (see Lotus v. Borland).
Be careful how you interpret this stuff; the headlines are much more inflammatory than the situation warrants.
If you go through to the original EE Times article, you'll discover that the nnARM implementation was radically incomplete: no interrupt handling, no virtual memory, no coprocessor instructions, no THUMB support. For what the guy in question was doing, that's fine; he can be perfectly comfortable building a GPS receiver w/o any of that -- but no large-scale embedded system builder would be interested in this chip. (A cell phone manufacturer would need to qualify any such chip set...no way. Linux and WinCE won't run on it. QNX won't run on it. Although I suppose ucLinux might run on it, that would require a full port to a new instruction set width, and that would cost much more than anyone would save by doing it.)
That puts quite a different light on this than the articles in the Reg implied. A chip like this poses no threat to ARM's licensing revenues. What it does do is confuse people about what an ARM core can do. In my opinion, ARM has a legitimate beef about that.
Granted I work for Computer Engineering, not Micro-e so my brain is prob quite fuzzy on this. Of course the fab being right across the hall from my office is pretty damn cool.
what is the point of cloning the ARM anyway, it is relatively cheap, and hardly at the cutting edge of processor performance ?
I mean, I despise the undemocratic murderous quasi-talibanic Chinese regime as much as the next American, but really there are other issues that we could criticise China for apart from trivial copyright infractions.
I think this shows the hidden capitalist bias of slashdot. People's rights are infringed on a daily basis in China, they are committing genocide in Tibet, and what does slashdot whine about ? Intellectual Property.
I realise Americans are insular and capitalistic, but have the events of Sept 11th gone completely over your heads ? Or are you in denial ?
Actually, you can get short-run IC fabrication for a reasonable price. Check out the MOSIS website, they will do fabrication runs of 25 chips or so. For a price example, we did a 3mm by 3mm chip in 0.5 micron Agilent (HP-14B), that cost about $8000 for 25 chips, all packaged. If you are a university student, you may be able to get fabrication donated, so you might want to check that out. I've had one chip made through this program. (It's a PIC16C6x compatible microcontroller, for those interested.) And if you want a layout tool, there is a freely available program called MAGIC that can handle this task (sorry too lazy to find link).
Lat I checked, Verilog wasn't even a company. I bet you're thinking of Xilinx or Altera. Note that Xilinx gets badass points for providing free development tools that aren't half bad, even if they are for Windoze.
As far as speed is concerned, there are two big factors that determine how fast you can run a hardware implementation of a design. First, there's the maximum clock speed of the FPGA. This is a parameter of the FPGA used, and, like CPUs, varies with the manufacturer and model. While it is possible to circumvent this with totally asynchronous designs, as you're not required to use the chip-wide clock, it's only practical in only a few unique applications (ARM AMULET). Second, the size of the design will affect the speed at which it will run. A simulation of an Athlon or a Pentium III (excluding large memories, like caches and ROMs) will be forced to run slowly because the propagation delay between far away cells in the FPGAs and, in extreme cases, between individual FPGAs themselves, will be too great to support high clock speeds. Plus, the gate propagation will be slower in an FPGA than on raw silicon. This factor is also somewhat dependent on the HDL CAD tool used and how smart its automatic floor planner is. Now put something simple like an ARM in an FPGA, and you can probably hit much higher speeds.
There may not be much difference in the minds of manufacturers between programming a chip to act like another chip (but slower) and using a poor quality Star Trek replicator to make a copy of it. You suddenly are capable of doing things with your hardware for free that you used to have to give them money (by buying *their* hardware) to be able to do.
I can see in the near future that this may become a big issue for chip manufacturers - between FPGAs which do emulation in hardware and companies like Transmeta that do the emulation in software, the risk gets larger as the technology gets better. How long will it be before the operators of file-sharing servers get sued by the CFAA (Chip Fabricators Association of America (fictitious organization, as if it weren't obvious)) because they are letting people swap source code for programmable microprocessors that works better than the original hardware?
How different is that from suing OpenCores.org for providing instructions for making a clone?
Are the instructions protected as free speech? Will source code implementations be similarly protected?
I know which way the RIAA, MPAA, Microsoft, etc. would like to see it go, but I also know that I don't want to live in a world where the inventor of the replicator will be sued for being an accessory to patent infringement.
I think it's time to write another letter to my congressmen...
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
Dude, it depends on who publishes the results of the ruling: See http://www.picoturbo.com/News/Court_Update/court_u pdate.html for the PicoTurbo view of things. I know that this was interpreted by the industry locally to be a Picoturbo win considering the fact that I've heard of a couple of folks looking seriously at Picoturbo now. Last I heard - you can't patent an ISA - you CAN patent particular methods used to implement that ISA.
As for not liking Reverse Engineering - get over it!
Have you compiled your kernel today??
But that argument, I would think, is moot here since you can NOT patent an interface. If you could, then Sun would have patented all of their Java interfaces. Hell, it's not even clear how far copyright applies to something.
So a reverse-engineered "work-alike" product is by no means necessarily infringing on a patent. It MAY be infringing on the patent, if it uses the patented mechanism (if it does not, it clearly does not violate the patent, even if it achieves the same results, i.e. can simulate/run ARM instructions). Furthermore, as mentioned above, it has to be established that the source code (which any HDL code basically is) is an implementation rather than a description. I don't know how this line is meaningfully drawn, but it's clear that it is pretty hard to convince a court in the US that something distributed for free in source form violates a patent (or else organizations like Fraunhofer would have tried to squelch the many free MP3 codec implementations out there).
If you want the exact wording from US Patent Law, see the USPTO summary document. An infringer is someone who "makes, uses, offers to sell, or sells any patented invention". Are you "making" an invention by writing an accurate description of it in an HDL? What about an accurate description in pseudocode? Are you making it when you encode it into an FPGA and deploy or sell a full product using it? Or are you just learning about it and testing a design for compatibility with it? The law just doesn't deal well with software/firmware/things on the boundary between digital information and physical stuff.
sure, it's nice that there's a software ARM emulator knocking around the internet, but it's in no way a substitute for a free processor core design, with which you may fabricate hardware ARM clones.
Correct.
But an emulator is very useful for hardware projects nontheless. It runs a lot faster than the verilog code in verification and can be used for a number of purposes.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Dude, if someone is going to make silicon they're ready to make the scripts and synthesis constraints, that's not the problem. Jtag in particular is easy, I have written a full JTAG TAP myself in VHDL and even a BSDL compiler (in C++).
With the price of mask sets (the company I am working for is creating a new SOC design in 0.25u: mask cost $250K) the problem is getting credible validation that the CPU is a complete clone and is fully debugged.
Knowing that the masks cost $250K, and that litigation may tie up their product or cost them bigtime, a $400K license and the royalty from ARM for most companies is just another NRE (Nonrecurring Engineering Charge) that they're happy to pay.
What's sad is that ARM presumably bullied the poor student chap when in truth they were on at least questionable legal ground assuming it was a ''cleanroom implementation'', which it very much sounds like from the EE Times article.
That's a gross mischaracterization. First, ARM has had a legal victory, but which claim that was actually based on was never decided. Concluding from that that ARM has "successfully defended" any particular aspect, or the entirety, of their architecture is just wrong.
Second, there is no indication that any form of "IP theft" has occurred. Creating a core from scratch that works like the ARM chip is entirely legal in and of itself.
As for you "microwave bacon cooker" example, you can legally make something that doesn't infringe the patent, no more and no less. Since the basic technology for microwave bacon cooking has been known for a while, their patent may not protect anything particularly important, and you may well be able to copy most of their engineering effort.
It's spelled "tolerance"
fscking mensa retards...
Under capitalism man exploits man. Under communism it's the other way around.
Having a synthesizable core does NOT mean that you can just drop it into any modern design. The deliverables for a commercially usable core are significant. Typically you need the following:
;-)
* Verilog code.
I'd rather have VHDL, but i can always synthesize a gate level VHDL description at a cost to simulation speed.
* TWO sets of timing constraints in Synopsys SDC format - one for synthesis, the other for static timing analysis and back-end physical design (i.e. defined clocks, high fanout nets like resets/selects, false/multicycle paths, case analysis statements for setting fastest propagation mode through the design).
While false path and multicycle path information must be provided if such exist, other timing constraints will be determined by the surrounding design, and must be selected by the system designer anyway.
Given the RTL description, constraints are a small matter.
* Synthesis scripts, which have specific mappings to the standard-cell libraries of the particular process (except if implemented in an FPGA).
Erm... if you can't even do that, what on earth are you doing with that expensive synopsys licence. gimme...
Seriously, you can't excpet the supplier of a MCU core to set up your synthesis tool for you.
* SRAM macro definitions and how they plug into the Verilog code (again, highly library/process specific and not relevant for an FPGA, assuming you can find enough on-board FPGA SRAM to equal the caches necessary for the ARM7)
Memory are usually provided by separate suppliers anyway. Given adequate information on the core's memory interface a small piece of glue logic would be quick to assemble. (Some do cores come with a MMU, which makes the job somewhat easier though)
* All JTAG-related files, including BSDL and tap controller specs.
Not really neccecary, and not really associated with MCU core.
* Scan and functional test vectors for Verilog VCS or NC-Verilog to show the core works.
Some of the point of an ip module is that you should have a reasonable excpectation that it is already verified. Functional testing of the core should therefore not be neccecary (though in this case I would propably do some verification myself)
Production testvectors are generated during synthesis, and are dependent of the synthesis environment and libraries, and thus not associated with the MCU core.
I'm not sure if this is a reply to my post about the ISA - but if it is, you seem to contradict yourself.
At the same time - in patents it seems from my limited experience (only hold two patents) the distance between a description of something and the implementation of something is ALL important.
One of my patents is a different implemenation of a specific feature on a competitors' product. There is a description of what the external interface looks like - I replicated interface with my own internal workings. Quite different enough to receive a patent.
My point is demonstrated by the existance of Amdahl which in days gone by used to build an ISA compatible version of IBM's architecture. The point was settled back in the 70's or earlier. You can't patent an ISA. Another example, there are LOTS of implementations of the 8051 by non-Intel licensee's. Oddly - you don't see Intel running after these people because they've already been down this road.
You can't patent mov Ax,Bx - but perhaps you could patent a series of registers organized into a a register file with an instruction register which has an attached collection of timing and control logic that implements mov Ax,Bx in a particular manner. That is the difference in a nutshell.
Have you compiled your kernel today??