Thank you for the comment, there are indeed some common steps in the inference pipeline used for both keyword-spotting recognition and hand gesture detection. However, from the results presented around 21:33 in the video, it looks like the feature extraction stage for gesture recognition (just an FFT) consumes a relatively small amount of energy when compared to the energy consumed by the rest of the stages. In the case of keyword-spotting, the feature extraction consumed a relatively high portion of the overall energy, which can be attributed to the several processing steps required for extracting the MFCC coefficients. The selection of a Temporal Convolutional Network as the model architecture is an interesting one and it would be worth testing whether there is any benefit in adopting that architecture for keyword-spotting applications.

Could you provide a link to the top-level GitHub/GitLab repository of your project? Is there a recommended/template folder structure for the accelerator subfolder or is it up to each individual designer to come up with a preferred structure?

Could you provide a link to the top-level GitHub/GitLab repository of your project? Is there a recommended/template folder structure for the accelerator subfolder or is it up to each individual designer to come up with a preferred structure?

Hi, I've been having some issues while trying to familiarise myself with the tools introduced by the labs of the Intro to SoC design course offered by Arm Education Media. The presented workflow introduces Xilinx Vivado and Arm Keil, both of which require a Windows environment (I think Vivado can also run on Linux). I am a Mac user and as a consequence I had trouble using the software. I have tried using the Soclabs servers, but the interface seems to become irresponsive sometimes. I have been told that this might be caused by a screensaver setting, but I still need to check.

I am wondering about what is the maximum size that can be used for a data input packet. Assuming that the address space for the accelerator is 4 kB, you could use up to 4092 bytes for your input packets and leave the remaining 4 bytes for your outputs packets, in a scenario where your dataflow is highly asymmetric. But I in this case it would take hundrends of writes to generate a valid-ready signal for your input packet, which could decrease you overall throughput. So would it be preferable to choose input (and output) packet sizes within the range of a few words to avoid dataflow bottlenecks?

I am trying follow the getting started page from the project's gitlab repository. When I try to download the IP for the Cortex-M0, I can only find the AT510-r0p0-03rel2-1 version not AT510-BU-00000-r0p0-03rel3 which is used by the project. As a result, when I run "make compile-mti, I get error messages, because the AT510 IP cannot be found.

Should I modify the file paths in the tbench_M0.vc file to accommodate the differences in the AT510 IP versions? Where could I find the rel3 version of the IP?

Hi David, I still have no access rights to the IP installed on the SoCLabs servers, so I had to download and unpack the IP myself from Arm's Product Download Hub. I modified the paths in tbench_M0.vc and the errors were eliminated. Once, I get access rights to the IP library installed on the server, I will try again with the original testbench file.

Many thanks for the help, I pulled the last commit into my forked repository and I successfully managed to create the symbolic links as suggested. However,  I was still getting 2 errors for the DMA-230 IP. It turns out that the cause of the error is that the IP is placed under DMA-230/shared/logical/pl230_udma/verilog/ instead of DMA-230/logical/verilog/ but I suppose you might have arranged things differently on the SoCLabs server.

As the amount of content placed on the site continues to grow, it feels like the existing tree-based navigation scheme becomes harder to use and sometimes a bit confusing. Although I can recognise its relative merits, I think it would helpful to consider some alternatives. In addition, the wide format that has been used for the display of text feels unfamiliar, given the fact that moat websites use a narrower layout. This is of course a matter of personal preference, but I think that switching to a narrower format could improve the overall look and feel.

As the amount of content placed on the site continues to grow, it feels like the existing tree-based navigation scheme becomes harder to use and sometimes a bit confusing. Although I can recognise its relative merits, I think it would helpful to consider some alternatives. In addition, the wide format that has been used for the display of text feels unfamiliar, given the fact that moat websites use a narrower layout. This is of course a matter of personal preference, but I think that switching to a narrower format could improve the overall look and feel.