Hi Rim,



You don't have to create a memory using the megawizard function, because the project already includes the instantiation of an onchip memory. All you have to do for the memory is to select the memory amount by changing the definition "`define MEMORY_ADR_WIDTH 13". 13 means 32kBytes, the equation is memory = 4*2^MEMORY_ADR_WIDTH.

The adaptation of the project to a target board should be made in 2 steps maximum. First the minsoc_defines.v file has to be adjusted, after that a constraint file for your specific pinout has to be created.



In order to implement a minsoc design on FPGA you just have to follow the "howto->5)Implementation" under doc/minsoc.pdf, which will also link you to "howto->7)Examples". I will add the short following Altera example to the minsoc.pdf under "7)Examples->d)Altera Devices".

In short you have to:
-uncoment "//`define ALTERA_FPGA"
-comment "`define XILINX_FPGA"
-comment "`define SPARTAN3A"
-select your memory amount "`define MEMORY_ADR_WIDTH 13"
-choose a clock division for your global clock related to your design max speed by changing the definition: "`define CLOCK_DIVISOR 5". Since you have an Altera device please use only even numbers for the division, odd numbers are going to be rounded down.
-Define your RESET polarity: uncomment "`define POSITIVE_RESET" for an active high reset or "`define NEGATIVE_RESET" for an active low reset and comment the other.

You don't have to change the or1200_defines.v, but you can:
-uncomment "//`define OR1200_ALTERA_LPM"
-uncomment "//`define OR1200_RFRAM_DUALPORT"
-comment "`define OR1200_RFRAM_GENERIC"
-comment "`define OR1200_QMEM_IMPLEMENTED"

After that you'd generally want the system to do something. For that you have to load a software to your memory so the processor can execute it. To do so you'd have to follow the item "6) use GDB to upload software and debug for simulation and implementation". Using the same cable connected to the same port you use to configure your FPGA you will be able to upload a software and control its execution.

All the discussion we had in this thread is about how to make a design already includes its firmware so you don't have to upload new software to it. For that I included the start-up code into minsoc, which I commented above.

If you have time, download the updates or update your svn working copy and tell me if the howto is ok.

Good luck,
Raul

Skarr,

'xdl' fails to convert your NCD file for some reason.
'xdl' is a Xilinx tool which converts NCD file of your project to a readable XDL format, which then can be used to create a BMM file for data2mem tool.

Maybe the problem is in your design. Also make sure you have all components and updates for Xilinx Webpack installed.

You can try to run this command and see if it gives some more output:

xdl -ncd2xdl sic_top.ncd

HTH,
Andrey

Hello Skarr,

I don't think I have attached any wrong files. Could you let me know the exact problem using the script.

I am using the same files to generate the block_ram.init file that I have attached in my earlier post. Copy the Makefile and the bin2init.c from my previous post attachment to your minsoc_project_path/sw/utils/. Do a 'make clean' and 'make all'. The bin2init executable should be built in the same directory.
I have attached a new Makefile in this post. The block_ram.init file is generated using uart-nocache.bin in this Makefile. Place it in the directory minsoc_project_path/sw/uart/ . Now again 'make clean' and 'make all' in this directory. block_ram.init file should now be generated in this folder.
Add as a source in your ISE project this block_ram.init.
Edit the minsoc_defines.v and add the following new define
'define BLACK_RAM_INIT

Also overwrite the minsoc_onchip_ram_top.v in your ISE minsoc project with the one from my previous post. Resynthesis your project and in your synthesis report you should be able to see the block ram variables being initialized.

Note: In my case I am instantiating RAMB16_S9 blocks in the minsoc_onchip_ram_top.v and the script is also written to initialize only the block instances created in this file only.

Hope this helps. I would also try the openrics_bram.pl, seem a better way of initializing than to recompile the hardware.

With Regards,
Ravi

My previous error message did not display properly. This is what it said:

WARNING:PersonalityModule:34 - The part xc4vfx20 was not found in family virtex4.
ERROR:XDL:130 - Can't process Ncd file sic_top.ncd.

