Branch : Quicklogic : symbiflow supports only 32 IO's though device has 46 IO's

[rakeshm75]

Symbiflow supports only 32 IO's though device has 46 IO's

Symbiflow throws error when a design has more than 32 IOs:
Error 1:
Type: Other
File: /tmp/really-really-really-really-really-really-really-really-really-really-really-really-really-long-path/conda/conda-bld/vtr_1583635602183/work/vpr/src/pack/pack.cpp
Line: 180
Message: Failed to find device which satisifies resource requirements required: PB-LOGIC: 867, PB-ASSP: 1, PB-SYN_VCC: 1, PB-SYN_GND: 1, PB-BIDIR: 46 (available PB-LOGIC: 891, PB-ASSP: 1, PB-SYN_VCC: 1, PB-SYN_GND: 1, PB-BIDIR: 32)
The entire flow of VPR took 2.64 seconds (max_rss 52.1 MiB)

rtl.zip

[kgugala]

hi @rakeshm75 are you using the latest code? This issue has been resolved more than a week ago. VPR reports the available IO in the following way:

  PB-BIDIR     : 32
  PB-SDIOMUX   : 14

So it handles both types of IOs and all 46 of them. This pcf maps all the available pins https://github.com/antmicro/symbiflow-arch-defs/blob/quicklogic-upstream-rebase/quicklogic/tests/quicklogic_testsuite/top_120_13/chandalar.pcf

GitHub

antmicro/symbiflow-arch-defs

FOSS architecture definitions of FPGA hardware useful for doing PnR device generation. - antmicro/symbiflow-arch-defs

[rakeshm75]

Hi Karol,

Thanks for the update.

Yes, I am using the latest code (pulled it today).

Now, I ran top_120_12 design (that you referred above) which also uses all the 46 IOs. This design
(top_120_12) runs fine without any issues.

The difference between the 2 designs with respects to IOs are:
1. top_120_12 design does not use the bipad macro in rtl
2. design6 uses the bipad macro in the rtl

bipad u_bipad_I0 (.A(GPIO_Out[0]), .EN( GPIO_oe[0]), .Q(GPIO_In[0]), .P(GPIO_PIN[0]));
bipad u_bipad_I1 (.A(GPIO_Out[1]), .EN( GPIO_oe[1]), .Q(GPIO_In[1]), .P(GPIO_PIN[1]));
bipad u_bipad_I2 (.A(GPIO_Out[2]), .EN( GPIO_oe[2]), .Q(GPIO_In[2]), .P(GPIO_PIN[2]));
.
.
bipad u_bipad_I29 (.A(GPIO_Out[29]), .EN( GPIO_oe[29]), .Q(GPIO_In[29]), .P(GPIO_PIN[29]));
bipad u_bipad_I30 (.A(GPIO_Out[30]), .EN( GPIO_oe[30]), .Q(GPIO_In[30]), .P(GPIO_PIN[30]));
bipad u_bipad_I31 (.A(GPIO_Out[31]), .EN( GPIO_oe[31]), .Q(GPIO_In[31]), .P(GPIO_PIN[31]));
bipad u_bipad_I32 (.A(GPIO_Out[32]), .EN( GPIO_oe[32]), .Q(GPIO_In[32]), .P(GPIO_PIN[32]));
bipad u_bipad_I33 (.A(GPIO_Out[33]), .EN( GPIO_oe[33]), .Q(GPIO_In[33]), .P(GPIO_PIN[33]));
.
.
bipad u_bipad_I44 (.A(GPIO_Out[44]), .EN( GPIO_oe[44]), .Q(GPIO_In[44]), .P(GPIO_PIN[44]));
bipad u_bipad_I45 (.A(GPIO_Out[45]), .EN( GPIO_oe[45]), .Q(GPIO_In[45]), .P(GPIO_PIN[45]));

Bipad macro should be applicable to both FBIO[31:0] (which is PAD[31:0]) & SFBIO[13:0] (which is PAD[45:32]).

Regards,
Rakesh

[rakeshm75]

design6_rtl_w_PCF.zip

[kgugala]

I see.
AFAIK, the SDIOMUX pins (SFBIO) does not have any configurable buffers (in opposite to BIDIR ones).

I assume we should simply remove the bipad instantiations for SFBIO pins in synthesis. Is that correct?

[rakeshm75]

Hi Karol,

Both FBIO (PAD[31:0]) and SFBIO (PAD[45:32]) can be configured as bidir pads. We should be able to use the bipad macro with SFBIO pads as well. SFBIO does not have the PREIO as the FBIO, but even on SFBIO the OEN and REN signals are driven from the FPGA interface like the FBIO.

I have attached the diagram of FBIO and SFBIO here.

Regards,
Rakesh
S3_FPGA_IO.pdf