Smalles Design, first scoring data :)

[Antti Lukats]

Hi,

a teaser:

https://github.com/micro-FPGA/riscv-contest-2018/wiki

I was pretty close estimating that Eric beats me by factor 2...

Preliminary data of course, will change a bit still.

br

Antti

[Charles Papon]

Interresting :D
Update about the SpinalHDL one :
I will not do emulation at all finaly, but focus on the performance one.
So, the usage of the small versions of the SoC on UP5K is currently  1610 LC (not LUT) for 0.39 DMIPS/Mhz  and  1806 LC for 0.73 DMIPS/Mhz

For the fast versions of the SoC, i got 1.30 DIPS/Mhz @ 114 Mhz (synthesis) on the Igloo2 and 1.27 DMIPS/Mhz @ 27Mhz on UP5K

[Charles Papon]

It would be interresting to add the performance (DMIPS/Mhz + cycle per instruction kind) of the SoC which target a small area, as (probably) reducing the area to those extends is about trading performances ? 

Le vendredi 16 novembre 2018 12:22:16 UTC+1, Antti Lukats a écrit :

[Charles Papon]

Oups, @ 27Mhz is wrong, should be @ 26Mhz

Le vendredi 16 novembre 2018 12:22:16 UTC+1, Antti Lukats a écrit :

[Nelson Ribeiro]

Hi Charles.

Can you disclose which is you critical path (performance for Lattice device)? 

I know I could run the tools, since your repository is public... but it is quicker to ask...

BR,

Nelson

--
You received this message because you are subscribed to the Google Groups "RISC-V Soft CPU Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softcpu-discu...@riscv.org.
To post to this group, send email to softcpu...@riscv.org.
Visit this group at https://groups.google.com/a/riscv.org/group/softcpu-discuss/.
To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/softcpu-discuss/2cd212e0-33d5-40bc-960f-00be29b750e4%40riscv.org.
For more options, visit https://groups.google.com/a/riscv.org/d/optout.

[Antti Lukats]

On Friday, 16 November 2018 14:35:55 UTC+1, Charles Papon wrote:

It would be interresting to add the performance (DMIPS/Mhz + cycle per instruction kind) of the SoC which target a small area, as (probably) reducing the area to those extends is about trading performances ? 

Charles, you are only scored on Absolute not DMIPS/MHz :) 

I updated the table

g

Antti

[Charles Papon]

No worries Nelson, also the uploaded netlist isn't necesserly updated, just got 28 Mhz.

The critical path is a mix between branch prediction (in the first fetch stage) and branch correction (in the memory stage). I don't use cache, but used the SPRAM.

And you ? How is it going ?

Thanks Antii ^^

About the Absolute DMIPS, igloo2 => 256176   up5k => 62920

[Charles Papon]

There is/was a lot of social movment around the area focused implementation, but not so much around the performance one XD

[Nelson Ribeiro]

The following hint may work for some, and may not work for others, but here it goes:

For the 32-bit divider you may gain some clock cycles by using something like a table which contains the results for small numbers, because Dhrystones only use small numbers! Instead of waiting 32 to 34 clock cycles for the result you just need 2 or 3.

type rom_t is array (15 downto 0) of std_logic_vector(3 downto 0); 

 type divtab_t is array (15 downto 0) of rom_t; 

 signal s_divtab_s : divtab_t := ( ((0), (0 / 1), (0 / 2), (0 / 3), (0 / 4), (0 / 5), (0 / 6), (0 / 7), (0 / 8), (0 / 9), (0 / 10), (0 / 11), (0 / 12), (0 / 13), (0 / 14), (0 / 15)), ((0), (1 / 1), (1 / 2), (1 / 3), (1 / 4), (1 / 5), (1 / 6), (1 / 7), (1 / 8), (1 / 9), (1 / 10), (1 / 11), (1 / 12), (1 / 13), (1 / 14), (1 / 15)), ((0), (2 / 1), (2 / 2), (2 / 3), (2 / 4), (2 / 5), (2 / 6), (2 / 7), (2 / 8), (2 / 9), (2 / 10), (2 / 11), (2 / 12), (2 / 13), (2 / 14), (2 / 15)), ((0), (3 / 1), (3 / 2), (3 / 3), (3 / 4), (3 / 5), (3 / 6), (3 / 7), (3 / 8), (3 / 9), (3 / 10), (3 / 11), (3 / 12), (3 / 13), (3 / 14), (3 / 15)), ((0), (4 / 1), (4 / 2), (4 / 3), (4 / 4), (4 / 5), (4 / 6), (4 / 7), (4 / 8), (4 / 9), (4 / 10), (4 / 11), (4 / 12), (4 / 13), (4 / 14), (4 / 15)), ((0), (5 / 1), (5 / 2), (5 / 3), (5 / 4), (5 / 5), (5 / 6), (5 / 7), (5 / 8), (5 / 9), (5 / 10), (5 / 11), (5 / 12), (5 / 13), (5 / 14), (5 / 15)), ((0), (6 / 1), (6 / 2), (6 / 3), (6 / 4), (6 / 5), (6 / 6), (6 / 7), (6 / 8), (6 / 9), (6 / 10), (6 / 11), (6 / 12), (6 / 13), (6 / 14), (6 / 15)), ((0), (7 / 1), (7 / 2), (7 / 3), (7 / 4), (7 / 5), (7 / 6), (7 / 7), (7 / 8), (7 / 9), (7 / 10), (7 / 11), (7 / 12), (7 / 13), (7 / 14), (7 / 15)), ((0), (8 / 1), (8 / 2), (8 / 3), (8 / 4), (8 / 5), (8 / 6), (8 / 7), (8 / 8), (8 / 9), (8 / 10), (8 / 11), (8 / 12), (8 / 13), (8 / 14), (8 / 15)), ((0), (9 / 1), (9 / 2), (9 / 3), (9 / 4), (9 / 5), (9 / 6), (9 / 7), (9 / 8), (9 / 9), (9 / 10), (9 / 11), (9 / 12), (9 / 13), (9 / 14), (9 / 15)), ((0), (10 / 1), (10 / 2), (10 / 3), (10 / 4), (10 / 5), (10 / 6), (10 / 7), (10 / 8), (10 / 9), (10 / 10), (10 / 11), (10 / 12), (10 / 13), (10 / 14), (10 / 15)), ((0), (11 / 1), (11 / 2), (11 / 3), (11 / 4), (11 / 5), (11 / 6), (11 / 7), (11 / 8), (11 / 9), (11 / 10), (11 / 11), (11 / 12), (11 / 13), (11 / 14), (11 / 15)), ((0), (12 / 1), (12 / 2), (12 / 3), (12 / 4), (12 / 5), (12 / 6), (12 / 7), (12 / 8), (12 / 9), (12 / 10), (12 / 11), (12 / 12), (12 / 13), (12 / 14), (12 / 15)), ((0), (13 / 1), (13 / 2), (13 / 3), (13 / 4), (13 / 5), (13 / 6), (13 / 7), (13 / 8), (13 / 9), (13 / 10), (13 / 11), (13 / 12), (13 / 13), (13 / 14), (13 / 15)), ((0), (14 / 1), (14 / 2), (14 / 3), (14 / 4), (14 / 5), (14 / 6), (14 / 7), (14 / 8), (14 / 9), (14 / 10), (14 / 11), (14 / 12), (14 / 13), (14 / 14), (14 / 15)), ((0), (15 / 1), (15 / 2), (15 / 3), (15 / 4), (15 / 5), (15 / 6), (15 / 7), (15 / 8), (15 / 9), (15 / 10), (15 / 11), (15 / 12), (15 / 13), (15 / 14), (15 / 15))

For the 64-bit multiplier you can do similar table, but the gain is not much. Although, Lattice DSP block is not very good for implementing the 3 mulxx instructions in an eficitn manner (for example for Spartan6 device I need 5 DSP48 + 10LUTS), but if you want to achieve 50MHz, my advice is to not to used them, use a serial version instead with a small table with the pre-computed results needed for Dhrystones (you would get the result in 2 or 3.cycles).

My project is really messy right now... As I also said in another thread, I had a design, which is a derivative work of someone else's work (not RISC-V architecture) which is distributed with GPL licence, and so I can't summit it to the contest, and I gave up starting from scratch since I wasted too much time in the SW infrastructure ( compliance tests, Zephyr OS, Dhrytosnes)

BR,

Nelson

 

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/softcpu-discuss/d89ec698-9676-4a33-8688-1882c2ea197e%40riscv.org.

[Antti Lukats]

On Friday, 16 November 2018 16:15:29 UTC+1, Charles Papon wrote:

There is/was a lot of social movment around the area focused implementation, but not so much around the performance one XD

You right,

I bet because the real radhard guys doing the performance version are inherently more silent ! 

g

Antti

 

[Charles Papon]

Hoo, for the divider trick, i already knew about it, but for me, it feel like cheating, as it realy exploit a weakness of the dhrystone benchmark. So i could implement it, it would save 33 cycles for each dhrystone iteration which would increase the DMIPS by 7.7%, but if i do it, it would be explicitly in the readme + the dhystone score with and without.

For the multiplication, the only gain in my case would be to have the result bypassed 2 stage in advance, which would only save 4 cycles per dhrystone iteration.

So, another trick is that normaly with the riscv gcc you can set the GP register close to the global variable used by the dhrystone benchmark. I don't know why, this optimisation isn't enabled in the GCC packet with the zephyr SDK. But you can map your data memory at the offset zero to have something similar. It five few % boost.

About the software infrastructure, yes for me it was also a big time investment, hopefully i had already the RISC-V design working before the contest started, just improved some things in it. 

The time frame of the contest was way to short for people that had nothing in hand before it started :(

[Nelson Ribeiro]

Well, cheating on Dhrystones for me is: 

          using -flto flag switch on compilation and linking or 

          compiling the two files like "cat dhry_2.c > temp.c; cat dhry_1.c >> temp.c; gcc <usual flags> temp.c -o dhry.exe". 

Hope the organizers exclude submissions like these ones, because this is not permitted as per rules of Dhrystones (similar as the one that says that you can't use inline functions).

That hint that I showed is tuning your CPU for the benchmarks, in my opinion.  That is why I think that for performance, one should use also other benchmarks like Coremark, and others that shows the arithmetic capabilities.

So, now to get a bether DMIPS score you may need to write optimized versions of the functions strlen and strcmp (strcpy may not be necessary, since the -03 already optimizes the copy of constant strings to other string variables).

BR,

Nelson 

 

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/softcpu-discuss/1c31ffbb-a4e4-4f6f-bf14-4131dcd1ca67%40riscv.org.

[Antti Lukats]

On Friday, 16 November 2018 16:50:55 UTC+1, Charles Papon wrote:

Hoo, for the divider trick, i already knew about it, but for me, it feel like cheating, as it

weak benchmark being chosen is not something to worry for the contestants, so implementing a divider that has "optimized" cycle per divide, sure adding special comment about it nice, but would really not count as real cheating.

 

realy exploit a weakness of the dhrystone benchmark. So i could implement it, it would save 33 cycles for each dhrystone iteration which would increase the DMIPS by 7.7%, but if i do it, it would be explicitly in the readme + the dhystone score with and without.

For the multiplication, the only gain in my case would be to have the result bypassed 2 stage in advance, which would only save 4 cycles per dhrystone iteration.

So, another trick is that normaly with the riscv gcc you can set the GP register close to the global variable used by the dhrystone benchmark. I don't know why, this optimisation isn't enabled in the GCC packet with the zephyr SDK. But you can map your data memory at the offset zero to have something similar. It five few % boost.

thats cool

 

About the software infrastructure, yes for me it was also a big time investment, hopefully i had already the RISC-V design working before the contest started, just improved some things in it. 

The time frame of the contest was way to short for people that had nothing in hand before it started :(

Well for me:

- never run any riscv code on any platform or simulator before

- designed from scratch own simulator

- zero experience with zephyr

- no riscv rtl code to derive the design from

however

15+ years experience with Microsemi and Lattice (35 years!?)

For those with no Microsemit/Lattice experience and nothing on hand for riscv/zephyr the workload was really high, with lots of time wasted on "secondary tasks"

g

Antti

[Charles Papon]

Right, it's not technicaly cheating i agree, but it feel like ^.^

"strlen and strcmp" => which open the door to custom instruction to make it faster, but is it allowed ? And is it even fair to change the default implementation of strlen and strcmp ?
Nom nom nom https://github.com/SpinalHDL/VexRiscv#add-a-custom-instruction-to-the-cpu-via-the-plugin-system

Sooooo many holes XD

[Antti Lukats]

On Friday, 16 November 2018 17:20:31 UTC+1, Charles Papon wrote:

Right, it's not technicaly cheating i agree, but it feel like ^.^

"strlen and strcmp" => which open the door to custom instruction to make it faster, but is it allowed ? And is it even fair to change the default implementation of strlen and strcmp ?

 

Nom nom nom https://github.com/SpinalHDL/VexRiscv#add-a-custom-instruction-to-the-cpu-via-the-plugin-system

Sooooo many holes XD

well the riscv dhrystone pulls in syscalls.c that implements its own strcmp, returning 1 there would be real cheating ;)

I assume that this files must be used as it is coming from official riscv benchmarking repo

g

Antti 

[Nelson Ribeiro]

Common sense on using Dhrystones as a benchmark for small CPU cores from the original sources is to make as little as possible changes (you may change the malloc lines, the call to the time function, you can print more information like DMISP/MHz),  but no changes are allowed inside the timed loop! 

Cannot use function inline and cant use -flto or append the two files into one and compile the final file. 

Generically speaking, you may supply your own start.S or crt.S plus some library code. For some CPU targets, I only compile bintutils and GCC for 1st stage (I do not compile newlib), so I have to supply functions like strlen.c, strcmp.c and strcpy, and sometimes the arithmetic functions for multiplication and division.

Charles, you make a good point with custom instructions, but I don't know if GCC version 6.1.0 (Zephyr version) has support for them (I know that at some point it existed the opcodes custom0, costum1... in binutils, but meanwhile I believe that they were removed)

BR,

Nelson

--

You received this message because you are subscribed to the Google Groups "RISC-V Soft CPU Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softcpu-discu...@riscv.org.
To post to this group, send email to softcpu...@riscv.org.
Visit this group at https://groups.google.com/a/riscv.org/group/softcpu-discuss/.

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/softcpu-discuss/d3c5fbb0-cfbe-45f9-8232-b880a9831577%40riscv.org.

[Antti Lukats]

On Friday, 16 November 2018 18:12:49 UTC+1, Nelson Ribeiro wrote:

Common sense on using Dhrystones as a benchmark for small CPU cores from the original sources is to make as little as possible changes (you may change the malloc lines, the call to the time function, you can print more information like DMISP/MHz),  but no changes are allowed inside the timed loop! 

Cannot use function inline and cant use -flto or append the two files into one and compile the final file. 

Generically speaking, you may supply your own start.S or crt.S plus some library code. For some CPU targets, I only compile bintutils and GCC for 1st stage (I do not compile newlib), so I have to supply functions like strlen.c, strcmp.c and strcpy, and sometimes the arithmetic functions for multiplication and division.

well strlen is provided by the syscalls.c from the same repo where riscv dhrystone is, so I assumed that using that syscalls.c (with minimal changes) would be the safest?

 

Charles, you make a good point with custom instructions, but I don't know if GCC version 6.1.0 (Zephyr version) has support for them (I know that at some point it existed the opcodes custom0, costum1... in binutils, but meanwhile I believe that they were removed)

BR,

Nelson

GCC 6.1. 0 ???

I assumed so far that taking GCC from there

https://gnu-mcu-eclipse.github.io/toolchain/riscv/

would be OK too, but do you want to say that I really have to find a way to compile the cross compiler on Windows PC from source? I do not know where to get 6.1.0 binaries for windows :(

fiddling around with the cross compiler add one more day of work at least :(

g

Antti 

[Eric Smith]

On Fri, Nov 16, 2018 at 8:50 AM Charles Papon <charles....@gmail.com> wrote:

The time frame of the contest was way to short for people that had nothing in hand before it started :(

I had nothing in hand before it started, although I did hack up an Intel 8089 assembler (yes, 8089) that I wrote in Python a few years ago, to repurpose it for use in developing my core.

In the time available, I didn't think I could develop a credible high-performance core, which is why I chose to work on the area-focused category, where I believed I had some worthwhile implementation ideas. I'm still not certain that I can complete it on time, but I'm optimistic.

If I were one of the contest judges, and had any discretionary style penalty points to award, I'd give as many as possible to my entry!

Eric

[Eric Smith]

On Fri, Nov 16, 2018 at 4:22 AM Antti Lukats <antti....@gmail.com> wrote:

I was pretty close estimating that Eric beats me by factor 2...

And I'm quite surprised at that, given that you have a _lot_ more FPGA expertise than I do. Perhaps we aren't designing using the same sort of microarchitecture.

 

Preliminary data of course, will change a bit still.

Definitely.

I'm not sure what "TrapEmu*" means. My core does implement ECALL, EBREAK, and FENCE/FENCEI. I think it will be fully compliant with the User Level ISA spec v2.2, but not fully compliant with the privileged ISA spec.

On the Microsemi, I'll use Cortex-M assisted boot, assuming that I can get it working quickly.  I haven't yet decided how best to boot on Lattice. I suppose I'll probably use either SPI or UART.

Eric

[Antti Lukats]

On Friday, 16 November 2018 18:26:51 UTC+1, Eric Smith wrote:

On Fri, Nov 16, 2018 at 8:50 AM Charles Papon <charles....@gmail.com> wrote:

The time frame of the contest was way to short for people that had nothing in hand before it started :(

I had nothing in hand before it started, although I did hack up an Intel 8089 assembler (yes, 8089) that I wrote in Python a few years ago, to repurpose it for use in developing my core.

8089 is one of the things I did not get my hands on, I guess it did not penetrate the iron curtain at all (most other stuff did).

 

In the time available, I didn't think I could develop a credible high-performance core, which is why I chose to work on the area-focused category, where I believed I had some worthwhile implementation ideas. I'm still not certain that I can complete it on time, but I'm optimistic.

if you have SF2 hardware, I't may be that I can release the M3 assisted example project soon enough for you to use, it basically pre-loads FPGA fabric RAM, and eSRAM so that RISC-V would see them pre-initialized when it starts. If you have IGLOO2, well bootstrap from SPI is possible easiest boot option, but you still need to debug the AHB to eSRAM..

and there is no demo how or guide how to flash the SPI flash on creative board, so it all adds extra work (time!)

 

If I were one of the contest judges, and had any discretionary style penalty points to award, I'd give as many as possible to my entry!

Eric

ROTFL, make it count Eric!

g

Antti

 

[Nelson Ribeiro]

Antti, you need to use the gcc provided by Zphyr OS, which only runs in linux. It is in the rules. I am on my mobile phone, cant provide link right now. 

I lost a lot of time trying to compile Zephyr SDK for windows, using msys2, which is not possible, or at least really really hard.. so I'd get window binary...

BR,

Nelson

--
You received this message because you are subscribed to the Google Groups "RISC-V Soft CPU Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softcpu-discu...@riscv.org.
To post to this group, send email to softcpu...@riscv.org.
Visit this group at https://groups.google.com/a/riscv.org/group/softcpu-discuss/.

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/softcpu-discuss/CAFrGgTTgx%2BFakLo2%3D5dYGprPLWEXMfSV6Tq8Z9xh%2BowkydryGw%40mail.gmail.com.

[Antti Lukats]

On Friday, 16 November 2018 18:38:57 UTC+1, Nelson Ribeiro wrote:

Antti, you need to use the gcc provided by Zphyr OS, which only runs in linux. It is in the rules. I am on my mobile phone, cant provide link right now. 

I lost a lot of time trying to compile Zephyr SDK for windows, using msys2, which is not possible, or at least really really hard.. so I'd get window binary...

BR,

Nelson

Oh noo, so the rules really force us to compile the GCC from scratch on linux ? Ok, I add one more day to the to-do before deadline.

I did not see zephyr providing GCC, as I am running Zephyr with ninja on windows..

thank you, and I try not to give up, but it is going to be close call for me too

Antti

 

[Charles Papon]

Technicaly, you can implement the strcmp and other function directly in assembly (crt.S), where you can feed the binarry with a .word which is in fact your custom instruction.

[Nelson Ribeiro]

You dont need to compile it. Binary files are provided. You just need to install them.

Br,

Nelson 

--

You received this message because you are subscribed to the Google Groups "RISC-V Soft CPU Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softcpu-discu...@riscv.org.
To post to this group, send email to softcpu...@riscv.org.
Visit this group at https://groups.google.com/a/riscv.org/group/softcpu-discuss/.

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/softcpu-discuss/9483745e-e384-4bcd-afbf-71b47af78fc3%40riscv.org.

[Antti Lukats]

On Friday, 16 November 2018 18:48:01 UTC+1, Nelson Ribeiro wrote:

You dont need to compile it. Binary files are provided. You just need to install them.

Br,

Nelson 

RISC-V GCC binary files inside Zephyr 1.13 github? I did not see them there.

OK, I have to investigate it. For sure if you use Zephyr 1.13 on windows you do not see anything about GCC 6.1.0

Antti

[Nelson Ribeiro]

https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/

Just download and install zephyr-sdk-0.9.5-setup.run

I have a script that does this automatically (change 0.9.3 for 0.9.5):

pushd . mkdir zephyr-sdk && cd zephyr-sdk wget https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/download/0.9.3/zephyr-sdk-0.9.3-setup.run sudo sh zephyr-sdk-0.9.3-setup.run export ZEPHYR_TOOLCHAIN_VARIANT=zephyr export ZEPHYR_SDK_INSTALL_DIR=/opt/zephyr-sdk popd This is for default dir instalation (/opt/zephyr-sdk ). For the location where are the binaries, libs,... check https://github.com/SpinalHDL/riscvSoftcoreContest/blob/master/software/dhrystone/up5kPerf/makefile, there are hints there. Nelson

--

You received this message because you are subscribed to the Google Groups "RISC-V Soft CPU Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softcpu-discu...@riscv.org.
To post to this group, send email to softcpu...@riscv.org.
Visit this group at https://groups.google.com/a/riscv.org/group/softcpu-discuss/.

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/softcpu-discuss/4c8a625c-1276-4b08-abb4-511689dede97%40riscv.org.

[Nelson Ribeiro]

That is very interesting. I did not thought about that.

.

I am aware that Xilinx introduced a specific instruction that helps in the string manipulation case: pattern compare byte find, which is easy to implement. 

If interested, please check https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=tree;f=newlib/libc/machine/microblaze;h=f7e8509254afb0fb0373d18a095e7b76c3794bd4;hb=HEAD, files strlen.c, strcmp.c and strcpy.c. 

if someone ports the functions to risc-v, and impediments that instructrion will also get small boost in the DMIPS/MHz metric. If implementing the instruction does affects maximum working frequency, you also  get a boost in the total/absolute DMIPS.

Nelson.

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/softcpu-discuss/96f1a6ac-eef2-4407-854f-4e80dea1303f%40riscv.org.

[Nelson Ribeiro]

I want to mention this issue with the  provided  Zephyr RISC-V GCC (I believe it was found and reported by Charles) :

https://github.com/zephyrproject-rtos/meta-zephyr-sdk/issues/110

This only happen if you are using rv32i (there is no issue if you use rv32im). 

It is a bit weird that not much people noticed this...

Nelson

[Tommy Thorn]

(Sorry for the hyperbole, but I'm trying to attract a response from the organizers)

Thanks for sharing.  It's telling that few noticed.

It does seem like a pretty serious issue that needs addressing by the organizers right away.  

Stating the obvious: the rules makes a big deal out of using the Zephyr SDK.  This bug

means that a RV32I core cannot work, thus forcing all entries to be RV32IM, contradicting

the contest description which states 

  "The entries will be RV32I-compliant soft CPUs. The core can support other standard

    extensions (e.g. ‘C’ or ‘M’) if the designers decide to do so."

So, which one is it?

Tommy

[Frank Buss]

Well, someone noticed it 10 days ago, the github issue is from the SpinalHDL guy. I noticed it as well for my C emulator, with the qemu target. But maybe with a custom target and some linker file and GCC compiler option magic this could be fixed?

[Olof Kindgren]

Den fredag 16 november 2018 kl. 16:50:55 UTC+1 skrev Charles Papon:

Hoo, for the divider trick, i already knew about it, but for me, it feel like cheating, as it realy exploit a weakness of the dhrystone benchmark. So i could implement it, it would save 33 cycles for each dhrystone iteration which would increase the DMIPS by 7.7%, but if i do it, it would be explicitly in the readme + the dhystone score with and without.

For the multiplication, the only gain in my case would be to have the result bypassed 2 stage in advance, which would only save 4 cycles per dhrystone iteration.

I would definitely not consider that cheating. Without any data to back me up, I would guess that most real-world mul and divs operate on smaller numbers. Having a performance boost for those would definitely make sense outside of Dhrystone as well

[Antti Lukats]

Hi Tommy,

1) if zephyr SDK GCC emits MUL this does not mean the core has to support MUL, you can trap on MUL and emulate it.

You can not use trap emulation on RV32I instructions as you would not pass cleanly the compliance test suite, but you can for sure emulate MUL.

2) the rules to no mention Zephyr SDK (I have checked it many times, last time 2 minutes ago) - if the organizers and judges enforce the actual use of "zephyr SDK GCC" then it means that all those participants who made a commitment to submit an entry when they applied for free board working on Windows PC are s*****, as Zephyr SDK enforces Linux use. If this happens that means the organizers are organizing a Windows ws Linux war with the contest.

1) Standard RISC-V mainstream GCC crosscompiler toolchain

2) precompiled verilator binaries

3) github distribution of Zephyr RTOS installation tagged 1.13

the above all work without any issues on windows without the need to recompile any c compilers.

If Zephyr SDK GCC is enforced, then:

1) windows users would need to recompile outdated and "pulpino patched" old GCC using MINGW, I know some have tried and failed, I will not not even try this would be suicide in this time-frame what is left

2) use linux binary installer and implement MUL emulation by trap code, I can not estimate if I can manage that in the time left til deadline

I will send separate email to the organizers email from the contest web-page also regarding this issue.

I was prepared to actually run the "zephyr binary distro" but I did not assume that this MUL issue pops up..

Antti

 

[Nelson Ribeiro]

One of the reasons that I quit'ed the contest was because I lost about 15 hours (one week real time ) to try to get Zephyr GCC working for Windows 7, realizing that binaries for Linux were provided, which means that much of work to be done must be done in Linux.  And I realized this by the end of October.

Which meant that I had to start using Bash scripts and Makefile's, which I am not that proficient, and lost another 10-15 hours or so doing that (another week). Currently I am having personal problems, and so I don't have free time anymore to work for the contest, and I know I made bad decisions in terms of time management, but it was due mainly because of lack of information about Zephyr SDK GCC...

Nelson

[Tommy Thorn]

Thanks Antti,

I didn't intend to criticize your page; I just thought you were using a different version and I listed
my differences for completeness.

> 2) the rules to no mention Zephyr SDK (I have checked it many times, last time 2 minutes ago) - if the organizers and judges enforce the actual use of "zephyr SDK GCC" then it means that all those participants who made a commitment to submit an entry when they applied for free board working on Windows PC are s*****, as Zephyr SDK enforces Linux use. If this happens that means the organizers are organizing a Windows ws Linux war with the contest.