The tools work on my PC: I managed to complete a "make bitfile-bram" in /xilinx-xc3sd-1800

Hi Ravi,



From what I can tell it seems you could have simply add the lines:
`ifdef BLOCK_RAM_INIT
`include "block_ram.init"
`endif

on the minsoc_onchip_ram.v, since it is only a wrapper for the real onchip memory; and in your case the same RAMB16_S9.

I was concerned that your initialization would ignore the further banks of the generated onchip memory. But I have seen you separated different banks and blocks directly on the initialization file, very nice.

This could really be useful for some people. Even with the or1k_startup module being ported for the minsoc project and being more widely applicable, there are cases where you don't have an external SPI memory where you can deploy your code, etc.

To port it tho, the bank and block number variables should be automatically read from the verilog definition file or input on command line. Furthermore, do you think this same initialization file would work for the different onchip instances, specially for lpm_ram_dq ?

Thank you in advance,
Raul

This is more of a follow up question than a reply.

I have successfully used the bin2init program that Ravi created to run minsoc software on a Xilinx Spartan 3E 1600 demo board. It works great, but takes forever every time a change is made to the software. I haven't tried Andrey's pearl script yet, I'm sure that will be faster. However, since this board has SPI flash on board, it really makes more sense just to use the startup function. Initially, I just created the bin file and added four bytes in the front for the end of program address. When I uploaded the same file that had worked with bin2init to the SPI flash and used the start up program, it did not work. Upon further investigation, it appears that the start up code is not just looking for a bin file with the first four bytes indicating the last program address, but is actually looking for an spi programmed with the first four bytes indicating the last address and followed by a sequence of address and program data pairs for the entire file. I can of course make a script to generate this file, but I wanted to first confirm that this is correct, and then ask if there was a reason for doing it this way. I guess if there are lots of skipped addresses, this would make sense, but my file would probably just be twice as long with an address for each instruction. Also, if there is already a script that is being used, please let me know. I am also considering changing the start up code to just load the program data bytes starting at address zero. Is there a reason that it is better to have the address / data pairs?

Thanks,

Jamie

Hi Jamie,

in the sw/uart or sw/eth directories, the corresponding Makefile already creates the hex file necessary to load the SPI memory with. This are the uart-nocache.hex or eth-nocache.hex for trunk and uart-nocache-twobyte-sizefirst.hex for stable.

Then you have to:
-uncomment START_UP of minsoc_defines.v
-define the FPGA pinout connection to the SPI memory on your constraint file (ucf for Xilinx)
-re-synthesize and P&R the design
-reload the bitfile
-download one of the files meantioned above to the SPI memory

You can even test if the hex file will work doing the following:
-commenting out INITIALIZE_MEMORY_MODEL of minsoc_bench_defines.v and uncommenting START_UP
-proceed as explained here: http://minsoc.wikaba.com/simulation

Then wait, it can take about 5 minutes because the SPI transactions done to load the main memory with the firmware are simulated. When the whole transaction is done, you will see "Memory start-up completed...". Complete simulation output below.

I hope that helps,
Raul

Simulation output:
raul@mp-pc133:~/or1k/minsoc/sim/run$ ./run_bench ../../sw/uart/uart-nocache.hex
(minsoc_bench.minsoc_top_0.uart_top) UART INFO: Data bus width is 32. Debug Interface present.

(minsoc_bench.minsoc_top_0.uart_top) UART INFO: Doesn't have baudrate output

WARNING: ../../bench/verilog/minsoc_bench.v:111: $readmemh: Standard inconsistency, following 1364-2005.
WARNING: ../../bench/verilog/minsoc_bench.v:111: $readmemh(../../sw/uart/uart-nocache.hex): Not enough words in the file for the requested range [0:131071].
�Memory start-up completed...
Loaded firmware:
../../sw/uart/uart-nocache.hex
Hello WorBld.
^C** VVP Stop(0) **
** Flushing output streams.
** Current simulation time is 139237000 ticks.

Raul --

Thank you for the detailed response. I had tried the hex file first. Perhaps I don't know the proper procedure for downloading this to flash. I couldn't get Impact to process a data file without a configuration file before it, so I tried the Xilinx promgen tool. When I used this on the generated hex file, it created a mcs file that included all of the linefeeds from the hex file. Also, it treated all of the ascii characters in the hex file as bytes so the first programming line of the mcs file became:

:1000000030300A30300A31650A37380A30300A3069
0 0 0 0 1 E 7 8... 0A are all extra from all line feeds

when it should have been:

:1000000000001E780000000000000000000000005A

I assumed it would sufficient to add the four count bytes to the front of the bin file and use that to generate the .mcs file. Using this with promgen produced an mcs file in standard hex format that started with the four size bytes followed by 256 zeros and then the code. I tried putting this on the flash, but the program did not load. It looks like my mistake was adding the program length bytes instead of just replacing the first four bytes.

In case anyone else is using the Xilinx tools, the command to convert the bin file to .mcs without including a configuration file is:

/opt/Xilinx/12.3/ISE_DS/ISE/bin/lin64/promgen -w -c -s 16384 -spi -p mcs -o eth.mcs -data_file up 0000 eth_with_size.bin

Thanks for your help. I also tried simulating the start up, which worked great.

Jamie

Hi Jamie,

I believe your mistake was to add the first four bytes instead of substituting them. You could try to recreate the hex file for simulation using your modified bin file and ten test it on simulation. This way you can try tweaking the bin until it works.

HTH
Raul

Hi Jamie,
did it work?
Greetings,
Raul

Raul --

It did work. After your first response, I reread the start-up spec and realized the four bytes replaced the first four, and were not added. I've got the uip telnetd server running on hardware now (not really useful yet, since I haven't set up access to off chip ram,) although I'm still seeing hangups after a small number of transactions. I've got one of the slow Xilinx cables and mismatched processor/gdb versions, so I haven't been able to trace down the hang up yet, but the startup from spi flash is working well (and much quicker than resynthesizing.)

Thanks,

Jamie

Hi There

I want to know the mimic of C programming for or1ksim. My main problem specially is in place when we want to write and read data from a physical interface like GPIO. I want to know how we can control the IRQ in our C program. Some compiler for real CPU offer #pragma Vector or something like this but here I don't know how we can jump our code as soon as we signaled by an IRQ.
Additionally, I read something about config file which in that we should enable peripherals which we need, determine the base address of them, enabling Interrupt and so on. But for C program I don't know.
In an implementation from Embecosm I saw code like this to send a character :

void simputc( int c )
{
__asm__ __volatile__ ( "\tl.nop\t%0" : : "K"( NOP_PUTC ));

}

but I don't know how it works and what is originate of that?

Thanks.

Hi Jamie,

great news, congratulations. If you manage to create an even nicer system to work with, it would be awesome if you could explain your steps in a special page of minsoc's wiki.

Greetings,
Raul

Hi mffpga_2

GPIO interrupt line is specified in the Or1ksim configuration. The user guide gives details.

The OR1K allows l.nop instructions to include a 16-bit constant. These have no semantic effect on the hardware, but can be used by simulators to provide "side effects". This provides a simple mechanism to provide I/O etc in simulation. In this case the constant NOP_PUTC (defined in one of the headers) will cause a simulator such as Or1ksim to print the character in r3 to standard output.

The Or1skim user guide has a full list of all the l.nop operand values that are currently supported.

HTH

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

Hi There

Thanks for previous response, will be very helpful.
But I asked another question which was about writing Interrupts function in C++ program for or1ksim. I don't know how should I refer a function to my interrupt? For example in some U-Processors' C compiler we have #pragma interrupt_vector = 0x03 or something like that to introduce an operation to compiler to do that operation whenever our Interrupt hints! For example in my application program If I want to read GPIO BUS as soon as getting data on it's router, what should I do?

Cheers,