(no commit message)
[libreriscv.git] / docs / pinmux.mdwn
1 # Pinmux, IO Pads, and JTAG Boundary scan
2
3 Managing IO on an ASIC is nowhere near as simple as on an FPGA.
4 An FPGA has built-in IO Pads, the wires terminate inside an
5 existing silicon block which has been tested for you. In an
6 ASIC, a bi-directional IO Pad requires three wires (in, out,
7 out-enable) to be routed right the way from the ASIC, all
8 the way to the IO PAD, where only then does a wire bond connect
9 it to a single pin.
10
11 Designing an ASIC, there is no guarantee that the IO pad is
12 working when manufactured. Worse, the peripheral could be
13 faulty. How can you tell what the cause is? There are two
14 possible faults, but only one symptom ("it dunt wurk").
15 This problem is what JTAG Boundary Scan is designed to solve.
16 JTAG can be operated
17 at very low clock frequencies (5 khz is perfectly acceptable)
18 so there is very little risk of clock skew during that testing.
19
20 Additionally, an SoC is designed to be low cost, to use low cost
21 packaging. ASICs are typically 32 to 128 pins QFP
22 only in the Embedded
23 Controller range, and between 300 to 650 FBGA in the Tablet /
24 Smartphone range, absolute maximum of 19 mm on a side.
25 1,000 pin packages common to Intel desktop processors are
26 absolutely out of the question.
27
28 Yet, the expectation from the market is to be able to fit 1,000++
29 pins worth of peripherals into only 200 to 400 worth of actual
30 IO Pads. The solution here: a GPIO Pinmux, described in some
31 detail here <https://ftp.libre-soc.org/Pin_Control_Subsystem_Overview.pdf>
32
33 This page goes over the details and issues involved in creating
34 an ASIC that combines **both** JTAG Boundary Scan **and** GPIO
35 Muxing, down to layout considerations using coriolis2.
36
37 <img src="https://libre-soc.org/shakti/m_class/JTAG/jtag-block.jpg"
38 width=600 />
39