Is it worth linking back certain stages of design flow pages to the appropriate tools in this section?

Basic tool guides would be useful, even if it is just pointing people in the right direction and not necessarily hosted on this site.

Would it be worth adding some Open-source, Synopsys and Cadence EDA tools to this section?

Is it worth splitting the tools and models into two (or more) groups? Off the top of my head, seperating the arm-provided tools for open-source tools might be a good starting point. Just makes it more obvious of the quality and support people will get with particular tools - are they industry tools or something someone has built for a PhD?

Hi Srimanth,

Not just yet. I think by commenting on this article you should now get any updates for this page. I'll work with John to try and get a system sorted to make this easier in the future.

Thanks,

David Mapstone

Hi Hakan,

Thanks for you comments.

1) - I do agree but I think that the topic for the verification isn't the verification of the accelerator and the wrapper but to demonstrate we are able get data in and out of the accelerator over the Nanosoc architecture. I through this together quite quickly and I thought this was the most appropriate image I had created to demonstrate what we are trying to do in this flow - showing the data flow from outside the soc to the accelerator is what the image is trying to visualise. 

I think a separate flow for wrapper verification is required to address the points you have addressed and is something that is on my to-do list when I get around to fleshing the wrapper infrastructure out further.

2) I thought the system structure picture was quite helpful to set the context for what we are trying to achieve and the fact that we have these other initiators in the system but we are deciding to only use the ADP Debug port at this time. I will probably add to this later to suggest that there are faster and (maybe better??) approaches available and how they could be carried out but our focus is clearly on using the debug interface. If you and others think that the diagram distracts from the rest of the flow, I will take it out.

3) Yeah, I agree - I can send you the full size image of this for you to use when putting the system together but unfortunately this is a technical limitation of the website at the moment. I could do as you've proposed but I think we should just push for a fix to the site instead of working around it.

4) Again back to my first point. It demonstrates how we are getting data to and from the accelerator which is the focus of this verification approach I believe.

Thanks,

David

Brilliant, thank you!

Thanks for your comments. 

I think we should lay out a clear distinction between engine, wrapper, system and accelerator verification. Accelerator verification encompasses all of the following and the diagram below should visualise very simply which is going on at each abstraction.

In this case, we have have missed out a stage of verification which is the Wrapper Verification which we will need to come back to as I said. The aim of this flow is for basic Accelerator "System" Verification where we are trying to verify the accelerator "through" the System Infrastructure. We are checking we have connected the accelerator (within its wrapper) into the system correctly, NOT whether the accelerator and wrapper are working correctly. We need them to work correctly in order to check the results coming back but in the case of real-world accelerator development, the verification should already be complete at both engine and wrapper level before attempting system integration - we are having to do this out of order to uncover bugs in the system integration and framework.

"What is the minimal data input and output for interfacing with the AHB-lite and how it looks like for this accelerator example" - Thank you for raising this, I will add more detail to this tomorrow in the flow but bare in mind, this is incredibly specific to the accelerator being used.  A brief overview though is we will use the ADP debug port to write 16 32-bit words to the accelerator input port which will trigger a 512-bit data packet to be sent into the engine.  The engine will return a 256-bit data packet which will be decomposed into 8 32-bit words which can be read back via the ADP debug port. The ADP Debug module will handle the AHB-Lite communication within the Nanosoc.

Thanks,
David

I don't think putting the detailed example wrapper in here is necessary and I will be producing my own version of the wrapper flow for others to use to wrap their accelerators up later this month. I think pointing people to the arm documentation with this information is okay, but I don't think directly copying from it is the right thing to do as we need to explicitly specify the interfaces the wrapper requires. I think putting this in here may confuse people as the ECOREVNUM signals for example aren't relevant for the Nanosoc and the detailed functionality of the example engine (the reg component in this case) is out of place. I think we just need to be careful about the information we put out regarding Nanosoc as if researchers come along and read it and then use it to spec their own accelerators off of, they may end up going in the wrong direction.

This section should slowly be populated by SoC Labs design flows 

Hi Fanis,

The top-level repository will be available here: https://git.soton.ac.uk/soclabs/accelerator-system-top. This is very much a work in progress at the moment but the idea is that you should be able to fork this repository and it will clone the SoC Labs IP repositories plus your accelerator repository.

Your accelerator engine repository will be free for you to shape in any way you wish, we may later on decide to provide a forkable repo that people can use as a starting point but at the moment, we don't currently have this. We will provide some guidance later on what key things should be present in your accelerator engine repository.

Thanks,

David