[Libre-soc-bugs] [Bug 507] ls180 asic needs an ioring, pads need defining and connecting
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Thu Oct 1 12:15:50 BST 2020
--- Comment #6 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
moving from here:
(In reply to Jean-Paul.Chaput from comment #96)
> Not sure I correctly see how the wiring is organized (I'm a visual
> guy, I understand more quickly schematics).
that is why i drew it
> Nevertheless, the
> strategy here is:
> * Put everything that contains gates under ls180. It will be flat
> placed & routed. So *below* ls180, you can have whatever
> hierarchy you like.
> * Complex wiring between pads and core (ls180) will take place
> inside the "corona" level (like the 'oe' signal for all pads
> part of the same bus).
right. except - see picture i drew - JTAG has to have "control" over what goes
to the IOPads.
i have "solved" this by making JTAG part of ls180 (core) so in effect as far as
coronais concerned JTAG is like an opaque block that might as well not exist.
> * Connexion betweens "corona" and I/O pads (that is, at "chip"
> level) go *almost* straight (in our case, they go straight
> because both side are symbolic layout).
> * And finally, a dedicated "router" connect the I/O pad ring
> connectors together, including corners.
to understand this fully: is this basically exactly what the AM2901 and
experiments4 examples do?
> NOTE: This partitionning also has the advantage to *not* include
> the I/O pad area inside the general routing area, which
> allows me to remove all special cases related to I/O pads
> from Katana (and they are hellish).
> > # this is bad
> > p_jtag_tck : pi_px <- nooo! must be of type pck_px!
> > port map ( ck => cki <- baaaad, noooo!
> > , pad => jtag_tck
> > , t => jtag_tck_core
> I understand. To avoid putting extra specifications, the fact that
> there is different clocks could be directly guessed from the I/O pad
> netlist (at "chip" level).
then there are several (if we include PLL, not decided yet, it has to be ready)
* sys_clk - this is 24 mhz input
* jtag_tck - completely independent of sys_clk, also input
* pll_48mhz, a digital divided testing signal.
must be slaved to JTAG clock:
* jtag_tms, tdo, tdi
i.e. the iopad must be this:
p_jtag_tdi : pi_px
port map ( ck => jtag_cki <-currently cki!
without this, from what i understand, if every pad is "controlled" by cki
(which links from corona to sys_clk) then we have a problem.
likewise, for SDRAM if sys_clk is 24mhz but PLL generates 300mhz then it is
*really* bad to try to link the 24mhz sys_clk to pxlib pi_px and other IOpads.
it should really be sdram_clock
> I think it is not very difficult to
> create disjoined parts in the I/O pad ring.
> The big question is, will each part be made of an assembly of pxlib
> pads *or* will Staf add some other kind with different wiring
Staf said he wants to stick with a drop-in pxlib. no change to pxlib API.
i see no reason why it should change.
the only thing is, extra pxlib pck_px IOpads must be created that are NOT
connected to "default always assumed sys_clk", and the IO associated with rhrm
must also be completely independent.
this then also means that the "ring" connecting all ck, pck_px to ck pi_px etc,
must ALSO be independent and not cross-wired to each other.
* jtag_cki ring must be independent
* sdram_cki ring must be independent
actually i now realise that sys_clk 24mhz is exclusively routed to the PLL, and
it is the INTERNAL clock (300mhz from PLL) that must be connected to ioring cki
GPIO, I2C, SPI etc!
> Before I upgrade the I/O pad "router" I would need a
> clear understanding of the I/O pads physical interface.
* PLL runs from external sys_clk, generates FASTER internal clock (300mhz) than
* pll_48mhz_o runs from PLL FASTER than 24mhz sys_clk
* JTAG runs from external clock jtag_tck
* SDRAM runs from *internal* clock sdram_clock which is FASTER than sys_clk
* I2C runs from internal clock but is SLOWER than sys_clk so can be ignored
* SDMMC sd0_ck runs at 50mhz from digital divide of PLL 300mhz CLK which is
FASTER than 24mhz sys_clk
we basically need a way to say "these pins are covered by this clock".
i can set that up as a dictionary, it is easy to do from pinmux.
i think it will not be possible to determine from examining netlists, it is
defined by the designer.
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs