Newest update on the contest rules

[Nelson Ribeiro]

Hello everyone.

I am really, really disappointed with how the contest has been managed so far.

(please, take my next statements as a constructive complain...). 

Some bullet points on which I am disappointed:

   -- lack of information of what is allowed or not;

   -- metrics for area optimized target not defined;

   -- metrics for performance optimized target not defined;

   -- rules constantly being changed, with the contest already in place.

The new announcement says "After feedback from the community," but which community is that?

And where can I find such arguments/discussion that lead to exclusion of the three instructions: FENCE, ECALL and EBREAK ?

I don't even understand why the tests for  ECALL and EBREAK are difficult! Can someone clarify this to me?

I do understand why FENCE may be excluded: for the guys doing XIP from SPI Flash its a bit tricky because they needed also to implement the capability to write into the SPI Flash, but if they have already a module that does the read part, implementing the write part is easy, just takes a few more logic.

For the guys that are targeting performance, not having to implement the FENCE instruction changes a lot in the CPU architecture, 

  -- now the best solution is to implement a CPU with Harvard Architecture with no cache (since there is no need to access the instruction memory during the execution of a program from the data side)

  -- before the best solution to achieve better working frequency with a very good CPI was to implement a CPU with Harvard modified Architecture with cache, with the entire program and bootloader runnig from internal memory from behind the cache; 

Does the organizers though really through in this decision? Are they aware of the time that contestants may have spend in implementing cache for the contest?

And why change rules 10 days before deadline? At least the change should be properly explained... changing rules of a contest which is already in place because some contestants find difficult to follow some of the rules are not ethical at all!

BR

Nelson

  

[Frank Buss]

I agree, the contest is not handled very well. I just saw the remarks about I.FENCE, EBREAK and ECALL on the contest page, and looks like the FAQ is gone now, too. Would at least be nice if we get informed about such changes on this mailing list, so that we don't have to diff the contest page each day with the last version and get surprised by the changes.

[Antti Lukats]

Hi all,

and please mercy :) sorry I have try my best..

inline -->

g

Antti

On Friday, 16 November 2018 11:02:38 UTC+1, Nelson Ribeiro wrote:

Hello everyone.

I am really, really disappointed with how the contest has been managed so far.

(please, take my next statements as a constructive complain...). 

:) 

Some bullet points on which I am disappointed:

   -- lack of information of what is allowed or not;

I'd say it is same as from day 1: you pass the test cases and run Zephyr apps

Take as much as possible from the risc-v github apply minimal changes..

 

   -- metrics for area optimized target not defined;

 

   -- metrics for performance optimized target not defined;

I'd say it is same as from day 1: Dhrystone, be it Dhrystone or DMIPS the CPI and FMax are both relevant

 

   -- rules constantly being changed, with the contest already in place.

Actually rules have not changed ;)

 

The new announcement says "After feedback from the community," but which community is that?

And where can I find such arguments/discussion that lead to exclusion of the three instructions: FENCE, ECALL and EBREAK ?

FENCE.I - self modifying code

EBREAK - hw debugger?

ECALL - no known reason to exclude

 

I don't even understand why the tests for  ECALL and EBREAK are difficult! Can someone clarify this to me?

They are not. There is to my knowledge one implementation that invokes hardware debugger on EBREAK instruction, this one implementation would not run if EBREAK compliance is directly required. There is no known reason to make ECALL optional to my knowledge.

 

I do understand why FENCE may be excluded: for the guys doing XIP from SPI Flash its a bit tricky because they needed also to implement the capability to write into the SPI Flash, but if they have already a module that does the read part, implementing the write part is easy, just takes a few more logic.

No, FENCE.I actually pretty much prevents SPI XiP applications.

 

For the guys that are targeting performance, not having to implement the FENCE instruction changes a lot in the CPU architecture, 

  -- now the best solution is to implement a CPU with Harvard Architecture with no cache (since there is no need to access the instruction memory during the execution of a program from the data side)

  -- before the best solution to achieve better working frequency with a very good CPI was to implement a CPU with Harvard modified Architecture with cache, with the entire program and bootloader running from internal memory from behind the cache; 

