Re:Unleashing Open-Source Silicon
by MayeulC on Monday November 25, 2019 @06:13PM
(#21633909)
Well, yes and no. Yes, FPGAs will always be slower than real HW (for the foreseeable future at least). But you can use a design taylored to your application (an accelerator indeed), whether it is a CPU, a GPU, a NIC or anything else, and get more performance out of it than silicon that's available today.
For instance: a custom RISC-V CPU with extensions for machine learning, whether it is for prototyping or not. Or a NIC with some complex routing capabilities, etc. And of course, I guess that various accelerators are indeed the main driver behind this.
I guess you could also run one of these devices you named without efficiency in mind: hardware/software validation, trusting trust, profiling, etc.
But the big part might also be: access to big FPGAs at a fraction of the cost you usually need to shell out to get them, which in turns enables more regarding design verification, etc. for Open source HW, and maybe bypass the annoying vendor-specific tools for a cleaner API, with a hassle-free experience. Can we directly modify the bytecode with this?
Re:Unleashing Open-Source Silicon
by code_code on Monday November 25, 2019 @06:49PM
(#21634213)
I've generally wondered about extensions for RTOS support. Special kinds of priority-encoders off registers for flags; shared-memory locks; -- that sort of thing.
For instance: a custom RISC-V CPU with extensions for machine learning, whether it is for prototyping or not. Or a NIC with some complex routing capabilities, etc. And of course, I guess that various accelerators are indeed the main driver behind this.
I guess you could also run one of these devices you named without efficiency in mind: hardware/software validation, trusting trust, profiling, etc.
But the big part might also be: access to big FPGAs at a fraction of the cost you usually need to shell out to get them, which in turns enables more regarding design verification, etc. for Open source HW, and maybe bypass the annoying vendor-specific tools for a cleaner API, with a hassle-free experience. Can we directly modify the bytecode with this?