Re: [Discuss-gnuradio] [GSoC19]Few Questions about Cycle-accurate Verilog Design Simulation Integration

[Bowen Hu]

Hi Marcus,

I am very glad to receive your reply. And I realized that I haven't introduced myself yet.

My name is Bowen Hu. I am a first-year graduate student majoring in microelectronics at Fudan University, China. And my undergraduate major is electronic information science and technology. The main job of my major now is to design digital integrated circuits with Verilog and many other tools. By far, I've used several programming languages including C++, Python, Verilog and MATLAB. Even though I have not used Verilator before, I do have experience of how to do Verilog simulation with ModelSim and Vivado, which are both the simulation tools commonly used in the industry. I heard about GNU Radio about a year ago, when I was an undergraduate. I built a wireless communication demo(it still needs clock wire though) with the flowgraph of GNU Radio. I never been involved in any open source projects before. But I am still interested in SDR, even though I chose IC design as my major. So, I feel excited when I saw the cycle-accurate Verilog design simulation integration project on the GSoC ideas page. I think I may be able to know more about how GNU Radio works through this project.

Thank you for your advise in the reply. I may try to include the files generated by Verilator in my module as a class, and build the module before the flowgraph starts. Or I can make these files as dynamic link library(which I never did before).

In addition, I actually have many more detailed questions. I hope I don't bother you by asking so many questions.

- There are a lot of different datatypes in GNU Radio, however Verilog would normally accept just bit/unsigned integer(the float-point number or complex number might have to be converted into fixed-point number), I think it should be necessary to add some limitations and rules on the datatype conversion.

- Users might want to specify the rules of data conversion in case that the default rules won't work properly. I wonder whether it is a part of the job?

- Due to cycle-accurate Verilog simulation by Verilator, the situation of input and output may vary in different module. For example, there might be uncertain number of cycles before the output data is valid(Of course, the author of the module should know about it).Or, some module would have to take its time to do the calculation, and won't respond to the input data for several cycles, which means if we put the data to the input port during these cycles, the data would just be ignored. I am not sure how to deal with this issue.

- I may have to learn more about how GNU Radio works. But I have this specific question that is the data rate ratio of each module in GNU Radio determined in advance before execute, or ajusted during run-time based on some signals? Then, what should I do with the Verilog module that changes the input/output data rate; like encoders do, which generate more data than it take in.

Best regards,

Bowen

---

From: Marcus Müller <address@hidden>
Sent: Sunday, March 3, 2019 15:32
To: Bowen Hu; address@hidden
Subject: Re: [Discuss-gnuradio] [GSoC19]Few Questions about Cycle-accurate Verilog Design Simulation Integration

 

Hi Bowen!

welcome to the GNU Radio mailing list. Nice having you around!
I'm super happy that someone is interested in the Verilog Simulation
idea; I found it pretty involved, because it requires interest in
Verilog – something that is rare!

I'm going to address your questions really quickly. I'm glad you've
asked them at this point; shows you've already looked at the idea and
had your own thoughts about how to approach the problem.

> Would it be appropriate to just call
> system() function to execute shell command just like doing it
> manually?

I'm afraid that, no, system() for every work call would not be OK, for
multiple reasons:

a) Technologically: GNU Radio blocks are basically wrappers around the
"work" function mentioned in that idea description. That function will
be called repeatedly, with variable sized chunks of input. Now,
whatever you'd do in Verilog quite likely has some state that will be
required for the next data point to be processed – repeatedly calling
an external executable would require always restoring that state from
some file from the previous run, and then saving the new state to a
file (or communicating the state to the main GNU Radio process, or
something similar). That's an additional burden that makes it
impossible to make a Verilog code independent wrapper.

It would also require GNU Radio and the process you started using
system() to communicate the in- and output through some mechanism – be
it temporary files, shared memory, sockets, …; you'd be adding a layer
of complexity to this that you could avoid if the simulation ran in the
same process space.

b) Performance-wise: We're doing this to process millions of samples
per second, which typically means that the average work function is
called every couple hundred microseconds or so with a couple hundred
data points. You'd not want to spawn the same process all over again
every time, I think. (not counting the state restoration/saving
overhead.)

> Or, is there any better way to realize this procedure?

Yes! Verilator generates valid C++ code. Simply link that into your
main GNU Radio module – ideally, at run time, but just inserting the
source file into the GNU Radio module sources would be a good start,
too!

You can then just call the functions defined in that generated code.

Verilator is supposed (its website says so) to also be able to produce
multi-threaded code. I don't know how that works, and how to
interchange data with these threads, if that's up to the verilator user
at all. Your task, should you take this GSoC project, would be to
evaluate ways of exchanging data between Verilator code and GNU Radio
code; it *should* be easy, because GNU Radio just works on contiguous
data arrays, but I've not tried it yet.

> With the very same question as above for Verilator itself , Would it
> be appropriate to call shell command to run Verilator just like doing
> it manually?

Yes, I think that would be OK – since this should only need to be done
once, when the verilog code has changed. And that will typically not
happen that often.

The interesting part is how to get the generated C++ code compiled and
callable from the main GNU Radio code. As said above, for a start,
requiring that the whole GNU Radio module be rebuilt when Verilog
changes would be OK:

Verilog changes ->
Call Verilator ->
Compile the GNU Radio module incl. the Verilator-generated sources ->
Run GNU Radio (which then calls the verilator-generated functionality)

For later, *iff* that is possible (up to you to figure out, but I will
assist you!), I'd love to see something like

Once: Compile the GNU Radio Module that has a dynamic loader for
plugins.
Verilog changes ->
Call Verilator ->
Compile the Verilator Plugin ->
Load the plugin from the GNU Radio Module

The advantage of that would be that you'd only need to compile the GNU
Radio module once, and then just load the "right" Verilog simulation as
a plugin.

> If the answers to these questions above are yes, Could I draw the
> conclusion that the major job I should do in this integration work is
> to wrap the C++ files generated by Verilator.

The answers are "no"; but: yes, that's going to be the core of your
work!

The workload will probably be something like: understanding how GNU
Radio works, how Verilator works, to come up with an architecture that
allows us to process data from GNU Radio in Verilator without doing
something different for every different Verilog code, figuring out how
to call verilators simulation code, writing tests and examples, and
writing documentation to your code and communicating with the
community.

I know that sounds scary, but if you want to do this project, you'll
need to write a project proposal, where you'd ideally already outline
(not finally present) an architecture; and we'll help you writing that
proposal by offering feedback and insight, especially on the GNU Radio
aspects! The good thing about projects like this one is that we learn
about how things work on the way, so we obviously need to be a bit
flexible about what our goals are – that puts you under some pressure
to communicate problems clearly and early enough, but gives us the
opportunity to figure out how far too go *after* you've started the
project.

Hope I've not scared you – again, this project is *meant* to be doable
within a GSoC project, and this idea is just that: a rough idea of what
should be happening. It's up to you to come up with a proposal that you
think is doable. If you find the scope too large, do not hesitate to
discuss that with us. The more we can trust you to autonomously solve
the issues, the better :)

Best regards,
Marcus