OpenCores
Home » All forums » OpenRISC » or1ksim stable_0_1_0
no use no use 1/1 no use no use
or1ksim stable_0_1_0
by Unknown on Feb 11, 2005 		Not available!
Hi all!

The first series of Nog patches are now in cvs and tested. Since there
will be more drastical changes comming I tagged this version of or1ksim with
stable_0_1_0, and also created branch stable_0_1_x that will be used
to track any bugfixes. The HEAD trunk will be used for development and may
not be stable all the time.

The most visible change is 15%-20% faster simulation times:

or1ksim: 11. 02. 2005

Exception 0x00000900 (Data TLB Miss) at 0xc004c978, EA: 0xc1d88110, ppc:
0xc004c978, npc: 0xc004c97c, cycles 2650520152, #109247582
exit(-1042613780)
@reset : cycles 0, insn #0
@exit : cycles 2650534782, insn #109248113
diff : cycles 2650534782, insn #109248113

real 4m56.850s
user 4m13.323s
sys 0m5.595s

or1ksim: 24. 12. 2004

Exception 0x900 (Data TLB Miss) at 0xc004c978, EA: 0xc1d88110, ppc:
0xc004c978, npc: 0xc004c97c, cycles 2650520152, #109247582
exit(-1042613780)
@reset : cycles 0, insn #0
@exit : cycles 2650534782, insn #109248113
diff : cycles 2650534782, insn #109248113

real 5m51.364s
user 5m7.375s
sys 0m5.301s


Nog i looked at your patches and you may commit all of the
peripheral cleanups.

Regarding FAST_SIM i'd really be interested in some numbers. Does it
really speed up execution by some meaningful margin (As far as i know
faster simulation time is the only it exists) ? If it's
negligable i'm all for throwing that one out.

best regards,
p.
or1ksim stable_0_1_0
by Unknown on Feb 11, 2005 		Not available!
The first series of Nog patches are now in cvs and tested. Since there
will be more drastical changes comming I tagged this version of or1ksim with
stable_0_1_0, and also created branch stable_0_1_x that will be used
to track any bugfixes. The HEAD trunk will be used for development and may
not be stable all the time.


