Turning to KDE

As I’m trying to finish my current project in VHDL recently, I found that kate is the most handy editor for me. Yes, I know vim is powerful and I did try to use vim, however, I’m not very familiar with it, and it requires some configuration to be done to enable VHDL folding function. So I’m turning to use KDE. The thing is that I always try to make things like email client and IM to work when I change OS or desktop enviroment, KDE is not so user friendly as gnome, so it takes some time to do the configuration.

I’m using KDE 4.7.x latest one 🙂

To get KMail to work:

kmail terminates during startup with “Failed to fetch the resource collection”

To use google calendar:

Accessing Google Calendar from KOrganizer – Occasional Thoughts (This I didn’t do, too troublesome)

alternative is to use davcal:





Using SRAM as FrameBuffer on DE2 115

As I need to use NiosII processor in my project and to run a program on it, so QSys is to be used and SDRAM is used for program code and data. And image captured from the D5M should be displayed through a VGA monitor, so a frame buffer is required to store the image data, and the best choice is to use SDRAM.

It’s a 16bit SRAM on DE2 115 and it requires 24bit to store a 8-8-8 bit RGB pixel data, so solutions:

1. change to use 5-6-5 16bit RGB data, and reduce the time to access SRAM

2. change the custom logic in SRAM controller (in fact, I need to write the SRAM controller all by myself in VHDL), to allow 32bit access (in two cycles).

There’s a problem is that both D5M controller and VGA controller will try to access SRAM, and probably at the same time, so logic needs to be added to resolve conflict. again solutions:

1. implement only one read/write slave port in SRAM controller, and share it between the D5M controller and VGA controller’s master interface. And let the arbitration provided by QSys to resolve the conflict. This is not a good idea as QSys use fairness-based, round-robin to resolve the conflict. However in this case, read request from VGA controller has a limited response time, while write request from D5M controller can wait for a couple of clock cycles.

2. implement two (one read and one write) slave interface in SRAM conflict, and use FIFO to make write request wait for read request. FIFO can use the Megafunction implementation.

Tomorrow I’ll try to implement the second solution.


On Friday, I’ll have an oral test for "Specification and Simulation of Digital Systems", hopefully it will go well this time.


Updates on this part of the project will be post in this post later on.




Today (or Yesterday) I rewrote the SRAM controller using separated Avalon MM read slave interface and write slave interface for D5M controller and VGA controller, However, now the thing is that the content written into the SRAM cell is not exactly what I intend to write, and it seems like a random error stuff.

I’ve already tried to use signal tap II to debug, but it’s not so suitable for this as some clock’s are involved and it requires to recompile the project every time (quiet slow). I’ll try another tool (Signal Probe) later.

Today I’ve got an oral test. Pray the professor not to be harsh. 😉



Oral test went very well. Though it’s just two simple questions, I didn’t know the answer of the very first question asked by the professor, I took a shot and guessed the right answer, 🙂

With another (this) course cleaned up, I’ve more time to do the DE2.115 project. But not today.



Damn It. The timing for Avalon Memory Mapped Read Salve of the SRAM controller was wrong, the content wrote to SRAM is right now, but the result read by VGA controller is not correct as I was using process to implement the logic and synchronized to the CLK signal. Need to re-wrote the SRAM controller again. 😦



Finally the system is finished. SRAM is used in the system as a frame buffer, use one single read/write cycle to read/write a 16bit RGB data from/to SRAM. The problem is that SRAM will not work @100MHz, and either @80MHz. 50MHz is working, and is enough for our project. And SRAM is directly accessed through the custom IP instead of the Avalon Memory Mapped interface, as in this way the read requests from the VGA controller and write requests from D5M camera can be correctly arranged by time.

Back to DE2.115

I need to finish the project on DE2.115 for the course “Electronics for Embedded System” of the very first semester before I go back to China for holidays. So recently, I’ll work on that project for most my free time.

