I have a project that is based on the processor or1K.
I must begin to test the processor for accomplish developed work later.

My first question :
the or1K must be connected with a memory to load the instruction or the qmem (or1200_qmem.v: embeeded memory) is the memory that will be loaded??
If it is not qmem which must be loaded ,so what is the role of qmem?? and how I should connect a new memory to the processor ? I must connect it directly to or1200_top?

My second question:
I have a windows OS .SO i can work with cygwin with no problem or I must install an Unix OS?

Thanks .

From the or1200_defines.v file:

/////////////////////////////////////////////////
//
// Quick Embedded Memory (QMEM)
//

//
// Quick Embedded Memory
//
// Instantiation of dedicated insn/data memory (RAM or ROM).
// Insn fetch has effective throughput 1insn / clock cycle.
// Data load takes two clock cycles / access, data store
// takes 1 clock cycle / access (if there is no insn fetch)).
// Memory instantiation is shared between insn and data,
// meaning if insn fetch are performed, data load/store
// performance will be lower.
//
// Main reason for QMEM is to put some time critical functions
// into this memory and to have predictable and fast access
// to these functions. (soft fpu, context switch, exception
// handlers, stack, etc)
//
// It makes design a bit bigger and slower. QMEM sits behind
// IMMU/DMMU so all addresses are physical (so the MMUs can be
// used with QMEM and QMEM is seen by the CPU just like any other
// memory in the system). IC/DC are sitting behind QMEM so the
// whole design timing might be worse with QMEM implemented.



There is a bus arbiter, you connect it to one of the slave ports (in ORPSoC there are a couple of dummy slaves you can get rid of, and then define the address area that slave occupies in the orpsoc_main.v as a parameter of the wb_conmax module.)


Yes, the software suite (compilers, GDB port, or1ksim) works fine under most standard Cygwin configurations, and there are Verlilog HDL simulators available for the Windows platform (Modelsim, most notably) which makefiles can call from within Cygwin environment without an issue.

I have a problem related to Rim's first question:



I want to initialize a RAM but I'm experiencing some problems.



If I do a make all in hello-uart I get a bootcode.elf file. Change to binary, convert to hex gives bootcode.hex. bootcode.hex contains a list of 19304 hexadecimal symbols. So I need about 18,8 kb of RAM. The on-chip RAM in the design has 16kb. I can't seem to increase this to 32k, my verilog skills are non existent. So I tried to change the total amount of ram available to the system by modifying or32.lb. I had to reflect the changes in ram.lb (inside the hello-uart folder) after I noticed that the makefile uses ram.lb instead of or32.lb.



After reducing the available ram by any amount, making clean and all, bootcode.hex's size does not change. Am I missing something?

Is there a solution to my problem without enlarging the RAM?

I'm using the following guide: http://pm.stu.cn.ua/wiki/xsoc/Getting_started

Hi Rim and Skarr,

It's the first time I see that project you linked, so I cannot answer how to do it there. It seems to be possible though.

But if you are trying to implement an Openrisc SoC and you want to extend your internal block ram so it fits your needs, you can also try the minsoc project. You can change the amount of instantiated memory by changing the minsoc_defines.v file adapting the value of "`define MEMORY_ADR_WIDTH 13". 13 is equivalent to 32 kBytes and is calculated by 4*2^MEMORY_ADR_WIDTH.

The project website is: http://www.opencores.org/project,minsoc the project has a small howto document minsoc.pdf inside of the doc folder. This howto also explains the memory amount adaptation part.

Best regads,
Raul

Thanks Raul

I had a look at minsoc about a week ago, but I got stuck at various points due to a problem with my cross compiling setup and the fact that I want to initialize my memory with actual verilog code and not upload it with gdb for example.

I have found a solution to the problem I described above. By decreasing the amount of c code used in my program I got the size down. I initialized the memory but I saw nothing on the uart port or leds. Something is wrong but I can't find the problem!

Now I'm going to try minsoc again. I seems easier now, I've learnt a lot the past week. But I'm still committed to initialize the ram with actual code. Do you see a possible problem with the following approach:

- run "make eth-nocache" in minsoc/trunk/sw/eth
- take the contents of the hex file that has been produced, for example:
00
FA
4B
15
A0

- format it in the following way: (if addr width is 12)
mem[000] mem[001] mem[002] mem[003] mem[004]
- paste it in minsoc_onchip_ram.v
- follow the guide as usual

I've only now just had my attention drawn to this project, and I've had a quick look at it. When i go into the sw/hello-uart path and do a "make all" I get the bootcode.elf file, then or32-elf-objcopy it to a binary file which is only 9Kbytes in size. If it's just this program that is loaded into that RAM then there should be enough room in a 16KByte RAM - the HEX file will be bigger because it's representing the data in human-readable format, with all sorts of extra delimiters used by the tools which download/embed the data. I haven't completely assembled and run the system but I'm pretty sure this should be the case. But this means that you don't need to increase the on-chip RAM to load/embed this program into the system's RAMs.



First, I can't find a file named or32.lb anywhere in the OpenRISC XSoC project. What file do you mean?

But, assuming you're working with this OpenRISC XSoC, and you did want to increase the size of the on-chip RAM for any reason, it looks like you have to play with the Xilinx BRAM instantiation in rtl/opencores/mem_if/onchip_ram_top.v and change the RAMB16_S4 instantiations to something bigger, and of course increase the address width parameter.

Just note that my previous message is a reply to Raul's post.


Yes that does make sense. I seems like it does fit even without decreasing the amount of c code used, like I did in my previous post.


Speaking under correction, I think or32.lb is the default 'linker' located at

/opt/or32-newlib/or32-elf/lib

