search

chipsalliance / chisel

Chisel: A Modern Hardware Design Language
https://www.chisel-lang.org/
Apache License 2.0
3.85k stars 579 forks source link

[RFC] Formalize support for IP-XACT #904

Open chick opened 5 years ago

chick commented 5 years ago

IP-XACT is a xml metadata format for describing interaces to IP circuit designs.

Motivation

There is a lot of interest from CAD vendors for us to support IP-XACT to streamline integration with their tools. A lot of work has been done here, particularly with respect to the Craft 2 project. It is not clear that this code has been kept current, or was ever adequately documented.

Current state

IP-XACT implementations exist in

Impact

This should be minimal disruptive because it does not alter existing API's. There are several steps to solidify support

edwardcwang commented 5 years ago

Can it live as a separate library? Or is it very deeply coupled to Chisel internals?

chick commented 5 years ago

Yes, I think it can although it may require (or already have) hooks in to the Builder State to help implement it. But otherwise I think this would seem to be yet another Annotation/Transform based library.

jackkoenig commented 5 years ago

What kind of hooks are necessary? They might be useful for other libraries as well.

Nic30 commented 5 years ago

Hello, I have very similar tool, it has support also for Quartus *_hw.tcl format. I would like to kill it in favor of chisel3 ecosystem. I can help you with you implementation if you want.

grebe commented 5 years ago

One issue with ipxact is that the ipxact library we use does not seem to live in maven- perhaps I simply haven't searched hard enough. That's an annoyance for build and deployment.

The approach in rocket-dsp-utils has some issues, the biggest of which is that it generates ipxact from the top level. If someone doesn't use a dspblock, they don't get ipxact out.

I think a better approach (that can hopefully use a lot of the same underlying code) is to have an API for annotating bundles with their parameterization. For example, an AXI-4 bundle could be annonated saying it is a slave with such-and-such addresses. A separate API for annotating modules to describe their own parameterization would also be good. This API should probably live in chisel.

A seperate firrtl pass can extract these parameters, along with structural information about widths, to generate ipxact (in principle, you could generate other formats too- say for xilinx ip integrator). This pass doesn't have to live in firrtl or chisel, but perhaps it makes sense to keep it in chisel anyways. It would be overkill to give it its own repo.

Nic30 commented 5 years ago

I think that It is good to have IP-core informations associated with definition of interface because of consystency. And it is bad to have IP-core generator in chisel because it is large and unrelated code.

In my framework I have api for annotations and https://github.com/Nic30/hwtLib/blob/master/hwtLib/amba/axis.py#L71 https://github.com/Nic30/hwtLib/blob/master/hwtLib/amba/axi3.py#L216

And ip core generator is separated. ipCorePackager