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."
Try here.
HIV Crosses Species Barrier... into Muppets
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
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.
its has THUMB support (1.22 anyway), interrupt handling is provided by the other stuff on opencores, a full copro is available on opencores and VM support was being worked on.
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.
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.
remind me why should one still call the US the Land of the Free?
Just a thought...
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 seems to be in my cache directory here