About the Scalability parameters and ConfigROM

[shgangchen]

Scalability parameters is configed thrgouh .spec files, right? So if I have built the vmod, the hardware is configed, no hardware modification should be done unless you build another version of vmod. Right?

What are the contents of ConfigROM and what can they do? You just throw out the ConfigROM and Sub-unit identifier, none of them are described in detail.

I think CPU or other MCU can only assign task to hardware blocks through register-writing using the CSB interface. What are these Descriptors and payloads of sub-units in the ConfigROM for?

Anyone is clear about that?

[ghost]

NV_NVDLA_CFGROM_rom.v seems to have fixed constants so it doesn't seem to be very useful now.

Anyway the goal was to store the scalability parameters there: http://nvdla.org/hw/v2/scalability.html

[shgangchen]

NV_NVDLA_CFGROM_rom.v seems to have fixed constants so it doesn't seem to be very useful now.

Anyway the goal was to store the scalability parameters there: http://nvdla.org/hw/v2/scalability.html

hi mmaciag, thanks for your reply. I guess that the ConfigROM is used to store scalability parameter. But I'm not sure about that. These parameters are used to config a specific hardware such as the number of MACs, and they are set through .spec file before building the vmod files, right? Scalability parameters are actually many precompiled macro such as `define s in verilog. right? I've searched some of the parameters given in http://nvdla.org/hw/v2/scalability.html, none of them are used directly in the codes in directory outdir. It seems reveal that the ConfigROM contains these scalability parameters. So, if they need a ConfigROM to store the saclability parameters, does that means the hardware is run-time configurated? If that so, what are those macros in project.vh used for?

Furthermore, there in the scalability page, they have given the "Descriptors and payloads of sub-units in ConfigROM". so what are those for? Thanks.

[ghost]

The architecture specification files (.spec) define what your hardware looks like. It indeed triggers some `defines and even #defines, because the build system uses GCC preprocessor a lot. ConfigROM should reflect this specification (which isn't now).

For some analogy, the ConfigROM is like USB device descriptor. It describes the device capabilities which is visible to software driver. This makes much easier to write one generic kernel driver that supports many configurations. This also enables you to check if your compiled neural network is compatible with hardware. For example you could have pooling layer but NVDLA might not have PDP engine at all! With ConfigROM you could detect this and raise error or even emulate pooling by CPU.

This is just idea, but current implementation seems to be far from that, because as I said values are fixed. I guess current values represent nv_small default specification, but I would need to check.

EDIT: From the very high level: http://nvdla.org/primer.html . NVIDIA promotes the standarization of the engine, which implies kiind of interoperability. ConfigROM may be important part of this and may prevent custom implementations from going wild (there is also entire verification suite for that of course).

[shgangchen]

OK, I see that. So ideally speaking, ConfigROM is a version of the hardware configuration for software convinience and standarization. Hardware config is still defined by .spec file before vmod built. I will check if the ConfigROM files for different hardware configuration are different or keeping the same. I started with the nvdla v2, so I think I skipped a lot of documents in v1. Maybe they should be reviewed. Thanks you.

[ghost]

Ideally speaking, yes. I am working with the built system for a while and I never seen any script or process that would substitute the fixed constants here: https://github.com/nvdla/hw/blob/master/vmod/nvdla/cfgrom/NV_NVDLA_CFGROM_rom.v

I think this is not far from working correctly by the way, it's matter of utilizing macros defined in spec/defs/projects.spec instead of constants.

[shgangchen]

so the configrablilty of nvdla v2 is still not quite as well as they said in the Primer document, which might be a goal. For now we users probably use the tested configruation to dive the hardware architecture and run some prepared tests. I have already built a nv_large version and nv_small version for the master branch nvdla. It turns out that there is no any difference between the generated ConfigROM files (NV_NVDLA_CFGROM_rom.v) as you said. And there surely be many differences between their .spec file. So software may not quite possible to detect the different hardware configuration for now, as they said only nv_small configuration is fully tested.

After that, I've grepped the macro "NVDLA_MAC_ATOMIC_C_SIZE" defined in file outdir/...../spec/project.vh, however, it not actually used in any of the files under /vmod. That's wired if these macros are intended to define the hardware.

I think I will go on to check the if there are any other differences between the vmod files of nv_large configration and the nv_small one.

[shgangchen]

I've figured out after quickly going through all the nvdla files that, the hardware is not configurable after being built, they just generate different verilog code for different spec file during building.