> could you be a bit more specific wrt your API design comment?
Sorry, I meant to be consistent with the registry API / implementation defined
at
[src/runtime/registry.cc](https://github.com/apache/incubator-tvm/blob/master/src/runtime/registry.cc).
Specifically, I think it's better to implem
Hi @areusch, thanks for proposing RPC support to MISRA-C runtime.
Regarding to the `TVMFuncRegistry` design, the `names` field are designed to be
rather compact, and requires a special handling of the list of strings. I would
rather propose an alternative way that we could use fixed-length st
Thanks for hosting and the friendly time zone converter.
---
[Visit
Topic](https://discuss.tvm.ai/t/utvm-embedded-focus-online-meetup/6908/11) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.ai/
Considering runtime support, I think the answer is yes, see
https://github.com/apache/incubator-tvm/pull/3554 . However, to run the VTA
tutorials on PCIe based FPGAs, driver-level support is not yet implemented.
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-vta-support-for-cloud-devices-
also cc @JammyZhou @ayaka @jinchenglee who might interested in this thread.
---
[Visit
Topic](https://discuss.tvm.ai/t/utvm-embedded-focus-online-meetup/6908/8) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https
Thanks @jknight for proposing the (embedded focused) online meetup.
Sure, I definitely like to give a brief talk regarding the MISRA-C runtime. I
think both of slots would be fine.
---
[Visit
Topic](https://discuss.tvm.ai/t/utvm-embedded-focus-online-meetup/6908/7) to
respond.
You are r
Seems like we are converging.
Another aspect that @thierry mentioned, and I would like to extend a bit that
we need to make sure that each design entry can follow a VTA spec via regular
CI testing. For now the unit test and integration test script ensures the
correctness of the existing three
[quote="remotego, post:15, topic:6676"]
Code re-usability is always an interesting topic in the HDL world.
[/quote]
I like your comment on this topic, and I highly recommend trying Chisel for
future HDL projects, as Chisel would actually help you define and connect
interconnect interfaces with
[quote="remotego, post:5, topic:6676"]
Could you explain a bit more on this multi-core parallelism requirement of
OpenCL?
[/quote]
A typical opencl kernel looks like
```c
__kernel void helloworld(__global char* in, __global char* out)
{
int num = get_global_id(0);
out[num] = in
Thanks @zhanghaohit for your proposal. It's quite interesting to bring VTA
framework into cloud devices. It seems to be this RFC brings a quite large
topic. I've read through the proposed change, and still unclear about:
* OpenCL requires multi-core parallelism, and we don't have multi-core su
Thanks for locating the bug @c! Is there any way to modify this in HLS
instead of modifying the generated Verilog, so that more people could avoid the
pitfall?
---
[Visit Topic](https://discuss.tvm.ai/t/rfc-vta-a-hls-c-vta-bug/6743/2) to
respond.
You are receiving this because you en
IMHO, you suggested we might require an `fence` instructions to block the
execution flow until data has been fully flushed back to DRAM. Therefore, I'm
not quite sure do we really need `prologue`?
If what we really need is just `epilogue` pragma, I think `barrier` might be a
better name for
12 matches
Mail list logo
