03-11-2019 07:56 AM
I have played around with a simple test example for coding styles. It has an internal memory (which is a member variable of the top module), a clock thread to initialize it and a clock thread that access the memory and produces an output. The objective is to understand how the memory access control signals (viz. address and clock enable) and the validation signals of the outputs are generated (since for some coding styles I got some non-obvious bizarre behaviors).
All these coding styles generates exactly the same behavior at high-level of abstraction SystemC simulation. However, they generate different HW with different behaviors. That it is not a surprise. However, I have been unable to find guide or documentation about how the coding style affects the FSMs and these control signals.
I attach the source files for the example (I hope they are easy enough to be understood for everybody) and screenshots of the waveforms of the studied signals for each style tested.
Please, can someone give us a clue or a reference for documentation about this topic? It is not trivial wich styles are better for HLS and which ones will mess up the design. Particularly, it is specially problematic when the memory clock enable is continuously switching all the time because it prevents the access to the memory from other cthreads. I hope this post may be useful for other users with similar coding style problems. This simple example may give some intel on which styles may be better.
Note: following Xilinx recommendations the output port has a "handshake" validation protocol (i.e. the dout_vld signal). Actually, this is necessary for re-using the SystemC testbench from the high-level of abstraction simulation, in which a lot of complex computation can be done in one "clock cylcle" (it would be more wise to say one simulation synchronization), to the RTL simulation, which needs more clock cycles to compute some of the functonalities described. Surprisingly, Vivado HLS generates extra validation signals internally, including a validation signal of the validation signal.
03-13-2019 04:18 PM
You're absolutely correct that coding styles can make a huge difference in the generated hardware, even though both give the same results. There's not really a guide to explain this in more detail than UG902, which does give general recommendations about what to do and what not to do to make your code synthesizeable.
In general, sometimes we want to know what HLS is creating for hardware so we can better optimize it, but that's difficult to do when the value of HLS is that we don't have to dive into the hardware. Plus, the HDL HLS produces is not exactly reader friendly, in the same way you usually wouldn't read the output of gcc.
I'll also add - the vast majority of our users code in C/C++ since it's simpler, but it also means help is hard to come by for SystemC users.