Allow me to address this one. I was puzzled that I had a different interpretation so I reread the rules again:

"For the “highest-performance implementation” categories, the performance of the entries will be measured using the Dhrystone benchmark compiled with the -O3 -fno-inline option.

...

Minimum Requirements

... The design must be a complete FPGA implementation targeting at least one of the two platforms and run the provided Zephyr RTOS application. The Zephyr 1.13 release should be used and can only be modified in a way that does not touch the OS core. Any modifications to the standard RISC-V GCC provided by Zephyr are strictly forbidden."

I read the "The Zephyr 1.13 release should be used ... Any modifications to the standard RISC-V GCC provided by Zephyr are strictly forbidden." paragraph as applying to the compilation of Dhrystone. If that's a misinterpretation, that's a great relief.

Thanks,
Tommy

[Tommy Thorn]

On Nov 19, 2018, at 01:10 , Nelson Ribeiro <ngrr.r...@gmail.com> wrote:

One of the reasons that I quit'ed the contest was because I lost about 15 hours (one week real time ) to try to get Zephyr GCC working for Windows 7, realizing that binaries for Linux were provided, which means that much of work to be done must be done in Linux.  And I realized this by the end of October.

I feel your pain.  This contest is supposed to be about the core, but at least for me most of the time have been spent dealing with the Zephyr software, learning a completely new FPGA, and learning a completely new FPGA tool chain.  I'm not sure I'll be able to complete an entry.

On the bright side, I've learned a few things already so there's that.

Tommy

--
You received this message because you are subscribed to the Google Groups "RISC-V Soft CPU Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softcpu-discu...@riscv.org.
To post to this group, send email to softcpu...@riscv.org.
Visit this group at https://groups.google.com/a/riscv.org/group/softcpu-discuss/.

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/softcpu-discuss/CAPvktdU2vJazk5c_z4x__ZAhhEv4RR93XbvC-nKL-RCphQKxzg%40mail.gmail.com.

[Antti Lukats]

On Monday, 19 November 2018 10:13:06 UTC+1, tommy wrote:

Thanks Antti,

I didn't intend to criticize your page; I just thought you were using a different version and I listed
my differences for completeness.

cool, thanks again - the wiki pages are way too much abandoned WIP, and include only random info from my knowledge perspective, well not proud of, I am bad at writing newbie style documentation, or it takes more time then I usually have.

 

> 2) the rules to no mention Zephyr SDK (I have checked it many times, last time 2 minutes ago) - if the organizers and judges enforce the actual use of "zephyr SDK GCC" then it means that all those participants who made a commitment to submit an entry when they applied for free board working on Windows PC are s*****, as Zephyr SDK enforces Linux use. If this happens that means the organizers are organizing a Windows ws Linux war with the contest.

Allow me to address this one.  I was puzzled that I had a different interpretation so I reread the rules again:

"For the “highest-performance implementation” categories, the performance of the entries will be measured using the Dhrystone benchmark compiled with the -O3 -fno-inline option.

This is actually insufficient statement..

 

...

Minimum Requirements

... The design must be a complete FPGA implementation targeting at least one of the two platforms and run the provided Zephyr RTOS application. The Zephyr 1.13 release should be used and can only be modified in a way that does not touch the OS core. Any modifications to the standard RISC-V GCC provided by Zephyr are strictly forbidden."

I read the "The Zephyr 1.13 release should be used ... Any modifications to the standard RISC-V GCC provided by Zephyr are strictly forbidden." paragraph as applying to the compilation of Dhrystone.  If that's a misinterpretation, that's a great relief.

Thanks,
Tommy

I think that if you compile Dhrystone with standard unmodified GCC retrieved from the resource links provided from the web pages of RISC-V Foundation - and your entry gets disqualified because of that (wrong C compiler) then any LAW student would win a case in your benefit. Maybe I am wrong here.

There is no "salvatorische klausel" applied to the rules, but you can think as it would be, that means if something is nonsense then the rest is still valid.

If Zephyr SDK GCC forces RV32IM to be implemented then this would mean that the zephyr GCC requirement is invalid, and the RV32I requirement prevails.

