Correct group to discuss Rocket to subsystem in a larger FPGA system?

Hello,

Could you tell me if this right group to discuss how I go about creating a Rocket chip based subsystem for inclusion in a larger FPGA system? If not could you direct me to the group that would be most appropriate, if one exists?

Thanks and regards,

Gadge

Yes! We are happy to help you use the rocket-chip open source repo. You can also email hw-dev@groups.riscv.org to reach a wider group of rocket-chip users.

What do you need to know?

Megan

Hello all,

What I am planning (or would like) to do is show that we
have the run-time debug capability for the RISCV which has the debug module as
currently being led by Tim Newsome (i.e. External Debug Support version 0.11 Sept12).
In order to do that I would like to have a RISCV core plus AXI plus the debug module. I don’t believe I need
the tilelinks. I have an existing FPGA system into which I would like to slot
the RISCV subsystem.

Is it possible to generate Verilog for such a minimal system
which I can then stitch in to the Verilog for my FPGA?

Any suggestions on how best to achieve this?

Thanks in advance,

  Gadge
1 Like

Gadge,

It’s quite simple to generate RISC-V Verilog with rocket-chip repository, especially if you have an existing FPGA system and are willing to code up the top level wrapper code to interface to the rest of your system.

You can follow the instructions on the rocket-chip README to check out the repository and generate verilog for RocketChipTop.

You will need to choose or create a ‘Config’ which has your exact parameters (number of AXI memory ports, processor size, cache parameters, for example). The README has some information on this, you can browse the Config.scala files to see what sorts of tuning is available, but you can see how close “DefaultConfig”, “TinyConfig”, or “DefaultFPGASmallConfig” is for your purposes.

The DebugModule described in Tim Newsome’s spec is included by default. If you want to add the JTAG interface described in the spec, you can add WithJtagDTM_ to your Config name. So you could build the verilog with something like:

make verilog CONFIG=WithJtagDTM_TinyConfig

Good luck and let us know if you have more questions.
-Megan

1 Like

Megan,

Thank you very much for you help.
So I can cascade the names, for example, have something like:

class WithOneAxiChannel extends Config (
(pname, site, here) => pname match {
case case NExtMMIOAXIChannels => 1
}

and then do something like:

make verilog CONFIG=WithOneAxiChannel_WithJtagDTM_TinyConfig.

Is there a description of what the parameters mean? For example, what does ‘NExtBusAXIChannels’ refer to? Do I need to set that to 1?
If such information exists online or in a document, I would appreciate a steer in the right dierction.

Thanks again,

Gadge

Hi Gadge,

Yes, you can cascade the names exactly as you show. They are applied in order, starting from the right with the things on the left adding on.

At the moment there isn’t a thorough description of each parameter other than comments in the code, but happy to explain any here.

NExtBusAXIChannels=1 means that you want an external AXI memory bus coming out of RocketChipTop, e.g. to an external memory controller. NExtMMIOAXIBusChannels=1 means you want one (or more) external memory-mapped IO bus coming out of RocketChipTop, usually to connect to memory-mapped peripherals. In general, the Configs in src/main/rocketchip/Configs.scala apply to “SoC” level things, like top-level ports, synchronizers, interrupts. Ther Configs in src/main/coreplex/Configs.scala set parameters like number of CPUs, ISA variant, whether you support FPU, etc.

Megan

Hello Megan,

Thanks again.
I have some further questions, I hope you don’t mind me asking them of you.
I have a class:

class USTConfig extends Config (
(pname, site, here) => pname match {
case NExtBusAXIChannels => 1
// case NExtMMIOAXIChannels => 1
case NExtMMIOAHBChannels => 1
case _ => throw new CDEMatchError
}
)

When I do:

make verilog CONFIG=USTConfig_WithJtagDTM_TinyConfig

I get an ‘illegal argument exception error’.

But when I do:

make verilog CONFIG=WithJtagDTM_TinyConfig_USTConfig

I don’t get an error nor do I get the AXI or AHB instantiated in the verilog.
I am guessing that the correct invocation should be ‘CONFIG=USTConfig_WithJtagDTM_TinyConfig’ as the application is done right to left.
Can I not set NExtMMIOAXIChannels or NExtMMIOAHBChannels?

You said in your previous reply:
NExtBusAXIChannels=1 means that you want an external AXI memory bus
coming out of RocketChipTop, e.g. to an external memory controller.
NExtMMIOAXIBusChannels=1 means you want one (or more) external
memory-mapped IO bus coming out of RocketChipTop, usually to connect to
memory-mapped peripherals.
Does this mean there would be an expectation that there will always be at least two buses? I mean can I not have a single AXI which is used to communicate to memory via the Memory Controller and other memory mapped perpherals?

Thanks and regards,

Gadge

Hello,

Can someone advise how I get a AXI master interface at the toplevel?
I have a class:

class USTConfig extends Config (
(pname, site, here) => pname match {
case NExtBusAXIChannels => 1
case _ => throw new CDEMatchError
}
)

When I do:
make verilog CONFIG=USTConfig_WithJtagDTM_TinyConfig

I get an ‘ExampleTop’ in the generate verilog which has a slave port not a master.

Thanks and regards,

Gadge

Gadge,

You’re correct, I gave you the wrong parameter name. “BusAXI” is for master inputs as you discovered.

If you want an AXI port to memory (e.g. DDR) you would want to have the parameter (which is disabled in TinyConfig)

NMemoryChannels => Dump(“N_MEM_CHANNELS”, 1)
TMemoryChannels => BusType.AXI

If you want an AXI port to Memory-mapped peripherals, you would want to set

case NExtBusMMIOAXIChannels => 1
case ExtMMIOPorts => List[AddrMapEntry]( … address map entries to describe which addresses should go out on this port)

Hope this helps!

Megan,

Thanks for the clarification.
I resorted to building a DefaultRV32Config, which is much larger than the Tiny version but it has a master AXI port. This allows us to proceed with integrating this into aour demno platform to show the debug mechanism operating (this is the Tim Newsome proposal). Can you think of any issues we might hit with using this core?

Is there a diagram or a note which show the describing the hierachy of the various Configs?

Thanks again for your help.

Gadge