OpenCores

OpenCores.org

NEWSLETTER SEPTEMBER 2011

www.orsoc.se

OpenRISC Linux port included in official Linux kernel release

After hard work from allot of people during the last couple of years, the OpenRISC Linux port is now included in the Linux upstream source tree.

Read more...


Design for portability - clock domain crossings

This article covering various aspects of clock domain crossings.

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...

Banner advertise at OpenCores

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.

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



Newsletter September 2011


OpenRISC Linux port included in official Linux kernel release

After hard work from allot of people during the last couple of years, we have together taken the complete OpenRISC system including all its necessary components (RTL verilog, Toolchain, Debugging SW, SW libraries, RTOS), up to a level where it now gets accepted into the official Linux 3.1 kernel upstream source tree.
We truly hope that this will get allot of publicity and will lead to many more OpenRISC processor contributers, helping us to continue the development of the worlds only truly open-source 32-bit RISC processor targeted for FPGAs and ASICs.

Information about the OpenRISC processor can be found here

OpenRISC-team





Design for portability - clock domain crossings

When a signal goes from one clock domain into an other we have what is called a clock domain crossing. To avoid metastability related problems all these signal paths must be designed with care. Problems related to clock domain crossing are seldom observed during simulations. They do show up in real world and hence needs careful attention. There are basically two ways to deal with this:
1. Handshake protocol
2. FIFO

The basic principle behind the handshake protocol is to ensure that signals are latched in the receiving clock domain when they are guaranteed to be stable. More on this later. A FIFO is an elegant way of solving this problem. The FIFO flags will be synchronous to transmitting side (FIFO full) and receiving side (FIFO empty). Such a FIFO can in an FPGA be built with a dual port RAM with different clocks for write respectively read. The drawback with this method is that implementation requires at least one memory resource.

One robust handshake protocol is the toggle protocol. In this protocol we use a change of state of the handshake signal to carry information. Implementation is made in three modules:
1. source clock handshake logic
2. synchronizer
3. destination clock handshake logic

The basic principle behind the handshake protocol is to ensure that signals are latched in the receiving clock domain when they are guaranteed to be stable. More on this later. A FIFO is an elegant way of solving this problem. The FIFO flags will be synchronous to transmitting side (FIFO full) and receiving side (FIFO empty). Such a FIFO can in an FPGA be built with a dual port RAM with different clocks for write respectively read. The drawback with this method is that implementation requires at least one memory resource.

One robust handshake protocol is the toggle protocol. In this protocol we use a change of state of the handshake signal to carry information. Implementation is made in three modules:
1. source clock handshake logic
2. synchronizer
3. destination clock handshake logic

Source clock handshake logic
The source clock side interface has two signals. The first, data_valid, indicates that we want to send data. Actual data signals do not go through any logic but must be held stable until we receive signal ack indicating that receiving sides has successfully latched the signals. The handshake signal will change state when data_valid goes high. The handshake signal is fed forward to the next module.

Synchronizer
The synchronizer is made up with two D-type flip-flops clock with receiving side clock for the handshake signal and two D-type flip-flops clocked with transmitting clock for the ack signal coming from receiving side and travels back to origin.

Destination clock handshake logic
Destination side logic will sense the change of state for the data_valid signal. A capture signal goes high for one clock period enabling latching of data. Capture going high will cause a change of state of ack signal.

This mechanism works for any ratio between transmit and receive clock frequencies.

For robust design two other aspects are worth mentioning.

Reset signals. Each clock domain should have a dedicated reset signal. Release of reset signal should be done in sync with the associated clock to ensure proper startup. For a design with an active low asynchronous reset signal code snippet below could be used:

always @ (posedge clk or negedge rst_n_i)
if (!rst_n_i)
    tmp <= 2'b11;
