Rocket chip for embedded, FPGA area

318 views
Skip to first unread message

Timmy Brolin

unread,
Feb 28, 2018, 6:57:46 AM2/28/18
to hw-...@groups.riscv.org

Hi All,

 

The rocket chip generator produces a design which takes about 11000 LUTs for even the smallest available configuration of the rocket chip.

From what I can tell, the majority of all those resources seems to be spent on TileLink stuff, and to some extent on the AXI interface.

TileLink looks like a massive overkill for embedded targets.

 

Is there some way to configure the rocket chip generator to generate a design which is more suitable for embedded targets?

 

 

Background:

I am building and evaluating all the RISC-V implementations on the market in an effort to find a good fit for embedded targets.

My target spec. is your basic embedded realtime + IoT softcore set of requirements:

  • RV32IMAC
    • C extension to save precious internal memory.
    • Would have liked to get rid of divison but keep multiplication if only compilers supported it.
  • Fmax 100+ MHz, and reasonable DMIPS.
    • Need some raw performance to keep up with TCP/IP and IoT
  • Nested interrupts.
    • For realtime tasks
  • RISC-V compliant JTAG debug support
  • FPGA area usage ~3000 LUTs
    • It has to be reasonably competitive with competing softcores.

 

Surprisingly, it seems to be impossible to find a RISC-V implementation meeting this spec.

 

Syntacore SCR1 can’t reach 100MHz.

Rocket chip vastly exceeds the area requirement, at ~11000 LUTs.
PicoRV32 lacks JTAG, and has performance issues since it uses 4 clocks per instruction.

Vectorblox ORCA lacks JTAG, the C extension, and surprisingly has no support for bus faults.

ZeroRiscy Lacks standard compliant JTAG, and can’t reach 100MHz.

 

 

Timmy Brolin
M.SC. Computer Systems Engineering


HMS Industrial Networks AB
Stationsgatan 37, Box 4126
300 04 Halmstad, Sweden


Email: tib@hms
.se
Direct: +46 35 17 29 32

http://www.hms-networks.com/images/librariesprovider6/default-album/hms-brands4a26d40422ce670692f4ff00001bbfd4
HALMSTAD | RAVENSBURG | NIVELLES  | BARCELONA  | KARLSRUHE | CHICAGO | BOSTON
PITTSBURGH | TOKYO | BEIJING | GOTHENBURG | BASEL | COVENTRY | MULHOUSE | MILAN | PUNE


www.hms-networks.com

 

Mauro Olivieri

unread,
Mar 1, 2018, 5:46:23 AM3/1/18
to hw-...@groups.riscv.org

Hello,

1) could pls specify what FPGA device you are using for synthesizing the cores?
2) I may be wrong but Zeroriscy supports Jtag "indirectly", as it is suppoed to be integrated within the Pulpino MCU platform, that supports a Jtag interface.

thank you,
M



--
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+unsubscribe@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/HE1PR0601MB2666B198B3924067A0608C0CCBC70%40HE1PR0601MB2666.eurprd06.prod.outlook.com.

Timmy Brolin

unread,
Mar 1, 2018, 8:02:09 AM3/1/18
to Mauro Olivieri, hw-...@groups.riscv.org

Hi,

1) I have tried Synthesizing for different FPGAs. Both LUT4 and LUT6 architectures. Xilinx 7-series for example. The results are similar.

 

2) Yes, Zeroriscy/Pulpino does support JTAG, but it does not seem to be the standard RISC-V JTAG debug interface. It is a custom/proprietary debug interface, which requires a custom Pulpino JTAG debugger. A standard J-Link or Lauterbach debugger will not work as far as I can tell.

 

We have had our fair share of working with specialized and poorly maintained debuggers. It is not a path we wish to go down if it can be avoided.


Regards,
Timmy Brolin


Email: t...@hms.se


Direct: +46 35 17 29 32

http://www.hms-networks.com/images/librariesprovider6/default-album/hms-brands4a26d40422ce670692f4ff00001bbfd4
HALMSTAD | RAVENSBURG | NIVELLES  | BARCELONA  | KARLSRUHE | CHICAGO | BOSTON
PITTSBURGH | TOKYO | BEIJING | GOTHENBURG | BASEL | COVENTRY | MULHOUSE | MILAN | PUNE


www.hms-networks.com

 

--

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.

 

--

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/.

Dr Jonathan Kimmitt

unread,
Mar 1, 2018, 9:17:30 AM3/1/18
to Timmy Brolin, Mauro Olivieri, hw-...@groups.riscv.org

Dear Timmy,

I understand your desire for a shrink-wrapped approach. This is the market the Cortex-M0 and its brethren is aimed at. Some of these RISCV cores are oriented a little at the research stage just now. But a million dollars spent on just one type of ARM cpu, which is inflexible if your needs change, is money that would fund RISCV development that would become a permanent open-source legacy of everybody. Obsolescence of test kit is a problem and Lauterbach make a good product, but for genuine long-term security of your IP, you should take ownership of the maintenance of your product in house, or support the research community to transfer the knowledge to you.

Did you know new ARM cores are often on the market for months before they get debug support? And this is from a large, well funded company. And what do you know every ARM core has a different way of debugging, so much so that the only way to support many cores is to make the debugger itself an FPGA.

And if you use a proprietary core, you need to have a procedure to control who can and cannot access the source code of the IP. This will be an extra hidden cost on your company for sure.

Regards,
Jonathan

Timmy Brolin

unread,
Mar 1, 2018, 11:49:30 AM3/1/18
to Dr Jonathan Kimmitt, Mauro Olivieri, hw-...@groups.riscv.org

Hi Jonathan,

There is no need to convince me of the advantages of open source.

If there is a RISC-V implementation out there which is reasonably close to meeting the requirements, I would develop and contribute the missing pieces.
However, having evaluated about 18 different RISC-V implementations now, I struggle to even identify one which with reasonable effort could be adapted to work well for a typical embedded application like this.
Which is why I posted to this mailing list. I was hoping that I was simply missing some config option for rocket-chip, or that there is another implementation out there which I was unaware of.

 

I am sure the proprietary JTAG implementation in Pulpino works for them, but it has no future outside Pulpino.

The entire point of RISC-V is create an open standard with a complete and long term ecosystem. It is what sets RISC-V apart from the countless other open-sourced CPUs out there.

 

Best Regards,
Timmy Brolin

Dr Jonathan Kimmitt

unread,
Mar 1, 2018, 12:06:20 PM3/1/18
to hw-...@groups.riscv.org

Much of the complication in Rocket arises from trying to compensate for the latency of DDR with

caches and branch prediction and so on. If you just want a core that runs single cycle from on-chip

RAM, this is a rather different beast. But all your feedback is valuable for our future developments.

Alex Solomatnikov

unread,
Mar 1, 2018, 2:51:26 PM3/1/18
to Timmy Brolin, hw-...@groups.riscv.org
Could you provide the information about exact config of Rocket you evaluated and all other relevant info to reproduce your result?

I'd like to take a look at why TileLink is large. 

I did this in the past for some other project and once the root cause was identified, it was easy to fix/improve.

Thanks,
Alex

--
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+unsubscribe@groups.riscv.org.

Timmy Brolin

unread,
Mar 2, 2018, 3:21:44 AM3/2/18
to Alex Solomatnikov, hw-...@groups.riscv.org

See below for my synthesis results and rocket chip config.
The rocket chip config is basically the standard “TinyConfig”, but with a few more interrupts.

I synthesise the generated Verilog in Vivado 2017.3 for target xczu17eg-ffve1924-3-e

 

As you can see in the synthesis result, the core (RocketTile) size is not exactly great but possibly acceptable at 4413 LUTs.

Competing softcores are at 2000 LUTs, so even at 4413 RISC-V is at a major competitive disadvantage.

But then TileLink and AXI related parts seems to blow the design up to 11208 LUTs for some reason which I don’t quite understand?

“WithIncoherentTiles” is used, so it should not be coherency mechanisms. Is it atomics?

 

Thanks,
Timmy Brolin

 

 

 

class MyBaseConfig extends Config(new BaseCoreplexConfig().alter((site,here,up) => {

  // DTS descriptive parameters

  case DTSModel => "freechips,rocketchip-unknown"

  case DTSCompat => Nil

  case DTSTimebase => BigInt(1000000) // 1 MHz

  // External port parameters

  case NExtTopInterrupts => 16

  case ExtMem => MasterPortParams(

                      base = x"8000_0000",

                      size = x"1000_0000",

                      beatBytes = site(MemoryBusKey).beatBytes,

                      idBits = 4)

  case ExtBus => MasterPortParams(

                      base = x"6000_0000",

                      size = x"2000_0000",

                      beatBytes = site(MemoryBusKey).beatBytes,

                      idBits = 4)

  case ExtIn  => SlavePortParams(beatBytes = 8, idBits = 8, sourceBits = 4)

}))

 

class MyTinyConfig extends Config(

  new WithNMemoryChannels(0) ++

  new WithIncoherentTiles ++

  new With1TinyCore ++

  new MyBaseConfig)

 

 

 

From: Alex Solomatnikov [mailto:so...@sifive.com]
Sent: den 1 mars 2018 20:51
To: Timmy Brolin <t...@hms.se>
Cc: hw-...@groups.riscv.org
Subject: Re: [hw-dev] Rocket chip for embedded, FPGA area

 

Could you provide the information about exact config of Rocket you evaluated and all other relevant info to reproduce your result?


Email: t...@hms.se


Direct: +46 35 17 29 32

http://www.hms-networks.com/images/librariesprovider6/default-album/hms-brands4a26d40422ce670692f4ff00001bbfd4
HALMSTAD | RAVENSBURG | NIVELLES  | BARCELONA  | KARLSRUHE | CHICAGO | BOSTON
PITTSBURGH | TOKYO | BEIJING | GOTHENBURG | BASEL | COVENTRY | MULHOUSE | MILAN | PUNE


www.hms-networks.com

 

--

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.

Reply all
Reply to author
Forward
0 new messages