Gowin. Add the ability to place registers in IOB

[yrabbit]

IO blocks have registers: for input, for output and for OutputEnable signal - IREG, OREG and TREG respectively.

Each of the registers has one implicit non-switched wire, which one depends on the type of register (IREG has a Q wire, OREG has a D wire). Although the registers can be activated independently of each other they share the CLK, ClockEnable and LocalSetReset wires and this places restrictions on the possible combinations of register types in a single IO.

Register placement in IO blocks is enabled by specifying the command line keys --vopt ireg_in_iob, --vopt oreg_in_iob, or --vopt ioreg_in_iob.

It should be noted that specifying these keys leads to attempts to place registers in IO blocks, but no errors are generated in case of failure.

[whitequark]

It should be noted that specifying these keys leads to attempts to place registers in IO blocks, but no errors are generated in case of failure.

What about warnings? If I want registers in IOBs I really want to know when it fails.

[yrabbit]

Yeah, I should probably rework the diagnostics.

[gatecat]

How do the vendor tools deal with this? Warning on every register that can't be packed into an IOB if the mode is enabled seems annoying in the case of a register that incidentally happens to be connected to an IO, but was never intended to be packed. Perhaps a per-IO/per-register attribute would be the best option, if there's nothing we can crib from the vendor tools.

[rowanG077]

Xilinx does use an attribute: https://adaptivesupport.amd.com/s/article/66668?language=en_US

[yrabbit]

How do the vendor tools deal with this? Warning on every register that can't be packed into an IOB if the mode is enabled seems annoying in the case of a register that incidentally happens to be connected to an IO, but was never intended to be packed. Perhaps a per-IO/per-register attribute would be the best option, if there's nothing we can crib from the vendor tools.

Vendor tool does not react in any way in case the mode is set to place registers in IO but it did not work.

On the other hand, there is a .CST file construct that specifies that a particular register should be placed in a particular IO block. In practice this is almost useless because you have to specify the name of the pimitive, i.e. an explicit DFF construct.

[rowanG077]

Vivado does give a warning afaik. I don't have it installed currently so can't check. But googling says it does show something like:

CRITICAL WARNING: [Place 30-73] Invalid constraint on register 'i_system_wrapper/system_i/sc_fxgen_1/U0/fxout2_reg[0]'. It has the property IOB=TRUE, but it is not driving or driven by any IO element.

Apologies if you are only referring to the gowin tools, it's not clear if you meant only that.

[yrabbit]

Placement modes are still specified by the command line keys
ireg_in_iob/oreg_in_iob/ioreg_in_iob, but also introduces more granular
control in the form of attributes at I/O ports:

  (* NOIOBFF *) - registers are never placed in this IO,

  (* IOBFF *) - registers must be placed in this IO, in case of failure
  a warning (not an error) with the reason for nonplacement is issued,

  _attribute_absence_ - no diagnostics will be issued: managed to place - good, failed - not bad either.

like:

module top (
    input clk,
    input key_i,
    input rst_i,
    (* IOBFF *) output [`LEDS_NR-1:0] led
);

[whitequark]

    (* IOBFF *) output [`LEDS_NR-1:0] led

Would it be possible to make the attribute bit-granular? Otherwise it is not possible to pack only some FFs into IOBs in an output like this. It's been causing issues for Amaranth.

Another option to solve this is to also accept the attribute on explicit IO buffer instances.

[yrabbit]

Another option to solve this is to also accept the attribute on explicit IO buffer instances.

Well I'm in favour of the latter option as it just works already now without any changes.

[whitequark]

Ah I didn't realize. That is preferred.

[gatecat]

I think that FFs with the IOBFF attribute set should be packed into IO buffers regardless of the nextpnr configuration, this is perhaps the most useful approach when you only have a few flipflops that you are certain you want placed in them

[yrabbit]

Done

[gatecat]

As I understand it, the while loop here is just to get a way of being able to use break - imo do { } while (false); would convey the semantics here better.