Hi,

It would be great if you could start a collaboration project for you accelerator activity. I know you are in contact with David Mapstone and we look forward to collaborating together. 

It is easy to add a project, use the navigation menu...

We are hoping to re-start this activity as part of nanoSoC v3 and the refactoring of the nanoSoC flows.

Hi,

Sorry for the delay in sending a message. Thanks for joining SoC Labs. Perhaps it would be worth meeting up with the team after Easter and finding out what you are working on.

John.

Hi,

Sorry for the late response sending this welcome message through. Looking forward to collaborating on some additional projects as well as getting the current HLS4ML to ASIC flow finally nailed.

John.

Some work is needed to understand how this IP is acting as the coordinating system clock in a reference for chiplet based systems within an Arm based ecosystem. 

The Arm Chiplet System Architecture defines two System Types, a Hub based model and a decentralised compute fabric based model within which time must be coordinated. 

In Chapter 6, the role of the System Counter  is defined. The system counter is specified by the Arm Architecture Reference Manual as a sub-component of the Generic Timer, a necessary component in an Arm system. It measures the passing of time in real-time, providing a uniform view of system time to all components in the Arm system that require it. This includes, in addition to the Generic Timer, trace timestamps and RAS telemetry.

In a system that is composed of chiplets the system counter is distributed over multiple chiplets. There is a primary system counter in a single chiplet that provides the source of the count, and secondary system counters in all other chiplets that require a view of system time. These secondary system counters are used for local distribution of the system count within their respective chiplet.

A system counter meets the requirements as specified by the Arm ARM Generic Timer and by the Arm Base System Architecture Clock and Timer Subsystem. 

There a separate Arm Architecture Reference Manuals for M class and A class implementations.

Looking towards the NanoSoC reference design this is an M class architecture. That architecture states:

The system timer, SysTick 

Generated by the SysTick timer that is an integral component of an Armv7-M processor. SysTick is permanently enabled. An Armv7-M implementation must include a system timer, SysTick, that provides a simple, 24-bit clear-on-write, decrementing, wrap-on-zero counter with a flexible control mechanism.

The timer is clocked by a reference clock. Whether the reference clock is the processor clock or an external clock source is implementation defined. If an implementation uses an external clock, it must document the relationship between the processor clock and the external reference. This is required for system timing calibration, taking account of metastability, clock skew and jitter.

Global timestamping 

When an implementation includes global timestamping, the ITM includes an external ITM timestamp interface, providing, 48-bit or 64-bit global timestamp count value and clock change signal that the system asserts if there is a change in the ratio between the global timestamp clock frequency and the processor clock frequency.

This project will need to consider the interaction between the various time elements within an Arm based Chiplet system.

There are a number of other SoC Labs projects that are looking at the Chiplet implementation space and these are a very small subset of the broader activities in this area. It would be useful to be clear where this work fits into the overall design space for Chiplet based systems. 

The first project in SoC Labs was the SRAM Chiplet. It explores the use of Arm IP to create a memory chiplet design. The Arm Thin links (TLX-400) was the IP investigated for the inter-chiplet exchange. This allows full AXI or AHB protocols to be converted it into an AXI stream interface for transmission between chiplets. 

This non-Arm IP based project clearly offers some alternate method to enable inter-chiplet communication. Understanding the relative benefits/trade offs would be beneficial. 

Hi,

You mention that "The subsystem uses a core Cortex-M0 processor (not the integration-level wrapper) ...."

What did you mean by 'not the integration-level wrapper'?

Hopefully this is obvious but I just wanted to make sure what was meant.

John.
 

Given an academic research perspective what are the architectural design consideration trade offs for this independent QSPI Flash Boot option.

What is the independence buying and what is it costing.

In an academic research I am not sure we are concerned with time to boot. In terms of measuring some part of system performance in order to determine research findings what is being gained from 'eliminating the host dependency during power-on'. For example is power saving during power-on a real concern.

It would be nice to see a clear articulation of the needs, benefits and costs.

John.

I raise the points above as a good example of design considerations that go into any Architectural Design phase. We have a set of enhancements that could be made but how do we rank them in order to decide which is the best to apply community resources towards.

John.

In the NanoSoC Ethernet Subsystem project it says:

"The next generation of NanoSoC provides a modular, YAML-driven SoC generation framework where subsystems are defined declaratively and assembled into complete chip designs. Each subsystem exposes standard AHB slave and master ports, allowing the top-level interconnect generator to wire them into the address map automatically."

Am I correct in assuming this is part of the work on 'adoptability' mentioned above? If it is then it might have been nice to see that reflected in a Milestone here?

John.