Rocket chip for embedded, FPGA area
Timmy Brolin
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
HALMSTAD | RAVENSBURG | NIVELLES | BARCELONA | KARLSRUHE | CHICAGO | BOSTON
PITTSBURGH | TOKYO | BEIJING | GOTHENBURG | BASEL | COVENTRY | MULHOUSE | MILAN | PUNE
www.hms-networks.com
Mauro Olivieri
--
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
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
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.
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.
--
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/CAK9RgBMGF2hVdwQJY7w4V%2BxYidcginPK6an%3DgdPP4TVW4GjQtw%40mail.gmail.com.
Dr Jonathan Kimmitt
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.
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
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/HE1PR0601MB266644639502863A960584FECBC60%40HE1PR0601MB2666.eurprd06.prod.outlook.com.
Timmy Brolin
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
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.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/HE1PR0601MB2666F49E88FC6A5FE9F3AFF9CBC60%40HE1PR0601MB2666.eurprd06.prod.outlook.com.
Alex Solomatnikov
--
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
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
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.