Anyone interested in joining the meeting this week. It is tomorrow (19th) at 3pm UK time: https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZWUxYzY4YTQtNWQxYy00YjAyLWJjOGItOGQ4NWVkZGQ5MjVj%40thread.v2/0?context=%7b%22Tid%22%3a%224a5378f9-29f4-4d3e-be89-669d03ada9d8%22%2c%22Oid%22%3a%22da03259c-2f3e-4038-96bb-de5e01994a6c%22%7d

Hi, Thanks for getting in contact.
The development of the HAPS workflow has been on pause for a little while as we're getting ready for a tape out. However the plans we have in place are to first build an FPGA image using our nanosoc reference design as this has already been implemented on the zcu104 and other zynq platforms. The main goal for this effort is to work on the debug environment for a SoC

After that the plan is to use the system for the development of an A class SoC. First will be to implement the A53 subsystem that we have already developed and again ensure that we can successfully debug this in the HAPS. 

Then we will use this to further develop the A53 subsystem into a full linux capable SoC; although this is likely to take some time.

If any of these are of interest to getting involved in, please let us know

Daniel

Hi,
I saw you sent a couple of messages to the soclabs contact about setting up the Arm IP. For our reference SoC projects, we have decided to keep all of the Arm IP seperate from our open-source IP. This is so we don't risk accidentally publishing any Arm IP on our git. 

The way we have done this on our server is to have a separate drive with all the arm IP that is laid out as in this article: https://soclabs.org/design-flow/ip-library-structure
You should be able to see from some of the nanosoc flist files there is the environment variable $ARM_IP_LIBRARY_PATH. You will need this setup on your system so that the flows know where to find the Arm IP. 

Hi,

I think we have now fixed this issue. Essentially bootloader was trying to pull data from uninitialised memory.

If you could pull the latest changes from accelerator-project and try to run this

Daniel

Hi, 

Thanks for getting in contact about this issue. I'd forgotten to add the address_map_m1_megasoc.sv file to the repository.

The newest update should work now. Just as a warning, this project is still under development so there may be some major changes happening. If you do find any bugs like this please let me know and I'll try to resolve them as soon as possible.

Daniel

Hi Duy Hieu,

The Expansion subsystem is a seperate git submodule. It may the case that this was added more recently. This link may help: https://stackoverflow.com/questions/1030169/pull-latest-changes-for-all-git-submodules
You will also have to run 'make first_time_setup' from the expansion_subsystem_tech directory. I will try to make this easier to do in the next update

And thank you for that suggestion, I will implement that change in the next update

Daniel. 

Hi,

One thing to think about, the current GPIO controller in nanoSoC doesn't have any way to control the drive strength of the pads. This could be a useful thing for your system, so that if you need to make any fine tuning/adjustment to the output current of the drivers. On the physical side it would be something like this:

And the digital side would need a few bits to control the drive strength of each pin (or you could control all of them with a single value)

It was historically left as a request of collaboration as we wanted to try and gauge what the different requirements for projects are in terms of data bandwidth and how DMA configurations can be tuned for applications. 

But I think the actual development work for this is complete so I'm going to move it to case studies and mark as complete. 

Hi John

Yes we do have a tape out targeted for this IP. I'm going to add some more detail to the project soon on this subject.

The plan is to tape out nanoSoC with this IP integrated in July 2026 on a miniASIC shuttle. We have already tested and verified the integration of the IP in nanoSoC and shown it to be working on FPGA. I will add some more detail about the backend floorplanning and constraints for this IP to this project

Daniel

Hi Lewis, 

Just wanted to share this with you. I've been doing some initial work on the nanoSoC SKY130 flow, and above is the layout of nanoSoC. I've not gone through the whole flow yet, but just wanted to reassure you that we should have plenty of space. The 4 blocks there are the SRAMs, the grey bits in between are all the standard cells (highlighted green is the bootrom) 

We've not got a bootrom macro (as OpenRam doesn't seem to generate timing views for this), but we should be fine just hard coding this with tie cells

Still work to do on timing and everything but hopefully this gives a bit of a picture

Daniel