What tag version of the RTL should I use that matches the or1k-sim?

[depaulfm]

I used the "Basic Custom OpenRisc System Hardware Tutorial" (from the
or1200 web-site) as a guide to start-up my work. The tagged RTL is
from 1/1/04. The or1ksim-0.2.0rc2 is almost 2 years younger than that
tag.

Why I care? I want to have an RTL simulation working and, to make sure
is correct, I would compare it w/ the output of the arch. simulator.

Is it really safe to use the 1/1/04 version?

Thanks,
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[Jeremy Bennett-4]

The latest stable release of Or1ksim is 0.2.0, which is available as a
single compressed file on the download page. You will find further
patches and guidelines on how to build it in the Embecosm application
note #2 at:

  http://www.embecosm.com/download.html

It represents a work in progress, but little work has been done for 3
years. However it is good enough to run Linux 2.6.19 kernel and the
BusyBox utilities (see the work at Rich D'Addio's Meansoffreedom
website, http://meansoffreedom.com/).

I am working on a small update, which will fix some bugs and also
provide a library version of the interface. That work will be committed
to CVS in the next week or two - once I have it working GDB 6.8.

There are plenty of bugs still to be found. Feel free to post any
discrepancies you find from your comparison, and I'll try to fix them.
Better still feel free to post your own fixes!

HTH,


Jeremy

-  
Tel:      [phone]
Cell:     [phone]
SkypeID: jeremybennett
Email:   jeremy.bennett@...
Web:     www.embecosm.com



-----Original Message-----
From: depaulfm@...
Reply-To: List about OpenRISC project <openrisc@...>
To: openrisc@...
Subject: [openrisc] What tag version of the RTL should I use that
matches the or1k-sim?
Date: Wed, 16 Jul 2008 18:47:14 +0200 (CEST)

I used the "Basic Custom OpenRisc System Hardware Tutorial" (from the
or1200 web-site) as a guide to start-up my work. The tagged RTL is
from 1/1/04. The or1ksim-0.2.0rc2 is almost 2 years younger than that
tag.

Why I care? I want to have an RTL simulation working and, to make sure
is correct, I would compare it w/ the output of the arch. simulator.

Is it really safe to use the 1/1/04 version?

Thanks,
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[depaulfm]

Hi Jeremy,

Let me try to be more specific on my question. What version of the
openrisc is the ork1sim based on?

A clear difference between version 1/1/04 and or1ksim 0.2.0 is that in the
latter there is a memory controler at address 0x93000000 (I looked in the
sim.cfg file), whereas in the RTL there is no memory controller per say --
meaning, I searched for a memory controller unit, or something that
resembles one, the only thing closer to it is the traffic cop.

The problem I'm having in the RTL is at the 5th instr (see below), when
the cpu is supposed to fetch instruction at address 0xf0000118.

To answer to your e-mail: I have downloaded and installed the new
toolchain. I was able to boot linux 2.6.19. No problem here. But, there
seems to be a clear difference between the actual hardware and the arch
simulator. The aim of this e-mail to make sure I am comparing apples w/
apples.

Thank you for your cooperation. And, yes, once I find bugs I will file
them and suggest fixes.


----- output of or1ksim

r3 =00000001                           00000100 l.ori r3,r0,0x1
              r3 =00000001              00000104 l.mtspr r0,r3,0x11
r3 =f0000000                           00000108 l.movhi r3,0xf000
r3 =f0000118 r3 =f0000118              0000010c l.ori r3,r3,0x118
r3 =f0000118                           00000110 l.jr r3

-----------
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[Jeremy Bennett-4]

Hi Flavio,

That is a harder question! I don't know, and I suspect there never was a
1:1 correspondence with any particular version of the RTL. Since the
version number is 0.2.0, I would assume there is still a lot of work to
do.

Certainly the match to the wider SoC (like the Traffic COP in
particular) is not complete. For SoC modeling I would only use the
Or1ksim for the CPU core and model anything else I cared about
separately (that was the motivation behind my SystemC application note).

My feeling is that the core CPU is reasonably accurate. I don't think
something as big as Linux would work if there were serious errors in the
instruction modeling. It is an architectural simulator, so don't expect
perfect cycle counts.

Could you explain the problem example in a bit more detail. Everything
you have included is correct. Is it that the program counter does not
subsequently change to 0xf0000118 (after allowing for the delay cycle)?
I seem to recall a problem where Or1ksim gets things wrong if you write
off the end of a memory block (it wraps the address round, rather than
flagging up an error). Do you have memory at 0xf0000118?

The best approach is to post any problems, and we'll see if we can fix
them. And of course the great thing about open source is that you can
always hack the code yourself.

Hope this helps,


Jeremy

-  
Tel:      [phone]
Cell:     [phone]
SkypeID: jeremybennett
Email:   jeremy.bennett@...
Web:     www.embecosm.com



-----Original Message-----
From: Flavio M. De Paula <depaulfm@...>
To: jeremy.bennett@..., List about OpenRISC project
<openrisc@...>
Subject: Re: [openrisc] What tag version of the RTL should I use that
matches the or1k-sim?
Date: Thu, 17 Jul 2008 12:11:15 -0700 (PDT)

Hi Jeremy,

Let me try to be more specific on my question. What version of the
openrisc is the ork1sim based on?

A clear difference between version 1/1/04 and or1ksim 0.2.0 is that in the
latter there is a memory controler at address 0x93000000 (I looked in the
sim.cfg file), whereas in the RTL there is no memory controller per say --
meaning, I searched for a memory controller unit, or something that
resembles one, the only thing closer to it is the traffic cop.

The problem I'm having in the RTL is at the 5th instr (see below), when
the cpu is supposed to fetch instruction at address 0xf0000118.

To answer to your e-mail: I have downloaded and installed the new
toolchain. I was able to boot linux 2.6.19. No problem here. But, there
seems to be a clear difference between the actual hardware and the arch
simulator. The aim of this e-mail to make sure I am comparing apples w/
apples.

Thank you for your cooperation. And, yes, once I find bugs I will file
them and suggest fixes.


----- output of or1ksim

r3 =00000001                           00000100 l.ori r3,r0,0x1
              r3 =00000001              00000104 l.mtspr r0,r3,0x11
r3 =f0000000                           00000108 l.movhi r3,0xf000
r3 =f0000118 r3 =f0000118              0000010c l.ori r3,r3,0x118
r3 =f0000118                           00000110 l.jr r3

-----------

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[depaulfm]

> My feeling is that the core CPU is reasonably accurate. I don't think
> something as big as Linux would work if there were serious errors in the
> instruction modeling. It is an architectural simulator, so don't expect
> perfect cycle counts.

OK! Let's talk from the CPU point-of-view, instead.

1) When passing an image to the or1ksim, does it load each specific
memory section (described in the sim.cfg) based on the address in the
image, or some address translation happens at this point? Let me
illustrate w/ a simple example:
   - In sim.cfg, the memory section "FLASH" has addressbase= 0xF0000000;
   - If the image has instructions that starts at this address base, will
or1ksim load those instructions into the "FLASH" memory section?
   - If I enable log in the "FLASH" memory section by assigning "log =
flash.log", I should see accesses to location above 0xF0000000, shouldn't
I? Unfortunately, I am not. That is what is leading me to believe there is
some address translation happening before the address gets out of the cpu.


2) The IMM is enabled in the or1ksim by default. I assume some
configuration of the page table, and imm registers need to occur before
using it. I believe you do that by default (within your implementation),
in other words, you don't require the image being loaded to configure the
IMM. Is this true?


Thank you,

PS: I could give you the vmlinux so that you'd see what I'm saying. Just
let me know if you need it.
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[Jeremy Bennett-4]

Hi Flavio,

Your description of FLASH is correct - there is no address translation
on load. However I've never used logging, so I don't know if it works.
Can you single step the simulator, so you can see the successive
changes? That will show immediately if the PC is changing to 0xf0000118.

I'm not aware of any default initialization of either MMU. Linux boot up
has code which sets it up for Linux, so I guess that is what you will
need to do.

Just so you understand, I only started looking at the code for Or1ksim a
few weeks ago, so I could use it in one of my projects. The people who
wrote the original code have not been actively involved in OpenCores for
some time, and I have not discussed the architectural simulator with
them.

I've fixed some bugs and written up what I did, so others can learn from
it. I'm very happy to share what I've learned about Or1ksim, but there's
still a great deal about it which I do not know.

By all means send me the vmlinux (and the Or1ksim command line you used)
and I'll see what happens when I try to run.

HTH,


Jeremy

-  
Tel:      [phone]
Cell:     [phone]
SkypeID: jeremybennett
Email:   jeremy.bennett@...
Web:     www.embecosm.com



-----Original Message-----
From: Flavio M. De Paula <depaulfm@...>
To: jeremy.bennett@..., List about OpenRISC project
<openrisc@...>
Subject: Re: [openrisc] What tag version of the RTL should I use that
matches the or1k-sim?
Date: Fri, 18 Jul 2008 11:35:32 -0700 (PDT)

> My feeling is that the core CPU is reasonably accurate. I don't think
> something as big as Linux would work if there were serious errors in the
> instruction modeling. It is an architectural simulator, so don't expect
> perfect cycle counts.

OK! Let's talk from the CPU point-of-view, instead.

1) When passing an image to the or1ksim, does it load each specific
memory section (described in the sim.cfg) based on the address in the
image, or some address translation happens at this point? Let me
illustrate w/ a simple example:
   - In sim.cfg, the memory section "FLASH" has addressbase= 0xF0000000;
   - If the image has instructions that starts at this address base, will
or1ksim load those instructions into the "FLASH" memory section?
   - If I enable log in the "FLASH" memory section by assigning "log =
flash.log", I should see accesses to location above 0xF0000000, shouldn't
I? Unfortunately, I am not. That is what is leading me to believe there is
some address translation happening before the address gets out of the cpu.


2) The IMM is enabled in the or1ksim by default. I assume some
configuration of the page table, and imm registers need to occur before
using it. I believe you do that by default (within your implementation),
in other words, you don't require the image being loaded to configure the
IMM. Is this true?


Thank you,

PS: I could give you the vmlinux so that you'd see what I'm saying. Just
let me know if you need it.

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[depaulfm]

Hi Jeremy,

I assumed you're original architect/developer of or1ksim. OK, in this
case I will also share whatever I find.

You can download the linux image and the sim.cfg file used from:

www.cs.ubc.ca/~depaulfm/or1ksim_files.tar.bz2

Please, let me know if you have any issue accessing them.

The command I used was pretty straight forward:

or32-uclinux-sim -f sim.cfg vmlinux


