System Design and Verification - All Comments

While ARM Holding is ...

Anonymous — Fri, 20 Nov 2009 10:44:04 GMT

While ARM Holding is going up and Intel Corporation is moving down, I therefore have no dought who will end up being a clear winner in the race to become no.1 micro chip producer in the years to come.

ARM with it ARM7 and ARM9 processor can easily take on Intel Atom for many reasons, firstly ARM7 and ARM9 consume less power and have longer standby times the Intel Atom processor. Secondly the ARM7 and ARM9 is much smaller in size then the Intel Atom, this will reduce cost for hardware vendors.

source:

www.payasyougomobilephones.mobi

I bow before you in ...

Anonymous — Tue, 03 Nov 2009 14:42:40 GMT

I bow before you in acknowledging my errors. I had searched the Cadence site for announcements, and listed all of the ones that I had found there, plus a web search, but I have to admit though that in the back of my mind I thought there were more.

I will see that the article is updated to include the ones that I missed.

Pablo, Thanks f ...

jasona — Fri, 23 Oct 2009 02:28:19 GMT

Pablo,

Thanks for reading.

If you have CodeSourcery 2009-q1 you need to supply correct the link map:

% arm-none-eabi-gcc -o hello hello.c -T your codesourcery install/arm-none-eabi/lib/generic-hosted.ld

With no link map I found undefined symbols.

If you use some other link map I found qemu-arm crashes also.

This should make your qemu-arm run correctly, it works for me.

I'm not sure why you get a permission on mmap, I haven't seen this. Seems like something security related on your machine.

qemu-arm is just a model of a CPU and memory so it can only run simple executables, qemu-system-arm models a more complete system and can boot an operating system, etc. qemu-system-arm can run simple executables also. You can run the hello program using

% qemu-system-arm -kernel hello -semihosting -nographic

Good luck.

Jason

How did you manage t ...

Anonymous — Thu, 22 Oct 2009 00:27:27 GMT

How did you manage to make CodeSourcery map the program to the correct memory region?

I get a segmentation fault whenever I run qemu-arm hello

Here are the details of my build:

$ arm-none-eabi-gcc -v

Using built-in specs.

Target: arm-none-eabi

Configured with: /scratch/maxim/arm-lite/src-4.3-arm-none-eabi-lite/gcc-4.3/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-shared --with-newlib --with-pkgversion='Sourcery G++ Lite 2009q1-161' --with-bugurl=support.codesourcery.com/GNUToolchain --disable-nls --prefix=/opt/codesourcery --with-headers=yes --with-sysroot=/opt/codesourcery/arm-none-eabi --with-build-sysroot=/scratch/maxim/arm-lite/install-4.3-arm-none-eabi-lite/arm-none-eabi --with-gmp=/scratch/maxim/arm-lite/obj-4.3-arm-none-eabi-lite/host-libs-2009q1-161-arm-none-eabi-i686-pc-linux-gnu/usr --with-mpfr=/scratch/maxim/arm-lite/obj-4.3-arm-none-eabi-lite/host-libs-2009q1-161-arm-none-eabi-i686-pc-linux-gnu/usr --disable-libgomp --enable-poison-system-directories --with-build-time-tools=/scratch/maxim/arm-lite/install-4.3-arm-none-eabi-lite/arm-none-eabi/bin --with-build-time-tools=/scratch/maxim/arm-lite/install-4.3-arm-none-eabi-lite/arm-none-eabi/bin

Thread model: single

gcc version 4.3.3 (Sourcery G++ Lite 2009q1-161)

$ qemu-arm

By the way, I can only run qemu-arm as root, otherwise, I get the following error message:

mmap: Permission denied

Finally, what is the difference between qemu-arm and qemu-system-arm?

Sorry for the question, but I couldn't find anywhere else. Thanks in advance.

Virtual platforms ca ...

Anonymous — Tue, 20 Oct 2009 03:24:21 GMT

Virtual platforms can be simulated on virtual systems using virtualization.

Say that over and over again ... quickly! :)