Things are not so easy. Current problem is that the R/G1/G2/B channel for D5M seems to be wrong, as the image shown on VGA monitor is not right in terms of colors. And except for a sample code in verilog from the CD with D5M, I couldn’t find much documents about this. The hardware specification is not so clear either. And I’m working on the part to write grey scale data to SDRAM.

I’ll keep updating my progress in this post. :-|.

SystemC setup on F16 x86_64

SystemC is required by one of the courses I attend this semester. Though I’ve already setup SystemC on my Laptop and Desktop’s Linux, SystemC under windows is not so easy to use, and BTW, I’d like to practice the usage of make and some other Linux development tools, so I decide to setup SystemC(2.2.0) in the virtual machine, newly released F16 x86_64, again.

1. Download the latest SystemC package on the website http://www.systemc.org

2. Unzip the package just downloaded

tar -xvf systemc-2.2.0.tgz

3. follow the file “INSTALL” to do configuration

mkdir objdir

cd objdir

../configure –prefix=/eda/systemc/2.2.0

4. in case of using gcc 4.6.x, there’s something need to be changed in the source code to avoid errors

* open src/sysc/datatypes/bit/sc_bit_proxies.h and search for “mutable” keyword, remove all the “mutable” keyword before a reference member.

* open src/sysc/utils/sc_utils_ids.cpp and following lines after the first include line.

    #include <cstdlib>

    using std::getenv;

    #include <cstring>

    using std::strcmp;

* now, run `gmake`

5. run `gmake install`

6. go to the examples folder, run `gmake check` to compile and run the examples, if everything is okay, output will be like this


7. Now ready to go with SystemC, headers files are in the include folder, library files are in lib-linux64 folder. Better to set an Environment Variable SYSTEMC point to the systemc root folder, so that $(SYSTEMC)/include and $(SYSTEMC)/lib-linux64 are valid systemc folders mentioned above.


SCV setup (Tricky one)

1. download&unzip the package

2. follow the INSTALL file to do configuration, as using x86_64 version, configure will fail as x86_64 is not recognized by the configure script.

* open the config.sub, and around line 883, add





      echo  …..

* and when using systemc, the configure script doesn’t understand the library files in a folder named lib-linux 64, so open configure script and change as

   line 3501


   line 5532


   line 5642

       #include <sstream>

   line 5654

       std::ostringstream outString;

   line 5872(3)


   some other changes due to test C++ code legacy problem. see attached patch file for detailed. for the sake of simplicity, if it’s certain the c++ compile is working properly, replace all the c++ test code in the configure script with  < int main(void) {return 0;} > 

../configure –with-systemc=/eda/systemc/2.2.0

3. change the config.h as in INSTALL

4. run `gmake`

   * to solve compile like “ambiguous operation<< overload in file scv_constraint_range.cpp”, just comment the line 46 in config.h as //#define _USE_UNIT64_WRITE as _GLIBCXX_USE_LONG_LONG in file ostream line 200 is defined as default when compiling which will make the definition of operator<<(unsigned long long __n) available

   * to solve relocation error like “relocation R_X86_64)32 against `a local symbol’ can’t be used when making a shared object” run `gmake –eval=”CXXFLAGS=$CXXFLAGS -fPIC”` instead of `gmake`. This is weird as change in Makefile can’t solve this problem. Need to check this later.

5. Finally `gmake install`


TLM setup

just unzip the package.


Add the RC script to set Environment Variables


something like this.


Okay, everything’s done.

Next step will be coding using SystemC.


patch link 1 : scv configuration files : http://dl.dropbox.com/u/6935052/scv.configure.F16x86_64.patch

patch link 2 : systemc :  http://dl.dropbox.com/u/6935052/systemc-2.2.0_F16x86_64.patch 



if make opt version of the packages (scv), need to change the Makefile mannually to add -fPIC option in the target opt’s make rule.