OpenCores

OpenCores.org

NEWSLETTER OCTOBER 2011

www.orsoc.se

Linux 3.1 is now released - with OpenRISC support

Linus Torvalds released Linux 3.1 this Monday with a long and exciting new feature list. Linux 3.1 includes a new iSCSI implementation and support for OpenRISC, Near-Field Communication chips, and Wii controllers.

Read more...


Design for portability - timing requirements

This article covering various aspects of timing requirements.

Read more...


Update from OC-Team

This topic gives you an update of what has been "cooking" at the OpenCores community during the last month.

Read more...


New IP-cores at OpenCores

View a list of all interesting new projects that have reached a first stage of development.

Read more...

OpenCores is the world's largest site/community focusing on open source hardware IP core development.

OpenCores Newsletter is published once a month - it gives you the latest news and updates at the site/community.

Do you wish to unsubscribe from this newsletter - uncheck the subscription button in your account settings at OpenCores. Or do a reply with the text "unsubscribe" in the subject-field.

(c) Copyright Opencores.org, equivalent to ORSoC AB. All rights reserved. OpenCores®, registered trademark.



Newsletter September 2011


Linux 3.1 is now released - with OpenRISC support

Linus Torvalds released Linux 3.1 this Monday with a long and exciting new feature list. Linux 3.1 includes a new iSCSI implementation and support for OpenRISC, Near-Field Communication chips, and Wii controllers.

The complete list of new features can be found at kernelnewbies-link below:
Linux 3.1 info

We have a goal to get the OpenRISC processor to be one of the most popular processors in the world. One big step in this work is to get the OpenRISC into the Linux kernel.

It started back in 2006 when we, within the company ORSoC, decided that we should "shape-up" the OpenRISC processor. This was after we found a severe bug in the OpenRISC after implemented it into an structured ASIC chip.

We, together with participants, corrected several bugs and did general improvements to the actual OpenRISC hardware implementation during 2006-2009. When this was done then we realized that the toolchain and Linux port was very out-dated and in a bad shape, so our focus changed to get the "software side" back on track again.

The work to port the latest Linux-kernel release to the OpenRISC processor was done during 2010-2011. During the same period a lot of work was done to upgrade the GCC compiler port. With all this in place we finally reached a very important milestone with the OpenRISC project - getting Linux into the official release.

The next step is to make it easier to "get started" using an OpenRISC processor system, so that even more people can start contribute and help us improve the OpenRISC faster then we can to today with our fairly small team of contributers. We need more hardware and software contributers.
ORSoC is now developing a new FPGA-development board that are 100% designed towards OpenRISC processor systems, our plan is to sell this board and make it "super easy" to get stated with both hardware and software development. We are right now testing the board and will hopefully be able to release it within 1-2 weeks. It will be sold via OpenCores webshop

Another goal is also to create the world's first community owned OpenRISC ASIC, which we have written earlier about in this newsletter. The new OpenRISC development board will also be used for this project, to prove the functionality and to enable the community help out with verification/design and to provide feedback on what function should be included.
This activity will hopefully trigger more people to participate in this project, enabling us together to create an ASIC that provides good performance with a low unit-price.

So join us, our "TODO LIST" is very long and we need your support!

The OpenRISC project

ORSoC / OpenRISC-team





Design for portability - timing requirements

Timing requirements are important. That a design works in the lab does not necessarily means that it works over voltage, temperature and process variations.
Clock networks should be constrained. Most timing analyzers can derive constraints for generated internal clock driven by PLL outputs. If this feature is not used, generated clocks should be manually defined with correct divisor ratio and phase relation to the source clock.
For synchronous IO signals both setup and hold requirements should be considered. This is especially true for high speed memory interfaces and other communication interfaces.

Clock networks that by design should be treated as asynchronous and does not have any relations should be defines as exclusive.

SDC example of exclusive networks:

# Set clkA and clkB to be mutually exclusive clocks.
set_clock_groups -exclusive -group {clkA} -group {clkB}

A properly constrained design can be moved to a new target technology. A new target could be an FPGA with a different speed grade.

For shorter time to market use timing constraints

Michael Unnebäck, ORSoC





Update from OC-Team

This topic gives you an update of what has been "cooking" at the OpenCores community during the last month.

This month activities:

Website information:

  • No issues.

Server information:

  • The servers has been running perfectly.

Our message to the community:

  • Please join the OpenRISC project, we need more hardware and software contributers.
  • Please help us improving OpenCores, send us bug-reports and ideas of new features/functions.
  • Don't be afraid to contact project-maintainers and ask them if they want help. The more we work together the better/faster it goes, and it's also more fun working in a team.

Marcus Erlandsson, ORSoC





New IP-cores

Here you will see interesting new projects that have reached the first stage of development.

cavlc decoder
This IP implements the CAVLC parsing process in ITU-T H.264 (05/2003)
Development status: Beta
License: LGPL
Updates:
Oct 21, 2011: rtl code uploaded

1G eth UDP / IP Stack
Implements UDP, IPv4, ARP protocols
Zero latency between UDP and MAC layer (combinatorial transfer during user data phase)
Allows full control of UDP src & dst ports on TX.
Provides access to UDP src & dst ports on RX (user filtering)
Couples directly to Xilinx Tri-Mode eth Mac via AXI interface
Separate building blocks to create custom stacks
Easy to tap into the IP layer directly
Separate clock domains for tx & rx paths
Tested for 1Gbit Ethernet, but applicable to 100M and 10M
More detail in doco under Downloads
Development status: Alpha
License: LGPL
Updates:
Oct 15, 2011: uploaded code and added PDF doco to overview
Oct 11, 2011: updated project status
Oct 11, 2011: Added project description, Detailed design docs and code coming soon

CFI flash controller
CFI flash controller IP.
Provides two modes of operation - simple (Wishbone bus straight through to flash bus, essentially, but with 32-bit word read capability, allowing XIP - execute in place - for 32-bit processors) and a "CFI engine" mode, which aims to simplify interfacing with a CFI flash.
Only implements asynchronous flash bus interface.
System bus interface is Wishbone, or CFI engine module can be used stand-alone and provides a generic bus interface.
Both modes tested with Intel P30 Strataflash part on Xilinx ML501 board.
Is implemented in the ORPSoC ml501 board port. A software driver for, and programming utility using this core can also be found in ORPSoC. XIP has been tested and works for OR1200 processor in ORPSoC.
Simple mode has been found to work fine with Strataflash drivers found in u-boot and Linux.
See the README under the doc/ path for further information.
Development status: Alpha
License: LGPL
Updates:
Oct 23, 2011: Update info about testing
Oct 23, 2011: Submit some project information.

KLC32
KLC32 is a 32 bit non-pipelined processor. This project is in the first stage of it's evolution and has a long ways to go yet, hence descriptions are a bit lacking. Read the code. First coding was Oct 4, 2011.

Programming Model:
There a 32 x 32 bit registers with register R0 always reads as zero.
There are two processor modes, user and system, each with it's own stack pointer. Some instructions are restricted to system mode only.
There is a group of eight condition code registers cr0 to cr7, each of which contains four status flags: carry,overflow,negative, and zero. The compare instruction can set any one of the group of condition codes. Many instructions update cr0 automatically.
Two address modes are supported: register indirect with displacement, and indexed addressing.
Development status: Planning
License: LGPL
Updates:
Oct 6, 2011: Updated project description


Johan Rilegård, ORSoC


© copyright 1999-2014 OpenCores.org, equivalent to ORSoC AB, all rights reserved. OpenCores®, registered trademark.