Tapeout: PHY bump final routing report
steveri opened this issue · 1 comments
My scripts route the analog bumps first, then the "normal" bumps. The main routing proc is route_bumps_main
in route-bumps.tcl
, which consists of exactly two commands, route_phy_bumps
(analog bump routing) and route_bumps
(remaining bumps).
Proc route_phy_bumps
, in file route_phy_bumps.tcl
, routes the analog bumps in six phases.
Phases 1 and 2 route CVDD and CVSS bumps S1 and S2 to their respective pads with 30-micron wires using innovus command fcroute
via a wrapper proc bump2stripe
. Despite its name, bump2stripe
routes to a pad's PAD port and not to the nearest stripe it sees.
Phase 3 routes the remaining CVDD and CVSS bumps using custom shape-drawing procs bump_connect_diagonal
(connects two or more bumps along a diagonal); bump_connect_orthogonal
(connects two or more bumps along a horizontal or vertical line); and bump2wire_up
(beginning at a given bump, run a wire vertically upwards and connect to the first horizontal wire you see). All wires are 30u.
Phase 4 routes bumps ext_Vcm
and ext_Vcal
via proc bump2aio
, which routes bumps to signal IO pads using the innovus router fcroute
. Uses 20u wires.
Phase 5 routes AVDD and AVSS using bump2stripe
(fcroute), same as CVSS and CVDD phases 1 and 2. 20u wires.
Phase 6 routes four signal bumps ext_clk_test[01]_[np]
using fcroute by way of a custom proc build_ext_clk_test_region
. 3.6u wires.
Below I list the bumps that were initially assigned to be routed, and the disposition of each.
CVDD: S1,S9,S27,S40,S41,S62,S63,S64,S65,S14,S29
CVSS: S2,S10,S11,S12,S13,S3,S28,S43,S42,S4
I routed all these (fig-cv) except CVDD bumps S14 and S29.
In the diagram that I was sent with last year's routings (fig-2019-s14s29), it looked like bumps S14 and S29 route to PHY pins but not to pads. Is that right? Doesn't seem right. Can someone confirm to me how these are supposed to work?
ext_rx_inp: DP1
ext_rx_inn: DP2
These were marked "no pad" so I didn't route them, I guess they go to PHY pins instead of IO pads, yes?
AVDD: S17
AVSS: S16
Routed (fig-av-vc-ext). Note in the original routing from last year (fig-2019-s14s29 above), AVSS and AVDD did not obviously route all the way to the pads. It looks like someone was trying to match the lengths and areas etc., but I don't know where/how they eventually connected. Will this be a problem?
ext_clk_async_p: S30
ext_clk_async_n: S15
ext_clkp: S45
ext_clkn: S46
ext_rx_inp_test: S47
ext_rx_inp_test: S44
clk_out_p: S49
clk_out_n: S48
clk_trig_p: S70
clk_trig_n: S69
"no pad"
ext_Vcm: DP3
ext_Vcal: DP4
Routed (fig-av-vc-ext above).
ext_clk_test0_p: S19
ext_clk_test0_n: S18
ext_clk_test1_p: S32
ext_clk_test1_n: S31
These were marked "no pad", but in the diagram from last year (fig-2019-s14s29 above) they did go to pads (as well as PHY pins(!?)). And we had pads available on the ring so I routed them (fig-av-vc-ext above).
pad_jtag_intf_i_phy_tck: S5
pad_jtag_intf_i_phy_tdi: S20
pad_jtag_intf_i_phy_tdo: S6
pad_jtag_intf_i_phy_tms: S21
pad_jtag_intf_i_phy_trst_n: S22
pad_ext_rstb: S23
pad_ext_dump_start: S7
"no pad"
DVDD: IVD1,IVD2,IVD3,IVD4,IVD5,IVD6,GVD
DVSS: VSS
DVDD and DVSS should be part of the normal heavy horizontal RDL strips that get laid down in the center core of the chip, but someone should double check and make sure. This should be bump rows 20 and 21, columns 6 through 21.
Closing this issue because it is STALE.