else
    tmp <= {1'b0,tmp[1]};
assign clk_domain_sync_rst = tmp[0]; //active high clock domain reset

Asynchronous input signals. All asynchronous input signals should be synchronized with dual D-type flip-flops. Failing to do so will cause unpredictable behavour. We do not want that.

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:

  • Fixed minor bugs.

Server information:

  • The servers has been running perfectly.

Our message to the community:

  • 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.

rtfSimpleUart
This is a simple uart core which includes a baud generator. The core uses a fixed format: 1 start,8 data, 1 stop bit.
Development status: Alpha
License: LGPL
Updates:
Sep 12, 2011: updated WISHBONE compliant

USB 3.0 Device and Hose IP Core
This project is still in planning / research phase. At the moment, I have as much idea about USB 3.0 as anyone would have by few google clicks. With full time job, I have little time to spend on this project so the progress will be slow.
First step in development of USB 3.0 is implementation of USB 2.0 so We'll start from there. Throughout the entire development, our emphasis will be on Low Power. Power consumption will get top priority when considering conflicting alternatives for a particular solution.
Those who want to contribute, please send me the request with your open cores User Name, so I can add you as a project maintainer.
Development status: Planning
License: LGPL
Updates:
Sep 28, 2011: Beginner's Intro

IMA ADPCM Encdoer & Decoder
The IMA ADPCM audio compression algorithm belongs to the Adaptive Differential Pulse Code Modulation type algorithms. The algorithm is based on a simple adaptive quantization of the difference between the input and a predictor. Each 16-bit input sample is converted to a 4-bit coded information which yields a compression ratio of ¼. We will not go through detailed description of the algorithm in this document. Please refer to one of the following links for detailed description of the algorithm:
1. http://serghei.net/docs/programming/algorithms/BOOKS/BOOK10/9711M/9711M.HTM
2. http://wiki.multimedia.cx/index.php?title=IMA_ADPCM
Many other links exist out there, just Google “IMA ADPCM”.
The main advantage of the IMA ADPCM compression algorithm are its simplicity. The algorithm is not limited to voice signals and can operate at any input sampling rate thus enabling compression of high quality audio as well. The implementation in this project does not follow any standard protocol format for the compressed information. The encoder uses a very simple interface to input 16-bit samples and output coded information nibbles (4-bits). A similar interface is used by the decoder to input the coded information nibbles and output 16-bit reconstructed samples. A bit exact fixed point Scilab implementation of the algorithm is supplied with the core and is used to generate files used during verification. Detailed description of the verification process is given in the Test Bench Description chapter.
Development status: Alpha
License: LGPL
Updates:
Sep 18, 2011: Initial version

Leros: A Tiny Microcontroller for FPGAs
Leros is a 16-bit processor optimized for FPGAs. It consumes less than 200 logic cells and 1-2 on-chip memories. Leros is programmed in assembler and in a restricted subset of Java. Leros is a direct competitor to tiny processor cores, such as PicoBlaze.

Comparison with PicoBlaze
Leros targets the same application area as PicoBlaze and is about the same size. Following list gives the main differences:
* Truly open source (BSD)
* Compiles on Altera and Xilinx tools
* Leros is a 16 bit architectures instead of 8 bit
* Leros has no restrictions on code and data size
* Single clock cycle instructions
* Java based assembler is platform independent
* Simplified Java compiler for Leros available
Development status: Stable
License: BSD
Updates:
Sep 5, 2011: Add FPGA proven

rtf68kSys
This is a complete system-on-a-chip.
Developed on a Diligent Spartan3e board, the SOC includes CPU (TG68), bitmap and text displays, PSG, keyboard and more.

Features
- 52x31 text display
- 416 x 262 bitmapped graphics display
- line draw accelerator
- 8 sprites
- 4 channel ADSR PSG (not working at the moment)
- random number generator
- PS2 compatible keyboard interface
- TG68 cpu
- RS232 interface UART

Overview
The SOC make use of the TG68 cpu core available at OpenCores.org. This fine core implements the MC68000 instruction set.
The Nexys Epp memory controller available on the Diligent site is used for external communications to the PSRAM and Flash ROM.
Also used are the rtfTextController and rtfBitmap Controller cores found elsewhere on OpenCores.org.
The chip a Spartan 3eS1200e is full!
WISHBONE bus is used for core interconnects.

Memory:
There are about a half dozen devices that can act as bus masters for the onboard PSRAM. These are all connected through a memory controller. Devices have a fixed priority arrangement for access to the RAM with burst bitmap video having the highest priority. During developement a 2k RAM and BIOS rom were connected on a private cpu bus to make it easier to get the cpu going.

I/O:
A PS2 compatible keyboard interface recieves scan codes from the keyboard which is then converted to ascii using a scan-code lookup table in hardware. Ctrl-Alt-Del is wired to the processor's NMI signal to allow the system to be reset.
A WXGA video sync generator supplies timing to several video cores. The video cores are connected together to form a video pipeline. The switches on the FPGA board may be used to switch on and off several video devices.

Software:
A modified version Gordo's Tiny Basic 1.2 is used and occupies the last part of the BIOS ROM. The Poke and peek commands can be used to control the devices in the system. Currently added to the tiny basic are a couple of graphics commands: LINE x0,y0,x1,y1. POINT x,y. AND PENCOLOR c. There is also a small ROM monitor. The ROM monitor allows dumping memory, and jumping to code.
Development status: Alpha
License: LGPL
Updates:
Sep 25, 2011: updated project description
Sep 25, 2011: updated project description

Video Pattern Generator
This is a video pattern generator which can be used for testing video displays. It currently supports four patterns; horizontal lines, vertical lines, moving horizontal lines, and moving vertical lines. It sends out 1 pixel every clock cycle and forms the pattern on the fly using counters. This module has been used sucessfully to test a Camera Link serializer, SDXC Card video streamer and video rotator.
Development status: Beta
License: LGPL
Updates:
Sep 21, 2011: Video Pattern Generator Initial Release

rtfBitmapController
This core is a low to medium resolution bitmap display controller. It was engineered for use on the Nexsys2 board, a Spartan3e FPGA board, but is readily adaptable to other environments.

Features:
- small size
- low to mid resolution bitmap display
- fixed format display
- 32 byte burst fetching
- memory bandwidth consideration
- line buffer
- independent video and bus clocks

While small, this controller core has a number of interesting features. It features low resolution (low resolution these days) bitmap display. The resolution is 416 x 262 x 8bpp. Memory usage is about 128Kb. The controller is of a fixed display format, and hence doesn't need any software control. It does have a control signal to allow page flipping between two different address ranges. The design of the controller takes into consideration the amount of memory bandwidth available to the system, using 32 byte burst fetches to fill a line cache. A trick to achieving a low resolution bitmap display, is to use a video line cache instead of a video fifo.

Operation:
The line cache allows the same video data to be retrieved several times for a given video display row, without accessing main memory.
Briefly, a fifo works by filling the fifo buffer once it becomes a certain percentage empty. As data is retrieved for display from the fifo, new data for future display is fetched and loaded into the fifo. A video line cache works slightly differently, by buffering entire video display lines in a line buffer.
The video line cache is periodically filled at a rate that keeps up with the video display. While one video row is being displayed, a to-be-displayed video row is being fetched from memory and stored in the line cache. The advantage of a line cache over a fifo is that the same video data may be redisplayed without refetching the data. This allows data for the display to be fetched across the duration of several scan lines, when a lower resolution mode is in use.
A video fifo is driven by the fifo status, if the status indicates that the fifo is becoming empty, more data is fetched. The line cache is driven directly by video timing instead. Rather than monitoring empty/full status, it simply automatically fetches data at periodic intervals.
The disadvantage of a video line cache is that it requires a larger memory reousrce than a video fifo would require. Often a fifo only needs to be a few dozen bytes in size. The line cache needs to buffer at least two entire lines, which can result in it being several kilobytes in size, depending on the video mode. Timing control for a line cache is more complex than a fifo.
The controller fetches data in 32 byte bursts at periodic intervals. One might think that it would be a lot simpler and more efficient to just fetch an entire line in a long burst. However this would have the drawback of consuming memory bandwidth for an extended duration of time. The 32 byte burst fetches are geared towards allowing other devices in the system to access the same memory. So that the peformance of the entire system isn't adverse. The controller relies on the memory system to support burst mode fetchs. In this case page-mode of the PSRAM is used.
The controller uses two independent clocks, one each for bus timing and video timing. Except for the video request flip-flop, all cross clock domain data is handled using a block ram resource. The block ram itself allows a different clock to be used on each port. Data is written to the block ram under control of the bus clock, and read from the block ram on the second port using the video timing clock. A clock domain crossing synchronizer is used to allow the video request signal to cross the clock domain.
Development status: Alpha
License: LGPL
Updates:
Sep 20, 2011: updating project page

rtfTextController
This is a text mode video controller that supports color. The default resolution is 52x31 expecting a 1680x1050 graphics mode for display. Teh controller uses an external sync generator which must supply end-of-scanline and end-of-frame signals. Display memory is nine bits wide allowing 512 different characters to be displayed simultaneously. Character bitmaps are stored in block RAM allowing them to be reprogrammed at run time, these can be pre-initialized in a constraints file.
The display controller fits into a memory map at addresses $FFD0xxxx, $FFD1xxxx, and $FFD2xxxx, for the text memory, attribute memory, and character bitmaps respectively. Note that there are multiple images of the memories within the address range. The display controller register set is at $FFDA00xx.
Development status: Alpha
License: LGPL
Updates:
Sep 20, 2011: updated project property: FPGA proven
Sep 12, 2011: updated description
Sep 6, 2011: updated spec - WISHBONE compliant
Sep 6, 2011: First archive of files uploaded


Johan Rilegård, ORSoC


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