Change the IO coding to synthetic

[yrabbit]

The new coding system uses a logicinfo table to search for the right fuzes by given combinations of attributes. Actually required bits are taken from vendor's longval tables. The same tables are used to decode binary images.

tiled_fuzzer.py calls the vendor compiler only once to get an empty image template.

• All references to IO coding bits, including standards, are removed from the base structure.
• Removed fuzzing IO.
• Removed fuzzing corner bank cells - their own table is used for them.
• Removed fuzzing of dual-purpose pins - their own table is used for them.
• Real LVDS primitives TLVDS_IBUF, TLVDS_TBUF and TLVDS_IOBUF are implemented.
• All emulated LVDS primitives are implemented: ELVDS_IBUF, ELVDS_OBUF, ELVDS_TBUF, ELVDS_IOBUF.
• All new primitives can connect with IOLOGIC.
• The OEN port of the I/O primitives (including differential ones) can be controlled by IOLOGIC.
• Added detection of gross user errors like placing TLVDS in place of the emulated one.
• It is possible to use as a differential special simplified IO elements located on the 6th row in the chips GW1N-1 and GW1NZ-1, but here may require additional research and in general the other pins should be enough.

[yrabbit]

Forgot:

• New test cases have been added.
• In the old examples, OBUF is replaced by TBUF, which reacts to the press of a button to demonstrate the workability of these primitives.

[yrabbit]

This doesn't change the chipdb format, or does it? Just want to make sure that if the final DB is different we maybe bump the db number, and if it isn't that we can compare the DB before and after this PR to make sure there are no unintended changes.

Yes, the structure has changed to throw out unnecessary and irrelevant information about IO. From nextpnr side, however, it is unnoticeable - the structure of exported data has not changed.

+++ b/apycula/chipdb.py
@@ -16,22 +16,6 @@ mode_attr_sep = '&'
 # can be either tiles or bits within tiles
 Coord = Tuple[int, int]

-# IOB flag descriptor
-# bitmask and possible values
-@dataclass
-class IOBFlag:
-    mask: Set[Coord] = field(default_factory = set)
-    options: Dict[str, Set[Coord]] = field(default_factory = dict)
-
-# IOB mode descriptor
-# bits and flags
-# encode bits include all default flag values
-@dataclass
-class IOBMode:
-    encode_bits: Set[Coord] = field(default_factory = set)
-    decode_bits: Set[Coord] = field(default_factory = set)
-    flags: Dict[str, IOBFlag] = field(default_factory = dict)
-
 @dataclass
 class Bel:
     """Respresents a Basic ELement
@@ -39,18 +23,12 @@ class Bel:
     and the specified portmap"""
     # there can be zero or more flags
     flags: Dict[Union[int, str], Set[Coord]] = field(default_factory=dict)
-    # { iostd: { mode : IOBMode}}
-    iob_flags: Dict[str, Dict[str, IOBMode]] = field(default_factory=dict)
-    lvcmos121518_bits: Set[Coord] = field(default_factory = set)
     # this Bel is IOBUF and needs routing to become IBUF or OBUF
     simplified_iob: bool = field(default = False)
     # differential signal capabilities info
     is_diff:      bool = field(default = False)
     is_true_lvds: bool = field(default = False)
-    # banks
-    bank_mask: Set[Coord] = field(default_factory=set)
-    bank_flags: Dict[str, Set[Coord]] = field(default_factory=dict)
-    bank_input_only_modes: Dict[str, str] = field(default_factory=dict)
+    is_diff_p:    bool = field(default = False)
     # there can be only one mode, modes are exclusive
     modes: Dict[Union[int, str], Set[Coord]] = field(default_factory=dict)
     portmap: Dict[str, str] = field(default_factory=dict)

[pepijndevos]

I tested a couple of examples and they all work so far. Except attosoc of course...

[pepijndevos]

Hmmm I tried to compare the chipdbs and it seems they are largely the same which is good news but there are a few differences, and I want to make sure they are expected. Need to try to remember what these values mean. attr.txt master.txt

[pepijndevos]

It seems to be only portmaps that are slightly different. If this makes sense to you, I think it's good to merge.

[yrabbit]

It seems to be only portmaps that are slightly different. If this makes sense to you, I think it's good to merge.

It makes sense and the portmap is not really different - just that some Bels are unloaded in a different order (sort of like IOBB was ahead of IOBA) and naturally drag their portmap with them.

I don't know why this thing happens, but it doesn't affect nextpnr in any way :)