after following the GNU toolchain with newlib installation guide.


I found a list of RAMB16_S4 and all his friends at

http://www.xilinx.com/itp/xilinx4/data/docs/lib/libguidetoc.html, chapter 9

But I could not find a good alternative to RAMB16_S4. By changing the 'flavour' (RAMB16_S9), a parity bit is added which makes my initialization plan somewhat insane. Furthermore the size stays on 16 kilobits. By changing the type (for example RAM32), the way the ram is initialized and operates changes. I don't know how to reconcile those differences.

Thanks for the help guys!

Hi Skarr,

if you want that your software be already on memory when you turn on your board you have two possibilities:
-initialize the BRAMs with the code: for this it would be better if you create a 32 bit width RAM memory using the coregen software from Xilinx, assuming you're using Xilinx, and then adapt the onchip_ram_top.v to instance this one RAM to create the wishbone interface. After that you have to tell the software, ISE or Coregen probably, you want it to use the hex or vmem file to initialize the RAM.

-use the start-up code and an external SPI memory: if you use minsoc you only have to uncomment "//`define START_UP" and attach the pins "spi_flash_mosi, spi_flash_miso, spi_flash_sclk, spi_flash_ss" to real pins of your FPGA, which connect to that SPI memory using a UCF file. After you write your code to that SPI memory, everytime your design starts it will load the content of that SPI memory to its internal memory and restart.

If you're using a Spartan3e starter kit or Spartan3A DSP 1800 the ucf files are already written and can be found under the backend folder of the minsoc project.

Good luck,
Raul

Hi Skarr and Raul,

In the minsoc project I adapted the minsoc_onchip_ram_top.v, to have the RAM initialized with the application sw and to by pass the GDB loading. As in my case I am using RAMB16_S9, I wrote a RAM initailization script sw/utils/bin2init.c adapted from sw/uitls/bin2vmem.c. Compiled this script and used it to generate the block_ram.init file and included it in the minsoc_onchip_ram_top.v.

Usage: ./bin2init app.bin > block_ram.init.

Find attached sw/utils/bin2init.c, modified sw/utils/makefile and the adapted minsoc_onchip_ram_top.v.

One just need to add a new 'define BLOCK_RAM_INIT in the minsoc_defines.v to enable this file inclusion.

This script could be modified to suit other RAM blocks like RAMB16_S4 easily I guess. Hope this could be of some use.

Regards,
Ravi

@Raul

Yes I am using Xilinx. I have a custom board so the first option will suit me better.

Well the grass is always greener on the other side. I have encountered strange errors while trying to get minsoc up and running. When I run make all in minsoc/sw/uart I get a bunch of errors about my or32.ld file (/opt/or32-newlib/or32-elf/lib) that is in conflict with the local linker file (uart/orp.ld). I managed to "get around" that by changing the makefile on line 9:

$(OR32_TOOL_PREFIX)-gcc

to

$(OR32_TOOL_PREFIX)-ln

I have no idea what that does but that's how the makefile in the XSoc project I mentioned above works. Either way I have a hex file now.

@Ravi

Thanks a lot for your effort but it seems like you have included the wrong files...

Hi Skarr,

all sw from minsoc has been compiled with the regular GNU toolchain installed by the script under http://www.opencores.org/openrisc,gnu_toolchain . Therefore it uses uClibc not newlib and precisely that might be your error.

Best regards,
Raul

Hi all,

I'm a maintainer of the OpenRISC XSoC project, Skarr mentioned it in his first post.

To easily initialize RAM in OpenRISC XSoC I created 'openrisc_bram.pl' utility. It allows to directly update a bitstream file with contents of ELF file. No need to recompile hardware if you just need to update the software, no need to convert anything.

It generates a valid BMM file for Xilinx data2mem utility and then uses data2mem to update the bitstream.

If you are using OpenRISC XSoC and want to initialize onchip RAM, follow these steps:

1. build SoC for your board with "make all" under "boards/board_name" directory
2. build "Hello UART" program with "make all" under "sw/hello-uart" directory
3. create "bootcode" directory under "boards/board_name"
4. copy "bootcode.elf" to newly created directory
5. run "make bitfile-bram" under "boards/board_name" directory

And you are done. Now you can use newly created bitfile to program the board.

You can read a bit more about it in Getting Started guide, I've just updated the Wiki. I've also updated tools and build scripts in our SVN, so please, make sure to update your local copy if you are using any of these.

The 'openrisc_bram.pl' utility can be used in other projects, however some modifications might be needed in particular cases.

Feel free to ask questions about OpenRISC XSoC if you need more help.

Andrey

Your guess is correct! I actually installed uClibc initially, so after changing my path variable from /opt/or32-newlib/bin to /opt/or32-elf/bin I did a make all in minsoc/sw/uart successfully!

I'll try the coregen procedure while I'm waiting for an update from Ravi.

Thanks a lot for the help!

hi all
Sorry ,I was sick for a week and I think I missed the discussion.
So I downloaded the minsoc and I compiled the hello world program by typing make all in the directory sw / uart and i get the hex , bin and vmem files.
Now, if I use an FPGA board,should i give a specific name (lpm_ram_dq)to the memory generated by megawizard function ?
and how can I instantiate this memory?
what are the lines I have to comment in the minsoc_defines.v and or1200.v??
Thanks

I have a custom board. I tried to run openrisc_bram.pl with the following extensions:

-f bootcode.elf -n sic_top.ncd -t onchip_ram_top -b sic_top.bit

I get the following output: Converting 'sic_top.ncd' to XDL format.. WARNING:PersonalityModule:34 - The part was not found in family . ERROR:XDL:130 - Can't process Ncd file .

I couldn't find any help by googling the error.