Hi,

One of the goals of SoC Labs is to help form global collaborations. It might seem odd to have a contest where you actually work with other contestants but that is something a bit unique. about this contest, it is better to work in collaboration and to share IP blocks that are re-usable across projects.

John.

The 2023/24 version of the nanoSoC reference design has been used to tape the following projects with custom accelerators and will hopefully give you some help in developing your own project.

• Fast-kNN: A hardware implementation of a k-Nearest-Neighbours classifier for accelerated inference by Epifanios Baikas

• Hell Fire SoC by Srimanth Tenneti

The die from the ASIC fabrication are back from manufacture and are being tested using the nanoSoC test board. 

If you need any help with your project please let us know.

John.

Hi,

Do you know the data throughput requirements you are expecting for this application. 

If you can let us know that may help define the SoC system.

John.

Hi,

Thanks for signing up to SoC Labs. We would be happy to work with you to find any potential projects that might work for you. I see you have shared an interest in FPGA using the Xilinx platform. We have also just had two projects tape out using TSMC 65nm node for student led projects.

I look forward to hearing from you.

John.

Here are the two projects that use the nanosoc reference design that have been verified through to tape out and have ASICs operational in the test board. 

• Fast-kNN: A hardware implementation of a k-Nearest-Neighbours classifier for accelerated inference by Epifanios Baikas uses the DMA 230 .

• Hell Fire SoC by Srimanth Tenneti uses the DMA 350. 

Hi,

Thanks for the updated milestones. If you need any help with the Synthesis then please let us know.

John.

Thanks for adding the latest milestone on the synthesis using 90nm libraries. Have you obtained foundry specific libraries?

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.

The HLS4ML environment can use various backend tool chains for High Level Synthesis (HLS). These tools support the generation of variations of hardware implementation for an algorithm written in a high level language portable language. The benefit of High Level Synthesis is that it bridges hardware and software design domains. 

It was good to get some details of your design environment. As I understand things you are using the Xilinx® Vivado® High-Level Synthesis (HLS) tool chain as your backend. HLS4ML uses streams to pass data and these are mapped into implementation buffers. As with other abstractions it provides an accelerated design environment but then requires effort to optimise the hardware implementation. This can be done by developing optimization directives that direct the tool chain to refine the automated generation of the implementation.

Alternatively some design teams move to use the next layer of tooling down in the design abstraction environment once they have a conceptual design. The data model for your project is relatively easy to understand. It was interesting discussing the use of the  Xilinx® HLS streaming interface.  We also discussed some of the challenges of moving beyond the FPGA fabric support into the full ASIC implementation flow and the subtle differences in performance of logic and memory between the two hardware instantiations. 

It will good to hear how things are progressing. 
 

Here is a good example of update to a milestone to add a completion date and show progress. It comes from one of last years projects.

It shows both the Completed Date and key additional information such as the reported area with a clear statement of the inputs that this is not using a specific technology node standard cells.