OpenCores

OpenCores.org

NEWSLETTER AUGUST 2011

www.orsoc.se

Multiple registration options at OpenCores

We have introduced multiple registration options at OpenCores. This means you can choose either to do a full registration and get all the features or just a minimal one with limitations.

Read more...


Design for portability - generic modeling

The third article covering various aspects of generic modeling.

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 August 2011


Multiple registration options

Before we describe the new registration option, let us first provide some background on why the current registration looks like it does today. We have been active working towards OpenCores since the start and we have met allot of engineers and companies using and wanting to use IPs from OpenCores. The number one common feedback has been that it was hard to see what projects that was "good quality", and that they wanted to know more about "how" and "where" these cores where being used in "real life". Back in the old days there were no registration at all and that the download statistics was not reliable due to scripts that was constantly downloading the same core (improving its own statistics).
Another big problem that we also had was spam, we were getting allot of spam to both the mailing-lists and also to OpenCores user emails.
We added the registration with its current details so that we can produce much better statistics and also provide a better "how" and "where" picture of each project. As you can see today we are presenting detailed statistics using the registration information, which helps allot when you are evaluating and comparing different projects. We have also added the "automatic-feedback" system (presented in an earlier Newletter) in order to try and present the "how" and "where" information of each project. We are currently evaluating the feedback that we receive so that we can see if this system is providing sufficient data, if yes, then we will also add this information to each project.

The new registration option is a "minimized" registration option that requires:
- username
- email address
- city

So why have we added a new registration option?
Running OpenCores for so long has learned us that all people are different, with different options, needs, requirements etc. Our goal has always been to try and support as many as possible. A small group of people have been asked for a minimized registration procedure, so we have therefore now added this to try and please this group of people that are a little bit more sensitive sharing personal information.

So what's the difference between these two registration options?
Users that select the "minimized" registration option will not be able to see the project statistics, which is fair we think, since they are not participting/contributing to it. We are also planning to add a new features, a user rating system. This features will also only be visible for users selecting the "normal" registration option. We truly hope that the majority of people will still continue using the "normal" registration option, and help us improving the statistics and creditability for projects hosted at OpenCores.org

Marcus Erlandsson, ORSoC





Design for portability - generic modeling

Good design praxis should make a design easy to port to a different target technology or to have optional functions for a design covering a large set of use cases. To be able to change target there might be a need to incorporate different modules depending on technology.

Typical functions that might need different implementation includes:
- memories
- arithmetic functions such as multiplication.
- PLL
- Flip-flops with async set and reset.

For a specific function a design could offer the following variants:
- memory controller with different bus interfaces (Wishbone, AMBA, Avalon ...).
- memories with configurable width and size.
- optional cache and MMU support for a processor.

There are basically two different ways of doing this. A design might use a mixture of these two:
1. conditional generate
2. preprocessor

Both VHDL and Verilog have basically the same support for conditional generate. In short it means that we can have conditional code that depending on a parameter (Verilog) or generics (VHDL) are used in the actual instance of the code. With this technique we can tailor the behavior of an instance per instantiation. The same subdesign could be used multiple times within a design with different behavior for each instance.

Pros with conditional generate:
the same code could be instantiated multiple times within a design with different behavior, typical use includes memories with different size.

Cons with conditional generate:
- In Verilog it is not possible to change input or outputs on a module.
- In VHDL it is possible with the use of records but it is somewhat complicated.
- During synthesis we must include source RTL even for things that we will in the end not use. Lets say we compile a design with different memory implementation for Xilinx and Altera. During synthesis we still need to have access to all possible source files.

In Verilog there exist a preprocessor that can modify the code prior to compilation. With this we can remove optional code based on defines. This is similar to the functions found in C. This is applicable to all parts of the code. VHDL do not support this feature. There is however standalone Verilog preprocessors available. One example is vppreproc. Information regarding this tool can be found at http://www.veripool.org/wiki/verilog-perl. Since this is a standalone tool it works both for Verilog and VHDL. Usage of a preprocessor will give you one common RTL that can be run through a preprocessor with different defines and will give you a design for a particular use case.

Pros with preprocessing:
- the parts of the code that we will not use in a actual use case are removed from the source support conditional input and output signals in modules/entities.

Cons with preprocessing:
- usage of include directories can cause confusion.
- naming of modules are normally not unique, more on this below.

Module naming can be a problem when using a preprocessor to generate modules with different behavior from a common RTL source. In one design we can not have two instances with the same name but with different behavior. There is a way around this problem.

In your design you should have a define that sets the base name of the implementation
`define BASE variantA_
For each module in the generic design set the module names according to this scheme
`define MODULE top
module `BASE`MODULE ( ...
`undef MODULE

To have this generic design included multiple times in a design can be done by generating each module with the preprocessor with different input signals. First instance will be generated with BASE set to VariantA_ and second instance with BASE set to VariantB_.
The preprocessor will set the individual names to VariantA_top respectively VariantB_top.
This works for both Verilog and VHDL

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:

  • Added a "subscribe" option for getting access to Bugzilla. This option is controlled via the "my account" page.
  • Ongoing work in order to upgrade our spamfilters.

Server information:

  • Restructured the intranet configuration.
  • The website was down for a while due to a problem located at our Internet-provider, caused by thunder storm.

Our message to the community:

  • Please join the OpenRISC-ASIC donation project
  • Marcus Erlandsson, ORSoC





    New IP-cores

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

    DDR2 SDRAM Controller
    This project implements a DDR2-SDRAM Controller on a Xilinx Spartan-3A Board
    Development status: Stable
    License: LGPL
    Updates:
    Aug 20, 2011: Project Infos updated
    Aug 20, 2011: Project started (Version 7.0)

    Multiple Switch Debouncer in VHDL
    This block is a general-purpose multiple input de-bouncing circuit.
    It handles multiple inputs, like mechanical switch inputs, and outputs a de-bounced, stable registered version of the inputs.
    A 'new_data' one-cycle strobe is also available, to sync downstream logic.
    The core is tested and is being used in FPGA hardware in several projects.
    Development status: Stable
    License: LGPL
    Updates:
    Aug 19, 2011: Updated project page HTML
    Aug 19, 2011: Updated links section
    Aug 16, 2011: Updated scope photos and verification details.
    Aug 12, 2011: Updated verification oscilloscope screenshots.
    Aug 11, 2011: Updated description.
    Aug 11, 2011: Updated description and scope photos.
    Aug 11, 2011: Updated SVN files with complete ISE13.1 project for testing on FPGA hardware. Updated project description.
    Aug 11, 2011: Updated description
    Aug 10, 2011: Updated project description
    Aug 10, 2011: Updated description
    Aug 10, 2011: SVN files uploaded. The project contains only the VHDL file for the debouncer. Testbench, hardware verification and documentation will be added later.
    Aug 10, 2011: updated description
    Aug 10, 2011: Updated description
    Aug 10, 2011: Updated description and SVN files


    Johan Rilegård, ORSoC


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