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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