There is a link in t ...

Anonymous — Mon, 05 Oct 2009 23:59:21 GMT

There is a link in the blog posting to the videos:

www.systemc.org/.../tlm20tutorial

I am taking course o ...

Anonymous — Mon, 05 Oct 2009 06:39:40 GMT

I am taking course on cadence kindly provide the vedio lecture on cadence

thank you

Hi Jason, I hav ...

vmotel — Fri, 18 Sep 2009 19:24:56 GMT

Hi Jason,

I have read Alicia's poster with great interest (by the way: congratulations to Alicia and Robert for the award !), because my customers of STMicro have adopted a very similar approach, based on linked hierarchical transactions and TxE. We have presented that at CDNLive! EMEA 2009 : "Architectural analysis at transaction level with C++ TxE" (the presentation can be found on the CDNLive! website : go to www.cadence.com/.../proceedingssummary.aspx , enter your Cadence.com login or create one if you don't have any, then go to "VI. System Design & Verification" and open Session SD&V02)

Globally, ST's approach is in line with the "eagle view" considerations, but with a few differences which are highlighted in our presentation:

- transaction come from bus or interface activity, but they can also be used to represent firmware activity or system level synchronization

- as the monitors, and some of the models, are written in SystemC, the SCV api is used for transaction recording instead of direct sdi: ST found it has good advantages

- quantitative analysis is performed on the transactions, to provide metrics for microarchitecture analysis (it is not only debug)

- C++ (Run-Time) TxE is preferred for scalable batch analysis (up to millions of transactions)

Also, I noted at the end of the presentation that Alicia suggests "transaction color coding" as a possible enhancement. It is not widely known, but it is already possible with the tcl scripting commands of TxE ! The command is "set_attribute highlight color_name", after the "accept" command.

I can confirm that indeed, abstract debugging improves productivity. Transactions alone help, links between transactions are fundamental, TxE and coloring help too.

Best regards,

Vincent

It should be noted t ...

Anonymous — Mon, 24 Aug 2009 18:22:25 GMT

It should be noted that Apple's shift to Intel was due to low power (and less heat) for laptop designs, which the PowerPC (nor, likely, Cell) was able to achieve at higher speeds. That would indicate to me that Intel had an edge in its semiconductor technology over IBM and/or Freescale in that face-off (sorry, a hockey term ... ice hockey, to be specific!), architecture aside. It will be interesting to see if process becomes a factor in Intel versus ARM battles for mobile platforms!

Here is a video show ...

Anonymous — Tue, 18 Aug 2009 14:05:41 GMT

Here is a video showing the demo board and the running ISX testbench:

www.youtube.com/watch

Thanks, Jason, for y ...

Anonymous — Fri, 31 Jul 2009 17:28:35 GMT

Thanks, Jason, for your article. I found Mark's comments to be very interesting ... and note that he describes what software engineers could do on one hand, hardware engineers on the other. But what about both of them, together? That points out a need for change in both process and organization.

I'm a former customer of Mentor's Seamless CVE and have used it for creating virtual prototypes. That product has been around for a while, so people have been using it for a while ... if they have the right user profile. It will be interesting to see if necessity will drive more users into such a profile (hw and sw team members working together, or coordinated by a program manager).

Disclaimers: as noted, I was a customer of Seamless CVE. And then I was on that program during my initial period at Mentor Graphics, where I worked until recently. But now, I'm of an open mind! (:

DAC '09 for the Specmaniac

Functional Verification — Wed, 22 Jul 2009 22:13:32 GMT

The following are the "must see" items for Specmaniacs lucky enough to get travel authorization

Specman And The Cadence ESL+TLM News

Functional Verification — Tue, 21 Jul 2009 20:15:05 GMT

Recently our colleagues on Team ESL announced a new TLM-Driven Design and Verification Solution . Team

DAC Virtual Platform Workshop

System Design and Verification — Tue, 30 Jun 2009 15:47:50 GMT

Back in early May, I wrote that it was Not Too Early to Start Thinking About DAC 2009 . Well, now it