[Libre-soc-dev] video assembler

[Luke Kenneth Casson Leighton]

On Mon, May 10, 2021 at 4:05 PM Lauri Kasanen <cand at gmx.com> wrote:

> By file access I meant "load the contents of this file to the simulated
> memory here" and "save the contents of simulated memory here, size N, to
> this file".

ah yes, that's perfectly possible

> Which is comparable to other hw simulators of similar
> ability. I'm sure it can be hacked by directly editing the python when
> running, but explicit support is user-friendly.

we'll basically have to make it up as we go along.

> Such an isolated simulator is on the edge of whether it makes sense to
> act now or not. Having to isolate each func, and extract various test
> data gets old fast (vs running a full binary against full files).

interestingly, the very first time i saw cocotb was with a JPEG
hardware example!
https://github.com/chiggs/oc_jpegencode

this *actually* does co-simulation of opencores JPEG encoder, extracts
the memory from it, then compares the result against python-imaging
library!

extremely cool.

that's the level we're at, basically.

> Running a full ffmpeg binary is certainly not possible under it.

no - no chance, and we really don't want to be.  even under say
power-gem5, the resources involved and the binary size is enormous.
hundreds of thousands if not millions of instructions would be
executed before we even got close to the actual code needed to be
tested.

now further down the *line* that's exactly what we want - need - to do
- but it's at least a year or greater away, and the last thing we need
is to run out of time with NLnet.

> I will think about it.

appreciated.

l.