Again maybe I am wrong here.

Antti

I have not studied LAW, I have had exactly one lesson of English (honestly), there I was asked to spell LOVE, I did spell it: L A W

boy was that :( well long time ago..

[Charles Papon]

No, don't worry, everything is more or less fine.

For RV32I entries, the __divdi3 stuff is added by the compiler when you use a 64 bits software division, which only appear in my dhrystone benchmark because i added some code to print the DMIPS/Mhz.

You can workaround this issue with the following code : https://github.com/SpinalHDL/riscvSoftcoreContest/blob/f4f5b5b5de7c2862912612d6af8086d2075fb357/software/dhrystone/up5kArea/src/stdlib.c#L97

Then to use the zephyr SDK RISC-V GCC in RV32I mode, you need to add the -march=RV32I flag for the compilation. To compile the zephyr app them self you can do as following : https://github.com/SpinalHDL/zephyr/blob/486f68fa4f843307eac6bb7d429a4c4023e566b5/arch/riscv32/soc/riscv-privilege/vexriscv/Kconfig.defconfig.vexriscv_contest_up5karea#L7

I hope that will help :)

[Antti Lukats]

On Monday, 19 November 2018 10:31:27 UTC+1, Charles Papon wrote:

No, don't worry, everything is more or less fine.

For RV32I entries, the __divdi3 stuff is added by the compiler when you use a 64 bits software division, which only appear in my dhrystone benchmark because i added some code to print the DMIPS/Mhz.

