Differents from the port para and core para

[zyn810039594]

Hello!

I'm learning the code and the structure of Nax, and now I'm trying to build a soc with it. But I can't understand some settings of port paras.
As the issue says #28 ,fetchRange => Is used to specify on which memory address range the CPU is allowed to fetch instructions.But at this code
class FetchAxi4(ramDataWidth : Int, ioDataWidth : Int, toPeripheral : FetchL1Cmd => Bool ) extends Plugin
there's a para "toPeripheral ", this para seems doing the same thing(or just a opposite way)with the "fetchRange", it looks like they just take effect in the different place,Is there some misinterpretations?

And, is there any plans about building a multi-core system?Add something like Tilelink?(but the tilelink code of Rocket is....a little bit .....hard to understand?hhh)

Thank you for your help!

[Dolu1990]

Hi ^^

toPeripheral

So the naxriscv data cache will always cache the instruction it reads. for that reason, it only has a single memory bus to read instructions. The toPeripheral allows then to split that single memory bus into 2. One to be used for high speed access on the main memory, one which can be used to read a embedded rom / ram in the SoC (the peripheral one).
That toPeripheral alows to specify which address goes to which bus.

And, is there any plans about building a multi-core system?Add something like Tilelink?(but the tilelink code of Rocket is....a little bit .....hard to understand?hhh)

Yes it is work in progess https://github.com/SpinalHDL/NaxRiscv/tree/coherency
I was halted in the progress as i had a big consulting work. But now i should be much more free to progress on it.

It would be tilelink, i'm currently experimenting to see if i can provide a more user friendly paradigme than rocket / chipyard.

[zyn810039594]

Thanks for your reply!

That toPeripheral alows to specify which address goes to which bus.

OK, so the toPerp is just a condition to split single port into double ports.

That toPeripheral alows to specify which address goes to which bus.

So the tilelink will be add to nax independently, or the generator will be a part of the spinal "bus" lib?Anyway,that's a good news!

[Dolu1990]

So the tilelink will be add to nax independently, or the generator will be a part of the spinal "bus" lib?Anyway,that's a good news!

I think directly in spinal.lib.bus

[Dolu1990]

@zyn810039594 Hi ^^

So, i'm tweeking around, trying to find the "good" middle ground with an API do design SoC.

but the tilelink code of Rocket is....a little bit .....hard to understand?hhh

Could you elaborate more on it ? I mean, i agree with you, but question is more about idenfitying the reasons.

For instance, we can map the problem over multiple axes :

• Usage of hidden implicits values
• Cake pattern used to provide the config is "too magic"
• Tilelink parameter negociation skims
• ...

I'm not saying having a good SoC API which check all the cases is easy ^^

Regards
Charles

[zyn810039594]

• Usage of hidden implicits values
• Cake pattern used to provide the config is "too magic"

Yeah i agree with you, it makes implicits value everywhere,and the sturcture like Russian dolls,make it's tightly coupled.It's just difficult to build and use it(i have to say all the things of rocket has low cohesion). Maybe it's because I'm a rookie of the scala hdl, i could not understand it easily.
And there's an incomprehensible phenomenon for me-almost all the core written in Chisel i see use rocket-core (and even boom-core) as a lib! In my opinion, making tilelink a single lib is a much better way. And, it seems like chipsalliance is just working on it(https://github.com/chipsalliance/tilelink).But at least for now,it's not working.

Tilelink parameter negociation skims

For me it's just ok.

Anyway,i'm a noob of spinalhdl.before nax i use it as a advanced verilog to build some peripheral, and i think the coding style of nax is better than that of rocket. For me it's much easier to understand(except for few comment, but it's a result of few manpower,is it?).Just make it more general, and be a lib of spinalhdl like pipeline.
But, is there anyway to improve collaboration efficiency for the structure like nax?I wanna spread spinalhdl in my work, and the structure is good for myself--my co-workers raise an objection. All of us used verilog before,and we always determined the interface first.The plugin way is flexible but hard to make modules independently.Use pre-arranged def to connect?Or other ways?

[Dolu1990]

Hi,

Sorry i missed your answer :/

And there's an incomprehensible phenomenon for me-almost all the core written in Chisel i see use rocket-core (and even boom-core) as a lib! In my opinion, making tilelink a single lib is a much better way. And, it seems like chipsalliance is just working on it(https://github.com/chipsalliance/tilelink).But at least for now,it's not working.

Ahh things likely just grew overtime.

(except for few comment, but it's a result of few manpower,is it?)

Yes, manpower is sooo squized :/
It is kinda very hard to find buddies to do things with XD

Lot of limitting factors, main ones seems to be :

• People having full time industry job
• People which can't contribute to open-source because of clauses in their job contract (quite a few open-source project die because of that)
• Hardware people not being much about using software to elaborate hardware ( SpinalHDL )

But, is there anyway to improve collaboration efficiency for the structure like nax?
All of us used verilog before,and we always determined the interface first.The plugin way is flexible but hard to make modules independently

Ahhh so, one way to see it is that instead of having hardware interface, you have to define software interfaces (which will give you hardware later on)

For instance :
https://github.com/SpinalHDL/NaxRiscv/blob/main/src/main/scala/naxriscv/interfaces/Service.scala#L99
https://github.com/SpinalHDL/NaxRiscv/blob/main/src/main/scala/naxriscv/interfaces/Service.scala#L348 and so on ^^

So, there is still interfaces to be designed in some ways. Just that things do not rely on Modules.
And so, durring implementation phase, if a given "service" is specified but not implemented yet, you can easily implement a dummy one as a place older.

This may interest you :
SpinalHDL/SpinalHDL#1115
https://github.com/SpinalHDL/SpinalHDL/blob/b792935ad084345a53c8b63f9144428e219eb9c2/lib/src/test/scala/spinal/lib/bus/tilelink/InterconnectTester.scala#L442

It is a tilelink interconnect which is kinda negociating stuff around using a very very similar aproache than NaxRiscv :)
it is very fresh, but already seems to go the right way.