Modified RAVEN processor and XFAB Digital Libraries

We are considering use of a modified RAVEN processor for an upcoming design in XH018 and have some flow/library questions. We’re covered via NDA with XFAB so we have full access to their digital libraries, verilog, etc.

We have used the opencircuitdesign flow for trials using the OSU018 and everything worked fine. Then we tried using qrouter for a “difficult” for another 180 nm process. That process is notoriously difficult to route with major direction sensitivities, and some commercial routers can’t handle the arcane DRC rules. Qrouter didn’t work either, no surprise.

XFAB routing should be a lot easier.

  1. The raven.v code references libraries “D_CELLS_3V” and “D_CELLS”. No issues with “D_CELLS_3V”, but “D_CELLS” does not seem to be available for the XH018 process.

1a. Do you know if “D_CELLS” is available for XH018?

1b. Alternately (even better), does qrouter now support “D_CELLS_HD” with a manageable number of DRC errors for a processor complexity type design?

  1. How would we handle synthesis in the eFabless synthesis considering the XFAB proprietary concerns. I looked in the knowledge base and did not seem to find insight for this.

Best Regards,

Henry Stewart

D_CELLS was deprecated by X-Fab some time ago. I have kept it on the efabless platform because the route grid spacing is much more amenable to qrouter than is the high-density route grid. Consequently, qrouter generates many more errors using D_CELLS_HD than D_CELLS. D_CELLS_3V3 is also based on the same high density route grid. I have kept it because there are no other available cell libraries from X-Fab for 3.3V use, and most designs routed for 3.3V use are small digital blocks, not entire processors.

You can try routing the Raven with D_CELLS_HD and see just how many DRC errors are generated by qrouter, and whether that is worth cleaning up by hand or not.

We are now trying to move rapidly to a flow using the OpenROAD tools. We have not yet ported the X-Fab processes to our OpenROAD flow, but the expectation is that it will be able to readily handle designs orders of magnitude larger than the Raven processor, and generate DRC clean results. The question for using this flow will be, on our end, how fast can we get the flow up and running with X-Fab XH018, and on your end, what is your timeline for the RISC-V processor.

For (2), X-Fab is pretty generous about allowing us to present to users all the basic needs for digital synthesis, such as LEF, DEF, liberty, and verilog files. The only thing in the digital flow considered completely proprietary is the GDS output; however, if you have a DEF file of a standard cell layout, GDS generation is just one step removed.


@henry were you able to resolve your D_CELLS issue? I do not have anything to add but I am hoping to learn what you did.