4

When I synthesize an empty circuit using Yosys and arachne-pnr, I get a few irregular bits:

.io_tile 6 17
IoCtrl IE_1

.io_tile 6 0
IoCtrl REN_0
IoCtrl REN_1

These are also part of every other file I could generate so far. Since an unused I/O tile has both IE bits set, I read this as:

  • for IE/REN block 6 17 0, the input buffer is enabled
  • for IE/REN block 6 0 0, the input buffer is enabled and the pull-up resistor is disabled
  • for IE/REN block 6 0 1, the input buffer is enabled and the pull-up resistor is disabled

However, according to the documentation, there is no IE/REN block 6 17 0. What is the meaning of these bits? If the IE bit of block 6 17 0 is unset because the block doesn't exist, why aren't the bits of the other blocks which don't exist unset, too? The other IE/REN blocks seem to correspond to I/O blocks 6 0 1 and 7 0 0. What do these blocks do, and why are they always configured as inputs?

The technology library entry for SB_IO does not mention the IE bit. How is it related to the PIN_TYPE parameter settings?

When I use an I/O pin as an input, the REN bit is set (the pull-up resistor disabled). This suggests that the pull-up resistors are primarily intended to keep unused pins from floating, not to provide a pull-up resistor for conditionally connected inputs (e.g. buttons). Is this assumption correct? Would it be ok to use the internal pull-up resistors for that purpose?

The technology library says the following:

defparam IO_PIN_INST.PULLUP = 1'b0;
// By default, the IO will have NO pull up.
// This parameter is used only on bank 0, 1,
// and 2. Ignored when it is placed at bank 3

Does this mean bank 3 doesn't have pull-up resistors, or merely that they can't be re-enabled using Verilog? What would happen if I clear that bit in the ASCII bitstream manually? (I'd be trying this, but the iCEstick evaluation board doesn't make any pin on bank 3 accessible – a coincidence? – and I'm not sure if I want to mess with the hardware yet.)

When I use an I/O pin as an output, the IE bit isn't cleared, but the input pin function is set to PIN_INPUT. What effect does this have, and why is it done?

rlutz
  • 77
  • 4
  • For anyone arriving here looking for more info related to the pin mapping -see e.g. $PREFIX/share/icebox/chipdb-5k.txt – Ralph Jan 19 '23 at 19:29

2 Answers2

5

The default behavior for unused IO pins is to enable the pullup resistors and disable input enable. On iCE40 1k chips this means IE_0 and IE_1 are set and REN_0 and REN_1 are cleared in an unused IO tile. (On 8k chips IE_* is active high, i.e. all bits are cleared in an unused IO tile on an 8k chip.)

icebox_explain by default hides tiles that have "uninteresting" contents. (Run icebox_explain -A to disable this feature.)

It looks like arachne-pnr does not set those bits for IO pins that are not available in the current package. Thus you get some unusual bit pattern in some IO tiles that contain IE/REN bits for IO blocks not connected to any package pin.

This is what a "normal" unused IO tile looks like on the 1k architecture:

$ icebox_explain -mAt '1 0' example.asc
Reading file 'example.asc'..
Fabric size (without IO tiles): 12 x 16

.io_tile 1 0
  B0 ------------------
  B1 ------------------
  B2 ------------------
  B3 ------------------
  B4 ------------------
  B5 ------------------
  B6 ---+--------------
  B7 ------------------
  B8 ------------------
  B9 ---+--------------
 B10 ------------------
 B11 ------------------
 B12 ------------------
 B13 ------------------
 B14 ------------------
 B15 ------------------
IoCtrl IE_0
IoCtrl IE_1

Would it be ok to use the internal pull-up resistors for that purpose?

Yes.

The technology library entry for SB_IO does not mention the IE bit. How is it related to the PIN_TYPE parameter settings?

When D_IN_0 or D_IN_1 from SB_IO is connected to something, then this implies IE.

When I use an I/O pin as an output, the IE bit isn't cleared

Note that IE is active low on 1k chips and active high on 8k chips. When you use an I/O pin as output-only pin on a 1k device, then the corresponding IE bit should be set, otherwise it should be cleared.

CliffordVienna
  • 7,995
  • 1
  • 37
  • 57
  • According to `chipdb-1k.txt`, I/O blocks 6 0 1 and 7 0 0 aren't unconnected; they are connected to TQ144 pins 49 (GBIN5/PIO2_01) and 50 (GBIN4/PIO2_02), respectively, which are not used on the iCEstick. — What about pull-up resistors on bank 3? Why is the input pin function set to PIN_INPUT (`IOB_ PINTYPE_0`) on output-only pins, and what effect does the IE bit have? – rlutz Mar 02 '17 at 11:15
  • The question was about IE/REN bits not IO blocks. There is no 1:1 relationship. See .ieren in chipdb file. Also: I cannot answer "why" questions: I have not designed the chip. You have to ask Lattice. – CliffordVienna Mar 02 '17 at 11:24
0

I found the explanation, so I'm sharing it here for future reference:

.io_tile 6 17
IoCtrl IE_1

I/O block 16 7 0 is connected to a pin in some packages but not in the TQFP package.

.io_tile 6 0
IoCtrl REN_0
IoCtrl REN_1

This corresponds to I/O blocks 6 0 1 and 7 0 0 (pins 49 and 50) into whose input paths the PLL PORTA and PORTB clocks are fed, respectively.

rlutz
  • 77
  • 4