(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.
6
7 Designing an ASIC, there is no guarantee that the IO pad is
8 working when manufactured. Worse, the peripheral could be
9 faulty. How can you tell what the cause is? There are two
10 possible faults, but only one symptom ("it dunt wurk").
11 This problem is what JTAG Boundary Scan is designed to solve.
12 JTAG can be operated
13 at very low clock frequencies (5 khz is perfectly acceptable)
14 so there is very little risk of clock skew during that testing.
15
16 Additionally, an SoC is designed to be low cost, to use low cost
17 packaging. ASICs are typically 32 to 128 pins QFP
18 only in the Embedded
19 Controller range, and between 300 to 650 FBGA in the Tablet /
20 Smartphone range, absolute maximum of 19 mm on a side.
21 1,000 pin packages common to Intel desktop processors are
22 absolutely out of the question.
23
24 Yet, the expectation from the market is to be able to fit 1,000++
25 pins worth of peripherals into only 200 to 400 worth of actual
26 IO Pads. The solution here: a GPIO Pinmux, described in some
27 detail here <https://ftp.libre-soc.org/Pin_Control_Subsystem_Overview.pdf>
28
29 This page goes over the details and issues involved in creating
30 an ASIC that combines **both** JTAG Boundary Scan **and** GPIO
31 Muxing, down to layout considerations using coriolis2.
32
33 <img src="https://libre-soc.org/shakti/m_class/JTAG/jtag-block.jpg"
34 width=600 />
35