Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SERV to design a Many-Core ASAP7 ASIC #96

Open
manili opened this issue Mar 21, 2023 · 5 comments
Open

SERV to design a Many-Core ASAP7 ASIC #96

manili opened this issue Mar 21, 2023 · 5 comments

Comments

@manili
Copy link

manili commented Mar 21, 2023

Hi all,
What are the minimum requirements of a SERV core to design a many-core ASIC using ASAP7 predictive PDK? I'm thinking about something like SMP architecture and I'm going to use OpenSoC Fabric as the fabric. I will use ~10mm^2 of die area so I can generate a comparable result with Google's MPWs and SKY130 PDK.

@olofk
Copy link
Owner

olofk commented Mar 21, 2023

@gatecat did a synthesis test of SERV for ASAP7 about two years ago (see this video around 3:00 https://award-winning.me/serv-for-a-fistful-of-gates/) which indicated it was around 94um2. Note that this is excluding the register file, so you need 128B SRAM for the RF. The good news however is that if you use the Subservient SoC (https://github.com/olofk/subservient/) you only need one single-port SRAM for RF, code and data memories.

@manili
Copy link
Author

manili commented Mar 22, 2023

@olofk
Although, Subservient SoC could be a very good candidate for the scheduler (manager), there's still an issue with it to be used as the processor for Many-Core or Symmetric-Multiprocessor architecture, it has different functional units (e.g. GPIO, SPI, ...) which are not essential for the role in the architecture.
What I want to do is connecting thousand of SERV cores and x4 8K-SRAMs together using mesh topology. Manager/Scheduler (which is going to be Subservient SoC) will read the input from outside, program the x4 SRAMs, initialize SERV cores and start the processing. After process has been done by the cores, it will collect the data and send it to the outside.
Now what is the proper SERV candidate/configuration?

@olofk
Copy link
Owner

olofk commented Mar 22, 2023

I see. To clarify, I didn't really mean using all of subservient, but perhaps the inner layer (subservient_core) if you want to use a combined memory for RF and code+data. If you are fine having a separate memory for the RF, then you can just use serv_rf_top and connect code/data memory + whatever you want to put on the data bus

@olofk
Copy link
Owner

olofk commented Mar 22, 2023

It sounds like a really cool project btw :)

@manili
Copy link
Author

manili commented Mar 22, 2023

Thanks a lot @olofk
I guess I got what you mean, please correct me if I'm wrong:

  1. SERV core itself does not include any sort of RF, $D or $I catch.
  2. SERV core technically needs "at least" 2 SRAMs. One as RF (32x32) and one as $D + $I.
  3. Subservient is an SoC that uses a technique which sees RF + $D + $I as one single unified SRAM.
  4. I can get rid of peripheral and debug interfaces and use the SRAM interface as the NoC connector.

Is it correct?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants