Timing violation for vta hardware implementation!

Questions
1

Hello there, I clone this repository and compile the hardware design “/tvm/vta/hardware/xilinx/”. It successfully generate the bitstream but the timing closure is not satisfied. It reports WNS and TNS are -1.601, -1198.534 respectively. My synthesis and implementation keep the default settings unchanged.

2

Dear @LiYB do you currently compile VTA with the default configuration, or did you tweak the settings?

If you send me the configuration parameters I can try to reproduce your results.

3

Also, we’re migrating to Vivado 2018.2 FYI, so I may get different timing closure results if I try to reproduce your example.

You are welcome to upgrade your toolchain to 2018.2 as well.

4

Hi Thierry thanks for your reply. I use Vivado 2017.1 with the default configuration for the vta compilation.
vta_config.jason :
{
“TARGET” : “pynq”,
“HW_FREQ” : 100,
“HW_CLK_TARGET” : 8,
“HW_VER” : “0.0.0”,
“LOG_INP_WIDTH” : 3,
“LOG_WGT_WIDTH” : 3,
“LOG_ACC_WIDTH” : 5,
“LOG_OUT_WIDTH” : 3,
“LOG_BATCH” : 0,
“LOG_BLOCK_IN” : 4,
“LOG_BLOCK_OUT” : 4,
“LOG_UOP_BUFF_SIZE” : 15,
“LOG_INP_BUFF_SIZE” : 15,
“LOG_WGT_BUFF_SIZE” : 18,
“LOG_ACC_BUFF_SIZE” : 17
}

5

Ok, I was able to reproduce the timing violation both in 2017.1 and 2018.2.

A simple workaround is to change the HW_CLK_TARGET to 7 instead of 8. This will tell HLS to more aggressively pipeline the VTA modules.

You should get a design that closes timing (I get +0.087ns of WNS).

I will issue a patch in TVM so that by default the design that gets generated closes timing. Thank you @LiYB for reporting the issue!

6

Here’s the fix: https://github.com/dmlc/tvm/pull/1489