Role of gapy, list of peripherals and capabilities of gvsoc
#1
Hello,

getting acquainted with PULP platform these last few weeks - so, first of all, a big thank you and a bigger congratulations to all the creators and contributors.

I haven't had prior experience with tools such gvsoc, so I am bit troubled by trying to wrap my head around where are its limits, actually - hence this post. Please, any clarifications in this discussion would be of great help.

First of all, I've seen the videos from pulp training:
  1. Understanding and working with PULP
  2. GVSoC / Dory Tutorial
  3. A Deep Dive into HW/SW Development with PULP
and I've downloaded the VM and played a bit, followed along the steps demonstrated in the GVSoC/Dory video. All works great - I got the instructions dissasembled, saw the waveforms.

Now, I am getting confused with gapy... what is that, actually? It is mentioned, listed as a tool, but its purpose eludes me... I tried looking for other resources online, but I couldn't form a picture. At first, I though that's a python library that serves as a sort of a glue between the RTL pieces... at some point in the video, it is spoken about python generators... is that it?

In the next video (A deep dive...), I see that IP dependencies are treated using a tool called IPApprox, however - that was back then, while today this is the task of bender, if I am correct. However, where is this list of IPs? In the video, there's a subdirectory IPs of the pulpissimo repo, but I don't see it there: https://github.com/pulp-platform/pulpissimo

Finally, this gvsoc - if I am getting the idea correctly, it is a cycle-accurate simulator, meaning that it can simulate execution of RISCV instructions on a PULP hardware and yield dissasembled instructions, signal waveforms and metrics, such CPI. However, is it a stone carved thing, in the sense that it can simulate only a predefined configuration of pulpissimo SoC? In other words, can it be changed without QuestaSim so that simulates execution of a PULP program on an SoC configuration with SPI and without UART, say?

I think I am pretty sure that, if I want to add novel, arbitrary RTL, then I must have QuestaSim. But if I want to play with pulpissimo SoC configuration (adding or removing some of the existing peripherals), can this be done without QuestaSim, just using gvsoc? It seemed to me that the part where (in the lecture GVSoC tutorial) it is shown how to run with and without cluster is the response to this, but - I didn't get how to exclude uart and then include spi, for example?

Thanks!
Reply
#2
Thanks a lot for the post. Quite a bit there, I'll try to answer a few:
- We have moved to "bender" for the most part instead of IPApprox recently.. that is correct. However the build scripts should execute this automatically
- The IPs will be downloaded form git recursively. You can see the list in Bender.yml
https://github.com/pulp-platform/pulpiss...Bender.yml
Some of these will also start loading additional repos (i.e. pulp_soc...)
- GVSoC as you mention is a simulator so that the entire SoC can be emulated without running RTL simulations. It will accept different configurations, but there are some 'tested and known' configurations. However, there is no 'real' difference between a configuration with/without (say) SPI.. if you do not use the SPI, you do not use it.. it does not contain, area/power contributions for these additional components.
- Unfortunately, stripping some components (at RTL level) from PULPissimo is not always so trivial (some components need to be involved in it). To make this easier we are contributing to something between PULPissimo and PULPino together with our friends at EPFL, LowRISC and OpenHW. It is still under development but you can follow it here (https://github.com/esl-epfl/x-heep)
- Adding/deleting components would make sense at HDL level if you want to build and see how your things work. Otherwise GVSoC is OK to play around with a setup.
Visit pulp-platform.org and follow us on twitter @pulp_platform
Reply
#3
Hi, thank so much for taking the time to respond.

Quote:- We have moved to "bender" for the most part instead of IPApprox recently.. that is correct. However the build scripts should execute this automatically
- The IPs will be downloaded form git recursively. You can see the list in Bender.yml
https://github.com/pulp-platform/pulpiss...Bender.yml
Some of these will also start loading additional repos (i.e. pulp_soc...)


Still, what is gapy? And, even better, what do the "python generators" do, where are they?

Quote:- GVSoC as you mention is a simulator so that the entire SoC can be emulated without running RTL simulations. It will accept different configurations, but there are some 'tested and known' configurations. However, there is no 'real' difference between a configuration with/without (say) SPI.. if you do not use the SPI, you do not use it.. it does not contain, area/power contributions for these additional components.

Right, makes sense - what does a software binary care if I access its part or not ("its part" being the piece of code that simulates the execution of SPI-related instructions). Still, what are the "tested and known" configurations - is there a list? 

Thanks, again!
Reply
#4
Re: gapy
I actually do not know what gapy is.. which video/slide was it? We are not so good with names, things get named/renamed.. maybe it is a dory (https://github.com/pulp-platform/dory) that is mapped to GAP systems. I'll leave it to someone else to answer that.. 

Re: GVSoC configurations: 
Again not the expert here, there should be several available.. It would be easier to help if you had a specific question about it.
Visit pulp-platform.org and follow us on twitter @pulp_platform
Reply
#5
Hi, thanks for the reply.

gapy shows up in slide 8 of this presentation: https://www.pulp-platform.org/docs/pulp_..._part1.pdf 

Mainly, the thing I am not really following here is the concept of "python generators" <== through the elimination system, I concluded that "gapy" is "python generators". What is it? What does it do? How is it used?

I can understand that no one person may know all about such a vast project as PULP, but are there maybe some more users, could you recommend someone, please, on this forum that I could PM and invite to this discussion?

On the GVSoC track, on the traces of your response: while the ability of a software binary (that a simulator is in its nature) to simulate a piece of code does not influence area/consumption/performance of a chip it simulates, you still mention "known and tested" configurations... so, what are these configurations? Do they enhance simulator performance? Or they bring extra functionality? Where can I read more about these?

Thanks.
Reply
#6
I am sorry if more people are not responding, but there is also not a direct question to be honest. gapy seems to be some internal python generator that resides inside the PULP SDK. I appreciate the interest, but why is this of so much interest? Is there something that is not working? Is there some issue with a part of it?

Slide 9 actually contains a list of peripherals that is being supported. These are peripherals, you either use them (like SPI, UART) or you don't, they do not enhance simulator performance, it adds a peripheral to the system that is being simulated with GVSoC. In theory you could mix and match a system according to your whims (5 UARTs..7 SPIs) and develop applications that run on this system (i.e. reading and writing to these peripherals) and debug your system. The slide contains a reference to the documentation.

A tested configuration would be that of GAP8 (a commercial chip by Greenwaves) for example..

I hope that helps.
Visit pulp-platform.org and follow us on twitter @pulp_platform
Reply
#7
Yes, this actually does help Smile Thanks!

It helps because now I understand what do you mean under "configuration". My first impression was that there are "configurations" of PULP platform source code that deliver different versions of GVSoC which influences how the C code is then executed. Now I see your point, under "configuration" you mean (and completely logical) an RTL that has been fabricated, i.e. "tested and known", like you said in the first message. Sorry, I didn't get that. Now it makes sense, thanks for the clarifications.

As for gapy, no, there's nothing that's not working. It's a matter of engineering curiosity: I am simply unaware of the concept "python generator", first time I read about this notion. Also, in the tutorial slides, gapy is just mentioned in slide 8 and I never see it used later on, so... just trying to understand what is going on.

I apologize for being repetitive. I completely understand the difficulty in responding to questions that are too wide. Thank you so much for the responses up to now - I'll try to investigate further and learn more.
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)