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!
Licensing their intellectual property is key to ARM's work, so they're far more likely to get all pit-bull over clones than a company that relies more on actual production of the hardware.
too bad i would have enjoyed making a modified chip myself, i mean how hard can it be ?? you would only need a fab plant, and those are aval. at the cornor drugstore! I mean really guys it's just like altering game software. : )
if you want "No More Hiroshimas" then I say "You First. No More Pearl Harbors."
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
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.
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 /. :)
It shouldn't matter how their competitors were able to copy their RISC processors, the important fact here is that the device has been granted a US patent. I'm sure people are going to say that reverse engineering makes it perfectly legal, but that is simply not the case. 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. Reverse engineering is nothing more than a legitimate way for engineers to steal the intellectual property of competitors and gain an unfair business advantage. 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.
Let's look at it this way, there are hundereds of very simple devices that have received US patents. Ever seen that microwavave bacon cooker advertised on Infomercials? 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!
-atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.
go here for a mirror of the core design
Cretin - a powerful and flexible CD reencoder
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.
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.
...to produce one of these ARM cores? I'm sure students don't have access to full size wafer fabs so I am curious.
Slightly more on topic, it almost sounds like ARM wants to hire Shen by how they said "he's a very bright chap, so we want to talk to him."
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 ?
They have sued Pico Turbo, and may have
t _u pdate.html
4 87 4FE3A80256A7200373224?OpenDocument&
threatened others at least one of which seems to
have caved (Faraday). However, Pico Turbo has
different view of the ruling issued by the judge
than ARM does...
http://www.picoturbo.com/News/Court_Update/cour
http://www.arm.com/news.ns4/iwpList125/F08341B4
Also note that MIPS also tries to take a simmilar
stance with instruction set compatible cores.
Not that these are impossible to write. Have a
look at http://www.gaisler.com for a SPARCv8
clone, which is very high quality and complete
Unlike the nnARM, it's actually complete and
flexable... Proof of what one/a few talented
people can do, which should scare the crap out
of ARM and MIPS
FWIW, you can't patent an instruction set IMHO.
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
http://www.fpgacpu.org/#011102
http://www.fpgacpu.org/log/jan01.html#010129
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.
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.
A lab for a VLSI course uses it
r tl /
http://www.ece.utexas.edu/~slee3/vlsi/lab3/arm/
EETimes story
More stories available from the first link.
I think it's scary.
uh.....gee, he wouldn't be making a clever play on words involving the phonetic similarities between "Unix" and "eunuch", would he? hmm.
go look up "eunuch" in a dictionary.
in the future, remember to take your medication.
IANAPL, but, IIRC, I heard that the method used to derive the ARM instruction set has been patented and this then effectively protects their IP.
I can't verify this because I'm far too lazy to go searching through the USPTO server to look for the patent.
Simon
I believe that their patents include the use of banked registers in a particular way. I have been wondering if it's possible to create an ARM code compliant processor, but don't do all the patentable features of the ARM itself...
$250k is about right for a 0.25u fab run (and it generally has way more than 4+2 layers).