DMIPS/MHz is not used for the scoring.. no need to add things that cause trouble (ok you have your workaround)

 

You can workaround this issue with the following code : https://github.com/SpinalHDL/riscvSoftcoreContest/blob/f4f5b5b5de7c2862912612d6af8086d2075fb357/software/dhrystone/up5kArea/src/stdlib.c#L97

Then to use the zephyr SDK RISC-V GCC in RV32I mode, you need to add the -march=RV32I flag for the compilation. To compile the zephyr app them self you can do as following : https://github.com/SpinalHDL/zephyr/blob/486f68fa4f843307eac6bb7d429a4c4023e566b5/arch/riscv32/soc/riscv-privilege/vexriscv/Kconfig.defconfig.vexriscv_contest_up5karea#L7

I hope that will help :)

cool, hm so the RV32IM requirement comes only from printing DMIPS/MHz ?

hm I was also forced to enable some 64 bit Long Long, that would then also trigger the issue? I spend several days fighting this already

Antti 

[Charles Papon]

I added the DMIPS/Mhz stuff for developpement reasons, it help traking the architecture performance without the frequancy factor :)

cool, hm so the RV32IM requirement comes only from printing DMIPS/MHz ?

Yes, but if you add the __divdi3 workaround, it can do down to RV32I. Just remember that i don't know if this hand written __divdi3 implementation work in all cases, but the the ranges of numbers i used, that was fine.

It probably don't work for negative numbers.

hm I was also forced to enable some 64 bit Long Long, that would then also trigger the issue? I spend several days fighting this already

From the moment you don't do 64 bits division/modulo/multiplication, it should be fine.

[Antti Lukats]

On Monday, 19 November 2018 10:11:00 UTC+1, Nelson Ribeiro wrote:

One of the reasons that I quit'ed the contest was because I lost about 15 hours (one week real time ) to try to get Zephyr GCC working for Windows 7, realizing that binaries for Linux were provided, which means that much of work to be done must be done in Linux.  And I realized this by the end of October.

Which meant that I had to start using Bash scripts and Makefile's, which I am not that proficient, and lost another 10-15 hours or so doing that (another week). Currently I am having personal problems, and so I don't have free time anymore to work for the contest, and I know I made bad decisions in terms of time management, but it was due mainly because of lack of information about Zephyr SDK GCC...

Nelson

Hi Nelson,

take care of whatever is important! 

The workload to get all requirements done,lets say without head-start and previous knowledge is really huge.

As project manager I would write invoice for 3 Man/Month for completing the contest entry (for microsemi+lattice platforms).