> Your description of FLASH is correct - there is no address translation
> on load. However I've never used logging, so I don't know if it works.
> Can you single step the simulator, so you can see the successive
> changes? That will show immediately if the PC is changing to 0xf0000118.

I think the cpu is outputting 0xf0000118. As far as I understand now,
or1ksim is really tied to the 'mc' module (memory controller).
Unless, there is another config option that I need to set up and that I'm
not aware of.
If I disable 'mc' nothing happens -- the executed.log outputs
fetched addresses 0x100 and 0x104 in an endless loop fashion.  I've even
tried simple code to  test this argument.

Please, let me know if this is really true or just some misunderstanding
in my part.

> I'm not aware of any default initialization of either MMU. Linux boot up
> has code which sets it up for Linux, so I guess that is what you will
> need to do.

Rich Daddio suggested me to take a look at the *.ld files. That's the
place where we can set up the final addresses for the relocatable code. But I'm
  a little bit concerned that it won't matter given that it seems or1ksim
needs 'mc' always enabled. I'll see how far I can go...

> I've fixed some bugs and written up what I did, so others can learn from
> it. I'm very happy to share what I've learned about Or1ksim, but there's
> still a great deal about it which I do not know.

Let me know if you want me to try something for you.

Thanks for all the help.
_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc

[Jeremy Bennett-4]

Hi Flavio,

I've run the program and single stepped it. It executes correctly for
me. I ran interactively with the command:

  or32-uclinux-sim -i -f sim.cfg vmlinux

Here is the executed.log file:

r3 =00000001                           00000100 l.ori r3,r0,0x1
             r3 =00000001              00000104 l.mtspr r0,r3,0x11
r3 =f0000000                           00000108 l.movhi r3,0xf000
r3 =f0000118 r3 =f0000118              0000010c l.ori r3,r3,0x118
r3 =f0000118                           00000110 l.jr r3
                                       00000114 l.nop 0
                                       f0000118 l.jal 0x83d
                                       f000011c l.nop 0
r3 =93000000                           f000220c l.movhi r3,0x9300

Here are a few of the step instructions:

