There are a number of considerations that need to be made at the architectural design phase which really impacts the design decisions later on. With hardware design, it always comes back to PPA - Power, Performance and Area. Having a performant architecture will usually have adverse implications on the power and area of the design in both FPGA and on ASIC. This means whenever a SoC architect is designing a new system, they will need to consider the trade-offs and work out the point that satisfied all criteria. 

For research projects, all three are very important, area especially for budgetary constraints. Have large numbers of SRAMs on chip for example, while they may improve performance and allow for better buffering techniques, especially in bursty applications, will have massive impacts on the area of a die. This is less important in FPGA implementations where there are usually MBs of BRAMs on chip, but for small ASIC designs, you often want to tune the size of your SRAM macros and then consider whether it is better to have multiple memories or one large one for area and performance impact.

To be able to do this, it is important to think about traffic conditions and where data is moving within your SoC. Are there direct channels between your CPU and memory for example or is it going over an arbitrated bus and what impacts does this have when other devices are trying to communicate over this bus too? How does the increased bus complexity impact the area and performance of your SoC? And how can this properly be verified and validated?

Thinking about the types of traffic moving in the system is important too and how this impacts what you're trying to achieve. Is data continuous and what are the implications of that on caching and buffering? What if the data requires higher bandwidth but is more bursty? What happens in the case of back-pressure and stalling within components in your system? Do they lock up and stop processing, are they well fed, do they have a specific amount of output buffering so they can keep processing? Understanding these behaviours of components in your system should decide how not only you shape your architecture of the SoC, but also the architecture of sensory and accelerator subsystems you might be designing. 

The point here being picking up a SoC off the shelf may get you so far, but modifying and analysing the architecture of the SoC, with your specific application case is an important step before hardening.

I think it would be good if we could get some more detail on here around the process of getting something on to an MPW service, the idea that back-end cell views aren't visibile as the foundry might not be making them available to everyone, details about IP merging, other considerations about cornering and seal rings and sawing that occur when being part of an MPW service that impact the design and explain the design rules provided by the intermediary. 

There are often other details with design submission that we need to raise awareness to as well. How long before a submission should someone be submitting a dry run, what should be done about DRC violations (the powerpoints that are expected to be returned with a design) and the general process of submissions so it doesn't become a surprise when it comes around to actually performing the submission.

I hadn’t actually heard of PSS before so that’s really interesting to hear something exists on this front and I think this tackles one of the main problems problems we have when transitioning between implementation. Building this stimulus set, especially around our SoCs and custom accelerators is going to become increasingly important, especially on megaSoC when moving from simulation to FPGA/HAPS based validation.

Really interesting read, I will need to look to see how we can adopt this on nanoSoC.

Hi Soma,

Sorry for only just responding to this, I must have missed the notification of your comment. The certainly many ways you can contribute to the project if you're interested, the more assistance, the better!

Was it more on the verification front you were interested in contributing.

Thanks,

David