I am new to SoC verification where the test is carried out by the program running on the processor.
I am planning to use C for this. One can use assembly program but the abstraction is quite low and hence productivity is less.
I am confused as to what guidelines to follow while writing such C program.
For example, I cannot simply call a print function as this is not a standard computer with display etc.
One idea I got after a brief research on the web is that probably embedded C program that can run on bare metal is the closest one to what I am thinking.
I need inputs and directions from the SoC experts.
Thanks in advance.
Regards,
In reply to verif_learner:
I am new to SoC verification where the test is carried out by the program running on the processor.
I am planning to use C for this. One can use assembly program but the abstraction is quite low and hence productivity is less.
I am confused as to what guidelines to follow while writing such C program.
For example, I cannot simply call a print function as this is not a standard computer with display etc.
One idea I got after a brief research on the web is that probably embedded C program that can run on bare metal is the closest one to what I am thinking.
I need inputs and directions from the SoC experts.
Thanks in advance.
Regards,
What is more typical in this scenario is that the SoC you’re verifying is
running some embedded O/S such as Linux rather than running on bare metal.
In that case your C program will use APIs of drivers that are supported
by that O/S for whatever devices it wishes to communicate with, such as
displays, UARTs, ethernet NiCs, PCI, USB, CAN, etc.
Taking the example of ethernet you will typically communicate through a
standard POSIX compliant Linux network socket interface that is implicitly
supported by the embedded O/S such as your Linux system. Operations through
that socket interface will result in register-level operations within that
O/S’s driver which, in turn communicate directly with the host hardware for
that particular NiC interface. Similar for SocketCAN API in how it communicates
with CAN devices for example.
For SoC verification we can often test such C applications and their
interactions with the embedded O/S drivers even using a virtual platform
such as QEMU rather than using real hardware and this often provides a very
convenient platform for not only your C application development but device
driver development as well.
On the other hand if it is bare metal applications that you’re really targeting
then it will be up to you to define your own direct register-level interactions
with whatever hardware you want. This can be a daunting task as compared to
just having this stuff available with your O/S !
But carrying it to your ‘printf()’ example yes you would have to implement your
own printf() function which itself communicates directly with whatever display
device hardware your bare metal system is connected to.
– johnS
In reply to jstickle:
[quote]In reply to verif_learner:
[quote]I am new to SoC verification where the test is carried out by the program running on the processor.
I am planning to use C for this. One can use assembly program but the abstraction is quite low and hence productivity is less.
I am confused as to what guidelines to follow while writing such C program.
For example, I cannot simply call a print function as this is not a standard computer with display etc.
One idea I got after a brief research on the web is that probably embedded C program that can run on bare metal is the closest one to what I am thinking.
I need inputs and directions from the SoC experts.
Thanks in advance.
Regards,
maybe towards the last leg of the project when you want to sign-off with HW-SW.
But in the initial stage of the project when the simulations are starting, i am not sure if you would be able to run with all the OS.
Secondly, running with OS in a simulation environment is quite slow. This type of test is probably targeted on an emulation or prototyping type of platform.
thirdly, it is possible that the embedded processor does not even support OS as such. So, we can only run bare metal programs.
Taking the example of ethernet you will typically communicate through a
standard POSIX compliant Linux network socket interface that is implicitly
supported by the embedded O/S such as your Linux system. Operations through
that socket interface will result in register-level operations within that
O/S’s driver which, in turn communicate directly with the host hardware for
that particular NiC interface. Similar for SocketCAN API in how it communicates
with CAN devices for example.
agree with this. for SW/FW development, virtual HW is probably the best and suffices.
On the other hand if it is bare metal applications that you’re really targeting
then it will be up to you to define your own direct register-level interactions
with whatever hardware you want. This can be a daunting task as compared to
just having this stuff available with your O/S !
agree. thanks
– johnS