uups, the SPI XiP issue seems to be very small compared to the issue for performance :(

from my understanding the best performance entry would not use cache, implement DIV/MUL and fetch always 64 bits from SPRAM/LSRAM per clock and execute more then 1 instruction per clock cycle, combining 2 instructions into one where possible., FENCE.I has no impact for that architecture

uuuuups - for those implementation that use wide cache and execute more than 2 instructions per one clock cycle FENCE.I comes really important issue.

Anyway, whatever it is, please blame only me (Antti Lukats) on the FENCE.I issue. I take responsibility making an issue out it, my fault. I assumed it has impact for some small designs, and did not think in depth enough for the impact on fast designs. 

Actually after some more thinking I would predict that small designs will not use SPI XiP anyway as other boot solution can save a few LUT.

However, failure on these tests will not prevent entry. Special consideration will be given to designs which pass all tests (including the optional ones) during the manual judging section.

 

I'd say it is still better to actually pass all tests clean, so everything is same as from day 1. Those small design that use SPI XiP would not be disqualified.

Does the organizers though really through in this decision? Are they aware of the time that contestants may have spend in implementing cache for the contest?

I think we have all spent more time we initially considered to be spent. I have. Much more. But I do not regret that, I am pretty happy actually. Time good spent.

I think you should implement the fast design the way you wanted, and not pay attention to some other solution that depends on FENCE.I and gains some speed benefit on this

 

And why change rules 10 days before deadline? At least the change should be properly explained... changing rules of a contest which is already in place because some contestants find difficult to follow some of the rules are not ethical at all!

I think we should all worry less :) the judges will use common sense in judgement. If there is close call where the FENCE.I makes difference it will be handled ethically correct.

BR

Nelson

  

[Charles Papon]

ECALL optional ? But it is used by the default Zephyr RISCV port ^^
https://github.com/zephyrproject-rtos/zephyr/search?q=ecall&unscoped_q=ecall

It's open bar for custom zephyr port XD

[Frank Buss]

On Friday, November 16, 2018 at 2:20:13 PM UTC+1, Charles Papon wrote:

ECALL optional ? But it is used by the default Zephyr RISCV port ^^
https://github.com/zephyrproject-rtos/zephyr/search?q=ecall&unscoped_q=ecall

It's open bar for custom zephyr port XD

Right, the rules are inconsistent now. Without ECALL you have to modify the core of Zephyr, because it is used for context switching for all RISCV platforms. But another rule says that you are not allowed to modify the core. So ECALL can't be optional.

[Nelson Ribeiro]

Antti, let say that the implementation of Fence.I is mandatory.

Again, I don't understand the issue with the XiP from SPI Flash. If you use a module (digital logic) that already issues (read) commands to the SPI flash, you just need to implement the write capability. I am a FPGA designer, but time to time I have to change linux kernel modules that makes use of SPI interfaces implemented in FPGA, I know what I am talking about because I implement solutions that requires read and write data from/to SPI Flash'es!  Its is 5x times much more difficult to build the infrastructure for Zephyr OS that implementing the write capability (at least from my perspective)! I understand that this adds logic, which is the opposite  that people that targets "least area possible" wants, but it is reasonable. You are exchanging external memory by logic after all!

EBREAK:

For HW debug, one can use a myriad of different solutions. So if someone had, previous to the contest, implemented a solution based in EBREAK, he had the exact same time to make a different implementation as another person that started from scratch. So do not understand the exclusion either!

ECALL:

It makes even less sense to exclude this compliance tests. My common sense is definitely different than the one from organizers.

Good luck for anyone that is implementing the architecture of fetching 64 bit each clocking cycle (and executing two instructions) in such device like the Lattice one. That architecture would run at maybe 10-20 MHz? I was targeting 40MHz to 50MHz (50 to 65 DMIPS), I doubt that architecture would be the best (did not tried the Microsemi devices). (Frequencies are estimated based in my experience with MachXO2 devices - I understand that the contest devices are completely different - so I may be a bit too confident here)

 

In the Lattice device the internal Block Rams are distributed so far apart, than in a proper balanced 5-stage pipeline CPU device, if you  do not use cache (8k/8k for inst and data), the critical path will be long for instantiating 32K of RAM (assuming that FENCE.I is mandatory, you need write access to all memory). You do not want to multiplex the lines from/to the internal logic to/from the internal memory blocks (EBR). Cache is the best solution!

Like I said previously, I already gave up on the contest, due to several factors... But I will continue working in my implementation  after the contest deadline...

So, I am just sad really (not mad...). This contest had so many things to be so much better managed... 

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/b3bda89e-a27f-499a-b5e3-6334e90f1954%40riscv.org.
For more options, visit https://groups.google.com/a/riscv.org/d/optout.

[Antti Lukats]

On Friday, 16 November 2018 14:37:15 UTC+1, Nelson Ribeiro wrote:

