Documentation Regarding RocketChip

[Pranav Shreyas]

Hello Developers,

Is there a document depicting the generic module connectivity in a Rocket core? I have a Top level Verilog model of a rocket core and find it hard to understand the connectivity with so many modules. A pictorial representation of how the SOC bus is connected to the core, memory map etc, would be of great help. Thanks in Advance!

Best Regards,

Pranav

[saravanan]

Hi Paranav,

I used to follow the below link.

http://www.lowrisc.org/docs/untether-v0.2/

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/02f51714-2dfd-427c-9824-9b5e10ff3888%40groups.riscv.org.

Mobiveil INC., CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain proprietary confidential or privileged information or otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender and destroy all copies and the original message.

[saravanan]

Hi All,

   1.  Can riscv boots from non-cache-able region ?

   2. bootrom is attached to periphery bus  of the processor. While
booting do processor performs   cahce-able  or non-cache-able read to
bootrom  ?

Thanks

Saravanan





--

[Frohic Food]

Yes of course RISC-V platforms can boot from either cachable or non cachable regions of memory.  The boot address is platform specific (i.e. you choose it yourself).  From 3.3 of the privileged spec: "The pc is set to an implementation-defined reset vector."

If your boot loader loads code from one location and stores it somewhere else before executing it you'll need to execute a FENCE.I instruction to ensure that the write date is flushed far enough that the fetch unit can see it, and the fetch can invalidate it's cache.

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/1c05e189-8f87-c1f6-31a9-e517bc4d302f%40mobiveil.co.in.

[saravanan]

Hi Frohic,

In RISCV Instruction cache cannot be disabled. I believe every time processor executes through cache. Please correct me, if i am wrong.    

[Frohic Food]

The choice of whether an instruction cache (I$) is implemented or not, enabled or not, or even only enabled for specific address ranges is implementation specific.  If you are the architect you get to choose.

Typically you would always implement an I$, and wouldn't have any need to disable or bypass it.

[saravanan]

Do you have idea, how it is implemented in rocket chip?

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CAPQXEtrU2SuvAp2ywSPwKZ52FoSzwG57WFDvnpWe1woOhP41OQ%40mail.gmail.com.

[Karthik Wali]

Hi,

What if I want to use group of Rocket cores and use a common I$? Can the I$ interface be modified to a simple memory interface?

Thanks

Karthik

On Sunday, November 19, 2017 at 8:21:58 AM UTC-8, saravanan wrote:

Do you have idea, how it is implemented in rocket chip?

On 11/19/2017 4:22 PM, Frohic Food wrote:

The choice of whether an instruction cache (I$) is implemented or not, enabled or not, or even only enabled for specific address ranges is implementation specific.  If you are the architect you get to choose.

Typically you would always implement an I$, and wouldn't have any need to disable or bypass it.

On Sun, Nov 19, 2017 at 1:39 AM, saravanan <sara...@mobiveil.co.in> wrote:

Hi Frohic,

In RISCV Instruction cache cannot be disabled. I believe every time processor executes through cache. Please correct me, if i am wrong.    

On 11/18/2017 3:52 PM, Frohic Food wrote:

Yes of course RISC-V platforms can boot from either cachable or non cachable regions of memory.  The boot address is platform specific (i.e. you choose it yourself).  From 3.3 of the privileged spec: "The pc is set to an implementation-defined reset vector."

If your boot loader loads code from one location and stores it somewhere else before executing it you'll need to execute a FENCE.I instruction to ensure that the write date is flushed far enough that the fetch unit can see it, and the fetch can invalidate it's cache.

On Sat, Nov 18, 2017 at 7:04 AM, saravanan <sara...@mobiveil.co.in> wrote:

Hi All,

   1.  Can riscv boots from non-cache-able region ?

   2. bootrom is attached to periphery bus  of the processor. While booting do processor performs   cahce-able  or non-cache-able read to bootrom  ?

Thanks

Saravanan

--
Mobiveil INC., CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain proprietary confidential or privileged information or otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender and destroy all copies and the original message.

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hw-...@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/1c05e189-8f87-c1f6-31a9-e517bc4d302f%40mobiveil.co.in.

Mobiveil INC., CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain proprietary confidential or privileged information or otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender and destroy all copies and the original message.

--
You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hw-...@groups.riscv.org.

To post to this group, send email to hw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CAPQXEtrU2SuvAp2ywSPwKZ52FoSzwG57WFDvnpWe1woOhP41OQ%40mail.gmail.com.

[Andrew Waterman]

On Wed, Jan 15, 2020 at 5:13 PM Karthik Wali <karthik...@gmail.com> wrote:

Hi,

What if I want to use group of Rocket cores and use a common I$? Can the I$ interface be modified to a simple memory interface?

No, your best bet is to give each core a very small I$, which caches a RAM shared by all the cores.

To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/88c73728-7f66-4a1e-b871-730e78b77f42%40groups.riscv.org.

[Hogege NaN]

Hi,

I think that it is depend on targeting application domain.

Motion estimation can have relatively lower data sharing rate, so private local memory is indeed sufficient for such domain and do message-passing is sufficient.

Best,

S.Takano

2020年1月16日(木) 10:32 Andrew Waterman <and...@sifive.com>:

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/CA%2B%2B6G0BA5jS0iyRBkkPvUdtscgOJhvSHfXch2JZ10n5Cf3wDtA%40mail.gmail.com.