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!
who's got it? I have to add it to my booty chest of banned warez
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.
I don't care what anybody says!!! it does get the whites whiter!
Snoozer.
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).
Mr Shen may have just landed himself an elite job, not bad going.
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.
http://www.sun.com/microelectronics/communitysourc e/sparcv8/download.html
Roll your own microsparc system.
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.
All their design has in common with ARM cores is the ISA ... how can the ISA not be an ISA?
... but simply using the ISA infringes on nothing by itself.
Wether something is an open standard or not is entirely besides the point, as your windows example should even made plainly visible to yourself. Ever noticed how many non m$ implementations of the win32 API there are???
There is a chance that they infringed on a patent in the implementation below the ISA
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
It is ARM (Cambridge, England) that is the culprit not the PRC government.
http://www.fpgacpu.org/#011102
http://www.fpgacpu.org/log/jan01.html#010129
I have setup a small mirror of the nnARM part :
http://www.foo.be/docs/nnARM/
Hope this helps to make a general idea what is it and what is the relation of ARM...
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.
IMHO I don't really agree with this under "your rights online". It might be good (if you were an electronic engineer) to have a quick peek at how the ARM people made their chip so well. Hell, I would be tempted to download the schematics just cuase its there [ for future use you see :-) ]. But I don't think it is a right for anybody to have this information for free.
I know a lot of people would say that information should be free, but this stuff took a lot of hard work to create. The ARM family of chips are (supposed) to be very efficient. The company should really reap the benefits of what they put into it. Pulling the specs for the chip of the web seems to me to be the decent thing to do.
hell, whipping up a simple MIPS core in an FPGA or a sim is a pretty common project in undergrad classes.
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++). Most ASIC houses are not processor design specialists. They usually leave it up to an outside IP vendor. Constraints are a different story - if you don't know functionally what you want, you can't get the processor to close timing. And this is just for a soft implementation. Never mind doing a hardmac and doing all the physical verification. 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. Well that's what I said - trying to get all the deliverables ready is impossible. And, unless this kid has access to something like Synopsys Test Compiler or Mentor Fastscan/DFT Advisor, he isn't gonna be able to deliver that. It isn't that trivial to run it through, trying to debug it and making sure you have adequate fault coverage. 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. And that's why they do it. In fact, even ASIC houses like IBM and LSI Logic who make hard implementations know that they have a per-design license for the core. I mean, why build it yourself? (By the way, your mask costs sound awfully high for a .25u process, you should be looking at more like the $50k-$60k range for a set of 4+2 layer reticles TOTAL.)
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.
Yeah, I wouldn't have budged if it was me. In fact, I wouldn't mind continuing the development of this core. Just making an instruction-level-compatible core isn't grounds for this type of action. But I stand by what I mentioned before - it's not in ARM's interest, PR wise, to do this. They've certainly lost my respect.
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.
It's spelled "lose". "Loose" is the opposite of "tight". You're welcome.
> I once was "Ungrounded Lightning Rod" but /. slashed off my " Rod". Is
> that why they call Linux a Unix workalike?
What the *FUCK* does a Slashdot bug or limitation have to do with Linux
or Unix, you stupid moron?
A lab for a VLSI course uses it
r tl /
http://www.ece.utexas.edu/~slee3/vlsi/lab3/arm/
Or am I missing something hidden between the lines? Just where did you get the idea that the Chinese government is interferring with Shen's activity? It's ARM who's "repressing" the student.
I have been wondering myself why the original post had to specifically mention a "Chinese" representative, because it sounds like that the "Chinese" is trying to stop the developer. Yet it turns out, it's because the developer is Chinese therefore the company (or the "capitalist") had to find itself a Chinese guy to talk to him.
It's so sad to see so many people blindly followed your cold-warish reflex.
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...