[GitHub] [tvm] vegaluisjose edited a comment on pull request #6971: [Hardware][Verilator] Integrating and simulating hardware accelerators in TVM

[GitBox <gi...@apache.org>]

vegaluisjose edited a comment on pull request #6971:
URL: https://github.com/apache/tvm/pull/6971#issuecomment-733884979


   Hi @comaniac , thank you for your feedback -- answers inline
   
   > Thanks for this interesting idea and implementation! Hopefully we can get this in. Meanwhile, we should let more people review this PR especially it introduces a new 3rdparty dependency (`hw-widgets`). I also agree with @giuseros that it would be good to have an RFC talking about what you expect users to make use of this feature, because I didn't get this point after reviewing the PR.
   > 
   > My confusion is what role "hw-widgets" plays in this feature.
   > 
   > 1. According to its README, "These are examples of hardware designs for testing Verilator backend integration to TVM", is it just examples? If so then I don't think we really need an example to be in a 3rd party dependency. We should even bring the implementation into the TVM code base and only compile it when Verilator is enabled.
   
   The `hw-widgets` repository is just an example on how to use this "backend" and a hardware codebase. The reason behind having a separate repo with examples is similar to the split that happen with VTA (3rdparty `vta-hw`).
   
   > 2. What should I do if I have a new design in Verilator? Should I 1) compile my design to a library like you did for hw-widgets, 2) modify the `verilator_codegen` and `verilator_runtime` to link that library? If this is a case, then this PR is more like just an example instead of a framework.
   
   I don't think I referred to this as a framework. I think this should be viewed more as another backend for TVM. Similarly to Ethos-N or DNNL, you need to have a precompiled library in your system but in this case this library is a cycle-accurate-version of your hardware as @giuseros pointed out. However, we need a separate ecosystem because like other external codegens, Verilator requires certain things to make it work.
   
   For example, building floating-point hardware is far more complicated than integer or fixed-point hardware. Most of the backends in TVM, uses kernel libraries based on floating-point because hardware support is already free. But if you are building things from scratch, or if you are in a power-constraint environment i.e., edge, you are most likely to start with integer ops. Therefore, we need a mechanism to not only leverage full-blown-complex-accelerators but also the tiny-smallest-version-of-hardware that allow us to have a more vibrant *hardware ecosystem/community* compared to other frameworks. The other benefit of this is being capable of building hardware "incrementally" and evaluate your design-decisions with TVM over time.
   
   > 3. The current implementation in this PR executes the graph op by op, but it seems not common for an accelerator. Is this just an example or your intention?
   
   This backend can mirror what we currently have for DNNL in terms of single and merged operators (composite), no reason for stopping here. The reason why we have a single one is because we have only one example for this particular operator. Eventually, we are hoping for the community to join this effort and add examples that run more complicated use cases i.e., CONV2D, etc.
   
   > 
   > cc @zhiics @tqchen
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org