Construct Plugin-wrapped objects using Factories OR Parameterize about vexriscv

[Dolu1990]

Hi,

Way 1) What's about :

class DAxiCachedPlugin(config : DataCacheConfig, memoryTranslatorPortConfig : Any = null) extends DBusCachedPlugin(config, memoryTranslatorPortConfig){
  var dAxi  : Axi4 = null

  override def build(pipeline: VexRiscv): Unit = {
    super.build(pipeline)
    dBus.asDirectionLess()
    dAxi = master(dBus.toAxi4Shared().toAxi4()).setName("dAxi")
    dBus = null //For safety, as nobody should use it anymore :)
  }
}

Then just have to use DAxiCachedPlugin instead of DBusCachedPlugin in your VexRiscvConfig, and you will get the Axi bus via the plugin.dAxi attribut

Does it match your needs ?

Way 2) Adding a function to a already existing class without changing the class definition via implicit definitions :

object MyExtention{
  implicit class MyExtentionPimper(that : DataCacheMemBus){
    def toAxi4(stageCmd : Boolean = true) = that.toAxi4Shared(stageCmd).toAxi4()
  }
}

//On the top of the file
import xxxPackage.MyExtention._

//In your hardware stuff 
val axi = plugin.dBus.toAxi4() //The toAxi4  function was added to the DataCacheMemBus via the implicit definition.

[drichmond]

I'm not a fan of either way, though they do address the problem I've encountered.

The first method works - but feels weird. I didn't realize that the Axi4Shared class also includes a toAxi4 method, so I suppose it would work.

It feels weird to ask for a (non-standard) shared bus first, and then up-convert to a more capable (standard) non-shared bus. A non-shared (standard) AXI bus has higher performance than a (non-standard) shared bus because non-shared can issue simultaneous reads and writes. Such a situation is unlikely to happen in AXI Lite, but I can construct a situation where it would happen in a cache

The question I would be left with then is - Does converting from shared to (standard) non-shared inhibit performance? My impression that the answer is yes - because the non-shared AXI signals are still driven by the (non-standard) AXI signals.

Implicits are strange and a lot more scary than useful

[Dolu1990]

The thing is you will not get overhead/performance drawback by using the Axi4Shared and then converting it to Axi4 (In the case of VexRiscv) as the DBusSimpleBus already use a shared readCmd/writeCmd stream channel.

Also, AXI4 could be heavy in FPGA, that's why Axi4Shared was added in SpinalHDL. It avoid all the cost of having to decode and arbitrate two address channels (lot of muxes avoided), also, in many case having a shared stream channel for will not reduce the performance of the bus (especialy if the access are made in burst mode).

In the uncached version of VexRiscv, the Axi4Shared bus also produce no performance overhead, as the cpu will only emit one transaction per cycle (No read + write at once)

Going from DBusSimpleBus to Axi4Shared and then Axi4 is realy natural.

Why are implicits strange ? I mean, in the current case the implicit isn't used to convert the DBusSimpleBus into a another object, but only to add a new functions in the DBusSimpleBus class, which is safe right ?

[drichmond]

Yes, you're right about the non-cached version. I was confused when you switched in your first response. My point still stands for the conversion from non-standard AXI4 Shared, and standard AXI4 shared.

I could believe that AXI4 could be heavy - I'd want to see evidence. But I believe it's negligible compared to the overall cost of implementing a soft processor and the benefits of providing standard AXI4 interfaces far outweigh non-standard interfaces. I've made this point before, but its worth bringing back - vendor tools don't work well with non-standard interfaces. There are a lot of really nice features if you're willing to use AXI

Do you have quantitate evidence that shows that your non-standard AXI Shared interface consumes less resources than standard AXI4? If your evidence suggests that AXI Shared is more efficient, why didn't Xilinx work to include it as part of the specification?

I don't like Implicits because I feel that they're a poor way of providing what you could provide through inheritance. Since Inheritance is a good way of extending codebases, as I've shown here, it makes your codebase harder to use.

Want another example? Try extending the CsrPlugin with another CSR Register without modifying CsrPlugin.scala.

Its your call, it's your project.

[Dolu1990]

Yes your point still stand in general about AXI4 vs Axi4Shared.

About the standard implementeds by VexRiscv, it always an neutral simple memory bus which can be bridged to industry standard without down sides. As instance :

//Convert the simple bus into a full AXI4 one
dBusSimplePlugin.dBus.toAxi4Shared().toAxi4().toFullConfig()

I try to avoid as much as i can code duplications as i'm the only one working on this repository. The less code there is, the better it is, as it mean less testing, less bugs. That's why now there is only one implementation of the DBusSimplePlugin, and not one for each industry busses.

Axi4Shared will offer a better FMax and a smaller Area usage for FPGA, as it will reduce by two the number of address stream to mux on each slaves and also reduce routing ressources usages. Even in a simple configuration each AXI4 address channel will be at least about 40 bits of data. Not only that but also using Axi4Shared instead of Axi4 will reduce by two the cost of having pipelining stages on the address channels.
I don't have numbers about how much is the gain, but i'm sure there is value in it.
Vendor tools can't be used as references, as i strongly thing there aren't a vector of inovation/trial/craziness but only borring and very standard stuff.
Also about the Axi4Shared concept, the Xilinx interconnect datasheet are adressing this issue, basicaly they let's the user driving the both Axi4 address channel from the same driver (except the valid) and then in the interconnect they directly return to a single address channel (if you activate the option).

Look at
https://www.xilinx.com/support/documentation/ip_documentation/axi_interconnect/v2_1/pg059-axi-interconnect.pdf
Figure 2-6: Shared Access Mode
It show that they have an option to internaly of the interconnet have some Axi4Shared like stuff.

Itinerence is great but should be use carefully, in the present case, i'm not against adding things like

class DAxiCachedPlugin(config : DataCacheConfig, memoryTranslatorPortConfig : Any = null) extends DBusCachedPlugin(config, memoryTranslatorPortConfig){
  var dAxi  : Axi4 = null

  override def build(pipeline: VexRiscv): Unit = {
    super.build(pipeline)
    dBus.asDirectionLess()
    dAxi = master(dBus.toAxi4Shared().toAxi4()).setName("dAxi")
    dBus = null //For safety, as nobody should use it anymore :)
  }
}

About the CsrPlugin, you can currently create new plugins which add new CSR register without having to change anything.
Look at :
https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/vexriscv/demo/CustomCsrDemoPlugin.scala#L11
https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/vexriscv/demo/CustomCsrDemoPlugin.scala#L39

In which sense extending VexRiscv is difficult ? I can understand that the documentation is missing and it is very unconventionnal ways of doing things, but is there any fondamental issues to extend VexRiscv codebase ?

[Dolu1990]

Have you seen this channel ?
https://gitter.im/SpinalHDL/VexRiscv?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge

I just documented it in the readme, that was missing.

[drichmond]

I have not seen the gitter channel - I'll start snooping on it. That is a much better resource for asking questions

One of my main gripes about RISC-V projects in general, has been documentation. But you're not alone - most RISC-V projects (Rocket included (!)) provide very little in the way of architectural documentation.

Thanks for the example - that's a good way of doing it. For some reason I had the misconception that you needed to re-use what you declared inside of the CSRPlugin - but your code shows otherwise

Given the challenges you've described you have created a performant RISC-V project. Probably the best one for FPGAs so far in my limited survey.

(And you're patient with critical ass^'s like me to boot!)

[Dolu1990]

Yes, i personnaly prefer chats over delayed messaging ^^ Confusion occure less often.

About documentation, i agree, it is lacking. For VexRiscv, the reason mainly the following :

1. I'm the only one working on this project.
2. I'm not paid to do it, not supported by any physical ways. So, my motivation mainly come from fun.
3. Documentation is a realy time consuming task, and i'm not good a it ^.^ (and it's not realy fun)
4. I also have to manage the SpinalHDL project (and i'm also not paid for it too XD)

Independent open source developpement is realy kind of society borderline activity. You contribute to the society by some ways but get nothing physical in return. So, motivation to do things is something that should be preserved very carefully, and writing documentation isn't helping in it XD, but i try to document things and put example to at least make it usable.

By "very little in the way of architectural documentation" you mean how the internals of the CPU are organized ? where there is bypassing, how many cycle use each instruction, this kind of things ?
Some days ago i added some information about the architectural configuration which produce 1.44 DMIPS/Mhz, look at the end of the https://github.com/SpinalHDL/VexRiscv#area-usage-and-maximal-frequency chapter. I agree that's not enough, some diagram would be great, i will take some time for it.

I also recently added https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/vexriscv/demo/DhrystoneBench.scala which test a bunch of different configuration and print the DMIPS/Mhz for each of them.
The area/Fmax of them can also be optained with https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/vexriscv/demo/SynthesisBench.scala
Again i have to document all of that tools XD

About RISC-V FPGA softcore, it look like VexRiscv is the best one on a good range of the visible spectrum. Then i realy have no idea about proprietary RISC-V softcores.

[drichmond]

I can probably help with documentation if you need it. (I also lack time, since project needs my attention, and probably should be deprecated at this point)

Yes, Internals - What kind of Caching policy, what kind of branch predictor (2-bit table, two level, return address stack, etc), IRQ handling (because some projects have custom handlers), and yes bypassing - as well as Meta-project information - What version of the RISC-V specification do you implement, what extensions work (or are in development), what assumptions do you make,

I recently wrote a paper surveying the different RISC-V architectures.

[Dolu1990]

Help of all kinds are welcome : D Even spotting missing things is great, i'm completly blind to this kind of things.
Anyway, i will add a documentation section which will explaine each plugin internals.

Is the paper online : D ?

[Dolu1990]

I hope it's usefull : https://github.com/SpinalHDL/VexRiscv#vexriscv-architecture