Antti, let say that the implementation of Fence.I is mandatory.

Again, I don't understand the issue with the XiP from SPI Flash. If you use a module (digital logic) that already issues (read) commands to the SPI flash, you just need to implement the write capability. I am a FPGA designer, but time to time I have to change linux kernel modules that makes use of SPI interfaces implemented in FPGA, I know what I am talking about because I implement solutions that requires read and write data from/to SPI Flash'es!  Its is 5x times much more difficult to build the infrastructure for Zephyr OS that implementing the write capability (at least from my perspective)! I understand that this adds logic, which is the opposite  that people that targets "least area possible" wants, but it is reasonable. You are exchanging external memory by logic after all!

Sorry - no, if you are running truly from XiP Flash with no writeable memory at all connected to the instruction bus, then implementing writeable flash functions while executing from the same flash add major amount of LUT taking account that small designs can potentially be as small as 150 LUT4. 

An easier option would be of course implementing ROM patching by storing the address of write and data, and later replacing that one instruction when fetched. Lots of ASIC and ROM based CPU/MCU use ROM patching.

 

EBREAK:

For HW debug, one can use a myriad of different solutions. So if someone had, previous to the contest, implemented a solution based in EBREAK, he had the exact same time to make a different implementation as another person that started from scratch. So do not understand the exclusion either!

I agree, but EBREAK should really not matter either way, if it is optional it means the hard-debugger logic does not need to be removed. There is not much other impact.

 

ECALL:

It makes even less sense to exclude this compliance tests. My common sense is definitely different than the one from organizers.

This is pure mystery to me :) no idea where this did come from..!

 

Good luck for anyone that is implementing the architecture of fetching 64 bit each clocking cycle (and executing two instructions) in such device like the Lattice one. That architecture would run at maybe 10-20 MHz? I was targeting 40MHz to 50MHz (50 to 65 DMIPS), I doubt that architecture would be the best (did not tried the Microsemi devices). (Frequencies are estimated based in my experience with MachXO2 devices - I understand that the contest devices are completely different - so I may be a bit too confident here)

 

You may be right here, FPGA architecture timing may make 2 instruction per clock not feasible..

 

In the Lattice device the internal Block Rams are distributed so far apart, than in a proper balanced 5-stage pipeline CPU device, if you  do not use cache (8k/8k for inst and data), the critical path will be long for instantiating 32K of RAM (assuming that FENCE.I is mandatory, you need write access to all memory). You do not want to multiplex the lines from/to the internal logic to/from the internal memory blocks (EBR). Cache is the best solution!

FENCE.I mandatory only means you need to implement ROM patching or cache invalidate

 

Like I said previously, I already gave up on the contest, due to several factors... But I will continue working in my implementation  after the contest deadline...

Doing things under time pressure is not fun, specially if unrelated fights (License setuo/FTDI drivers..) pop up.

Hope you have fun and motivation to work on at your pace.

 

So, I am just sad really (not mad...). This contest had so many things to be so much better managed... 

Timing and underestimation of the total "Scope of Work" for the contest. 

I would estimate the SoW to be 2-3 man/month, and yes to be done in 6 weeks deadline :)

Those with no "headstart" had little chances or really hard times to get all setup and ready to rock.

[Tommy Thorn]

The contest, like all contests, could be dramatically improved.  That

true, but it is what it is.  What I find intolerable is that one random

individual rants to the committee and they change the rules "based

on input from the community".  Nobody elected you to speak for

the community.

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/17d05e5e-ae2e-4d18-a141-f731bb6592b1%40riscv.org.

[Antti Lukats]

On Saturday, 17 November 2018 04:59:20 UTC+1, tommy wrote:

The contest, like all contests, could be dramatically improved.  That

true, but it is what it is.  What I find intolerable is that one random

individual rants to the committee and they change the rules "based

on input from the community".  Nobody elected you to speak for

the community.

Tommy

Dear Tommy,

I admire you for your courage and willingness to spell out loud what others did not, I did cross the line. You said it out, thank you for this it was badly needed. I am trying to live my life with "no-regrets" - but I would be glad if I could take back all my rantings, just to know that you would come and help me to clean up BBQ equipment in the backyard of my friends house in Milpitas say, December 5th? But I cant make things undone. 

I tried to make something better, but failed, it would have been better to-do just nothing. I could have realized that at the beginning, but did not. In any case I am not trying to speak for others. I have to admit that I suggested the extra prize, I did think that it is a good idea.

br

Antti