Any way to replace 'Area' with 'Component' in plugin's implementation?

[davine47]

Hi, i am trying to use Vexriscv's CPU framework in ASIC design.
But for now, all logics will be generated in a module. This is unfavorable for IC layout design. The backend department wants the RTL to have a clear boundary between modules and module I/O.
Any suggestions to solve this?
Thanks! ^_^

[Dolu1990]

Hi,

currently, the only way to get component stuff, is to explicitly define them and instanciate them in a given plugin, like the data cache for instance.
There would be ways (unimplemented) to automaticaly push the hardware from each plugin in their own components and then automaticaly legalising their in/out. It shouldn't be too complicated to implement, but this isn't planned yet.

So far, i didn't thinked that having clear boundaries inside VexRiscv itself would realy matther, given the "small size" of the cpu.
Are you running on a large node / very limited die size ?

[davine47]

Hi,

currently, the only way to get component stuff, is to explicitly define them and instanciate them in a given plugin, like the data cache for instance. There would be ways (unimplemented) to automaticaly push the hardware from each plugin in their own components and then automaticaly legalising their in/out. It shouldn't be too complicated to implement, but this isn't planned yet.

So far, i didn't thinked that having clear boundaries inside VexRiscv itself would realy matther, given the "small size" of the cpu. Are you running on a large node / very limited die size ?

Yes, i'm running on a large scale CPU design, benchmarking against ARM A76, but it has larger decode width, at least 8. The whole layout has configurable 1-16 cores with L3 shared cache slices. I think the scale of this chip is really large, compared to VexRiscv.

Currently, I am exploring the feasibility of SpinalHDL and VexRiscv on large scale ASIC design.

I think vexriscv CPU framework demonstrates a clear framework, configurability, and scalability. It reduces the control complexity of the CPU design. But its not friendly to backend's layout, for now.

Will there be features oriented towards ASIC design in the future(Spinalhdl or vexriscv series)?

thanks!
^_^

[Dolu1990]

Hi,

About frameworks, did you toke a look at VexiiRiscv ? (it doesn't solve the component thing, but is interresting)

Will there be features oriented towards ASIC design in the future(Spinalhdl or vexriscv series)?

There as been some improvements related to asic, mostly :

• constraint generation
• ram blackboxing

but currently, nothing else is planned.

One question i have, is would the backend tools be capable to work by filtering stuff by names ? (instead of by module)

[davine47]

One question i have, is would the backend tools be capable to work by filtering stuff by names ? (instead of by module)

hi,
For now, the backend department is more accustomed to delivering by module, their tools and scripts are also tailored for modules. This should not change due to alterations in front-end tools, i think.

For ASIC design, when the chip scale exceeds 1 billion transistors, the challenges we are facing are as follows:

• The server’s computational power is unable to support such a large-scale backend circuit optimization all at once, and sometimes optimizations fail for certain paths due to server performance issues.
• The efficiency of backend optimization for large-scale circuits is also not high. The extension of feedback time for the front-end department resulted in a longer iteration cycle.

The best solution is to divide the architecture into multiple modules during the micro-arch design phase.

There would be ways (unimplemented) to automaticaly push the hardware from each plugin in their own components and then automaticaly legalising their in/out. It shouldn't be too complicated to implement, but this isn't planned yet.

Currently my team is interested in spinalhdl and its framework, we will do some explorations to implement these features.

Thanks, ^_^

[Dolu1990]

Hi,

Thanks for the info :D

So, yeah, either would need to add this kind of special Component which have "soft" bundaries.
either would need to expllicitly define sub components in plugins (as it is done for the i$ d$ in VexRiscv)

Currently my team is interested in spinalhdl and its framework, we will do some explorations to implement these features.

Let me know how it goes :)

Regards
Charles