CPU Build Documentation incorrect... about spinalhdl HOT 24 CLOSED

Hi,
Yes sorry, the documentation isn't uptodate. there was a CoreQSysAvalon, it was striped out durring some changes to reduce the code base
A second iteration of the CPU with many improvments and new features was made there :
https://github.com/SpinalHDL/VexRiscv

• Better FMax
• Smaller
• Optional MMU
• Better plugin system to add new instruction in the CPU

Are you interrested just by the CPU itself ? Or a complet SoC with it ?
Currently i have a demo project running on DE1-SoC. If you want i can send it to you.

Currently this VexRiscv is AXI4, but it would be easy to make it avalon ready.

Then about Qsys component generation, there is a utilie which is able to look the interface of a SpinalHDL component and then generate QSys tcl script to import it in QSys.
There is an example of this tool used on a AvalonMMVgaCtrl :

Let's me know if you are interrested by the VexRiscv

from spinalhdl.

from spinalhdl.

Oh, wow... QSysifying components (So that other people can consume this as a Macro block) was actually blindingly easy, once it became clearer what I was not doing right- the simpler, clearer example you gave me helped quite a bit. It's not "right" but it generated the right stuff for what I did tell SpinalHDL I wanted to do.

This desperately needs an update on your documentation (I know...busy, and legitimately so...) Spinal does have quite a bit of potential here- it's just...somewhat hard unless you're steeped in it to get really going here. I think that between this and CLaSH, I've got some winners for my own personal projects... :D

from spinalhdl.

I'd greatly appreciate it and hints on what needs to
be done to make VexRiscv Avalon capable...or a timeline on when you expect
to have that as a new update on it. :-D

So it need exactly the same than what was required to make it AXI4, just a two bridges (I+D) from a neutral bus to Avalon. Or a native dedicated plugin could be added to nativlely do Avalon memory request, but i don't think there is realy gain in it.

There is how is currently implemented the bridge from the simple instruction bus (without cache) to AXI4 : https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/VexRiscv/Plugin/IBusSimplePlugin.scala#L47
It's realy straigt forward.

Which configuration are you interrested in ? Instruction bus with/without cache ? Data bus with/without cache ?

Is the current RISC-V
core in the SpinalHDL core usable (I'm needing a stopgap that has a proper
JTAG interface, amongst other things...)?

The Riscv in the SpinalHDL lib (this one : https://github.com/SpinalHDL/SpinalHDL/tree/master/lib/src/main/scala/spinal/lib/cpu/riscv/impl) is usable (had JTAG working with openOCD + GDB debuging), but is no more maintained, because the new implementation (https://github.com/SpinalHDL/VexRiscv) is better from all point of view (fmax/area/features, except there is currently no avalon implementation) (VexRiscv has also fully fontionnal JTAG with openOCD + GDB debuging)

But on thing which is very cool with the VexRiscv and also with its SoC, it's the fact that all the system can be runned in sim with Verilator at 500 Kcycles/second simulated, and also with interractive JTAG/openOCD/GDB, which mean you can debug the CPU/SoC which is running in simulation by using eclipse C debugger. It's realy practical (you can capture the wave of all signals).

from spinalhdl.

I'm going to be honest and tell you I'm a greedy SOB- "all of the above" would be what I'd reach for if I wasn't also very gracious. :D It's appreciated what you've done so far with the tool here. Cached is probably going to be preferable. We've got more than enough real-estate on the FPGA for the initial phases of this project to allocate the full beast there and laugh all the way to the bank for performance, ease of ASIC-ability, etc.

The fact that it can FULLY be simulated in Verilator is epic. I have to agree it's a better, much better solution. I'm just running into a few gotchas (It kind of defeats the purpose to have QSysify do conduits so I have to hand add the core into the SoC I'm building for this customer's project. :D

from spinalhdl.

As for the documentation, I've noticed you've flagged the stuff as deprecated/unsupported.

With it having that status over VexRiscv and Briey, you probably ought to clean the entries out (after archiving for posterity) of the documentation and take it out into a deprecated area if you want to give some examples, or ripped out if not- because...upon review...the VexRiscv stuff's "better" and at least a bit clearer.

I'll log a differing issue for QSysify... >:-D

from spinalhdl.

Hi,
I'm currently in holiday, hard to anser correctly currently, will have some time to manage this sunday ^^

from spinalhdl.

I made a Avalon port, not tested in sim/fpga, there : https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/VexRiscv/demo/VexRiscvAvalon.scala

It also generate the QSys tcl script on the side.
Just in QSys, don't forget to link the debug_resetOut to the reset :

Then as jtag to avalon bridge, you can use this one :

Another way, which would be safer, as this is the one that i'm always using for my tests and my SoC is to use the AXI4 version of the CPU. Currently the QSysify doesn't support AXI4, but this list of things :

It is easy to add support of new things.

from spinalhdl.

Yes i agree, i have to move the documentation to the Briey/VexRiscv stuff and move the old stuff into a dedicated area :)

from spinalhdl.

Some updates about VexRiscv https://github.com/SpinalHDL/VexRiscv#area--fmax

from spinalhdl.

from spinalhdl.

I'm currently implementing some avalon verification for the cpu

from spinalhdl.

Hi, i added regression stuff to test the full avalon version of the CPU, it's working well

(regression command : make clean run IBUS=CACHED_AVALON DBUS=CACHED_AVALON DEBUG_PLUGIN=AVALON)

from spinalhdl.

Did someone managed to get the Avalon version working?, I have integrated it in Qsys but I'm unable to halt the processor using OpenOCD and if I initialize the VexRISCV memories nothing happens at all.
I know this works fine, I'm just asking for a working Qsys demo. I'm asking to save some time, if not, I'll figure it out by myself.

from spinalhdl.

Hi,

So currently the Avalon version of the CPU is passing tests.
To run tests you have to :

1. Generate the verilog by modifiying in VexRiscvAvalon.scala

• val report = SpinalVhdl{  =>     val report = SpinalVerilog{
  

• cpu.setDefinitionName("VexRiscvAvalon")   =>       //cpu.setDefinitionName("VexRiscvAvalon")
  this will genreate the toplevel into VexRiscv.v instead of VexRiscvAvalon.v
  

2. run into src/test/cpp/regression the following command :

• make clean run IBUS=CACHED_AVALON DBUS=CACHED_AVALON DEBUG_PLUGIN=AVALON CSR=no MMU=no
  

Then i have to say that the avalon version of the CPU was never tested / integrated into QSys (as far i know) Maybe it would be better to try the standard version first (axi with apb for the debug), just to be sure that all the other things are ok.

Also if you want to get the wave from the regression test, just add TRACE=yes into the command line
I hope it help XD

Let's me know :)

One thing that you can do is running the CPU through a ROM ? Then you don't have to run trough the JTAG stuff, and maybe it could point some bugs ? Can you run a simulation of your QSys design ?

from spinalhdl.

Hooo also, the Avalon version of the CPU doesn't rework anything deep in it, it is just a very fine bridging, so if there is some bug it's just on the interface layer / bridge

from spinalhdl.

Hooo one issue could be :
How did you wire the reset stuffs ?

from spinalhdl.

Hi, sorry for not answering in appropriate time, I really was too busy this weekend.

For me, what it make sense is to connect it like this, you can correct me if I'm doing it wrong.

I'll launch the VCS simulation with Qsys stuff to catch any issue.
BTW, the way in which you answer all the issues makes me more interested in using your softcore.

from spinalhdl.

Hooo there is the issue, the reset wireing isn't ok.

Now i just have added some documentation about it =>
https://github.com/SpinalHDL/VexRiscv#cpu-clock-and-resets

Let's me know then how things are going ^^

from spinalhdl.

Hoooo
Also, wait a sec, how do you connect the JTAG ?
Basicaly recently, there was some changes on the JTAG stuff, and now there is the possibility to fully integrate it into the CPU. I'm taking a look to make it for the avalon CPU now

from spinalhdl.

Ok so, i just commited some changes.

Now you have two VexRiscv demo versions with avalons

• VexRiscvAvalonForSim without integrated JTAG, but with the debug bus, which should be used if you want to run regressions tests
• VexRiscvAvalonWithIntegratedJtag that you can instanciate in your QSys which will have a dedicated jtag interface for the debugging

Basicaly, maybe two months ago, i changed how openOCD debug the CPU, by the past the JTAG has a full direct access to the whole memory mapping (as on the pinsec SoC picture). but it is a realy heavy design.

Now the JTAG has access to the memory mapping of the design through the CPU. By pushing instruction into the CPU it can access everything, a little bit slower, but by using much less hardware

from spinalhdl.

changed pinsecSoc picture. old one is there :
https://camo.githubusercontent.com/8a5130cdd16810bbeace92a4c7cccdd4f24e6feb/687474703a2f2f63646e2e7261776769742e636f6d2f5370696e616c48444c2f5370696e616c446f632f646431373937316161353439636362393931363861666435356161643237346262646666316538382f61737365742f706963747572652f70696e7365635f68617264776172652e737667

from spinalhdl.

You work very fast man!, thank you.
I tested it and it works, thank you for pointing out my wrong connection and adding documentation about that, I'm sure other folks will find this very useful 👍

from spinalhdl.

Great, good to know it work in QSys ^^
Have fun !

from spinalhdl.