wrt feature gating, I think that the simplest option might just be to add an yxi feature (which itself depends on serialization) and so consequently doesn't compile the axi backend if the feature is not given. I think this is reasonable and how other crates handle this type of stuff in practice, but if we don't want to add another feature then I guess the entire axi backend needs to be behind the serialization feature. I suppose they're both identical.

I prefer one of the above over making the axi backend a no-op when the serialization feature is not used since that seems needlessly confusing. Regardless, we don't want to have an ungated dependency on serde since that breaks compilation.

I don't know if @sampsyo has thoughts on this

I think we should eventually move AXI out of thr compiler and mame it a standalone tool

Sorry for the late reply on this, the new JSON fields are great!! This has all the info I need for my testbench creation script 🙂

I think the dependencies look better now, could either/both of you confirm? @EclecticGriffin @rachitnigam
The yxi backend now only gets compiled with a cargo build --features yxi

Most changes seems fine except the one comment I left. Overall, I'd like for YXI to be a separate tool from the Calyx compiler because it doesn't need the rest of the optimization infrastructure.

Thanks for taking a look.
I think I'd need a bit of guidance on how to start migrating YXI out of the compiler, could maybe talk about this synchronously/on slack? My main concern is the fact that YXI currently relies on the IR to get information about memories. Would YXI just be standalone with dependencies on the IR? Not exactly sure what that looks like in practice.