Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment: RE Open source chips (Score 5, Informative) 56

by olof_k (#46365785) Attached to: Experimental Port of Debian To OpenRISC
Hi, Having worked on the OpenRISC project for ~4 years I thought I could share some insights here, as the licensing question pops up all the time. The RTL for OpenRISC and most of the peripheral controllers that are used are licensed under LGPL, not GPL. While we all know that this is a software license with some concepts that don't translate well to hardware, the consensus is that LGPL means that you are obliged to shared modifications of the LGPL-licensed core, while GPL-licensed RTL would require the whole SoC to be GPL.

This is a view that we in the OpenRISC community share with the Open Source Hardware developers at CERN and other groups. This has also been tried by IP lawyers for a large company that wanted to use OpenRISC about ten years ago.

As for ASIC implementations it could be worth mentioning that there are ASICs running or1200 (the original LPGL-licensed OpenRISC implementation) in Samsung Digital TVs, in some of the Allwinner SoCs, Zigbee ASICs and other places, so it has been done many times over the years

Comment: Re:Where can I get one? (Score 1) 165

by olof_k (#37836476) Attached to: Linux 3.1 Released With Support for the OpenRISC CPU
License is a big thing. In most cases you want to put your own IPs in the same ASIC, and many companies are afraid of putting GPL code together with their own stuff. The leon and opensparc are available as GPL and as a commercial license that cost quite a bit, while the OpenRISC is LGPL only, which makes it more suitable for commercial interests in this case.

Comment: Re:OpenRISC on FPGA? (Score 1) 165

by olof_k (#37828556) Attached to: Linux 3.1 Released With Support for the OpenRISC CPU
I'm very interested in that area, but haven't had time to look at it in details. One way to move forward could be to profile drivers and see if there are any heavy number-crunching parts that could benefit from being moved to hardware. In the short run this would require patched drivers to interface the hardware, but in the long run I would like to see completely new interfaces, just as OpenGL defined a HW/SW interface for something that was traditionally done in software

Comment: Re:Where can I get one? (Score 1) 165

by olof_k (#37828532) Attached to: Linux 3.1 Released With Support for the OpenRISC CPU
Some of the OpenRISC founders started Beyond semiconductors. They have made ASICs of designs based on the OpenRISC. As it is closed-source, I don't know how far from the original OpenRISC they have deviated. Flextronics have also made OpenRISC ASICs about ten years ago. There are many more, but most are under NDAs.

Comment: Re:OpenRISC on FPGA? (Score 1) 165

by olof_k (#37823354) Attached to: Linux 3.1 Released With Support for the OpenRISC CPU
Yes, there are several ports for different development boards with FPGAs from Actel, Altera or Xilinx.. Here's a list of some boards that are supported by ORPSoC (The OpenRISC Reference System On Chip) http://opencores.org/or1k/FPGA_Development_Boards Most of them contain UART, Ethernet, GPIO, SPI and in some cases HDMI, USB and Flash.

MinSoC support even more boards (http://opencores.org/project,minsoc) but there are less supported peripherals there. Ethernet and UART IIRC

The cheapest ones are about $50 or $60. Think the de0-nano is cheapest

If you want to try out some OpenRISC developing without having to buy a dev board, there is also the OpenRISC architecture simulator or1ksim http://opencores.org/or1k/Or1ksim It supports UART through xterm or telnet, ethernet with TUN/TAP and a framebuffer

Comment: Re:Where can I get one? (Score 1) 165

by olof_k (#37821358) Attached to: Linux 3.1 Released With Support for the OpenRISC CPU

Or simply the dude who did it owned a DSP1800 as opposed to the board I have at home?

You're actually spot on :)

I think it was a tight fit though, so I'm not sure it will fit on smaller spartan 3 FPGAs. Disabling caches and hardware mul/div and stuff like that could help. It's a pretty common board, so if anyone is interested in trying, just drop in to #opencores on freenode and chat with us

Comment: Re:How well do openrisc cpus compare? (Score 1) 165

by olof_k (#37821124) Attached to: Linux 3.1 Released With Support for the OpenRISC CPU
The OpenRISC is a lot smaller and simpler than the OpenSPARC and probably a bit slower, as it is a single issue CPU. Haven't seen any benchmarks comparing them though. The advantage is that you can buy a $50 FPGA dev board and start hacking on the OpenRISC. The hardware required for an OpenSPARC dev board is significantly more expensive

Comment: Re:Single chip computer (Score 1) 76

by olof_k (#37814620) Attached to: Jumentum Introduces a Single-Chip Linux System
It could be done. We have booted Linux for OpenRISC on a dev board with 8MB of RAM. A quick look at the xilinx website shows that their top end Virtex-7 FPGAs have 85Mb of Block RAM which theoretically should be enough if not too much of that is used by the cores. You could also build some extra memory from the Slice FFs But that alternative certainly will be expensive. I don't know if there are cheaper FPGAs that specializes in having a higher memory to logic ratio.

Comment: Re:Too long ? (Score 1) 54

by olof_k (#37789342) Attached to: Open Source CPUs Coming To a Club Near You?
New, is to stretch it a bit as it's about 12 years old by now :) Anyways, it is MIPS-inspired, but not compatible. There has been some discussion about making next version MIPS-compatible, but we chose not too, as we would like to add and remove features that can better fit modern embedded systems. Here's a link to the or1200 spec http://opencores.org/websvn,filedetails?repname=openrisc&path=%2Fopenrisc%2Ftrunk%2For1200%2Fdoc%2Fopenrisc1200_spec.pdf

Comment: Re:Too long ? (Score 1) 54

by olof_k (#37788562) Attached to: Open Source CPUs Coming To a Club Near You?
I checked my facts, and as you say, Lattice fixed the licensing issues. Also, I wasn't aware of the differences in size between the two. Modularity is one of the things on the todo list for the OpenRISC. Hopefully we can bring it down in size in the future. Sounds like a fun weekend project to do some resource usage analysis between the two. If only there were more weekends :)

Comment: Re:Too long ? (Score 1) 54

by olof_k (#37788148) Attached to: Open Source CPUs Coming To a Club Near You?
Finally a comment that makes sense. The milky mist is a really cool project and deserves all the publicity it's getting. Thinking of buying one to try it out. The problem however is with the LM32. The license is very unclear, and IIRC there are at least three different licenses on the RTL code itself. I'm not even sure that it's really allowed to use it on any other FPGAs than Lattice's. From what I've heard it's also lacking a MMU (could be wrong on this part though) I also agree that there are way too few people working on open source hardware, but at least there is a lot more than there was five years ago. We have opencores for a lot of RTL cores and Dangerous prototypes cover a lot of cool open source hardware stuff on the PCB and MCU side just to mention a few. Open source also makes more sense for hardware in some cases as the verification part often is way more time consuming than the development. We have had much help from students that has chosen to do some formal verification project on the OpenRISC or some of the wishbone cores.

CPU implementations, in this case, are far from what they could be. Why is there not an open source equivalent of ARM's processors in the way that the Linux kernel was developed due to a lack of other open OS kernels? There's actually a couple of good reasons, but none should be terminal to the idea.

I'm working on the OpenRISC project. That is 100% LGPL and with Linux 3.1 it will be supported in the mainline kernel (along with an ever increasing support for different RTOS's). We are slowly getting there :)

Waste not, get your budget cut next year.

Working...