Re: [openhw.core-v.sw] OpenHW: request for help with our "test program e

[Jeremy Bennett <jeremy.bennett@xxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(copied in the OpenHW SW mailing list - apologies for anyone who gets
this twice).

On 15/05/2020 14:00, Mike Thompson wrote:
> Hi,
>
> I think everyone knows me, but just in case, let me (re) introduce
> myself - this is Mike Thompson, Director of Engineering for the
> OpenHW Group's Verification Task Force.  I'm reaching out to you as
> you all members of the Software Task Group and I have an urgent
> need for your expertise to define and implement a "Test Program
> Environment" for our simulation testbenches.  I anticipate that
> this would be no more than two or three days work for a software
> developer comfortable working on "bare metal" systems.  Can we set
> up a conference call to discuss this?
>
> A bit of background is below:
>
> The simulation testbench for the SystemVerilog RTL model of the
> CV32E40P core implements a very simple "bare metal" execution
> environment for the core.  Basically, what we have is a 1Mbyte
> address space for instruction and data memory, a small area for
> debug code plus a set of memory mapped "virtual peripherals" that
> allow code running on the core to interact with the simulation.
> These virtual peripherals are spec'd in the Simulation Tests
>
<https://core-v-docs-verif-strat.readthedocs.io/en/latest/sim_tests.html#virtual-peripherals>
>
>
chapter of the Verification Strategy document on readthedocs.

Hi Mike,

I am assuming this is an event-driven simulation
(Incisive/ModelSim/VCS?). If so, the challenge is that the simulator
is in control - i.e. it pulls in the program, you don't push it in.
Typically you'll want SystemVerilog tasks using DPI-C to connect to
the outside world. The best way to connect is via a debug server
(OpenOCD, Embecosm gdbserver) to GDB, since you then have complete
control over the programs.

You'll need a variant of newlib which knows how to interact with your
virtual peripherals. Unless you are trying to test models of the
actual peripheral hardware, my advice would be not to use this
approach, but use GDB File I/O to provide any peripheral support (in
marketing speak this is "semi-hosting"). The existing newlib is
already set up for this.

You'll then just need a linker script modified to your memory map,
which is a trivial job.

It is that the interface to the simulator will be the hard task.

BTW - this is much easier if the outside world drives the simulator. I
am working on patching up the Verilator model for CV32E40P. For a year
or two we have used Verilator models of RI5CY for GNU and LLVM
regression testing. See the tb/verilator-model directory of the repo.

> We already have code from a variety of sources that executes on
> this "bare metal" execution environment in simulation.  For
> example, we want to run Compliance tests from the RISC-V
> Foundation, a set of tests we inherited from the PULP team, a set
> of tests being developed by Paul Zavalney of SiLabs for debug
> verification and test programs auto-generated by the Google random
> instruction generator.

I commend to you the 150,000 GCC C and C++ regression tests. 30+ years
of tiny programs shaking the corners of a huge range of architectures.

> The issue we are facing is that each of these sources of test
> programs comes with its own software support files such as a C
> run-time config (crt0.S), linker control file (link.ld), vector
> jump tables (vector.S) and associated library routines.   Some of
> this is quite old with a long forgotten history and some is very
> new, hacked together to "make it work".
>
> My objective is to have a single set of these files which I am
> calling a Test Program Environment
>
<https://core-v-docs-verif-strat.readthedocs.io/en/latest/test_program_environment.html>
>
>
that would be used for all test porgrams running in simulation.  I have
> made an attempt to create such a thing, but I am operating at the
> extreme edge of my skillset and progress is slow.  So I am asking
> if someone from the Software Task Group can spend some time having
> a look at what we've got and helping to define and implement an
> environment that meets our current and future needs.

This is what the compliance TG have been trying to do for the past 2+
years! I think we can distill it down to a guide on how to build,
link, load and run programs, suitable for professional hardware
engineers (i.e. you don't need to be a specialist software engineer).

HTH,


Jeremy
>
> Cheers, ---mike


- -- 
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Twitter: @jeremypbennett
Email: jeremy.bennett@xxxxxxxxxxxx
Web: www.embecosm.com
PGP key: 1024D/BEF58172FB4754E1 2009-03-20
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQRASGDWqmhRZUfAaPW+9YFy+0dU4QUCXr6o3wAKCRC+9YFy+0dU
4T3vAJ9uRYzsoGmPDmq0D9j9DzYRWxrdZACghbqPGCTrzHXr9+VjRw4VgHEPS+I=
=ZAud
-----END PGP SIGNATURE-----