Hi Jeremy. I can see from your comments that you grasp the issue(s). BTW, this is directly related to the on-going MM discussion you are having with Sebastien Jacq. To answer your specific questions:
Am I correct that you restart the simulation each time you want to run a piece of software.
Yes, that is correct.
For this approach, all you need is:
- - a version of newlib which implements the library functions as writes to the shared area rather than syscalls.
- - a suitable linker script
- - possibly a new crt0.s, although I would hope the standard one is fine.
Yes, I believe that is correct. Paul Zavalney has suggested that we may need a vector jump table as well (vector.S), but I believe (do not know for sure) that this can be part of the linker script.
Can you point me at a documentation of the memory map and the memory mapped peripheral area.
If you can then send me a few of your example programs, I'll see what is needed.
If you clone
https://github.com/openhwgroup/core-v-verif you will see example programs in
core-v-verif/cv32/tests/core and below. (Please ignore the csmith directory, it will be removed in a future update). Some of the manually generated test programs are there:
- core-v-verif/cv32/tests/core/custom/hello_world.c
- core-v-verif/cv32/tests/core/cv32_riscv_compliance_tests_firmware (this directory contains a set of C files that we may wish to keep, but that is optional).
Are you intending running C++ programs as well as C?
No. 99.9% of our test programs are either written or generated in assembly. At this point we have only a few C programs, and we probably won't write many more.
The approach I suggested in my previous email is more generic, and
probably where you want to end up eventually. It will allow you to use
the same tool chain and interface for all different targets,
simulation or physical hardware. It also means you can debug the
software when something goes wrong.
Yes, that is the goal. We will need to update some things in both the RTL and testbench to make this happen. For example, the branch address for the debug logic is hardcoded into the RTL (its a parameter, so it can be changed at compile-time). Similarily, the structure of the memory in the testbench is fixed at compile-time. Long term, these can be refactored to allow for runtime control of memory sizes, addressing, etc.
Cheers,
---mike
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 15/05/2020 16:34, Mike Thompson wrote:
> Thanks Yunhai, I also am looking forward to working closely with
> you. I think you understand the issue. Let me reply to your
> comments:
>
> you can lead to build the "Test Program Enviroment", and we will
> help you solve the problem you encounter.
>
> The Test Program Environment is already in place. Here is a
> picture of one of our testbenches that shows the TPE in
> relationship to the overall simulation environment. This is all
> in place today and running. However, we have a unique TPE (crt0.S,
> link.ld, etc.) for every test (testcase.S). The goal is to create
> a single set of TPE files that will be compatible with the hardware
> model (inside the yellow box at the right of the Figure) and all
> test programs. image.png
Hi Mike,
This diagram is useful. Am I correct that you restart the simulation
each time you want to run a piece of software.
For this approach, all you need is:
- - a version of newlib which implements the library functions as writes
to the shared area rather than syscalls.
- - a suitable linker script
- - possibly a new crt0.s, although I would hope the standard one is fine.
Can you point me at a documentation of the memory map and the memory
mapped peripheral area. If you can then send me a few of your example
programs, I'll see what is needed.
Are you intending running C++ programs as well as C?
The approach I suggested in my previous email is more generic, and
probably where you want to end up eventually. It will allow you to use
the same tool chain and interface for all different targets,
simulation or physical hardware. It also means you can debug the
software when something goes wrong.
Best wishes,
Jeremy
> The second idea is that you can help us to build the whole
> verification environment(test sets can be run in it), preferably a
> virtual machine image, and then we can build the "TPE" together. We
> can do this. As you may know, IBM is a member of the OpenHW
> Group and they are contributing Cloud services to us. I can
> easily create a new VM for you to use. I am not sure this will be
> necessary as the problem is with the software, not the
> SystemVerilog simulator.
>
> ---mike
>
> On Fri, May 15, 2020 at 10:55 AM 尚云海 <yunhai.syh@xxxxxxxxxxxxxxx
> <mailto:yunhai.syh@xxxxxxxxxxxxxxx>> wrote:
>
> Hi Mike,
>
> Glad hear from you.
>
> Your idea is very good and I am agree with you. Because I don't
> have the verification environment to run, there is no good way to
> kown how these test sets work together. Every test set may need
> different enviroment.
>
> I have two ideas to move this forward. The first is that you can
> lead to build the "Test Program Enviroment", and we will help you
> solve the problem you encounter. The second idea is that you can
> help us to build the whole verification environment(test sets can
> be run in it), preferably a virtual machine image, and then we can
> build the "TPE" together.
>
>
> Best wishes, Yunhai
>
> ------------------------------------------------------------------
> 发件人：Mike Thompson <mike@xxxxxxxxxxxxxxx
> <mailto:mike@xxxxxxxxxxxxxxx>> 发送时间：2020年5月15日(星期五) 22:04 收件
> 人：jeremy.bennett <jeremy.bennett@xxxxxxxxxxxx
> <mailto:jeremy.bennett@xxxxxxxxxxxx>>; Craig Blackmore
> <craig.blackmore@xxxxxxxxxxxx
> <mailto:craig.blackmore@xxxxxxxxxxxx>>; zbigniew.chamski
> <zbigniew.chamski@xxxxxxxx <mailto:zbigniew.chamski@xxxxxxxx>>; 尚云海
> <yunhai.syh@xxxxxxxxxxxxxxx <mailto:yunhai.syh@xxxxxxxxxxxxxxx>>;
> JACQ Sebastien <sebastien.jacq@xxxxxxxxxxxxxxx
> <mailto:sebastien.jacq@xxxxxxxxxxxxxxx>> 抄 送：zbigniew.chamski
> <zbigniew.chamski@xxxxxxxxx <mailto:zbigniew.chamski@xxxxxxxxx>>;
> Paul Zavalney <Paul.Zavalney@xxxxxxxxxx
> <mailto:Paul.Zavalney@xxxxxxxxxx>> 主 题：Re: OpenHW: request for help
> with our "test program execution environment"
>
> Adding Sebastien Jacq of Thales TDT to this thread.
>
> ---mike
>
> On Fri, May 15, 2020 at 9:00 AM Mike Thompson <mike@xxxxxxxxxxxxxxx
> <mailto:mike@xxxxxxxxxxxxxxx>> 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.
>
> 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.
>
> 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.
>
> 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+0dU4QUCXr7JvgAKCRC+9YFy+0dU
4W55AJ9vRuVZDe5A6US9jXc7pPSgHNNmvwCfe2R6I6mx0YB8wroltAvZE00d3HI=
=PXea
-----END PGP SIGNATURE-----
