how do I synthesize this in quartus for the de0 nano

[salmansheikh]

I am trying to add the top level in a quartus project but many hdl files are missing from the core dir that the top level calls out.

[olofk]

Have you installed FuseSoC? That will take care of pulling in all the files, create a Quartus project for you and build the design. Just run 'fusesoc build de0_nano' after you have installed FuseSoC. After that, you can open the Quartus project file (located in build/de0_nano/bld_quartus) if you prefer to work from Quartus

[salmansheikh]

Okay, I did get fusesoc from the git, ran

autconf -i
./configure --prefix=/home/ssheikh
And make install.

When I run ~/bin/fusesoc, I get the following (i do have a ~/lib/python2.7 directory created). I am not admin so, is that okay to have them there or should I have him do an install as root?

ssheikh@gs-560g3080090e:~$ ~/bin/fusesoc
Traceback (most recent call last):
File "/home/ssheikh/bin/fusesoc", line 23, in
from fusesoc.build import BackendFactory
ImportError: No module named fusesoc.build

[salmansheikh]

Never mind...I set PYTHONPATH=/home/ssheikh/lib/site-packages and fusesoc is cranking on quartus for my de0-nano....too cool if it works!!

[salmansheikh]

I programmed the de0_nano. Now how do I load the program?

In the orpsoc-cores/systems/de0_nano/utils, I see a program called
flash-helper.sh

It seems it run a mkimage. Where does that come from? I have a linux 12.04
and don't see it.

Salman

On Thu, Aug 13, 2015 at 7:02 AM, Olof Kindgren notifications@github.com
wrote:

Have you installed FuseSoC? That will take care of pulling in all the
files, create a Quartus project for you and build the design. Just run
'fusesoc build de0_nano' after you have installed FuseSoC. After that, you
can open the Quartus project file (located in build/de0_nano/bld_quartus)
if you prefer to work from Quartus

—
Reply to this email directly or view it on GitHub
#86 (comment)
.

Even a Smile is charity :)

• Prophet Muhammad

[olofk]

Hi,

Sorry for the late reply. mkimage is part of u-boot.

There are several ways to load a program. Either you can connect via JTAG, write the program to RAM and run it directly from there. In that case I recommend you to read up a bit on openocd. I've also outlined the procedure for another project here https://github.com/myriadrf/STREAM/blob/master/stream_openrisc_soc/doc/quickstart.html The part about openocd should be very similar on the de0 nano

The other way is to put a program into the SPI Flash and boot it from there. In that case flash_helper.sh will help you put together an image and put it into the Flash.

Hope this helps

[salmansheikh]

I am attemping to add another uart to the de0_nano. I modified the
orpsoc_top.v in the de0_nano orpsoc-cores/systems but the problem when I
try to run fusesoc is there is no signal declaration of wb_2ms_uart1_adr.
I saw it in the wb_intercon.v but that file said its autogenerated by
web_intercon_gen.

How do I do run that program and where is it?

Salman

Error (10161): Verilog HDL error at orpsoc_top.v(631): object
"wb_m2s_uart1_adr" is not declared File:
/home/ssheikh/tmp/build/de0_nano/src/de0_nano/rtl/verilog/orpsoc_top.v
Line: 631

On Tue, Sep 22, 2015 at 3:13 PM, Olof Kindgren notifications@github.com
wrote:

Hi,

Sorry for the late reply. mkimage is part of u-boot.

There are several ways to load a program. Either you can connect via JTAG,
write the program to RAM and run it directly from there. In that case I
recommend you to read up a bit on openocd. I've also outlined the procedure
for another project here
https://github.com/myriadrf/STREAM/blob/master/stream_openrisc_soc/doc/quickstart.html
The part about openocd should be very similar on the de0 nano

The other way is to put a program into the SPI Flash and boot it from
there. In that case flash_helper.sh will help you put together an image and
put it into the Flash.

Hope this helps

—
Reply to this email directly or view it on GitHub
#86 (comment)
.

Even a Smile is charity :)

• Prophet Muhammad

[fjullien]

Hi,

you can find wb_intercon_gen here: https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_intercon/sw/wb_intercon_gen

So, in order to add another uart in your system you need to edit your wb_intercon.conf and add your new uart. Then ./wb_intercon_gen wb_intercon.conf wb_intercon.v

If you want quicker help you can join #openrisc on freenode IRC.

Franck.

[salmansheikh]

I did it manually..edited both files by hand...now I need to find some
software examples of how to use the 2nd uart. How does software know printf
is for the main uart and is the 2nd uart only accessible by writing to it's
registers directly?

Salman

On Tue, Sep 29, 2015 at 2:44 AM, Franck Jullien notifications@github.com
wrote:

Hi,

you can find wb_intercon_gen here:
https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_intercon/sw/wb_intercon_gen

So, in order to add another uart in your system you need to edit your
wb_intercon.conf and add your new uart. Then ./wb_intercon_gen
wb_intercon.conf wb_intercon.v

If you want quicker help you can join #openrisc on freenode IRC.

Franck.

—
Reply to this email directly or view it on GitHub
#86 (comment)
.

Even a Smile is charity :)

• Prophet Muhammad

[olofk]

Hi Salman,

I assume that you are running a bare-metal program. If you are running an OS, such as Linux, the answer is different

Anyway, the bare-metal toolchain (or1k-elf-) uses newlib, which in turn calls libgloss to carry out the hardware-dependent tasks, such as reading and writing characters from/to a UART. The OpenRISC-specific code for libgloss can be found here https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=libgloss/or1k;h=e0fb2ac034c5d238e6ec9c04b73c94b666326673;hb=HEAD

Specifically for the UART, there is or1k_uart.c which handles the low-level functions. It expects to find a UART at base address _or1k_board_uart_base, which in turn is defined in libboard. So to sum it up, a printf in your code calls the printf function in newlib, which calls _write in libgloss, which in turn calls or1k_uart_write

Looking at or1k_uart.c now, I realize that these functions aren't really built to handle additional UARTs. For now, I think your best option would be to copy or1k_uart.[c,h], and make your own version where you can set a base address to your second UART. We should probably make a better fix for this some time

//Olof

[salmansheikh]

Does anyone have a Openrisc fusesoc implementation for the ProASIC3 fpga?

On Thu, Oct 8, 2015 at 9:08 AM, Salman Sheikh salmanisheikh@gmail.com
wrote:

Thanks..yes, I got the bare-metal working with uart one..I will attempt
direct register writes on uart too..then I may do as you suggest with the
copy/new version..

On Thu, Oct 8, 2015 at 6:59 AM, Olof Kindgren notifications@github.com
wrote:

Hi Salman,

I assume that you are running a bare-metal program. If you are running an
OS, such as Linux, the answer is different

Anyway, the bare-metal toolchain (or1k-elf-) uses newlib, which in turn
calls libgloss to carry out the hardware-dependent tasks, such as reading
and writing characters from/to a UART. The OpenRISC-specific code for
libgloss can be found here
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=libgloss/or1k;h=e0fb2ac034c5d238e6ec9c04b73c94b666326673;hb=HEAD

Specifically for the UART, there is or1k_uart.c which handles the
low-level functions. It expects to find a UART at base address
_or1k_board_uart_base, which in turn is defined in libboard. So to sum it
up, a printf in your code calls the printf function in newlib, which calls
_write in libgloss, which in turn calls or1k_uart_write

Looking at or1k_uart.c now, I realize that these functions aren't really
built to handle additional UARTs. For now, I think your best option would
be to copy or1k_uart.[c,h], and make your own version where you can set a
base address to your second UART. We should probably make a better fix for
this some time

//Olof

—
Reply to this email directly or view it on GitHub
#86 (comment)
.

Even a Smile is charity :)

• Prophet Muhammad

Even a Smile is charity :)

• Prophet Muhammad

[zavax2005]

Hi Olof

Trying to use flash_helper.sh and de0_nano.cof to merge the FPGA configuration and application firmware into one image (did I understand correct?), and then use quartus_pgm to upload the generated .jic file to EPCS flash.

However, I noticed the HEX_OFFSET in the de0_nano.cof is 524288. Is it true that this offset should be >= sof size + sof starting address to avoid overlap. If the sof file I generated with Fusesoc is 709373, shall I increase the HEX_OFFSET to be greater than 709373?

Thanks,
-Xueming

[olofk]

hmm.. good question. I'm not completely sure, but I think that the sof file is compressed somehow. Looking at https://www.altera.com/en_US/pdfs/literature/hb/cyclone-iv/cyiv-51008.pdf page 4, the sof size is larger than 524288, so you could perhaps increase the offset to be sure, but it has always worked for me to put it at the original offset.

Note however that if you change this offset, you will also need to tell the boot loader to look for the program at the new address. You can do this by entering ~/.local/share/orpsoc-cores/systems/de0_nano/sw and run BOOTROM_ADDR=0x100000 make to create a new boot ROM that will search at address 0x100000 (=1048576 = 524288*2)

[zavax2005]

Hi Olof

I tried both 0x80000 and 0x100000 per your reply, but neither worked after I uploaded the jic file onto the board.

What makes me confuse here is some older tutorials I found online, in which a "bin2binsizeword" program is called to replace the first word of application image with the the size of itself. However I didn't that step in your "flash_helper.sh". Is it obsoleted?

Thanks,
-Xueming

[olofk]

bin2binsizeword is obsoleted. It was an old, very simple image format that just used the first word to indicate the size of the image. I figured it was better to use an existing format instead and chose therefore uImage, which is the same format as uBoot is using. The spi_uimage_loader (which I assume you are using as the bootrom) expects the application image to use the uImage format. At this point it's hard to tell what could be wrong. The bootloader doesn't provide any visible clues about what is going on.

Some ideas for further investigation

• Run a simulation. This would require you to convert the uImage file to verilog hex and load it into the simulator with --spi_flash_file=/path/to/file.vh
• Extend the bootloader to provide more information. For example by lighting up different LEDs depending on what it is doing.
• Try a different application. Perhaps everything is working fine, and it's just that your application is somehow broken. I also found a .jic file on my computer. Honestly, I haven't got a clue what's in the image or if it even works, but it could be a led blinker or Linux. Your could try this one and see if it works