Archive for the ‘ C/C++ ’ Category

ipxact2systemverilog

Registers in an ASIC are described in many different places, for example in:

  • Actual physical registers
  • Block level test benches
  • Top level test benches
  • Block level models
  • System architectural model
  • Software
  • Software help files
  • Block documentation
  • Chip documentation
  • Chip datasheet

The register descriptions in the datasheet many times covers many hundreds of pages. Imagine if the registers are described independently in these +10 places: how many incompatible descriptions of the same thing will there be?

Clearly there is a need to describe the registers once, and generate all the other descriptions or views from the same source. Luckily the the fellows at http://www.accellera.org/activities/committees/ip-xact/ has set an industry standard to describe registers.

I had a little time over and took the opportunity to write a few registers description generators:

https://github.com/oddball/ipxact2systemverilog

The package contain these generators

ipxact2systemverilog
ipxaxct2vhdl
ipxact2rst

Through the reStructuredText (rst) file there are implicitly 2 other generators

ipxact2pdf
ipxact2html

Through .rst files it is also possible to generate .odt or .doc files, but writing documentation in those formats is an engineering sin.

In order to generate UVM or OVM packages, there are other generators available.
One nice tutorial can be found here

http://www.doulos.com/knowhow/sysverilog/ovm/tutorial_rgm_1/

2013
09/26
CATEGORY
ASIC
C/C++
Python
Semiconductor Design
Verilog
VHDL
1 comment

Embed Python for use with HDL

Wanted to show how easy it is to use Python together with Verilog or VHDL. With just a few lines the Python interpreter can be embedded and call tasks or functions in SystemVerilog. I am using the proprietary simulator Questasim in this example.

The SystemVerilog code looks like this

`timescale 1 ns/1 ns
module top;
      import "DPI-C" context task startPython();
      export "DPI-C" task sv_write;

   // Exported SV task.  Can be called by C,SV or Python using c_write
   task sv_write(input int data,address);
      begin
	 $display("sv_write(data = %d, address = %d)",data,address);
      end
   endtask

   initial
     begin
	startPython();
	$display("DONE!!");
     end

endmodule

The C code looks like this

#include
#include "vpi_user.h"
#include "pythonEmbedded.h"

static PyObject * c_write(PyObject *self, PyObject *args) {
  int address,data;
  if(!PyArg_ParseTuple(args, "ii", &data, &address))
    return NULL;
  sv_write(address,data);
  return Py_BuildValue("");
}

static PyMethodDef EmbMethods[] = {
  {"c_write",c_write, METH_VARARGS,"c_write(data,address)"},
  {NULL, NULL, 0, NULL}
};

DPI_DLLESPEC
int startPython(){
    Py_Initialize();
    Py_InitModule("emb", EmbMethods);
    PyRun_SimpleString("import emb\n"
		       "emb.c_write(0,1)\n");
    Py_Finalize();
    return 0;
}

Easiest way to try it out:

git clone http://github.com/oddball/embedPythonInVerilogExample.git
cd embedPythonInVerilogExample
make

Can also view the code online at https://github.com/oddball/embedPythonInVerilogExample

2011
11/03
CATEGORY
ASIC
C/C++
Python
Semiconductor Design
Verilog
VHDL
1 comment

Auto Dependency Makefile Example

Despite having written my fair share of Makefiles, every time I need to start from scratch with a new Makefile, I wonder how it is done. Looking at the last Makefile usually don’t help, since they tend to become quite bloated with time. I also read on Wikipedia that the Makedepend program is now viewed as the last resort. Since I always used it, I wanted to see how else to do it.

There are a lot of “Hello World” examples out there, but I seldom find them complete. There for I made one, mostly for myself. It automatically updates the dependencies from all source files.

So in my example I have a src directory that looks like this:

ls -1 src/
classA.cc
classA.hh
classB.cc
classB.hh
main.cc

The main.cc file has one instance of classA and one of classB. The Makefile requires that there is one main.cc file, but there can be any number of class files.

The Makefile looks like this

DIRS    := src
SOURCES := $(foreach dir, $(DIRS), $(wildcard $(dir)/*.cc))
OBJS    := $(patsubst %.cc, %.o, $(SOURCES))
OBJS    := $(foreach o,$(OBJS),./obj/$(o))
DEPFILES:= $(patsubst %.o, %.P, $(OBJS))

CFLAGS   = -Wall -MMD -c
COMPILER = g++

#link the executable
main: $(OBJS)
        $(COMPILER) $(OBJS) -o main

#generate dependency information and compile
obj/%.o : %.cc
        @mkdir -p $(@D)
        $(COMPILER) $(CFLAGS) -o $@ -MF obj/$*.P $<
        @sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\\$$//' \
             -e '/^$$/ d' -e 's/$$/ :/' < obj/$*.P >> obj/$*.P;

#remove all generated files
clean:
        rm -f main
        rm -rf obj

#include the dependency information
-include $(DEPFILES)

To see how it works, the easiest thing is to do:

git clone http://github.com/oddball/autoDependMakefileExample.git
cd autoDependMakefileExample
make

PS:

When writing Makefiles, this is nice page to have in the background
http://www.gnu.org/s/hello/manual/make/Automatic-Variables.html

When doing automatic dependencies, this is an excellent article. Even if I find it incomplete
http://mad-scientist.net/make/autodep.html

Trying to figure out what the switches to g++ mean?
http://linux.die.net/man/1/g++

At last but not least. If you ever had a feeling that your recursive make does odd things, you should read this aegis.sourceforge.net/auug97.pdf

2011
10/05
CATEGORY
C/C++
2 comments

Recent entry

Archive

Category