Where is the "get started" documentation?

[byllgrim]

Greetings.

I don't have time to be eloquent, sorry.

Is there some documentation, readme or tutorial on how to use the pulp designs?
Maybe it is common knowledge in the field of digital design (like ./configure make is a common standard in software), but I am a meager noob and student and I spent lots of hours without getting anything to work.

I managed to use modelsim to compile all RI5CY sources necessary to run a simulation of tb_riscv_core, but there was no clock signal and I don't know how to load programs etc.
Maybe I was hasty but I couldn't find proper help in the repo.

Thanks.
Regards Robin.

[kgf]

Hello,

The easiest way to get started is to start with a platform (rather than a single core like RI5CY), that is a system that includes both the core, and associated peripherals, memory and the interconnect that belongs to it.

If you want to do very basic things, the older PULPino (https://github.com/pulp-platform/pulpino) is a very simple platform, and I would follow the instructions on the github page. This is good, if you are only interested in the core, and not necessarily want to use it as a microcontroller.

If you are planning on using a more complete (and up to date) single core microcontroller I would look at PULPissimo (https://github.com/pulp-platform/pulpissimo). Both of these platforms will use the PULP SDK (https://github.com/pulp-platform/pulp-sdk). There are also several platforms that use multiple cores (like HERO and OpenPULP, but this is probably not needed for you at this stage).

There are other platforms (that are not designed by us) that use RI5CY, like the Greenwaves GAP8 (which has a Platform IO based environment) https://greenwaves-technologies.com/en/sdk/ or open-isa.org that provides its own environment (https://open-isa.org/downloads/).

It is of course also possible to just use the core, but as you point out, it is not very directly accessible (you normally always need it to be part of a platform to do something with it).

I hope this helps a little
KGF

[byllgrim]

Hello,

The easiest way to get started is to start with a platform [...]

[...]

I hope this helps a little
KGF

Thank you!

That narrows my quest a little, so that I won't exhaust myself on dead-ends.
I shall heed your advice and give it another shot.

Regards Robin.

[byllgrim]

[...]

If you want to do very basic things, the older PULPino (https://github.com/pulp-platform/pulpino) is a very simple platform, and I would follow the instructions on the github page.

[...]

Oi! Indeed this was a good way to get started quickly.

After a bit of finicking (I journaled this endeavor if anyone is interested) I got a nice little

Code:

# RX string: Hello World!!!!!

Thanks again.

[kgf]

[Athena]

I have a similar question regarding getting started with the PULP systems.
Pulpissimo has documentation regarding the peripherals.
However, I could not finding hardware description of memory system used in it. 
The same goes for the single cluster system. 
How exactly is the TCDM memory and Instruction cache being used and described.



Maybe, I am understanding it wrong since I am just starting to work with these systems. 

[kgf]

Hello,

The memory system is not that exciting actually. The drawing on the GitHub page is actually pretty accurate. There is no real 'memory hierarchy' it is assumed that all the memory in the PULPissimo system is (relatively) small. A multi banked memory (Tightly Coupled Data Memory == TCDM) is connected to the requesting systems cores (one for data one for instruction), accelerators, DMA engine and JTAG through the logarithmic interconnect that does arbitration of the requests. In most cases accesses will be to different banks and all requests can be handled in parallel. So all devices that access memory should be stallable (in case they do not get access to the memory) and in the best case (no conflicts) all memory accesses will be handled with single cycle latency. 

In Arnold for example the TCDM is 512 kByte and there are 16 banks of memory cuts. The core has a tiny buffer (typically 1 word) for the instructions (to handle compressed instructions) if really needed an instruction cache could be connected to it as well, we do not use it, and it is not part of the PULPissimo distribution.

Does that answer the question?

[Athena]

Hello,

The memory system is not that exciting actually. The drawing on the GitHub page is actually pretty accurate. There is no real 'memory hierarchy' it is assumed that all the memory in the PULPissimo system is (relatively) small. A multi banked memory (Tightly Coupled Data Memory == TCDM) is connected to the requesting systems cores (one for data one for instruction), accelerators, DMA engine and JTAG through the logarithmic interconnect that does arbitration of the requests. In most cases accesses will be to different banks and all requests can be handled in parallel. So all devices that access memory should be stallable (in case they do not get access to the memory) and in the best case (no conflicts) all memory accesses will be handled with single cycle latency. 

In Arnold for example the TCDM is 512 kByte and there are 16 banks of memory cuts. The core has a tiny buffer (typically 1 word) for the instructions (to handle compressed instructions) if really needed an instruction cache could be connected to it as well, we do not use it, and it is not part of the PULPissimo distribution.

Does that answer the question?

Hello,

Yes, well it sort of does. 
I specifically wanted to see the implementation of memory system in hardware description language. 
I am working on making my own system based on the instructions given on the github page and I will investigate a bit more. And then perhaps phrase the question in a better way.

Thanks!

[DavidL]

Hi, kgf,
About the instruction cache, I have a few questions. It seems there are some repositories in the github(icache_private, cluster_peripherals/icache_ctrl_unit, icahe_mp_128_pf, icache-intc, hier-icache...)
Some of them might be deprecated or not well documented. So if I try to use one of them, which one to choose?
are there any SoC(pulpissimo, pulpino) use one the these implementations? Any more document to read?
Thanks!

Hello,

The memory system is not that exciting actually. The drawing on the GitHub page is actually pretty accurate. There is no real 'memory hierarchy' it is assumed that all the memory in the PULPissimo system is (relatively) small. A multi banked memory (Tightly Coupled Data Memory == TCDM) is connected to the requesting systems cores (one for data one for instruction), accelerators, DMA engine and JTAG through the logarithmic interconnect that does arbitration of the requests. In most cases accesses will be to different banks and all requests can be handled in parallel. So all devices that access memory should be stallable (in case they do not get access to the memory) and in the best case (no conflicts) all memory accesses will be handled with single cycle latency. 

In Arnold for example the TCDM is 512 kByte and there are 16 banks of memory cuts. The core has a tiny buffer (typically 1 word) for the instructions (to handle compressed instructions) if really needed an instruction cache could be connected to it as well, we do not use it, and it is not part of the PULPissimo distribution.

Does that answer the question?

[kgf]

Hi, kgf,
About the instruction cache, I have a few questions. It seems there are some repositories in the github(icache_private, cluster_peripherals/icache_ctrl_unit, icahe_mp_128_pf, icache-intc, hier-icache...)
Some of them might be deprecated or not well documented. So if I try to use one of them, which one to choose?
are there any SoC(pulpissimo, pulpino) use one the these implementations? Any more document to read?
Thanks!

These repositories contain code and sub blocks used in our systems. It is true that some of it is experimental and not all are mature. They are not meant to be used directly but the 'proper' versions should be automatically taken by the higher level platforms (i.e. PULPissimo, PULPopen, BigPULP). 

At least in the beginning I would suggest to use them as part of the larger platforms. Later you will realize that the different parameters are actually defined at higher levels. 

Of course most of the code is also directly usable for other projects, but as you point out some of them lack the documentation, therefore it is not always very straightforward to do so