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:
- email address
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:
- arithmetic functions such as multiplication.
- 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
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 ( ...
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:
- 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.
- 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
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
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
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