It would have been possible to reduce the amount of "unrelated work" and let everybody to focus on the SoftCPU, (but no one had the stamina to help out here, including myself), the tools actually work, complete setup of everything is less 1 day, but when you have to pull in all the pieces alone, it takes ages of frustration.

I have had endless fights with cygwin and mingw and would have never tried to cross compile zephyr GCC on windows, would have said that to you too, well too late, time wasted, I guess at many parties.

br

Antti

[Antti Lukats]

On Saturday, 17 November 2018 00:08:55 UTC+1, Nelson Ribeiro wrote:

https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/

Just download and install zephyr-sdk-0.9.5-setup.run

I have a script that does this automatically (change 0.9.3 for 0.9.5):

pushd . mkdir zephyr-sdk && cd zephyr-sdk wget https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/download/0.9.3/zephyr-sdk-0.9.3-setup.run sudo sh zephyr-sdk-0.9.3-setup.run export ZEPHYR_TOOLCHAIN_VARIANT=zephyr export ZEPHYR_SDK_INSTALL_DIR=/opt/zephyr-sdk popd This is for default dir instalation (/opt/zephyr-sdk ). For the location where are the binaries, libs,... check https://github.com/SpinalHDL/riscvSoftcoreContest/blob/master/software/dhrystone/up5kPerf/makefile, there are hints there. Nelson

Hi Nelson the link you did give is not 1.13 release, you can not use any newer SDK than 1.13 tagged on per contest rules.

can you point where Zephyr 1.13 GCC installer is located, I am on linux machine ready to install but failing to find the 1.13 installer :(

g

Antti 

[Nelson Ribeiro]

Well, when I wrote that script and realized that Zephyr SDK GCC had to be used, we were at the end of October and official release was then Zephyr SDK 0.9.3, which seems to me to be the official release by the time Zephyr 1.13 was released. Check the releases dates. Sorry, I do not have more information. Besides this forum, I don't talk to anyone else about the contest...

Nelson

--

You received this message because you are subscribed to the Google Groups "RISC-V Soft CPU Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softcpu-discu...@riscv.org.
To post to this group, send email to softcpu...@riscv.org.
Visit this group at https://groups.google.com/a/riscv.org/group/softcpu-discuss/.

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/softcpu-discuss/b3a67e93-c466-42ef-ba90-0c6b225eb75f%40riscv.org.

[Antti Lukats]

On Monday, 19 November 2018 12:09:20 UTC+1, Nelson Ribeiro wrote:

Well, when I wrote that script and realized that Zephyr SDK GCC had to be used, we were at the end of October and official release was then Zephyr SDK 0.9.3, which seems to me to be the official release by the time Zephyr 1.13 was released. Check the releases dates. Sorry, I do not have more information. Besides this forum, I don't talk to anyone else about the contest...

Nelson

Very complicated.

If the rules do not mention SDK or SDK release versions at all, how should it be determined ?

g

Antti 

[Matthew Ballance]

By the way, I found that I could add -march=RV32I to the CMakeLists.txt file for my SoC:

https://github.com/mballance/fwrisc-zephyr/blob/master/soc/riscv32/fwrisc/CMakeLists.txt

For me, at least, this caused the Zephyr SDK compiler to produce proper RV32I code without mul, div, etc.

-Matthew

--

You received this message because you are subscribed to the Google Groups "RISC-V Soft CPU Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to softcpu-discu...@riscv.org.
To post to this group, send email to softcpu...@riscv.org.
Visit this group at https://groups.google.com/a/riscv.org/group/softcpu-discuss/.

To view this discussion on the web visit https://groups.google.com/a/riscv.org/d/msgid/softcpu-discuss/60cf3e46-6462-4212-8447-34b045628d1f%40riscv.org.

[Olof Kindgren]

For the recode, my design called serv now boots on an FPGA. It's still lacking interrupts and a bootloader so I have only managed to run a single-threaded zephyr hello world so far. I don't have a up5k board to test with, so I'm trying out on a TinyFPGA BX (hx8k FPGA). As there is only 16KB onchip memory I don't think the larger applications will work with that even if I managed to finish the interrupt support. With that said it currently clocks in at 1066 LC and 18 4k RAM

//Olof

Den fredag 16 november 2018 kl. 12:22:16 UTC+1 skrev Antti Lukats:

Hi,

a teaser:

https://github.com/micro-FPGA/riscv-contest-2018/wiki

I was pretty close estimating that Eric beats me by factor 2...

Preliminary data of course, will change a bit still.

br

Antti

[Antti Lukats]

On Wednesday, 21 November 2018 14:59:26 UTC+1, Olof Kindgren wrote:

For the recode, my design called serv now boots on an FPGA. It's still lacking interrupts and a bootloader so I have only managed to run a single-threaded zephyr hello world so far. I don't have a up5k board to test with, so I'm trying out on a TinyFPGA BX (hx8k FPGA). As there is only 16KB onchip memory I don't think the larger applications will work with that even if I managed to finish the interrupt support. With that said it currently clocks in at 1066 LC and 18 4k RAM

//Olof

Olof you really need UP5K or microsemi as target FPGA for this contest. 

on HX8K you can easily run philosophers, by using XiP from flash, the onchip RAM is sufficient, but it would not count as entry in the main  4 categories

g

Antti