Re: [libre-riscv-dev] next tasks

[Jacob Lifshay <programmerjake@gmail.com>]

On Thu, Mar 12, 2020, 07:44 Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:

> On Thu, Mar 12, 2020 at 2:32 PM Hendrik Boom <hendrik@topoi.pooq.com>
> wrote:
> >
> > On Thu, Feb 20, 2020 at 09:39:21AM +0200, Lauri Kasanen wrote:
> > > On Wed, 19 Feb 2020 14:14:16 +0000
> > > Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > >
> > > > we only have a few months in which to hang together all of the pieces
> > > > that have been put together, to make a 64-bit 180nm chip.  because
> > > > we're not doing this in verilog i believe it is reasonably doable, if
> > > > we take steps to cut "unnecessary" things out i.e. not do too much.
> > > > chop out L2 cache for example.
> > >
> > > What about the C/C++ simulator/interpreter timeline? It's not a blocker
> > > for the hw tapeout, but it is a blocker for my work, which probably
> > > mostly won't make it for the simple Oct tapeout anyway.
>
> correct.  it's on a separate track.
>
> > Or a simulation of the new SoC instruction set in C/C++?
>
> to start from an existing power isa simulator (gem5 for example), that
> simulator *happens* to be written in c or more likely c++, therefore
> simulated vector and VPU instructions *have* to be written in c / c++.
>
> otherwise we need to create - from scratch - an entire new POWER ISA
> cycle-accurate instruction simulator, which would be a genuinely
> stupid thing to spend time on given that there are a number of such
> simulators in existence already.  including qemu.
>

Note that qemu is by-design not a cycle-accurate simulator -- it is
specifically designed to go as fast as possible rather than matching timing
with any particular CPU.

If we decide to create our own simulator, it might be a good idea to write
it in rpython or similar since that has an optimizing JIT trace compiler
that can effectively speed up any interpreter/simulator. That's what's used
to implement PyPy -- it's basically just a python interpreter written in
rpython.

If we decide we don't want rpython, then I would suggest Rust -- I've
already started writing a cycle-accurate CPU simulator to test out my idea
for making a spectre-proof cpu (I stopped since it was taking longer than a
few days):
https://salsa.debian.org/Kazan-team/spectre-resistant-speculative-processor

Jacob
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev