tag:blogger.com,1999:blog-71499877758614799102024-10-17T21:49:27.037-07:00Anonymoushttp://www.blogger.com/profile/17136443261145576521noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-7149987775861479910.post-4099449643345318552012-05-01T08:27:00.000-07:002012-05-03T08:44:54.918-07:00

As most of you might know that MARSS provides a simple interface to generate periodic dump of selected statistics counters.   You can easily input this periodic stats file into Excel or similar application and generate graphs or process the data according to your requirements.  But many times, due to long simulation runs, the size of this data grows significantly large and most of the

Anonymoushttp://www.blogger.com/profile/17136443261145576521noreply@blogger.com1tag:blogger.com,1999:blog-7149987775861479910.post-39858001729095037202012-03-12T18:17:00.001-07:002012-03-13T15:33:35.323-07:00

One of the most requested feature in MARSS has been fast-forwarding N instructions before starting simulation. Recently we have developed some hooks into QEMU's translation logic to count number of instructions emulated. With this logic we are now able to support fast-forwarding and simpoint in MARSS. Both of these features are available in features branch right now. Fast-Forwarding

Anonymoushttp://www.blogger.com/profile/17136443261145576521noreply@blogger.com1tag:blogger.com,1999:blog-7149987775861479910.post-6571623669644050902012-02-02T10:09:00.000-08:002012-02-02T10:09:21.013-08:00

Recently we have pushed many changes related to bug fixes and code cleanup. Normally I don't blog about releasing bug-fixes patch on any branch but these ones deserve a special post. The first big fix is related to CPU ticks and clock value when simulation is started. When we switch to simulation mode we slow down the cpu ticks and clock based on simulation speed and user configured machine

Anonymoushttp://www.blogger.com/profile/17136443261145576521noreply@blogger.com0tag:blogger.com,1999:blog-7149987775861479910.post-60705563575418196902012-01-03T15:43:00.000-08:002012-01-04T11:18:09.129-08:00

Since we started working on Marss (back in Jan '10) we always wanted to take advantage of multi-core platforms for simulating the same multi-core platforms!! It was so frustrating that if we want to keep cycle-accurate simulations features it doesn't leave us too much room for parallelising execution as we have to wait for every core to execute one cycle. Marss typically runs around 200KIPS

Anonymoushttp://www.blogger.com/profile/17136443261145576521noreply@blogger.com0tag:blogger.com,1999:blog-7149987775861479910.post-3629572853316326462011-12-16T14:22:00.000-08:002011-12-16T14:22:24.551-08:00

Couple of months ago we introduced a new feature 'syncing multiple simulations instances' (available in 'features' branch right now). This feature allows users to run multiple instances of Marss that synchronize at given number of clock ticks. This blog post talks about what was the reason to implement such a feature. Super-Duper fast Server Issue We were running multiple instances of Marss

Anonymoushttp://www.blogger.com/profile/17136443261145576521noreply@blogger.com0tag:blogger.com,1999:blog-7149987775861479910.post-33185755113836362582011-10-04T14:32:00.000-07:002011-10-04T14:32:44.442-07:00

After 0.2 release, now we are focusing on next stage of Marss developments. While working on 0.2, we did pushed couple of branches on github (core-models, newstats, qemu-0.14 etc.) and it made things confusing for lot of users. To make things more standardized I have pushed two new branches 'features' and 'qemu' on github. Features Branch All new features that are not tested extensively will

Anonymoushttp://www.blogger.com/profile/17136443261145576521noreply@blogger.com0tag:blogger.com,1999:blog-7149987775861479910.post-4636921771249125632011-09-27T14:43:00.000-07:002011-10-14T18:17:32.795-07:00

Running deterministic simulations gets too much complicated when you are dealing with more than one processes. In each simulation run you need to make sure that processes are assigned to same CPUs all the time and kernel scheduler does not introduce any randomness. For single process with multiple threads its easy to synchronize them using thread level synchronizations like mutex, barriers etc..

Anonymoushttp://www.blogger.com/profile/17136443261145576521noreply@blogger.com14tag:blogger.com,1999:blog-7149987775861479910.post-87776452236269896062011-08-03T15:21:00.000-07:002011-09-08T09:26:31.073-07:00

Recently I published new disk images that transfers the application core-dump from Simulated OS to Marss. This little feature will help users to: Get notified if the application/benchmark crashes in simulation mode. Use core-dump to find out why and at which location the application crashed. This feature uses linux kernel's '/proc/sys/kernel/core_pattern' interface to invoke custom core-dump

Anonymoushttp://www.blogger.com/profile/17136443261145576521noreply@blogger.com0