Feature Request: Expanded CFS I/O

[stnolting]

Feature Request: Expanded CFS I/O

[umarcor]

Also, I am not sure if high-level designs (like the Vivado IP packager) might struggle with these interface types.

FTR, GHDL allows processing any VHDL code and generating a VHDL 1993 netlist that any vendor tool can accept. It can effectively be used for adding "VHDL 2008" support to the vendors that don't support it. See https://ghdl.github.io/ghdl/using/Synthesis.html#cmdoption-ghdl-out.

[stnolting]

I should have seen it coming that 32-bit of CFS in/outs might be a limiting factor...

type cfs_io_t is array (integer range <>) of std_ulogic_vector(31 downto 0);

I have to admit, this is an elegant solution!

However, personally I do not like having multi-dimensional array data types in the top entity. Also, I am not sure if high-level designs (like the Vivado IP packager) might struggle with these interface types.

How-about a trade-off? We could transform your [N][M] IO array into a single [N*M] array.

New generic for neorv32_top:
CFS_IO_SIZE : natural := 32;

And the modified CFS IO conduits:

cfs_in_i    : in  std_ulogic_vector(CFS_IO_SIZE-1 downto 0) := (others => '0');
cfs_out_o   : out std_ulogic_vector(CFS_IO_SIZE-1 downto 0);

But I am open for a discussion 😉

[vhdlnerd]

Personally, I don't mind port types of multi-dimensional arrays (or arrays of records, record with arrays, records of records,... well, just about anything VHDL allows 😄) at any level of the hierarchy (except the true top that connects to FPGA I/O). But, that is just my coding style; I'm not saying it's better than anyone else's coding style. Plus, if you want to use a higher level IP stitching tool, it's best to avoid crazy port types.

Anyway, what you suggested is fine with me -- in the end it's just wires! I have two comments though:

1. Can we have separate generic lengths for the CFS inputs and outputs? I would think these would rarely need to be the same length.
2. I would use 'positive' types for the port lengths. Its an indication to the user that zero is not a valid value. This is, again, a style thing. 'Natural' type is good enough -- either way, setting the length to zero will cause an error.

Thanks!

[AWenzel83]

Also, I am not sure if high-level designs (like the Vivado IP packager) might struggle with these interface types.

I can confirm, that the IP packager doesn't work with multidimensional arrays

[stnolting]

@vhdlnerd

Can we have separate generic lengths for the CFS inputs and outputs? I would think these would rarely need to be the same length.

You could still leave all unused wires unconnected.
But having separate size configurations sounds fine. 👍

I would use 'positive' types for the port lengths. Its an indication to the user that zero is not a valid value. This is, again, a style thing. 'Natural' type is good enough -- either way, setting the length to zero will cause an error.

That's a nice fail-safe approach.

@AWenzel83

I can confirm, that the IP packager doesn't work with multidimensional arrays

Thanks for clearing this. What about having a generic to define the size of a top entity signal? Maybe changing the generic would have no immediate effect at all and the IP would require re-packaging to adapt signals sizes. Have you ever tried that?

[AWenzel83]

Generic sizes are working, I have done that before.

[stnolting]

Generic sizes are working, I have done that before.

Good to know!

I will add separate size configuration generics for the CFS input and output conduits 👍

[stnolting]

I have added the CFS IO-size configuration generics

    IO_CFS_IN_SIZE  : positive := 32; -- size of CFS input conduit in bits
    IO_CFS_OUT_SIZE : positive := 32; -- size of CFS output conduit in bits

and modified the according CFS signals

    cfs_in_i  : in  std_ulogic_vector(IO_CFS_IN_SIZE-1  downto 0); -- custom CFS inputs conduit
    cfs_out_o : out std_ulogic_vector(IO_CFS_OUT_SIZE-1 downto 0); -- custom CFS outputs conduit

Feel free to open a new issue if something isn't working as expected.