Newsletter June 2009
OpenCores continues to grow rapidly and we are pleased to announce that we have just passed 50,000 registered users. We have also noticed a large increase in activity on the site, in both downloading cores/projects and creation of new cores/projects.
Digital multimedia has become ubiqutious: digital television (via satellite, cable, and terrestrial broadcast), multimedia streaming and video-on-demand (over Internet and wireless networks), video storage and playback from multiple mediums (from DVD, Blue-ray, and magnetic storage), video-conferencing, mobile video, multimedia messaging services, security with video surveillance, and high-quality studio distribution. In all these technologies video compression is a key component.
There are at least two important reasons why video compression (encoding) and decompression (decoding) is needed. First, video compression makes it possible to transmit video over networks and store video on storage devices that would not support uncompressed raw video material. One example is a common format for digital television; the ITU-R Recommendation BT.601-5 (PAL with YCbCr 4:2:2, 25 Hz frame rate, frame size 864 x 625, 8-bit samples). This means a bit rate of 216 Mbps. So, in most cases, the Internet bandwidth available to the homes of people is insufficient to handle uncompressed video in real time. Another example is the DVD disc. Such a disc can only store a few seconds of raw video at television resolution and frame rate. So, storage on a DVD disc would not be practical without the compression of video and audio. Second, video compression means a more efficient (and more economical) use of network transmission bandwidth and storage resources. Several high-resolution compressed video streams can share the same transmission channel, rather than giving the channel to a single low-resolution uncompressed stream.
Over the years several standards for audio, image, and video compression have been proposed and developed. The purpose of a standard is to ensure interworking and competition. Compliant encoder and decoder products from different manufacturers can successfully communicate with each other. At the same time manufacturers can develop competitive and innovative products.
Digital television and DVD-video is based upon the (now rather old) MPEG-2 standard. Two more recent and modern International Standards that have emerged are MPEG-4 Part 2 Visual and MPEG-4 Part 10 / H.264 / AVC. These two standards are both concerned with video compression, but they have quite different visions. MPEG-4 Visual emphasises flexibility and provides coding techniques for rectangular video frames, video objects of arbitrary shapes, still images, scalable coding, and hybrids of natural and synthetic (computer-generated) 2D and 3D visual objects. In contrast to this H.264 has a more pragmatic vision, focusing on efficient compression and robust transmission of camera-shot rectangular video frames. H.264 out-performs MPEG-4 Visual in compression efficiency but it does not have the huge flexibility of MPEG-4 Visual.
There are certainly many useful, entertaining, cool, and some of them perhaps even necessary multimedia products out there. But we tend to ask for more all the time. Therefore we, as members of the OpenCores community, think that it is important that there are IP cores supporting modern multimedia standards (H.264 in particular) available at the OpenCores web site.
Right now there are a number of projects at OpenCores that are interesting and promising. Some examples are cores supporting complex arithmetic operations, division, DCT/IDCT, fast Hadamard transform, colour conversion, (M)JPEG encoding and decoding, and H.264 Baseline decoding. There is also one project that supports H.264 Baseline encoding with intra-prediction (but not yet inter-prediction).
We think that open source-alternatives are needed for all kinds of products out there, and multimedia is certainly an important and hot product segment. So, in the light of what has been said, we feel that one of the things we really would like to have at OpenCores is a ‘complete’ H.264 Baseline encoder, supporting both inter- and intra-prediction. Having such an encoder would be a strong foundation for the development of multimedia products based upon the open cores philosophy. We believe this will help generating new exiting products in the future to come.
This article is written by Krister Karlsson at ORSoC (www.orsoc.se)
The OC-team wants to define and start a new multimedia project pursued within the OpenCores community. The long term goal is to be able to support various multimedia standards and products by expanding our collection of media IP cores. However, we need to have a first reasonable goal.
H.264 / AVC is one of the more recent and modern international standards that has attracted a lot of attention. We suggest that the first goal for the multimedia project would be a ‘complete’ H.264 Baseline (progressive) encoder that supports both intra- and inter-prediction. At present time there is one project at OpenCores (the "Video compression systems" project maintained by Richard Herveille and Andy Henson) that supports H.264 Baseline encoding with intra-prediction (but not yet inter-prediction). This seems to be the obvious place to start.
And now some technical stuff. There are obviously several possible architectures for a multimedia chip. The spectrum of general and specialised architectures ranges from, say, general-purpose CPUs with a pure SW implementation, over special-purpose processors (DSPs or other ASIPs), over a mix of DSPs and HW accelerator blocks, to the pure HW ASIC implementation. Typically, the general-purpose CPU approach has the best flexibility but the worst area and power efficiency, and the pure ASIC solution has very little or no flexibility at all but the best area and power efficiency.
Video coding algorithms require both (complex) decision-making and intense mathematical calculations. This is especially true for the encoder. Therefore we propose a heterogeneous SoC architecture, containing a programmable RISC DSP core and HW accelerator blocks specific for video compression. The RISC core features conditional execution and branching and is therefore efficient for the decision-making. Typically the RISC core takes care of the overall system control, the user interaction, and perhaps some of the less intense video coding at the higher layers. The HW accelerator(s) take care of the video processing at the macroblock level (prediction and interpolation, transformation, quantisation, entropy coding, filtering, colour conversion etc). The heterogeneous SoC architecture attempts to combine the (re-) programming flexibility of the RISC DSP core with the ASIC-like performance and efficiency of the HW accelerators. It allows for a more precise fine-tuned matching of intense calculation and decision-making.
So, what we have in mind right now is a SoC architecture similar to the one below.
- The Camera Controller is an interface to a CCD or CMOS image sensor of a camera.
- The Memory Controller is connected to the external system memory (off-core or off-chip), typically SDRAM. The reference frame buffer is located in this memory.
- The Bit-Stream Core is very useful for a decoder. The codewords of a compressed bit-stream usually have any bit-width within a certain range. They follow in a sequence after each other and are therefore not nicely aligned to certain memory address boundaries. Finding such codewords in the bit-stream can be a painful job for a microprocessor, meaning a lot of shifting, masking, and other bit-manipulation operations. The purpose of the Bit-Stream Core is to manage the bit-stream reading and help the decoder to quickly find codewords.
- The first goal is that the AVC/H.264 Codec Core should be a H.264 Baseline encoder.
- The Display Controller supports the chosen display device.
- The DMA Controller manages the data traffic between off-chip and on-chip memories.
- The main CPU in the system is an OpenRISC processor (e.g. OR1200).
The interface blocks shown should be understood as examples. Others may apply as well.
So, we hereby address the OpenCores community!
Our wish is to form a multimedia group to undertake this mission. We therefore want to encourage the knowledgeable, experienced, and interested members of the OpenCores community to participate. Let us know if you want to be a part of this!
Send your contact details to firstname.lastname@example.org along with an indication of your talents and interests.
To start with we will create a new topic in the "Cores" forum, specifically for multimedia related discussions. We will create further specialised forums in the future as required.
This topic gives you an update of what has been "cooking" at the OpenCores community during the last month.
This month activities:
- Modified the "project-list"-page so that it shows the actual license of each project.
- Improved the handling of forum post formatting. Note that if you use HTML syntax anywhere in the post, then the entire post must use HTML formatting.
- Addressed "bottle necks" on the website to improve the user experience and decrease the overall load on the servers.
- Upgraded the internal RAM to 4GB with ECC.
- Replaced failing disk. The system is still running since we have a "hardware RAID5 system" on all OpenCores servers.
Our message to the community:
Update your project with a "description"-text
In order to make your project more visible on Google and other search-engines, we have made the "Description"-block on the "Overview"-page a "meta description"-tag. The first 160 characters will be visible at Goggle’s search-list, so it’s important that you describe your project in a short and understandable way in the "Description"-block.
Update your project with "license"-information
There are still many projects without the "license"-property. Please update your project information to indicate the appropriate license. The license property can be set by clicking on the "Edit"-button on the "Other project properties"-block on the "Overview"-page.
Help us find incomplete or obsolete projects
We have now started task to "cleanup" the project-list on OpenCores, meaning that we want to "mark" incomplete orobsolete projects with a "not ready"-sign. This will make it easier for all users to find suitable projects and hopefully also motivate the project maintainer to complete the project.
View a list of some of the projects that have been updated during the last month. Here you will also see interesting new projects that have reached the first stage of development.
The data unconfuser engine is designed to handle streaming data which occurs for long durations of time. The goal of the confuser is to make it difficult for others to easily determine the contents of the data. The confuser is a simple single key data processing engine intended to be placed in various communications products where some low level of data protection is desired, but the costs of true public /private key encryption are not justified.
Phase: Design done, Specification done
DPLL with a Random Walk Filter
The DPLL consists of 4 modules:
- DPLL (top module)
- FREQDIVIDER (generating the output dejittered signal)
- PHASECOMPARATOR (compares the input and output signals)
- RANDOMWALKFILTER or VARIABLERESETRANDOMWALKFILTER (the loop filter)
If you will desired to use the Random Walk Filter with Variable Reset then apply to  for right selection of "M" and "N" parameters. In the module you must set "M" directly via defparam directive and "N" assigned as doubled "N_FilterResetValue" parameter. Also have in view that Note that "L" (named in ) per se Divider coefficient determinated in PHASECOMPARATOR module.
Additional info: Design done, FPGA proven
YANU - UART with predictive interrupt events on Rx/Tx buffers state
YANU (Yet Another Niosii Uart) has been built from scratch with the efficiency in terms of CPU load in mind. A complete uCLinux TTY driver has also been developed.
Its main feature is that it has TX and RX FIFO buffers with a predictive "event to interrupt" generation. This will lead to a lower CPU usage needs in high efficiency point to point communication links at high baud rates. It has a fractional prescaler so that almost any baud rate can be generated from any input clock frequency. It detects all the common asynchronous errors (Parity,Framing,Overrun). It is programmable in terms of hardware handshake, number of bits and stop bits; it can generate break conditions, etc... It has an Avalon compliant bus interface and it has been tested successfully in Altera FPGAs (average logic block usage is 330 logic cells in CycloneIII family).
Additional info: FPGA proven
This file computes the modulo-3 (%3) for a register which can range in size from 3-bits to 64-bits. This is needed because most synthesis tools (Xilinx XST in particular) only deal with modulo's that are powers of 2, ie %2, %4, %8, which of course are easy to do by looking at lsb's. You select your bitsize in this file (modulo3_Nbit.v) and if you want to simulate, also select the bitsize in file tb_modulo3.v. The other .v files are just for educational purposes. The only file you need for your project is modulo3_Nbit.v
Development status: Not specified
Versatile memory controller
This is a modular memory controller supporting different types of memories. Initial design will have support for SDR SDRAM. Upcoming releases will add support for DDR SDRAM and possibly other variants as well.
The design is built with the following modules
1. Wishbone interface
2. Dual async FIFO buffers
3. Specific memory controller
Development status: Planning
Manchester Decoder for Wireless
This core decodes incoming Manchester encoded data. The core is easily modified for your particular project, in that there are just a few constants that you must change.
This project is in an alpha stage and is currently too susceptible to other radio noise. In our development environment, there is currently a 25-50% error rate, which comes from the algorithm misidentifying signal for noise and noise for signal.
Additional info: FPGA proven
RTL Verilog code of the Two Dimensional Fast Hartley Transform (2D-FHT) algorithm with decimation in frequency domain is presented.
- High Clock Speed
- Low Latency(97 clock cycles)
- Low Slice Count
- Single Clock Cycle per sample operation
- Fully synchronous core with positive edge triggering
- Flexible core control with regard to input data width
Discrete Hartley Transform is used in a wide variety of signal processing applications such as filtering, convolution, correlation, compression and so on. The most popular usage of the Hartley Transform is image processing applications.
Additional info: FPGA proven
The TV80 is an 8-bit Z80-compatible microprocessor core, written in Verilog.
- executes 8080/Z80 instruction set
- cycle timing is similar to original Z80
- small die area
- sample peripheral with GMII interface
- Optional Wishbone wrapper for TV80 core now available
Additional info: ASIC proven, FPGA proven
The VHDL Test Bench
The VHDL test bench is a collection of VHDL procedures and functions which allow the user to create their own scripting instructions for test stimulus. The stimulus script or test case contains the instructions in a regular ASCII text file. The function of the instructions is coded in VHDL as part of the test bench. The test bench VHDL package contains procedures to create instructions, read, parse and execute the test script (stimulus file, test case, script).
Development status: Stable
Cache Architecture for Configurable Hardware Engine:
Additional info: Specification done
Simple AES3/SPDIF receiver
AES3 / SPDIF receiver is simple, minimalistic but powerful core which decodes biphase mark coded AES3 compatible signal and retransmitts it in I2S-like format. Audio words are coded in 2's complement format, however, in contrast to I2S, they are LSb and not MSb aligned and all auxiliary bits of AES3 are left unchanged and transmitted together with audio word. There is even some mess in first four bits of each word as result of preamble detection. Nevertheless, this core can be implemented on XC9572XL-5 with only 39 macrocells utilization and fmax = 138MHz while capable of receiving AES3 at fs = 96kHz with clk at 50MHz. I2S transmitter can be replaced by channel output registers (TODO), and used for example with PLB interface as MicroBlaze peripherial.
Additional info: Design done , FPGA proven
The announcement on June 4 that Intel are to acquire Wind River Systems can be viewed as another vote of confidence in the Open Source model. Wind River are a leading embedded systems software vendor, focusing primarily on "middleware" software used between the kernel and application layer. Their software has been used in fields ranging from automotive to interplanetary exploration. Intel, as is well known, are the goliath processor vendor who have, until recently, had limited or no interest in the embedded systems market. The introduction of the Atom processor and the heating-up of the nascent netbook market has seen Intel take steps which indicate its interest in long term dominance of the embedded market. Moves such as making the Atom processor IP available to third-parties via the TSMC fab in Taiwan, and the acquisition of Wind River suggest they want Intel inside not just desktops, servers and netbooks, but everything embedded.
Wind River and Intel have been getting cosy over recent years. Last year's collaboration between the two in the optimization of an open source in-vehicular infotainment platform for use on Atom-based systems indicates Intel have been testing the waters for some time, preparing to become a bigger player in the field. A notable element here is the role open source has played in Wind River's buisiness model, and this move by Intel could be seen as a departure from their well known "Wintel" past. Wind River have, for several years, have been active supporters and participants of open source development. Flagship products such as the Wind River Linux kernel, built upon the open source Linux kernel, is a foray into a reliance upon open source technology as the foundation of their design. They've also been active in contributing back to the community through participation in the LiMo consortium, the Moblin project, and releasing work such as interprocess communication libraries (TIPC) from VxWorks and contributions to the Eclipse project.
The realization that the majority of development costs in embedded systems are now spent on software has resulted in shifts away from total in-house development approaches and towards an increased uptake of open source technologies. Wind River's introduction of its modified and optimized Linux kernel has seen a change in where it adds the value (to optimization and tool chain support) and has resulted in improved results in terms of time-to-market and performance. Its leveraging of open source technology along with its vision and experience has helped Wind River become one of the biggest players in the embedded systems software field.
The emergence of industry alliances such as the Moblin group and the LiMo Foundation are also votes of confidence in the open source model. Wind River are active participants in both. No doubt Intel's previous work with Wind River will be an advantage for them, with developers of mobile media platforms looking at the progress of this alliance with the intent to base their products on the open source based platform.
However, the perception of Intel shaking off its "Wintel" past might not be what it seems. Some say it is Wind River's proprietary VxWorks embedded OS Intel are most interested in, and the acquisition may result in development for all but x86 architectures discontinued. This remains to be seen, and doubtless the encouraging results of Wind River's utilization of open source software technologies, along with customer demand for Linux on mobile platforms, will make Intel think twice before putting its eggs all in one basket.
This move by Intel can also be seen as vindication of the model that other mobile handset software developers are taking, such as the Open Handset Alliance's Android platform. Intel are doubtless attempting to develop an entire mobile platform incorporating it's embedded x86 processors, targeted at the ever-growing mobile market.
Ultimately Intel are sure to take advantage of Wind River's partnerships with open source-based industry alliances and open source-based technologies. The acquisition can be seen as further validation of open source-based models of development and industry collaboration to produce stable and reliable solutions in less time and with greater ease than alternate approaches.
This article is written by Julius Baxter at ORSoC (www.orsoc.se)