does sw use SystemC model?or how to use my own SystemC model?

[chifredhong]

I'm reading the KMD and UMD source code , but dosen't find the entrance or call to SystemC model. So could anyone tell me what the role the SystemC model play?

[nvhook]

Does the information in Issue #51 answer your question?

[chifredhong]

I have read the Issue #51 , It's about the KMD and UMD installation manully. In the Virtual Platform Documents, SystemC model is build in hw directory. In fact, I don't clearly understand the relationship between UMD(or KMD) and SystemC model

[ghost]

@chifredhong I am not experienced in QEMU + SystemC, but I would start from GreenLib and TLM2.0 which, I think, were used in nvdla/vp to bind external SystemC model. Nice feature of such co-simulation is that you don't need direct calls in KMD or UMD, so the drivers are as close to what you would use in final system as possible.

[chifredhong]

Thanks for your reply @mmaciag . Actually, I didn't use GreenLib and TLM2.0 before. I think maybe you are right, because I find FindNvdlaCmod.cmake in vp/cmake directory.So I still have two questions: how to choose different SystemC model? until now , I could only use the default configuration according to the doucument How runtime run the co-simulation if there is no calls in KMD or UMD?

[ghost]

As for the last question: the KMD communicates with memory mapped device. So you won't find classic C/C++-style function calls to the SystemC model. Emulated NVLDA will be accessed as ordinary memory mapped device, e.g. by pointer dereference, DMA stream, ioread32/iowrite32, etc... Under the hood memory accesses (e.g. to CSB registers) are somehow handled by emulator. I never get into details, but the "glue logic" appears here: https://github.com/nvdla/vp/tree/master/models/nvdla. It becomes part of emulator, not emulated software. As I understand the TLM2.0 is just a standarized way for QEMU to attach such memory mapped devices.

The SystemC model is in cmod in nvdla/hw repository. But I never managed to test other models than default in VP too, so I cannot help further than this.

[chifredhong]

At the beginning, I thought the NVDLA core was driven by DRM because I found sw/umd/port/linux/include/drm.h at UMD portable layer. If TLM2.0 is used for communicating with NVDLA core , what is DRM used for? Another question , I found NVDLA processor implementation in KMD repository only read or write some register , Is it meant that Emulator only simulate the process that CPU read and write registers? @mmaciag

[ghost]

If you are interested in running virtual platform see http://nvdla.org/vp.html, Figure 89. "Guest kernel" runs user applications, UMD, KMD driver and related DRM driver and all of it is "unaware" of what NVDLA actually is (emulated SystemC component or actual piece of hardware). CPU reads/writes registers in KMD, but it is "unaware" of the extra translation layer. See nvdla.cpp:52, nvdla.cpp:33. The csb_port location is defined in device tree (likely this file). It works in opposite direction: NVDLA (SystemC) reads from or writes to similar AXI "adaptors".

On AmazonAWS things work a bit differently - there is actual FPGA hardware, but abstraction layer is a bit different.

UMD/KMD in nvdla/sw repository can work either on virtual platform or actual system. I work, for example, on Zynq UltraScale+ with PetaLinux and actual NVDLA hardware implemented in FPGA, and I run the same, almost unmodified UMD/KMD. Here things are much easier to understand because there is no emulation, "adoptors", "TLM" and other stuff that resemble "Inception" movie :).

[chifredhong]

Thanks so much ! I' m more clear about the Framework of virtual platform. BTW, does you hardware implement need VCS to synthesize for bitstream file? @mmaciag

[ghost]

No, my primary tool for synthesis and implementation is Vivado. I don't have VCS and this is really painful if you have to verify the design. There is an option to use open-source Verilator and available test traces, but this is very limiting and new customized traces cannot be generated without VCS. Forget about xsim, the Vivado embedded simulator. It can be unpredictable and is completely useless when it face SystemVerilog and UVM...

[chifredhong]

Hi, @mmaciag I keep reading the ./sw code these days to figure out which data type that compiler converts the caffemodel format file to. According to your answer, there is no classic C/C++-style function calls to the SystemC model. And each processor only perform corresponding operation by writing registers in KMD. The register address is given by head file opendla_initial.h .Sorry for my dullness, I can't understand the SystemC code. Does the System model in ./hw/cmod really perform convolution or pooling operations?

[ghost]

No need to apologize - I myself have lots of undiscovered areas in this project yet :-)

I think my best advice for reading ./sw code is: do not bother with SystemC model at all. The connection between KMD and SystemC makes sense only in QEMU emulation - and it is so loosely coupled that, as I said, KMD don't even know if it writes to real silicon or SystemC blackbox (I mean - there is no special compiler flag or macro that would switch KMD between talkt-to-SystemC-model and talk-to-real-hardware mode). That's the point of emulation by the way :). Just treat SystemC as a black box with virtual AXI4 and CSB interfaces. QEMU is 1st use case of SystemC model in this project.

Recently I am trying to get deeper into hw/verif - even if I do not have VCS. If I understand correctly, part of the verification suite uses SystemC to verify the output of the Verilog RTL simulation. That's being said SystemC is not only fully operable NVDLA hardware simulator (which answers your questions about convolution and pooling), but it is also used as a golden reference for the actual hardware. Design verification is 2nd use case of SystemC model in this project.

Yesterday 'for fun' I wrote custom CSB/AXI4 adapters using TLM-2.0 library just following vp/model/nvdla existing 'adaptors' and this tutorial: https://www.doulos.com/knowhow/systemc/tlm2/tutorial__1/. This compiles to stand-alone application, where I can do everything I could do on real hardware, but without hardware (and slower :)). That would be 3rd use case for SystemC model - custom simulation environment alternative to VCS and Verilator.

I guess there is more use cases, but as you can see the usefulness of SystemC depends on what you are doing: system verification, software engineering, hardware implementation, etc ...