Demo user design doubt

[Dario-CP]

Hello everyone,

I am reviewing the demo sequential_16bit_en.v user design to understand how to translate my own designs and test-benches into the FABulous framework. In doing so, I found some things I do not really understand. This is the code, with some comments I added in the process of understanding how the interface of the module has to be implemented for it to work with the top wrapper:

module sequential_16bit_en (
    /*
    * io_in: Concatenation in the top_wrapper of all inputs to user design 
    *        of the W_IO/IO_1_bidirectional_frame_config_pass modules
    * io_out: Concatenation in the top_wrapper of all outputs from user design 
    *        of the W_IO/IO_1_bidirectional_frame_config_pass modules
    * io_oeb: Concatenation in the top_wrapper of all tristate controls from user design perspective 
    *        of the W_IO/IO_1_bidirectional_frame_config_pass modules
    *
    * Thus, the first pad (pad0) is composed of:
    *   - io_in[0]
    *   - io_out[0]
    *   - io_oeb[0]
    * and so on for the other 27 pads.
    */
    input wire clk,
    input wire [27:0] io_in,
    output wire [27:0] io_out,
    output wire [27:0] io_oeb   // 1 = input (high-Z), 0 = output
);
    wire rst = io_in[0];    // Input of pad0 = reset
    wire en = io_in[1];     // Input of pad1 = enable
    reg [15:0] ctr;         // 16-bit counter

    always @(posedge clk)
        if (en)
            if (rst) ctr <= 0;
            else ctr <= ctr + 1'b1;
        else ctr <= ctr;

    assign io_out = {12'b0, ctr};   // Output counter on lower 16 bits of io_out
    assign io_oeb = 28'b0000000000000000000000000001;   // pad0 -> input, others -> output
endmodule

As I understand it, we are using pad0 and pad1 as inputs, but only pad0 is set accordingly. Also, the output is placed at the lower 16 bits of io_out , so the LSB of it would be lost from outside the eFPGA as pad0 is set as input. Am I understanding the code incorrectly or are the IOs incorrectly managed?

Thanks in advance

[KelvinChung2000]

When we simulate the fabric, we are not simulating a true tri-state IO pin; we are simulating it as individual input/output pins. If you check the code of IO_1_bidirectional_frame_config_pass.v, you can see that the input and output are independent, and the tri-state control is just a pass-through.

We should have implemented a true tri-state construct to better model the IO for more accurate simulation and catch issues like this. So, the correct setting should have the bottom 2 bits set to input when using the fabric as the FPGA.

[Dario-CP]

Thanks for the answer. For the final GDSII to have the proper IO pads with the correct tristate control, what do I need to do? Is it something outside of the FABulous flow, where I need to manually connect the I/O/T signals to the corresponding connections in the PDK's pad macro using a layout tool? Or do I need to change the verilog of IO_1_bidirectional_frame_config_pass.v to reflect the tristate logic and then it will be automatically implemented in the GDSII? Sorry if it is a stupid question, I have never done a tapeout, so I never had to deal with adding IO pads.

Also, in the attached image you can see there are metal connections along the chip perimeter, but those do not connect to the corresponding connections in the tiles. Is that caused by an error in the tile stitching flow or is it intended and I need to connect them manually? The LVS with gen_fabric_macro was failing, saying there were many disconnected nodes, which I assume is because of that.

[KelvinChung2000]

Normally, you will have another final top-level integration. Yes, as you said, you will need to manually connect the IO to those top-level IO cells. Maybe you can give https://github.com/mole99/greyhound-ihp a look and see how this is done.

Regarding the IO not being connected, I have pushed a fix which fixes your issue. You can do a git pull and re-run the fabric stitching step; the LVS issues will be resolved.

[IAmMarcelJung]

In Greyhound the connection is done here.