Hi,

Great to see the project live. It is very easy to add the initial milestones and you can come back as each milestone progresses and make updates. 

IITH are a good example of milestones in their project https://soclabs.org/project/real-time-edge-ai-soc-high-speed-low-complexity-reconfigurable-scalable-architecture-deep

You can simply select milestones from the generic design flow stages or create any unique milestones.

Hi,

It was great to hear today how you worked through the analysis to come to the view that the data window of 40 beats and 20 LSTM units are sufficient to achieve a classification accuracy of 99.02%. It was also interesting to explore how the data movement across the bus and into your accelerator will form based on this requirement.

Different people have taken similar but slightly varying approaches to how the data transactions flow into their working registers within their accelerators. There are a few projects that can act as examples:

SHA-2 Accelerator Engine | SoC Labs

Given the volume of data flowing I think you concluded the Master for the bus was likely the M class CPU and not a DMA controller.

All sounds very promising and it will be great to understand more on the design and expected milestones.

Hi,

It was good to open the discussion on what will be your frame work for creating test benches. There are a variety of approaches people are adopting. The Verification pathway parallels the Design pathway through the Design Flow  stages. There are even standarisation efforts in this area: 

Universal Verification Methodology | SoC Labs

It often comes down to experience of various tools and languages that are easily adopted, or the ability to re-use prior verification assets that reduce the overall project timeline rather than extend it with new skills acquisition for unknown techniques. 

There are some  verification assets in SoC Labs and some projects to continue to develop these.

System Verification of NanoSoC | SoC Labs

I think you had some specific focused test bench requirements you wanted to work on for the data flow across the bus. I guess this is part of the usual ebb and flow of design, either top down for the SoC systems architecture or bottom up from foundation IP blocks.

Looking forward to seeing how these develop on your project.

John. 

Hi, you just need to save to Editorial and not Drafts to get it submitted. You can come back later and change.

Hi,

It would be good to get an update on your milestones at the end of the month.

I think you have been working on the interface Atrial Fibrillation Detection Accelerator core to main Nanosoc. As I understand things, you were considering the need for a DMA for data transfer. If you do not use a DMA the processor will have to initiate all transfer of data between your sensor input and your custom accelerator. 

Let us know where you have got to?

John.

Hi Rami,

We've just updated the way you can configure nanosoc, to hopefully make it more easy for people to make changes to the overall configuration without having to change multiple files. If you pull the latest changes you should see a nanosoc.config in the nanosoc_tech directory

If you leave the options blank, they will not be included and if you write a yes (or really any text after) then it will be included. There is also a section to edit the paths to arm IP

You should now not have to make any edits to flists (apart from to include your accelerator) or to any of the makefiles

Let me know how it goes

Daniel

It was good to hear you confirm the Architectural design pattern for data movement within your proposed SoC. It was interesting talking through the various options:

1. Using the processor to Poll status registers for results. Using the processor to periodically inspect status registers associated with the processing of the external data for both data handling and obtaining results can consume unnecessary processor cycles and may not allow the processor to enter low power modes. Polling might be needed during initiation sequences before the main operating cycles of the SoC are established.
2. Using an Interrupt driven approach where by your custom hardware raises an interrupt request signal on the processor when it requires service. The processor then accesses the status registers only when required and avoids the overhead of period polling. The processor is still active in managing all the data transfer in the system. 
3. Using a separate Direct Memory Access (DMA) controller as an Initiator (Master) for data movement transactions. Interrupts on the processor are raised only when additional processing needs to be undertaken. 

Given the low data bandwidth requirements for you specific project you felt the DMA approach was not needed. A simple interrupt architectural design pattern with a mapping of registers within your custom hardware into the address space of the processor and accessible from the main system bus was I recall your proposed design. This will be a combination of data, status and result registers.

It will be good to see how this develops.

You are able to build nanoSoC with the DMA removed. The two nanoSoC designs taped out recently had either the DMA 230 or the DMA 350. Aba and the team are developing an accelerator core with micro DMA engines within their accelerator design. This allows them to generate similar firmware for their FPGA implementation as their ASIC implementation. They have been varying the nanoSoC project to build without the  DMA 230 or DMA 350 IP but containing their addressing within the accelerator expansion region.