Slashdot Mirror
Open Source Finally Hits Real Silicon
pagercam2 writes "While Open Source software has many success stories, hardware and particularly chips haven't had as much. While there have been multiple Open Source projects, none have come to a final product until now. The OpenRISC 1000 has been implemented by Flextronics Semiconductor(a division of Flextronics, the contract manufacturer possibly best known for its production of many Cisco products) along with PCI, 10/100 Ethernet, serial, GPIO etc. ... Details and pretty pictures available at OpenCores.org, and it even runs uClinux. Good Job!"
So what's Sparc V? Swiss Cheese? Sparc specs have been available for a LONG time.
Javascript + Nintendo DSi = DSiCade
If they make money with this and other chip fabricators get on the open source boat then perhaps one day we'll see an entire open source chipset and motherboard combo. No "SecureThisBIOS" and "TrustedThatOS" needed.. That would be damn sweet.
Trolling is a art,
What's the roadmap from here for these open core processors? Is there one?
I have been pwned because my
This is indeed a good step for the Opencores project, but the subject itself is misleading.
The LGPL'd SPARC-compatible processor Leon was put to silicon a long while ago.
Give credit where credit is due, the Leon tracked over this territory years before OpenRISC.
Karma Whoring for Fun and Profit.
>>Flextronics Semiconductor(a division of Flextronics, the contract manufacturer possibly best known for its production of many Cisco products).
m l
Flextronics would actually be best known for being the main manufacter of the Microsoft Xbox.
http://www.wired.com/wired/archive/9.11/flex.ht
A lot of what's floating in space runs with what we could consider antiquated hardware.
Old != Junk
Trolling is a art,
Project: OpenRISC 1000
Silicon Implementations
Several companies are making silicon implementations (ASICs) of OR1200 using different library vendors and foundaries, process geometries from 0.35um to 0.13um. For references contact lampret@opencores.org.
Here is an example of System-On-Chip (SOC) from Flextronics Semiconductor. It is a 32-bit general-purpose microcontroller implemented on UMC 0.18um targetting embedded applications with maximum clock frequency of 160MHz. The SOC features:
* OR1200 processor
* Memory Controller (FLASH, SDRAM, SRAM, DPRAM)
* PCI 2.2 32-bit interface 33/66MHz
* Ethernet MAC 10/100
* UART16550
* GPIO
* JTAG/Debug Interface
The OR1200 is implemented with 8KB instruction and 8KB data caches, I/DMMU with 64 TLB entries each, power management unit, debug unit, tick timer and interrupt controller. Its 32x32 multiplier is coupled with a 64-bit MAC unit.
Test board for testing the SOC has 64MBytes of SDRAM, 32MBytes of FLASH, RS232 transceiver, Ethernet 10/100 PHY. Connectors are for RS232, Ethernet, JTAG/Debug and several Mictor logic analyzer connectors. The board has its own DC/DC regulators for 3.3V IO power supply and 1.8V core power supply. It can be used as stand alone board or as PCI standard form plugin board.
Software running on the SOC is Embedded Microcontroller Linux (uClinux) with a console on serial RS232. The console shows a network ping to a local network host - the ping shows the Ethernet 10/100 capability.
This board was the first prototype built (not fully assembled at the time)
Dynamic power of the entire test board is 1.4W. Dynamic current of the SOC IO power supply is 52mA (3.3V) and dynamic current of the SOC Core power supply is 86mA (1.8V). These are nominal values measured at 100MHz system clock.
Maximum system clock frequency of the SOC is 160 MHz. System clock is used to clock not only the OR1200 processor but the entire chip (exception is memory controller which can also run at 1/2 system clock). Max system clock 160MHz was obtained at 25C ambient temperature, 3.3V IO and 1.8V core.
Test boards are available to Flextronics Semiconductor ASIC customers. For more information about the test boards, the SOC technical details and business engagement please contact Flextronics Semiconductor.
IMPORTANT NOTE: For a live demonstration of the SOC in Silicon Valley, California during Dec 8th 2003 and Dec 15th please contact Damjan Lampret.
-- john
Project: OpenRISC 1000
Silicon Implementations
Several companies are making silicon implementations (ASICs) of OR1200 using different library vendors and foundaries, process geometries from 0.35um to 0.13um. For references contact lampret@opencores.org.
Here is an example of System-On-Chip (SOC) from Flextronics Semiconductor. It is a 32-bit general-purpose microcontroller implemented on UMC 0.18um targetting embedded applications with maximum clock frequency of 160MHz.
The SOC features:
The OR1200 is implemented with 8KB instruction and 8KB data caches, I/DMMU with 64 TLB entries each, power management unit, debug unit, tick timer and interrupt controller. Its 32x32 multiplier is coupled with a 64-bit MAC unit.
Test board for testing the SOC has 64MBytes of SDRAM, 32MBytes of FLASH, RS232 transceiver, Ethernet 10/100 PHY. Connectors are for RS232, Ethernet, JTAG/Debug and several Mictor logic analyzer connectors. The board has its own DC/DC regulators for 3.3V IO power supply and 1.8V core power supply. It can be used as stand alone board or as PCI standard form plugin board. Software running on the SOC is Embedded Microcontroller Linux (uClinux) with a console on serial RS232. The console shows a network ping to a local network host - the ping shows the Ethernet 10/100 capability.
This board was the first prototype built (not fully assembled at the time)
Dynamic power of the entire test board is 1.4W. Dynamic current of the SOC IO power supply is 52mA (3.3V) and dynamic current of the SOC Core power supply is 86mA (1.8V). These are nominal values measured at 100MHz system clock. Maximum system clock frequency of the SOC is 160 MHz. System clock is used to clock not only the OR1200 processor but the entire chip (exception is memory controller which can also run at 1/2 system clock). Max system clock 160MHz was obtained at 25C ambient temperature, 3.3V IO and 1.8V core.
Test boards are available to Flextronics Semiconductor ASIC customers. For more information about the test boards, the SOC technical details and business engagement please contact Flextronics Semiconductor. IMPORTANT NOTE: For a live demonstration of the SOC in Silicon Valley, California during Dec 8th 2003 and Dec 15th please contact Damjan Lampret.
Chas - The one, the only.
THANK GOD!!!
Or, I'm just being fanatical and ranting about nothing, whatever.
- A
In general, what problems would there be in creating open-source engineering designs for hardware of all kinds branched off from off-patent intellectual property? That, as it turns out, was the express purpose of the US Patent system as conceived by Benjamin Franklin, unless I am mistaken.
Just my two cents...
Procrastination sucks.
"Can anyone seriously point out some practical applications of this processor?"
Sure.
For chips derived from this test SoC:
MP3player
VoIP hard phone
Network Router
Firewall
Wireless Access Point
DVD player
Car stereo
Cell Phone
PDA
For uClinux:
It's all around you, many of the products _you_ use every day run it. Just because you think Linux means servers and desktops doesn't mean that's the only place it's widely deployed!
J
Just FYI, this guy's a troll. Check out his recent posts. Apparently he's also "in middle management at Honda". I highly doubt Apple are considering OpenRISC for the iPod.
Bad troll. Bad.
Sailing over the event horizon
...their server is running off one of these since its already Slashdotted.
Didn't you hear? Honda is purchasing Apple. I work in middle management at Hopple MotorComps, so you can believe me.
Judging from the specs included at the linked site, this core compares favorably with CPU cores from ARM, NEC and others who make big bucks selling (and supporting) these cores for system integration. This is interesting, and it's maybe even more interesting that I haven't noted it in any trade journals (did I miss it, or has this thing been going on under the industry radar?)
However, it seems like the CPU core itself is open-source, while a lot of the bonus features on the SoC (System On a Chip) example cited are IP from Flextronics (the the company that did the physical design for this open-source CPU core, which was manufactured by UMC). I can't tell for sure because the site is slashdotted already. The links on PCI, JTAG etc. would presumably tell if all these IP macros (besides the CPU) are open source also -- does anyone know for sure?
Either way, the specs on the sample chip are interesting: SoC with OR1200 CPU implemented by Flextronics Semiconductor: 32-bit general-purpose microcontroller, UMC 0.18um fab process, maximum clock frequency of 160MHz. This SoC contains (1 each I assume): OR1200 processor, Memory Controller (FLASH, SDRAM, SRAM, DPRAM), PCI 2.2 32-bit interface 33/66MHz, Ethernet MAC 10/100. UART16550, GPIO, JTAG/Debug Interface.
BTW, 160MHz is pretty darn good, until you see that 160MHz is not really "MAX" as in "max (worst-case) operating conditions" as one usually specs these things. Usually, when a spec says "maximum clock frequency", it means that you can safely run the part at these speeds under the entire range of allowed operating conditions (temperature and voltage). It's rather meaningless to tell the fastest it canpossibly go (which would be 0Kelvin, with a voltage almost high enough to fry the cip), so wpecs tend to tell you the max safe speed.
That would be the highest temperature (usually ~70C, but it's really based on the junction temp, which is calculated from ambient temp, airflow, and package thermal characteristics -- higher than 25C in any case, since that's usually called "typical"), lowest voltage (usually nominal minus 5% or 10%; so for 3.3V system, worst case voltage would be 3.3-0.33=2.97V, for 1.8V core it would be 1.62V), and slowest process from the fab (whther this is the case or not is unspecified in the list). Instead, lower down the page I see:
Max system clock 160MHz was obtained at 25C ambient temperature, 3.3V IO and 1.8V core
I could take a wild guess and say the thing would run at least 125MHz (respectable for the tech at hand), so calling it 160MHz (but not at worst-case conditions) is a little odd, or at least non-standard. If it were a "normal" industry player quoting me a part's clock rate that way, I'd become very, very suspicious of them for the rest of the negotioations.
It's still way cool, and if those IP cores are all available open source also, I'm really excited. But, I still have a lot of unanswered questions that I expected to see at least a brief mention of:
- Is a hardware/software co-simulation environment available?
- If so,what simulators and languages are supported?
- What support model(s) are available for design teams considering this core?
- What is the die size for the SoC made by Flextronics?
- How much is Flextronics selling these SoC's for, or are the ASIC (customer-specific)?
I guess I could do as the article suggests and call or email Flextronics:Test boards are available to Flextronics Semiconductor ASIC customers. For more information about the test boards, the SOC technical details and business engagement please contact Flextronics Semiconductor.
everything in moderation
I appreciate the joke, heh, heh.
But I'd like to point out that opencores has had a fair amount of its open IP commited to silicon to date... not via lithographic processes maybe, but in FPGA's at least in onesies twosies lots if not more.
It's pretty sweet to be able to put a Z80 core on an FPGA along with a few peripheral cores and make a machine-on-a-chip that can run your legacy embedded code with little or no change... and at a faster clock rate.
This represents a branch point from the First World industrial paradigm of economy of scale and elimination of manual labor, coupled with planned obsolescence and faddishness to ensure a short interval between new car purchases. An open-source car reverses this drastically. Low economy of scale and higher manual labor content coupled with an open-ended product lifetime shifts the focus from the manufacture of the car to that of its components. The car owner repairs the vehicle over a period of many years, possibly turning over the majority of its components one or more times over a long period of time. Small-scale manufacturers would build a mix of components based on demand for specific versions of a component. Clever management of the project should consciously support this. This business model is unsustainable by massive industrial concerns, but might work well in an economy with lower-skilled, small-scale enterprise. It would not be massively profitable, but may be a model for keeping large populations employed.
If the interconnection ot the automobile's components is carefully and thoughtfully evolved, a single vehicle might be an ever-changing machine, gradually absorbing better components over time. It would not be a static piece of technology that quickly becomes obsolete. This is a subtext of my original post.
Your questions are all perfectly logical in the context of the traditional semiconductor design process, but reading them gave me an insight: open source IP cores have all the markings of a disruptive technology. They are too slow/low-quality/unsupported to be usable in traditional markets, but they are much cheaper and could enable new applications that don't exist today. And eventually they may start to eat away at the low end of the existing market...
Maybe today open hardware is an esoteric industry. But with self-assembling circuits being the way things are heading (What? IBM's announcement of self-assembling FLASH didn't make Slashdot? Shame on the mods.) that'll change. Why? Because the most practical way to make dense circuits will be as an FPGA where the self-assembling units are not FLASH modules but FPGA cells. In effect, all major components become FPGAs.
:v)
But it won't stop there. Turning this new capability to its advantage, it will make sense to re-compile the CPU cores to perform the task at hand with maximum efficiency. If you're going to start doing that, an open design is nigh on essential.
We are rapidly entering an era where it is worth designing things that cannot yet be built, because the manufacturing technology is catching up very rapidly. Even now, Sony are designing their consumer device chipsets as FPGAs to shorten time to market. The trend will not decrease.
Vik
It's one hell of a LONG way from making an 300K gate FPGA work at 150Mhz to making a 32/64 bit CPU at 2GHz! A modern CPU core may have as many as a few million gates. Add in on-chip cache and other things and that number gets higher. Now if you want to talk micro-controller then 300K gates might get you a decent 8/16 bit one like the old 8051s (which you can do a LOT with but I don't think it would run Linux). Your idea sounds like a good Sr. Project for a CSE class in Computer Architecture.
The cost of R&D and design of the chip is probably a drop in the bucket compared to building a chip fabrication plant. And much of it the advances required to make a fast chips would be in fabrication technologies (materials, layering, etc.) that might has nothing to do with the chip design. And these technologies are likely to be patented.
guys,
while i'm sure the opencores crowd has done an outstanding job, you need to look further at the Big Picture.... and comparable processors.
a motorola ppc8245 at 300MHz is $19 in qty (at least that's what we pay). it has all of the features enumerated in the article above (16K caches, PCI, MMU, ethernet, dual UARTs, etc etc etc), and is supplied replete with a Big DataBook of We're Pretty Damn Sure This Will Work Knowledge and 10e6 embedded programmers worldwide. not to mention an entire library of (linux AND powerpc) Google entries. you can attach all manner of BDM/BDI/JTAG debuggers (e.g. BDI2000) to an 82xx and there are a half dozen compiler suites (including gcc) to choose from. boundary scan routines are already understood and implemented, which eases ICT development at production time. if it's 2AM the day before the Big Pitch to the client, i'm pretty sure i can find someone who's awake and can fix my 82xx register access problem. i'm no motorola bigot (i always try to make a PIC fit until it can't do the job) but the economies of scale are WAY WAY WAY against the little guy when it comes to microprocessors.
you are not selling your soul to moto for $19. you are making a cost effective, performance increasing, risk reducing decision, that's all.
just another datapoint.