I think this is too trivial to get serious about, it is just some
subjective suggestions based on my experience and I don't think there is a golden right or wrong here.
On Wed, Apr 27, 2022 at 5:26 PM Blaok @.***> wrote:
+In the most basic case, tapac takes in the source code and generate an XO object with the suffix .xo. The XO object will be passed to the Vitis v++ compiler as the input for bitstream generation.
+
+- Actually, the XO object is a .zip file with a different name.
+
+- If you unzip the XO object, you will see (1) all the RTLs corresponding to the C++ source code and (2) configuration files with metadata about the design.
+
+- If you like, you could modify the contents of the XO file. Simply unzip the XO object and modify the RTL as you want, then zip it back and passing it to v++.
+
+The XXX_generate_bitstream.sh script
+-------------------------------------------------
+
+tapac will automatically generate this script, which will invokes v++ to compile the .xo object into the final bitstream. The parameters in the script will be matching the options passed to tapac.
+
+- By default, the script will use the Explore option for opt_design, phys_opt_design, route_design and use the EarlyBlockPlacement option for place_design.
+
+- The default frequency target is 300 MHz. For HBM applications, you could edit the script if a lower frequency is enough to saturate the HBM bandwidth. We usually set the target slightly above what could be actually achieved.
In this case, why not specify the HLS target as 250MHz as well, to allow
potentially less resource usage? Is it because the HLS timing model often
underestimates the delay?
I think this is too trivial to get serious about, it is just some subjective suggestions based on my experience and I don't think there is a golden right or wrong here.
On Wed, Apr 27, 2022 at 5:26 PM Blaok @.***> wrote: