VTA: VTAMemInsn - missed "unused" field into instruction

Hello. I got confused during understanding VTA runtime. There is instructions found into VTA documentation :

There are an “unused” fields into both lower and upper words. But there is no “unused” paddings into vta/include/vta/hw_spec.h: typedef struct { /*! \brief The instruction opcode / uint64_t opcode : VTA_OPCODE_BIT_WIDTH; /! \brief Unused in this instruction / uint64_t pop_prev_dep : 1; /! \brief Pop dependence token from GEMM stage / uint64_t pop_next_dep : 1; /! \brief Unused in this instruction / uint64_t push_prev_dep : 1; /! \brief Push dependence token to GEMM stage / uint64_t push_next_dep : 1; /! \brief Source/destination SRAM for store/load instruction / uint64_t memory_type : VTA_MEMOP_ID_BIT_WIDTH; /! \brief SRAM base address (pointer to memory elem type) / uint64_t sram_base : VTA_MEMOP_SRAM_ADDR_BIT_WIDTH; /! \brief DRAM base address (pointer to memory elem type) / uint64_t dram_base : VTA_MEMOP_DRAM_ADDR_BIT_WIDTH; /! \brief 2D access pattern: y-size / uint64_t y_size : VTA_MEMOP_SIZE_BIT_WIDTH; /! \brief 2D access pattern: cx-size (in terms of memory elements) / uint64_t x_size : VTA_MEMOP_SIZE_BIT_WIDTH; /! \brief 2D access pattern: x-stride (in terms of memory elements) / uint64_t x_stride : VTA_MEMOP_STRIDE_BIT_WIDTH; /! \brief 2D access pattern: start padding along y dimension / uint64_t y_pad_0 : VTA_MEMOP_PAD_BIT_WIDTH; /! \brief 2D access pattern: end padding along y dimension / uint64_t y_pad_1 : VTA_MEMOP_PAD_BIT_WIDTH; /! \brief 2D access pattern: start padding along x dimension / uint64_t x_pad_0 : VTA_MEMOP_PAD_BIT_WIDTH; /! \brief 2D access pattern: end padding along x dimension */ uint64_t x_pad_1 : VTA_MEMOP_PAD_BIT_WIDTH; } VTAMemInsn;

As a result, it seems, that instructions generated don’t have proper bits set. Length if VTAMemInsn is 121 bits instead of 128. However, matrix multiplication example works on simulator. Could you, please, clarify this moment?

Maybe this helps?

C automatically packs the above bit fields as compactly as possible, provided that the maximum length of the field is less than or equal to the integer word length of the computer. If this is not the case, then some compilers may allow memory overlap for the fields while others would store the next field in the next word.

So I guess in this case it will be packed to EDIT: multiples of 64bits (since they are uint64_t). Im not sure about this, apparently it is dependent on what size an integer word is. I assume it will be either 32 or 64 bits, but in any case 128 is an integer multiple of both of these bitwidths.

1 Like