(sim) t
0000010c: a8630118  l.ori r3,r3,0x118 (executed) [cycle 40, #4]
00000110: 44001800  l.jr r3 (next insn)
GPR00: 00000000  GPR01: 00000000  GPR02: 00000000  GPR03: f0000118  
GPR04: 00000000  GPR05: 00000000  GPR06: 00000000  GPR07: 00000000  
GPR08: 00000000  GPR09: 00000000  GPR10: 00000000  GPR11: 00000000  
GPR12: 00000000  GPR13: 00000000  GPR14: 00000000  GPR15: 00000000  
GPR16: 00000000  GPR17: 00000000  GPR18: 00000000  GPR19: 00000000  
GPR20: 00000000  GPR21: 00000000  GPR22: 00000000  GPR23: 00000000  
GPR24: 00000000  GPR25: 00000000  GPR26: 00000000  GPR27: 00000000  
GPR28: 00000000  GPR29: 00000000  GPR30: 00000000  GPR31: 00000000
flag: 0
(sim) t
00000110: 44001800  l.jr r3 (executed) [cycle 50, #5]
00000114: 15000000  l.nop 0 (next insn) (delay insn)
GPR00: 00000000  GPR01: 00000000  GPR02: 00000000  GPR03: f0000118  
GPR04: 00000000  GPR05: 00000000  GPR06: 00000000  GPR07: 00000000  
GPR08: 00000000  GPR09: 00000000  GPR10: 00000000  GPR11: 00000000  
GPR12: 00000000  GPR13: 00000000  GPR14: 00000000  GPR15: 00000000  
GPR16: 00000000  GPR17: 00000000  GPR18: 00000000  GPR19: 00000000  
GPR20: 00000000  GPR21: 00000000  GPR22: 00000000  GPR23: 00000000  
GPR24: 00000000  GPR25: 00000000  GPR26: 00000000  GPR27: 00000000  
GPR28: 00000000  GPR29: 00000000  GPR30: 00000000  GPR31: 00000000
flag: 0
(sim) t
00000114: 15000000  l.nop 0 (executed) [cycle 60, #6]
f0000118: 0400083d  l.jal 0x83d (next insn)
GPR00: 00000000  GPR01: 00000000  GPR02: 00000000  GPR03: f0000118  
GPR04: 00000000  GPR05: 00000000  GPR06: 00000000  GPR07: 00000000  
GPR08: 00000000  GPR09: 00000000  GPR10: 00000000  GPR11: 00000000  
GPR12: 00000000  GPR13: 00000000  GPR14: 00000000  GPR15: 00000000  
GPR16: 00000000  GPR17: 00000000  GPR18: 00000000  GPR19: 00000000  
GPR20: 00000000  GPR21: 00000000  GPR22: 00000000  GPR23: 00000000  
GPR24: 00000000  GPR25: 00000000  GPR26: 00000000  GPR27: 00000000  
GPR28: 00000000  GPR29: 00000000  GPR30: 00000000  GPR31: 00000000
flag: 0
(sim) t
f0000118: 0400083d  l.jal 0x83d (executed) [cycle 70, #7]
f000011c: 15000000  l.nop 0 (next insn) (delay insn)
GPR00: 00000000  GPR01: 00000000  GPR02: 00000000  GPR03: f0000118  
GPR04: 00000000  GPR05: 00000000  GPR06: 00000000  GPR07: 00000000  
GPR08: 00000000  GPR09: f0000120  GPR10: 00000000  GPR11: 00000000  
GPR12: 00000000  GPR13: 00000000  GPR14: 00000000  GPR15: 00000000  
GPR16: 00000000  GPR17: 00000000  GPR18: 00000000  GPR19: 00000000  
GPR20: 00000000  GPR21: 00000000  GPR22: 00000000  GPR23: 00000000  
GPR24: 00000000  GPR25: 00000000  GPR26: 00000000  GPR27: 00000000  
GPR28: 00000000  GPR29: 00000000  GPR30: 00000000  GPR31: 00000000
flag: 0

I notice you have the Ethernet configured - my application note builds
Linux without this configured and disables the Ethernet entry in the
config file. This is a material difference to the configuration in my
application note.

I then ran using your command (i.e. not interactively) and Linux booted
fine for me. On my machine (a low end Core 2 Duo) it took about 1 minute
to get from the "Ok, booting the kernel." to the UART being initialized
so other output could appear. Here's the output from the telnet session
connected to port 10084:

-------

[jeremy@thomas ~]$ telnet localhost 10084
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Ok, booting the kernel.
Linux version 2.6.19-or32 (flaviod@xena12) (gcc version 4.2.2) #1 Wed
Jul 16 17:34:42 PDT 2008
Detecting Processor units:
  Signed 0x391
Setting up paging and PTEs.
write protecting ro sections (0xc0002000 - 0xc024e000)
Setting up identical mapping (0x80000000 - 0x90000000)
Setting up identical mapping (0x92000000 - 0x92002000)
Setting up identical mapping (0xb8070000 - 0xb8072000)
Setting up identical mapping (0x97000000 - 0x97002000)
Setting up identical mapping (0x99000000 - 0x9a000000)
Setting up identical mapping (0x93000000 - 0x93002000)
Setting up identical mapping (0xa6000000 - 0xa6100000)
Setting up identical mapping (0x1e50000 - 0x1fa0000)
dtlb_miss_handler c00040c8
itlb_miss_handler c00041a8
Built 1 zonelists.  Total pages: 3953
Kernel command line: root=/dev/ram console=ttyS0
PID hash table entries: 128 (order: 7, 512 bytes)
start_kernel(): bug: interrupts were enabled early
Console: colour dummy device 80x25
Dentry cache hash table entries: 4096 (order: 1, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 0, 8192 bytes)
Memory: 26568k/31744k available (2213k kernel code, 5176k reserved, 252k
data, 112k init, 0k highmem)
Mount-cache hash table entries: 1024
checking if image is initramfs...it isn't (bad gzip magic numbers);
looks like an initrd
Freeing initrd memory: 2048k freed
NET: Registered protocol family 16
NET: Registered protocol family 2
IP route cache hash table entries: 256 (order: -3, 1024 bytes)
TCP established hash table entries: 1024 (order: -1, 4096 bytes)
TCP bind hash table entries: 512 (order: -2, 2048 bytes)
TCP: Hash tables configured (established 1024 bind 512)
TCP reno registered
eth0: Open Ethernet Core Version 1.0
rcu-torture:--- Start of test: nreaders=2 nfakewriters=4 stat_interval=0
verbose=0 test_no_idle_hz=0 shuffle_interval = 5
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 2048 (order 0, 8192 bytes)
Installing knfsd (copyright (C) 1996 okir@...).
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
disabled
serial8250.0: ttyS0 at MMIO 0x90000000 (irq = 2) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 2048KiB [1 disk] into ram disk... done.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 112k freed
init started: BusyBox v1.7.5 (2008-04-26 13:18:58 EDT)
starting pid 22, tty '': '/etc/init.d/rcS'

Please press Enter to activate this console.

-----

There is then a problem with the UART. Here's what happens:

-----

starting pid 24, tty '': '/bin/sh'


BusyBox v1.7.5 (2008-04-26 13:18:58 EDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off
# # stty -echo
serial8250: too much work for irq2
serial8250: too much work for irq2
serial8250: too much work for irq2
serial8250: too much work for irq2
serial8250: too much work for irq2
serial8250: too much work for irq2
serial8250: too much work for irq2
serial8250: too much work for irq2
serial8250: too much work for irq2
serial8250: too much work for irq2

-----

I believe this is due to two bugs in the Linux kernel UART setup and
microsecond timers. The serial driver gets flooded with interrupts. Both
are fixed in the Embecosm patch. Do you have this patch applied?

Interestingly I don't get the problem if I use an xterm rather than
telnet for the UART connection (modified sim.cfg attached).

-----

Please press Enter to activate this console.

starting pid 24, tty '': '/bin/sh'


BusyBox v1.7.5 (2008-04-26 13:18:58 EDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off
# ls
ls
bin      etc      linuxrc  root     tmp      var
dev      home     proc     sbin     usr
# stty -echo
stty -echo
# ls /proc
1              2              bus            iomem          self
10             24             cmdline        ioports        slabinfo
11             27             cpuinfo        kcore          stat
12             3              crypto         kmsg           sys
13             4              devices        loadavg
sysrq-trigger
14             5              diskstats      locks          sysvipc
15             6              driver         meminfo        tty
16             7              execdomains    misc           uptime
17             8              filesystems    mounts         version
18             9              fs             net            vmstat
19             buddyinfo      interrupts     partitions     zoneinfo
#

-----

I don't know why the "/bin/sh: can't access tty; job control turned off"
message appears.

I hope this is useful.


Jeremy

-  
Tel:      [phone]
Cell:     [phone]
SkypeID: jeremybennett
Email:   jeremy.bennett@...
Web:     www.embecosm.com



-----Original Message-----
From: Flavio M. De Paula <depaulfm@...>
To: jeremy.bennett@..., List about OpenRISC project
<openrisc@...>
Subject: Re: [openrisc] What tag version of the RTL should I use that
matches the or1k-sim?
Date: Mon, 21 Jul 2008 20:31:06 -0700 (PDT)

Hi Jeremy,

I assumed you're original architect/developer of or1ksim. OK, in this
case I will also share whatever I find.

You can download the linux image and the sim.cfg file used from:

www.cs.ubc.ca/~depaulfm/or1ksim_files.tar.bz2

Please, let me know if you have any issue accessing them.

The command I used was pretty straight forward:

or32-uclinux-sim -f sim.cfg vmlinux


> Your description of FLASH is correct - there is no address translation
> on load. However I've never used logging, so I don't know if it works.
> Can you single step the simulator, so you can see the successive
> changes? That will show immediately if the PC is changing to 0xf0000118.

I think the cpu is outputting 0xf0000118. As far as I understand now,
or1ksim is really tied to the 'mc' module (memory controller).
Unless, there is another config option that I need to set up and that I'm
not aware of.
If I disable 'mc' nothing happens -- the executed.log outputs
fetched addresses 0x100 and 0x104 in an endless loop fashion.  I've even
tried simple code to  test this argument.

Please, let me know if this is really true or just some misunderstanding
in my part.

> I'm not aware of any default initialization of either MMU. Linux boot up
> has code which sets it up for Linux, so I guess that is what you will
> need to do.

Rich Daddio suggested me to take a look at the *.ld files. That's the
place where we can set up the final addresses for the relocatable code. But I'm
  a little bit concerned that it won't matter given that it seems or1ksim
needs 'mc' always enabled. I'll see how far I can go...

> I've fixed some bugs and written up what I did, so others can learn from
> it. I'm very happy to share what I've learned about Or1ksim, but there's
> still a great deal about it which I do not know.

Let me know if you want me to try something for you.

Thanks for all the help.

[sim-jpb.cfg]

---

/* sim.cfg -- Simulator configuration script file
   Copyright (C) 2001-2002, Marko Mlinar, markom@...

This file is part of OpenRISC 1000 Architectural Simulator.
It contains the default configuration and help about configuring
the 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 ork1sim has various parameters, that are set in configuration files
   like this one. The user can switch between configurations at startup by
   specifying the required configuration file with the -f <filename.cfg> option.
   If no configuration file is specified or1ksim searches for the default
   configuration file sim.cfg. First it searches for './sim.cfg'. If this
   file is not found, it searches for '~/or1k/sim.cfg'. If this file is
   not found too, it reverts to the built-in default configuration.
   
   NOTE: Users should not rely on the built-in configuration, since the
         default configuration may differ between version.
         Rather create a configuration file that sets all critical values.

   This file may contain (standard C) comments only - no // support.
   
   Configure files may be be included, using:
   include "file_name_to_include"

   Like normal configuration files, the included file is divided into
   sections. Each section is described in detail also.

   Some section have subsections. One example of such a subsection is:

   device <index>
     instance specific parameters...
   enddevice

   which creates a device instance.
*/


/* MEMORY SECTION

   This section specifies how the memory is generated and the blocks
   it consists of.

   type = random/unknown/pattern
      Specifies the initial memory values.
      'random' generates random memory using seed 'random_seed'.
      'pattern' fills memory with 'pattern'.
      'unknown' does not specify how memory should be generated,
      leaving the memory in a undefined state. This is the fastest
      option.

   random_seed = <value>
      random seed for randomizer, used if type = 'random'.

   pattern = <value>
      pattern to fill memory, used if type = 'pattern'.

   nmemories = <value>
      number of memory instances connected

   baseaddr = <hex_value>
      memory start address

   size = <hex_value>
      memory size

   name = "<string>"
      memory block name

   ce = <value>
      chip enable index of the memory instance

   mc = <value>
      memory controller this memory is connected to

   delayr = <value>
      cycles, required for read access, -1 if instance does not support reading

   delayw = <value>
      cycles, required for write access, -1 if instance does not support writing

   log = "<filename>"
      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 */
  log = "flash.log"
  name = "FLASH"
  ce = 0
  mc = 0
  baseaddr = 0xf0000000
  size = 0x01000000
  delayr = 10
  delayw = -1
end

section memory
  /*random_seed = 12345
  type = random*/
  pattern = 0x00
  type = unknown /* Fastest */
  log = "ram.log"

  name = "RAM"
  ce = 1
  mc = 0
  baseaddr = 0x00000000
  size = 0x02000000
  delayr = 20
  delayw = 25
end

section memory
  /*random_seed = 12345
  type = random*/
  pattern = 0x00
  type = unknown /* Fastest */

  name = "SRAM"
  mc = 0
  ce = 2
  baseaddr = 0xa4000000
  size = 0x00100000
  delayr = 1
  delayw = 2
end


/* IMMU SECTION

    This section configures the Instruction Memory Manangement Unit

    enabled = 0/1
       '0': disabled
       '1': enabled
       (NOTE: UPR bit is set)

    nsets = <value>
       number of ITLB sets; must be power of two

    nways = <value>
       number of ITLB ways

    pagesize = <value>
       instruction page size; must be power of two

    entrysize = <value>
       instruction entry size in bytes

    ustates = <value>
       number of ITLB usage states (2, 3, 4 etc., max is 4)
       
    hitdelay = <value>
       number of cycles immu hit costs
   
    missdelay = <value>
       number of cycles immu miss costs
*/

section immu
  bus = "or1k_spr:0.0"
  enabled = 1
  nsets = 64
  nways = 1
  pagesize = 8192
  hitdelay = 0
  missdelay = 0
end


/* DMMU SECTION

    This section configures the Data Memory Manangement Unit

    enabled = 0/1
       '0': disabled
       '1': enabled
       (NOTE: UPR bit is set)

    nsets = <value>
       number of DTLB sets; must be power of two

    nways = <value>
       number of DTLB ways

    pagesize = <value>
       data page size; must be power of two

    entrysize = <value>
       data entry size in bytes

    ustates = <value>
       number of DTLB usage states (2, 3, 4 etc., max is 4)

    hitdelay = <value>
       number of cycles dmmu hit costs

    missdelay = <value>
       number of cycles dmmu miss costs
*/

section dmmu
  bus = "or1k_spr:0.0"
  enabled = 1
  nsets = 64
  nways = 1
  pagesize = 8192
  hitdelay = 0
  missdelay = 0
end


/* IC SECTION

   This section configures the Instruction Cache

   enabled = 0/1
       '0': disabled
       '1': enabled
      (NOTE: UPR bit is set)

   nsets = <value>
      number of IC sets; must be power of two

   nways = <value>
      number of IC ways

   blocksize = <value>
      IC block size in bytes; must be power of two

   ustates = <value>
      number of IC usage states (2, 3, 4 etc., max is 4)

   hitdelay = <value>
      number of cycles ic hit costs
   
    missdelay = <value>
      number of cycles ic miss costs
*/

section ic
  bus = "or1k_spr:0.0"
  enabled = 0
  nsets = 512
  nways = 1
  blocksize = 16
  hitdelay = 20
  missdelay = 20
end


/* DC SECTION

   This section configures the Data Cache

   enabled = 0/1
       '0': disabled
       '1': enabled
      (NOTE: UPR bit is set)

   nsets = <value>
      number of DC sets; must be power of two

   nways = <value>
      number of DC ways

   blocksize = <value>
      DC block size in bytes; must be power of two

   ustates = <value>
      number of DC usage states (2, 3, 4 etc., max is 4)

   load_hitdelay = <value>
      number of cycles dc load hit costs
   
   load_missdelay = <value>
      number of cycles dc load miss costs
       
   store_hitdelay = <value>
      number of cycles dc load hit costs
   
   store_missdelay = <value>
      number of cycles dc load miss costs
*/

section dc
  bus = "or1k_spr:0.0"
  enabled = 0
  nsets = 512
  nways = 1
  blocksize = 16
  load_hitdelay = 20
  load_missdelay = 20
  store_hitdelay = 20
  store_missdelay = 20
end


/* SIM SECTION

  This section specifies how or1ksim should behave.

  verbose = 0/1
       '0': don't print extra messages
       '1': print extra messages

  debug = 0-9
      0  : no debug messages
      1-9: debug message level.
           higher numbers produce more messages

  profile = 0/1
      '0': don't generate profiling file 'sim.profile'
      '1': don't generate profiling file 'sim.profile'

  prof_fn = "<filename>"
      optional filename for the profiling file.
      valid only if 'profile' is set
     
  mprofile = 0/1
      '0': don't generate memory profiling file 'sim.mprofile'
      '1': generate memory profiling file 'sim.mprofile'

  mprof_fn = "<filename>"
      optional filename for the memory profiling file.
      valid only if 'mprofile' is set

  history = 0/1
      '0': don't track execution flow
      '1': track execution flow
      Execution flow can be tracked for the simulator's
      'hist' command. Useful for back-trace debugging.

  iprompt = 0/1
     '0': start in <not interactive prompt> (so what do we start in ???)
     '1': start in interactive prompt.

  exe_log = 0/1
      '0': don't generate execution log.
      '1': generate execution log.
     
  exe_log = default/hardware/simple/software
      type of execution log, default is used when not specified
     
  exe_log_start = <value>
      index of first instruction to start logging, default = 0
       
  exe_log_end = <value>
      index of last instruction to end logging; not limited, if omitted
 
  exe_log_marker = <value>
      <value> specifies number of instructions before horizontal marker is
      printed; if zero, markers are disabled (default)

  exe_log_fn = "<filename>"
      filename for the exection log file.
      valid only if 'exe_log' is set

  clkcycle = <value>[ps|ns|us|ms]
      specifies time measurement for one cycle
*/

section sim
  verbose = 1
  debug = 0
  profile = 0
  prof_fn = "sim.profile"

  history = 1
  /* iprompt = 0 */
  exe_log = 1
  exe_log_type = software
  exe_log_start = 0
  exe_log_end = 2000000
  exe_log_marker = 50
  exe_log_fn = "executed.log"

  clkcycle = 10000ns
end


/* SECTION VAPI

    This section configures the Verification API, used for Advanced
    Core Verification.

    enabled = 0/1
        '0': disbable VAPI server
        '1': enable/start VAPI server

    server_port = <value>
        TCP/IP port to start VAPI server on

    log_enabled = 0/1
       '0': disable VAPI requests logging
       '1': enable VAPI requests logging

    hide_device_id = 0/1
       '0': don't log device id (for compatability with old version)
       '1': log device id
       

    vapi_fn = <filename>
       filename for the log file.
       valid only if log_enabled is set
*/

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 = <value>
   rev = <value>
      specifies version and revision of the CPU used

   upr = <value>
      changes the upr register
     
   sr = <value>
      sets the initial Supervision Register value

   superscalar = 0/1
      '0': CPU is scalar
      '1': CPU is superscalar
      (modify cpu/or32/execute.c to tune superscalar model)

   hazards = 0/1
      '0': don't track data hazards in superscalar CPU
      '1': track data hazards in superscalar CPU
      If tracked, data hazards can be displayed using the
      simulator's 'r' command.

   dependstats = 0/1
      '0': don't calculate inter-instruction dependencies.
      '1': calculate inter-instruction dependencies.
      If calculated, inter-instruction dependencies can be
      displayed using the simulator's 'stat' command.

   sbuf_len = <value>
      length of store buffer (<= 256), 0 = disabled
*/

section cpu
  ver = 0x1200
  rev = 0x0001
  bus = "or1k_spr:0.0"
  dbus = "wb:0.0"
  /* upr = */
  superscalar = 0
  hazards = 0
  dependstats = 0
  sbuf_len = 0
end


/* PM SECTION

   This section specifies Power Management parameters

   enabled = 0/1
      '0': disable power management
      '1': enable power management
*/

section pm
  bus = "or1k_spr:0.0"
  enabled = 0
end


/* BPB SECTION

   This section specifies how branch prediction should behave.
   
   enabled = 0/1
     '0': disable branch prediction
     '1': enable branch prediction
     
   btic = 0/1
     '0': disable branch target instruction cache model
     '1': enable branch target instruction cache model

   sbp_bf_fwd = 0/1
     Static branch prediction for 'l.bf'
     '0': don't use forward prediction
     '1': use forward prediction
   
   sbp_bnf_fwd = 0/1
     Static branch prediction for 'l.bnf'
     '0': don't use forward prediction
     '1': use forward prediction

   hitdelay = <value>
       number of cycles bpb hit costs
   
   missdelay = <value>
       number of cycles bpb miss costs
*/

section bpb
  enabled = 0
  btic = 0
  sbp_bf_fwd = 0
  sbp_bnf_fwd = 0
  hitdelay = 0
  missdelay = 0
end


/* DEBUG SECTION

   This sections specifies how the debug unit should behave.

   enabled = 0/1
      '0': disable debug unit
      '1': enable debug unit

   gdb_enabled = 0/1
      '0': don't start gdb server
      '1': start gdb server at port 'server_port'

   server_port = <value>
      TCP/IP port to start gdb server on
      valid only if gdb_enabled is set

   vapi_id = <hex_value>
      Used to create "fake" vapi log file containing the JTAG proxy messages.
*/

section debug
  bus = "or1k_spr:0.0"
  enabled = 0
  gdb_enabled = 0
  server_port = 9999
end


/* MC SECTION

   This section configures the memory controller

   enabled = 0/1
     '0': disable memory controller
     '1': enable memory controller

   baseaddr = <hex_value>
      address of first MC register

   POC = <hex_value>
      Power On Configuration register

   index = <value>
      Index of this memory controller amongst all the memory controllers
*/

section mc
  enabled = 1
  baseaddr = 0x93000000
  POC = 0x00000008                 /* Power on configuration register */
  index = 0
end


/* UART SECTION

   This section configures the UARTs

     enabled = <0|1>
        Enable/disable the peripheral.  By default if it is enabled.

     baseaddr = <hex_value>
        address of first UART register for this device

     
     channel = <channeltype>:<args>
     
        The channel parameter indicates the source of received UART characters
        and the sink for transmitted UART characters.

        The <channeltype> can be either "file", "xterm", "tcp", "fd", or "tty"
        (without quotes).

          A) To send/receive characters from a pair of files, use a file
             channel:

               channel=file:<rxfile>,<txfile>

          B) To create an interactive terminal window, use an xterm channel:

               channel=xterm:[<xterm_arg>]*

          C) To create a bidirectional tcp socket which one could, for example,
             access via telnet, use a tcp channel:

               channel=tcp:<port number>

          D) To cause the UART to read/write from existing numeric file
             descriptors, use an fd channel:

               channel=fd:<rx file descriptor num>,<tx file descriptor num>

          E) To connect the UART to a physical serial port, create a tty
             channel:

               channel=tty:device=/dev/ttyS0,baud=9600

     irq = <value>
        irq number for this device

     16550 = 0/1
        '0': this device is a UART16450
        '1': this device is a UART16550

     jitter = <value>
        in msecs... time to block, -1 to disable it

     vapi_id = <hex_value>
        VAPI id of this instance
*/

section uart
  enabled = 1
  baseaddr = 0x90000000
  irq = 2
  /*channel = "file:uart0.rx,uart0.tx"*/
  /* channel = "tcp:10084" */
  channel = "xterm:"
  jitter = -1                     /* async behaviour */
  16550 = 1
end


/* DMA SECTION

   This section configures the DMAs

     enabled = <0|1>
        Enable/disable the peripheral.  By default if it is enabled.

     baseaddr = <hex_value>
        address of first DMA register for this device

     irq = <value>
        irq number for this device

     vapi_id = <hex_value>
        VAPI id of this instance
*/

section dma
  enabled = 1
  baseaddr = 0x9a000000
  irq = 11
end


/* ETHERNET SECTION

   This section configures the ETHERNETs

     enabled = <0|1>
        Enable/disable the peripheral.  By default if it is enabled.

     baseaddr = <hex_value>
        address of first ethernet register for this device

     dma = <value>
        which controller is this ethernet "connected" to

     irq = <value>
        ethernet mac IRQ level

     rtx_type = <value>
        use 0 - file interface, 1 - socket interface

     rx_channel = <value>
        DMA channel used for RX

     tx_channel = <value>
        DMA channel used for TX

     rxfile = "<filename>"
        filename, where to read data from

     txfile = "<filename>"
        filename, where to write data to

     sockif = "<ifacename>"
        interface name of ethernet socket

     vapi_id = <hex_value>
        VAPI id of this instance
*/

section ethernet
  enabled = 1
  baseaddr = 0x92000000
  dma = 0
  irq = 4
  rtx_type = 0
  tx_channel = 0
  rx_channel = 1
  rxfile = "eth0.rx"
  txfile = "eth0.tx"
  sockif = "eth0"
end


/* GPIO SECTION

   This section configures the GPIOs

     enabled = <0|1>
        Enable/disable the peripheral.  By default if it is enabled.

     baseaddr = <hex_value>
        address of first GPIO register for this device

     irq = <value>
        irq number for this device

     base_vapi_id = <hex_value>
        first VAPI id of this instance
        GPIO uses 8 consecutive VAPI IDs
*/

section gpio
  enabled = 0
  baseaddr = 0x91000000
  irq = 3
  base_vapi_id = 0x0200
end

/* VGA SECTION
   
    This section configures the VGA/LCD controller
   
      enabled = <0|1>
        Enable/disable the peripheral.  By default if it is enabled.

      baseaddr = <hex_value>
        address of first VGA register
       
      irq = <value>
        irq number for this device
       
      refresh_rate = <value>
        number of cycles between screen dumps
       
      filename = "<filename>"
        template name for generated names (e.g. "primary" produces "primary0023.bmp")
*/

section vga
  enabled = 1
  baseaddr = 0x97100000
  irq = 8
  refresh_rate = 100000
  filename = "primary"
end


/* TICK TIMER SECTION

    This section configures tick timer

    enabled = 0/1
      whether tick timer is enabled
*/

section tick
  bus = "or1k_spr:0.0"
  enabled = 1
end

section pic
  bus = "or1k_spr:0.0"
  enabled = 1
  edge_trigger = 1
end

/* FB SECTION
   
    This section configures the frame buffer
   
    enabled = <0|1>
      Enable/disable the peripheral.  By default if it is enabled.

    baseaddr = <hex_value>
      base address of frame buffer
       
    paladdr = <hex_value>
      base address of first palette entry
       
    refresh_rate = <value>
      number of cycles between screen dumps
       
    filename = "<filename>"
      template name for generated names (e.g. "primary" produces "primary0023.bmp")
*/

section fb
  enabled = 1
  baseaddr = 0x97000000
  refresh_rate = 1000000
  filename = "primary"
end


/* KBD SECTION

    This section configures the PS/2 compatible keyboard
   
    baseaddr = <hex_value>
      base address of the keyboard device
     
    rxfile = "<filename>"
      filename, where to read data from
*/

section kbd
  enabled = 1
  irq = 5
  baseaddr = 0x94000000
  rxfile = "kbd.rx"
end


/* ATA SECTION
   
    This section configures the ATA/ATAPI host controller
   
      baseaddr = <hex_value>
        address of first ATA register
       
      enabled = <0|1>
        Enable/disable the peripheral.  By default if it is enabled.

      irq = <value>
        irq number for this device

      debug = <value>
        debug level for ata models.
        0: no debug messages
        1: verbose messages
        3: normal messages (more messages than verbose)
        5: debug messages (normal debug messages)
        7: flow control messages (debug statemachine flows)
        9: low priority message (display everything the code does)

      dev_type0/1 = <value>
        ata device 0 type
        0: NO_CONNeCT: none (not connected)
        1: FILE      : simulated harddisk
        2: LOCAL     : local system harddisk

      dev_file0/1 = "<filename>"
        filename for simulated ATA device
        valid only if dev_type0 == 1

      dev_size0/1 = <value>
        size of simulated hard-disk (in MBytes)
        valid only if dev_type0 == 1

      dev_packet0/1 = <value>
        0: simulated ATA device does NOT implement PACKET command feature set
        1: simulated ATA device does implement PACKET command feature set

   FIXME: irq number
*/

section ata
  enabled = 0
  baseaddr = 0x9e000000
  irq = 15

  dev_type0   = 1
  dev_file0   = "/tmp/sim_atadev0"
  dev_size0   = 1
  dev_packet0 = 0

  dev_type1   = 0
  dev_file1   = ""
  dev_size1   = 0
  dev_packet1 = 0
end

---

_______________________________________________
http://www.opencores.org/mailman/listinfo/openrisc