Automatic tests on simulator #21
Replies: 3 comments 1 reply
-
|
@suarezvictor This is a great goal to have. I think we can get far for single main function designs - like blink. But I anticipate lots of work trying to support full PipelineC designs in this Gets complicated with multiple main functions 'in parallel'. Heck, multiple clock domains too. Simple one clock domain functions can be 'compiled as C' and 'simulated' by putting them in a 'clock loop' directly like blink. But entire designs will be hard to verify this way. I think it makes sense for like math funcs, rsqrt should be able to. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with the complexity. In my view such kind of simple functions
should not deviate from C if not strictly required. Keeping C sintax at
full level, then we'll see what *cannot* be run by a compiler and a clever
set of emulated functions. For example, if in the middle of a function you
"return" a value and then the function continues, this can be accomplished
with coroutines.
I think C syntax and compatibility should be kept to the maximum extent
until proven impossible... Then, when that's really impossible, there's the
following route: generate C code from pipelineC as a tremendously fast
simulator, skipping verilator (proposing that as a future project)
…On Thu, Sep 30, 2021 at 6:53 PM Julian Kemmerer ***@***.***> wrote:
@suarezvictor <https://github.com/suarezvictor> This is a great goal to
have.
I think we can get far for single main function designs - like blink. But
I anticipate lots of work trying to support full PipelineC designs in this correct
for a C compiler way.
Gets complicated with multiple main functions 'in parallel'. Heck,
multiple clock domains too. Simple one clock domain functions can be
'compiled as C' and 'simulated' by putting them in a 'clock loop' directly
like blink. But entire designs will be hard to verify this way. I think it
makes sense for like math funcs, rsqrt should be able to.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACBHVWMQNEWFL2PWILTKV23UETL35ANCNFSM5FBNAHSA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
As seen with the test on #25, such example can be extended this way: an automatic main.cpp testing source can be generated. This way with each new function the users develop for testing, the automated test can be run as frequently as needed. |
Beta Was this translation helpful? Give feedback.
-
Since with verilator and cxxrtl a model can be run cycle by cycle, and considering that a "main" function is supppsed to run once by cycle, the values updated by main function and by the simulator can be compared INE by one. Proposed signals (as a start) can be the "simulator debug" ones. This way we know that the algorithm is correcly translated to VHDL.
I have a prototype of that half baked. Will start with the "led blink" one.
NOTE: this will requiere that syntax of PipelineC code is correct for a C compiler, even with respect to the way debug signals are currently specified.
For this variables of arbitrary numbers of bits should be used (see "bitsreg" template C++ clases on a recent discussion)
Beta Was this translation helpful? Give feedback.
All reactions