grayresearch / CX

Proposed RISC-V Composable Custom Extensions Specification
Apache License 2.0
66 stars 12 forks source link

Mark CFU-LI signals as required or optional #7

Open olofk opened 2 years ago

olofk commented 2 years ago

Allowing to leave out signals that are not strictly required can increase the flexibility of the standard. As a point of reference, I believe only the tvalid signal is actually required in the AXI4 Stream interface and similarly I believe there could be of interest to have a CFU that doesn't have any data ports.

The above is just an example but I propose that we are economical with required signals in all interface levels

grayresearch commented 2 years ago

Olof, thank you. I concur with your sentiment of economy and that was a motivation for CFU-LI levels. In simpler, lower feature levels, unnecessary ports are absent.

At present, all ports have a width configuration parameter. When a port is configured with width=0, it is implemented [0:0], driven with 1'b0, optimized away, and any input value is ignored.

This approach also allows CFU RTL modules, which source or sink all ports at a given CFU-LI level, to compose sans glue just by configuring port widths and other configuration parameters appropriately.

I think you want something more, that certain ports be optional, and sometimes absent. For example, sometimes a CFU implements one function only, and there is no utility in driving and decoding the function ID port. In the present spec, a composer configures the CFU's parameter CFU_FUNC_ID_W=0. The port is still there, [0:0], driven to 1'b0, ignored. But I think you prefer it is completely absent from the top level and from the CFU ports.

I understand how that could work when a CPUs <-> CFUs interconnection network is generated programmatically by a tool. But I don't think that would work with HDL module <- wires -> HDL module composition.

What do you think?

olofk commented 2 years ago

Yes. I want to mark ports as optional with the idea that they can be absent from the ports list. To me, the idea of having unused signals as [0:0] vectors is more of a workaround for the current crop of HDLs not having the ability to programmatically omit ports, but I think writing that into the spec is not a very clean interface design.

As you say, it would work just fine for automatically created interconnections. E.g. IP-XACT readily supports this and supports default values both on the bus or the ports for absent signals. And if you do it manually, with HDL module <-wires-> HDL module I don't really see the issue. Isn't it just a matter of not connecting the wires? Again, comparing with AXI Stream, there's a boatload of signals in the spec but I rarely see all of them exposed on HDL modules.