[Libre-soc-bugs] [Bug 739] NGI POINTER Gigabit Router Pinout Considerations

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=739

--- Comment #14 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jean-Paul.Chaput from comment #13)

>   I've loosely followed this discussion up until now, I'm not sure
>   to follow exactly what the question is. Are there specific
>   routing constraints to manage? If so, could you draw a schematic
>   or a figure of the layout you expect ?

yes, here is a page i wrote in advance with some diagrams:
https://libre-soc.org/docs/pinmux/

all of this is combinatorial logic, no clocks at all.

https://libre-soc.org/docs/pinmux/gpio_block.png

the green (out) mux and the red (out) mux are *in addition* to
the JTAG Boundary scan muxes:

https://libre-soc.org/shakti/m_class/JTAG/jtag-block.jpg

so *after* going through the pair of JTAG Boundary Scan
"bypass" MUXes, if we want say 1,000 IO functions to be
shared access to say only 200 pins, there are *additional*
4:1 IN/OUT Muxes that must be added.

this gives *two* levels of MUXes (actually three) that
data *including incoming CLK lines* have to go through.

* JTAG PAD Mux 1:2
* JTAG Core Mux 2:1
* GPIO IN (or OUT) Mux 4:1

hence why i am asking, because this is all Combinatorial
Logic, and any delay/sync buffers due to clock trees would
actually cause the output data to get *out of sync* with
the external clock!

this is, funnily enough, a situation that is fully recognised
by the creators of the Gigabit Ethernet RGMII Specification:
they have special lines TXDLY and RXDLY which introduce 2ns
of clock delay *at the PHY*!

but, that is 125 mhz clock rates so hardly surprising.

-- 
You are receiving this mail because:
You are on the CC list for the bug.