[Libre-soc-bugs] [Bug 1070] Simple-V / Libre-SOC FOSDEM Conference Feb 03-04 2024

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Mon Dec 4 18:40:15 GMT 2023


https://bugs.libre-soc.org/show_bug.cgi?id=1070

--- Comment #46 from Konstantinos Margaritis (markos) <konstantinos at vectorcamp.gr> ---
(In reply to Luke Kenneth Casson Leighton from comment #45)
> (In reply to Luke Kenneth Casson Leighton from comment #36)
> 
> > https://pretalx.fosdem.org/fosdem-2024/talk/review/
> > 7XKH3XHNHWBQ3H78CFX8GB9WRCTMMXLJ
> > 
> > Konstantinos Margaritis
> > 
> > https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-November/005799.html
> 
> konstantinos this is a great talk (just read the abstract) however as the
> abstract will be public can you please update it to be factually
> representative?
> thanks in advance.
> 
> i totally get the advantages of the approach, however it is complementary
> to existing techniques (DMI+JTAG interface i developed and used to test the
> FPGA and verilator), as well as the qemu VM technique developed by
> Lauri Kasanen, so the abstract should be representative and recognise that
> this is a complex extremely comprehensive project to which you have
> contributed.

It is factually representative, I claim nothing which is untrue. It is
impossible at the moment to test SVP64 instructions on FPGA, so I'm not even
touching that topic. And before you can even start testing user-space software
you would have to enable kernel support for SVP64, the actual CPU, the board,
fix the bootloader, before you can even start testing stuff like DCT or crypto.
So, in the case of finding potential problems with instructions, or even other
possible optimization opportunities, it might mean lost time in board
upbringing. I'm not demeaning the project, I'm just mentioning hard facts.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the libre-soc-bugs mailing list