Umm, what happened to updateing the configure script and Makefile.ins? (CVS
doesn't exactly build out-of-the-box like this...)

Nog i looked at your patches and you may commit all of the
peripheral cleanups.


I'm on it.

Regarding FAST_SIM i'd really be interested in some numbers. Does it
really speed up execution by some meaningful margin (As far as i know
faster simulation time is the only it exists) ? If it's
negligable i'm all for throwing that one out.


If I can get a working simulator with --enable-fsim, I'll do some benchmarks.
If we actually want to keep FAST_SIM, then we'll need to rethink the peripheral
cleanups. FAST_SIM is based on the assumption that all the configuration is
static and the compiler will remove always true or always false conditions.
With the peripheral cleanups however, everything became dynamic...

nog.

or1ksim stable_0_1_0
by Unknown on Feb 11, 2005 		Not available!
* György 'nog' Jeney (nog@sdf.lonestar.org) wrote:
> The first series of Nog patches are now in cvs and tested. Since there
> will be more drastical changes comming I tagged this version of or1ksim with
> stable_0_1_0, and also created branch stable_0_1_x that will be used
> to track any bugfixes. The HEAD trunk will be used for development and may
> not be stable all the time.


Umm, what happened to updateing the configure script and Makefile.ins? (CVS
doesn't exactly build out-of-the-box like this...)


i'm still waiting on opencores admin. i'll let him
update the configure script, Makefile.ins,... and commit it to
both branches.

regards,
p.


or1ksim stable_0_1_0
by Unknown on Feb 14, 2005 		Not available!
> Regarding FAST_SIM i'd really be interested in some numbers. Does it
> really speed up execution by some meaningful margin (As far as i know
> faster simulation time is the only it exists) ? If it's
> negligable i'm all for throwing that one out.


If I can get a working simulator with --enable-fsim, I'll do some benchmarks.
If we actually want to keep FAST_SIM, then we'll need to rethink the peripheral
cleanups. FAST_SIM is based on the assumption that all the configuration is
static and the compiler will remove always true or always false conditions.
With the peripheral cleanups however, everything became dynamic...
I've done some benchmarks. The results are surpising to such an extent that I'm sure I'm doing something wrong. I am useing stock cvs. I have attached a copy of fast_config.c which has been generated from the attached sim.cfg (sim --output-cfg). I have also attached my `hack' to linux to prevent it from recalibrating its delay loop (just to make it boot faster). +-----+-------------------------+----------------------------+ | Run | Real with --enable-fsim | Real without --enable-fsim | +-----+-------------------------+----------------------------+ | 1 | 3m35.566s | 2m55.641s | | 2 | 3m24.519s | 3m8.849s | | 3 | 2m45.621s | 3m32.061s | | 4 | 3m34.219s | 3m33.546s | +-----+-------------------------+----------------------------+ I have pasted the output of the time commands below. Run 1: with --enable-fsim: real 3m35.566s user 2m47.960s sys 0m5.630s without --enable-fsim: real 2m55.641s user 2m40.160s sys 0m3.160s Run 2: with --enable-fsim: real 3m24.519s user 2m45.460s sys 0m6.290s without --enable-fsim: real 3m8.849s user 2m41.890s sys 0m7.940s Run 3: with --enable-fsim: real 2m45.621s user 2m39.440s sys 0m3.730s without --enable-fsim: real 3m32.061s user 2m46.800s sys 0m3.580s Run 4: with --enable-fsim: real 3m34.219s user 2m49.140s sys 0m3.160s without --enable-fsim: real 3m33.546s user 2m47.300s sys 0m4.750s nog. -------------- next part -------------- /* This file was automatically generated by or1ksim, using --output-cfg switch (cfg file 'sim.cfg'). */ const static struct config config = { tick:{enabled:0}, nuarts:1, uarts:{ {channel:"tcp:10000", jitter:-1, baseaddr:0x90000000, irq:2, vapi_id:0x00000000, uart16550:1}}, ndmas:1, dmas:{ {baseaddr:0x9a000000, irq:11, vapi_id:0x00000000}}, nethernets:1, ethernets:{ {baseaddr:0x92000000, irq:0, dma:0, rtx_type:1, tx_channel:0x00000000, rx_channel:0x00000001, rxfile:"eth0.rx", txfile:"eth0.tx", sockif:"eth0", base_vapi_id:0x00000000}}, ngpios:0, gpios:{}, mc:{enabled:1, baseaddr:0x93000000, POC:8}, memory:{pattern:0, random_seed:-1, type:MT_UNKNOWN, nmemories:3, table:{ {ce:0, baseaddr:0xf0000000, size:0x00800000, name:"FLASH", log:"", delayr:1, delayw:-1}, {ce:1, baseaddr:0x00000000, size:0x02000000, name:"RAM", log:"", delayr:1, delayw:2}, {ce:2, baseaddr:0x08000000, size:0x00400000, name:"SRAM", log:"", delayr:1, delayw:2}}}, immu:{enabled:1, nways:1, nsets:64, pagesize:8192, entrysize:0, ustates:0, missdelay:1, hitdelay:1}, dmmu:{enabled:1, nways:1, nsets:64, pagesize:8192, entrysize:0, ustates:0, missdelay:1, hitdelay:1}, ic:{enabled:1, nways:1, nsets:512, blocksize:16, ustates:0, missdelay:1, hitdelay:1}, dc:{enabled:1, nways:1, nsets:512, blocksize:16, ustates:0, load_missdelay:2, load_hitdelay:2, store_missdelay:0, store_hitdelay:0}, bpb:{enabled:0, sbp_bnf_fwd:0, sbp_bf_fwd:0, btic:0, missdelay:0, hitdelay:0}, cpu:{upr:0x0000e83f, ver:0x1200, rev:0x0001, superscalar:0, hazards:0, dependstats:0, sr:0x00008001}, sim:{debug:1, verbose:1, profile:0, prof_fn:"sim.profile", mprofile:0, mprof_fn:"sim.mprofile", history:0, exe_log:0, exe_log_fn:"executed.log", clkcycle_ps:4000, spr_log:0, spr_log_fn:"spr.log"}, debug:{enabled:0, gdb_enabled:0, server_port:0, vapi_id:0x00000000}, vapi:{enabled:0, server_port:9998, log_enabled:0, hide_device_id:0, vapi_fn:"vapi.log"}, pm:{enabled:0} }; -------------- next part -------------- /* sim.cfg -- Simulator configuration script file Copyright (C) 2001, Marko Mlinar, markom@opencores.org This file includes a lot of help about configurations and default one This file is part of OpenRISC 1000 Architectural Simulator. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ /* INTRODUCTION The or1ksim have various parameters, which can be set in configuration files. Multiple configurations may be used and switched between at or1ksim startup. By default, or1ksim loads condfiguration file from './sim.cfg' and if not found it checks '~/.or1k/sim.cfg'. If even this file is not found or all parameters are not defined, default configuration is used. Users should not rely on default configuration, but rather redefine all critical settings, since default configuration may differ in newer versions of the or1ksim. If multiple configurations are used, user can switch between them by supplying -f option when starting simulator. This file may contain (standard C) only comments - no // support. Like normal configuration file, this file is divided in sections, where each section is described in detail also. Some section also have subsections. One example of such subsection is block: device instance specific parameters... enddevice which creates a device instance. */ /* MEMORY SECTION This section specifies how is initial memory generated and which blocks it consist of. type = random/unknown/pattern specifies the initial memory values. 'random' parameter generate random memory using seed 'random_seed' parameter. 'pattern' parameter fills memory with 'pattern' parameter and 'unknown' does not specify how memory should be generated - the fastest option. random_seed = random seed for randomizer, used if type = random pattern = pattern to fill memory, used if type = pattern nmemories = number of memory instances connected instance specific: baseaddr = memory start address size = memory size name = "" memory block name ce = chip enable index of the memory instance delayr = cycles, required for read access, -1 if instance does not support reading delayw = cycles, required for write access, -1 if instance does not support writing 16550 = 0/1 0, if this device is uart 16450 and 1, if it is 16550 log = "" filename, where to log memory accesses to, no log, if log command is not specified */ section memory /*random_seed = 12345 type = random*/ pattern = 0x00 type = unknown /* Fastest */ nmemories = 3 device 0 name = "FLASH" ce = 0 baseaddr = 0xf0000000 size = 0x00800000 delayr = 1 delayw = -1 /* log = "flash.log"*/ enddevice device 1 name = "RAM" ce = 1 baseaddr = 0x00000000 size = 0x02000000 /* size = 0x00800000 */ delayr = 1 delayw = 2 /* log = "ram.log"*/ enddevice device 2 name = "SRAM" ce = 2 baseaddr = 0x08000000 size = 0x00400000 delayr = 1 delayw = 2 /* log = "ram.log"*/ enddevice end /* IMMU SECTION This section configures Instruction Memory Menangement Unit enabled = 0/1 whether IMMU is enabled (NOTE: UPR bit is set) nsets = number of ITLB sets; must be power of two nways = number of ITLB ways pagesize = instruction page size; must be power of two entrysize = instruction entry size in bytes ustates = number of ITLB usage states (2, 3, 4 etc., max is 4) */ section immu enabled = 1 nsets = 64 nways = 1 pagesize = 8192 end /* DMMU SECTION This section configures Data Memory Menangement Unit enabled = 0/1 whether DMMU is enabled (NOTE: UPR bit is set) nsets = number of DTLB sets; must be power of two nways = number of DTLB ways pagesize = data page size; must be power of two entrysize = data entry size in bytes ustates = number of DTLB usage states (2, 3, 4 etc., max is 4) */ section dmmu enabled = 1 nsets = 64 nways = 1 pagesize = 8192 end /* IC SECTION This section configures Instruction Cache enabled = 0/1 whether IC is enabled (NOTE: UPR bit is set) nsets = number of IC sets; must be power of two nways = number of IC ways blocksize = IC block size in bytes; must be power of two ustates = number of IC usage states (2, 3, 4 etc., max is 4) */ section ic enabled = 1 nsets = 512 nways = 1 blocksize = 16 end /* DC SECTION This section configures Data Cache enabled = 0/1 whether DC is enabled (NOTE: UPR bit is set) nsets = number of DC sets; must be power of two nways = number of DC ways blocksize = DC block size in bytes; must be power of two ustates = number of DC usage states (2, 3, 4 etc., max is 4) */ section dc enabled = 1 nsets = 512 nways = 1 blocksize = 16 end /* SIM SECTION This section specifies how should sim behave. verbose = 0/1 whether to print out extra messages debug = 0-9 = 0 disabled debug messages 1-9 level of sim debug information, greater the number more verbose is the output profile = 0/1 whether to generate profiling file 'sim.profile' prof_fn = "" filename, where to generate profiling info, used only if 'profile' is set history = 0/1 whether instruction execution flow is tracked for display by simulator hist command. Useful for back-trace debugging. iprompt = 0/1 whether we strart in interactive prompt exe_log = 0/1 whether execution log should be generated exe_log_fn = "" where to put execution log in, used only if 'exe_log' is set clkcycle = [ps|ns|us|ms] specifies time measurement for one cycle */ section sim verbose = 1 debug = 2 profile = 0 prof_fn = "sim.profile" history = 0 /* iprompt = 0 */ exe_log = 0 exe_log_type = software exe_log_start = 0/*48400000/*17600000*/ exe_log_end = 36800000 exe_log_marker = 50 exe_log_fn = "executed-1.log" end /* SECTION VAPI This section configures Verification API, used for Advanced Core Verification. enabled = 0/1 whether to start VAPI server server_port = TCP/IP port to start VAPI server on log_enabled = 0/1 whether logging of VAPI requests is enabled vapi_fn = specifies filename where to log into, if log_enabled is selected */ section VAPI enabled = 0 server_port = 9998 log_enabled = 0 vapi_log_fn = "vapi.log" end /* CPU SECTION This section specifies various CPU parameters. ver = rev = specifies version and revision of the CPU used upr = changes the upr register superscalar = 0/1 whether CPU is scalar or superscalar (modify cpu/or32/execute.c to tune superscalar model) hazards = 0/1 whether data hazards are tracked in superscalar CPU and displayed by the simulator r command dependstats = 0/1 whether inter-instruction dependencies are calculated and displayed by simulator stats command. parameters for CPU analysis */ section cpu ver = 0x1200 rev = 0x0001 superscalar = 0 hazards = 0 dependstats = 0 end /* DEBUG SECTION This sections specifies how debug unit should behave. enabled = 0/1 whether debug unit is enabled gdb_enabled = 0/1 whether to start gdb server at 'server_port' port server_port = TCP/IP port to start gdb server on, used only if gdb_enabled is set section debug enabled = 0 gdb_enabled = 0 server_port = 9999 end /* MC SECTION This section configures the memory controller enabled = 0/1 whether memory controller is enabled baseaddr = address of first MC register POC = Power On Configuration register */ section mc enabled = 1 baseaddr = 0x93000000 POC = 0x00000008 /* Power on configuration register */ end /* UART SECTION This section configures UARTs nuarts = make specified number of instances, configure each instance within device - enddevice construct. instance specific: baseaddr = address of first UART register for this device rx_file = "" filename, where to read data from tx_file = "" filename, where to write data to irq = irq number for this device 16550 = 0/1 0, if this device is uart 16450 and 1, if it is 16550 jitter = in msecs... time to block, -1 to disable it vapi_id = VAPI id of this instance */ section uart nuarts = 1 device 0 baseaddr = 0x90000000 irq = 2 channel = "tcp:10000" /*channel = "file:uart0.rx,uart0.tx"*/ jitter = -1 /* async behaviour */ 16550 = 1 enddevice end /* DMA SECTION This section configures DMAs ndmas = make specified number of instances, configure each instance within device - enddevice construct. instance specific: baseaddr = address of first DMA register for this device irq = irq number for this device vapi_id = VAPI id of this instance */ section dma ndmas = 1 device 0 baseaddr = 0x9a000000 irq = 11 enddevice end /* ETHERNET SECTION This section configures ethernets enabled = 0/0 whether ethernets are enabled nethernets = make specified number of instances, configure each instance within device - enddevice construct. instance specific: baseaddr = address of first ethernet register for this device dma = which controller is this ethernet "connected" to rtx_type = 0 ETH_RTX_FILE 1 ETH_RTX_SOCK rx_channel = DMA channel used for RX tx_channel = DMA channel used for TX rx_file = "" filename, where to read data from tx_file = "" filename, where to write data to vapi_id = VAPI id of this instance */ section ethernet enabled = 1 nethernets = 1 device 0 baseaddr = 0x92000000 dma = 0 irq = 4 rtx_type = 1 tx_channel = 0 rx_channel = 1 rxfile = "eth0.rx" txfile = "eth0.tx" sockif = "eth1" enddevice end /* section fb baseaddr = 0x97000000 refresh_rate = 10000000 filename = "primary" end */ /* KBD SECTION This section configures PS/2 compatible keyboard enabled = 0/1 whether keyboard is enabled baseaddr = base address of the keyboard device rxfile = "" filename, where to read data from */ /* section kbd irq = 5 baseaddr = 0x94000000 rxfile = "kbd.rx" end */ section ata natas = 1 device 0 baseaddr = 0x9e000000 irq = 15 dev_type0 = 1 dev_file0 = "drv" dev_size0 = 5 dev_packet0 = 0 dev_type1 = 0 dev_file1 = "" dev_size1 = 0 dev_packet1 = 0 enddevice end -------------- next part -------------- --- init/main.c 2004-04-15 03:37:03.000000000 +0200 +++ /home/nog/linux-2.4/init/main.c 2005-02-14 15:15:44.000000000 +0100 @@ -164,12 +164,15 @@ void __init calibrate_delay(void) { +/* unsigned long ticks, loopbit; int lps_precision = LPS_PREC; loops_per_jiffy = (1
or1ksim stable_0_1_0
by Unknown on Feb 16, 2005 		Not available!
* György 'nog' Jeney (nog@sdf.lonestar.org) wrote:
> Regarding FAST_SIM i'd really be interested in some numbers. Does it
> really speed up execution by some meaningful margin (As far as i know
> faster simulation time is the only it exists) ? If it's
> negligable i'm all for throwing that one out.

>
> If I can get a working simulator with --enable-fsim, I'll do some benchmarks.
> If we actually want to keep FAST_SIM, then we'll need to rethink the peripheral
> cleanups. FAST_SIM is based on the assumption that all the configuration is
> static and the compiler will remove always true or always false conditions.
> With the peripheral cleanups however, everything became dynamic...


I've done some benchmarks. The results are surpising to such an extent that I'm
sure I'm doing something wrong. I am useing stock cvs. I have attached a copy
of fast_config.c which has been generated from the attached sim.cfg (sim
--output-cfg). I have also attached my `hack' to linux to prevent it from
recalibrating its delay loop (just to make it boot faster).

+-----+-------------------------+----------------------------+
| Run | Real with --enable-fsim | Real without --enable-fsim |
+-----+-------------------------+----------------------------+
| 1 | 3m35.566s | 2m55.641s |
| 2 | 3m24.519s | 3m8.849s |
| 3 | 2m45.621s | 3m32.061s |
| 4 | 3m34.219s | 3m33.546s |
+-----+-------------------------+----------------------------+

I have pasted the output of the time commands below.

So you're saying that --enable-fsim is actually --enable-slowsim ;)...
(for all but one misterious case)...

Just to make sure, are you running this on otherwise idle machine ? Do you
have any daemon that renices processes hard on cpu or similar ?

Please give me a few days to confirm this (or anybody else if you want
to help) and if it turns out our results are consistent it's bye-bye
"FAST_SIM"... Agreed ?

best regards,
p.


or1ksim stable_0_1_0
by Unknown on Feb 16, 2005 		Not available!
Just to make sure, are you running this on otherwise idle machine ?


Yep, the machine was otherwise idle.

Do you have any daemon that renices processes hard on cpu or similar ?


Nope, nothing of this sort.

Just to be absolutely sure that nothing is running, I rebooted into runlevel 1
and ran the bechmarks again. The times are more eaven, but --enable-fsim still
shows a minor slowdown. I still don't understand why that is...

+-----+-------------------------+----------------------------+
| Run | Real with --enable-fsim | Real without --enable-fsim |
+-----+-------------------------+----------------------------+
| 1 | 2m42.967s | 2m42.081s |
| 2 | 2m42.965s | 2m42.026s |
+-----+-------------------------+----------------------------+

Again, the raw data appears below:

Without --enable-fsim:
real 2m42.081s
user 2m33.980s
sys 0m7.980s

real 2m42.026s
user 2m34.860s
sys 0m7.170s

With --enable-fsim:
real 2m42.967s
user 2m35.380s
sys 0m7.580s

real 2m42.965s
user 2m35.540s
sys 0m7.420s

nog.

or1ksim stable_0_1_0
by Unknown on Feb 16, 2005 		Not available!
+-----+-------------------------+----------------------------+
| Run | Real with --enable-fsim | Real without --enable-fsim |
+-----+-------------------------+----------------------------+
| 1 | 2m42.967s | 2m42.081s |
| 2 | 2m42.965s | 2m42.026s |
+-----+-------------------------+----------------------------+


Now I just kick my feet up and admit that I have no clue as to what's going.
While browsing the cvs commit logs I came across this one (sim-config.h,
revision 1.49): "fsim runs 4 times faster than sim" by markom. If you (Marko)
are kind enough could you maybe give a quick comment to this log entry? What
is the underlying reason that FAST_SIM gives such a performance boost? I don't
understand why I'm not seeing this performance boost. From what I could tell,
the simlulator configuration didn't change all that much since revision 1.49 and
now.

nog.

or1ksim stable_0_1_0
by Unknown on Feb 17, 2005 		Not available!
* György 'nog' Jeney (nog@sdf.lonestar.org) wrote:
> Just to make sure, are you running this on otherwise idle machine ?


Yep, the machine was otherwise idle.

> Do you have any daemon that renices processes hard on cpu or similar ?


Nope, nothing of this sort.

Just to be absolutely sure that nothing is running, I rebooted into runlevel 1
and ran the bechmarks again. The times are more eaven, but --enable-fsim still
shows a minor slowdown. I still don't understand why that is...

+-----+-------------------------+----------------------------+
| Run | Real with --enable-fsim | Real without --enable-fsim |
+-----+-------------------------+----------------------------+
| 1 | 2m42.967s | 2m42.081s |
| 2 | 2m42.965s | 2m42.026s |
+-----+-------------------------+----------------------------+

Again, the raw data appears below:

Without --enable-fsim:
real 2m42.081s
user 2m33.980s
sys 0m7.980s

real 2m42.026s
user 2m34.860s
sys 0m7.170s

With --enable-fsim:
real 2m42.967s
user 2m35.380s
sys 0m7.580s

real 2m42.965s
user 2m35.540s
sys 0m7.420s


My testruns also showed similar results (few secundes faster execution at
~3 min total running time without --enable-fsim).

So go ahead throw it out, i guess nobody uses it anyway. (if you do now is
the time to shout and convince us why we should keep it).

best regards,
p.

PS. Here is one example run...

with --enable-fsim

0xc004c978, npc: 0xc004c97c, cycles 2639603090, #108829136
exit(-1042605588)
@reset : cycles 0, insn #0
@exit : cycles 2639617720, insn #108829667
diff : cycles 2639617720, insn #108829667

real 3m49.526s
user 2m51.581s
sys 0m5.193s

without --enable-fsim

0xc004c978, npc: 0xc004c97c, cycles 2639603090, #108829136
exit(-1042605588)
@reset : cycles 0, insn #0
@exit : cycles 2639617720, insn #108829667
diff : cycles 2639617720, insn #108829667

real 3m47.118s
user 2m51.156s
sys 0m5.121s


no use no use 1/1 no use no use
© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.