[Libre-soc-bugs] [Bug 507] ls180 asic needs an ioring, pads need defining and connecting

[bugzilla-daemon at libre-soc.org]

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

--- Comment #6 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
moving from here:
https://bugs.libre-soc.org/show_bug.cgi?id=199#c96

(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

https://bugs.libre-soc.org/attachment.cgi?id=108

> 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).

ah, goood.

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

outputs:

* 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.

great.

>     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
>   strategies?

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
24mhz sys_clk
* 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.