[Libre-soc-bugs] [Bug 199] Layout using coriolis2 main core, 180nm

[bugzilla-daemon at libre-soc.org]

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

--- Comment #96 from Jean-Paul.Chaput at lip6.fr ---
(In reply to Luke Kenneth Casson Leighton from comment #84)
> Created attachment 108 [details]
> how jtag is organised
> 
> ok so here is how it is organised.
> 
> * the top level "core" is now called "ls180" where "test_issuer" contains
>   the PowerISA.
> 
> * ls180 contains:
> 
>   - test_issuer
>   - JTAG
>   - Litex "stuff" mostly wishbone bus management and arbiters
>   - peripherals
> 
> * JTAG has three "things" it controls:
> 
>   - IOPad testing
>   - DMI
>   - Wishbone
>   - (we may add PLL "counter" here although it will probably be part of Core)
> 
> * Litex provides peripherals however the IO for UART and GPIO need to
>   be routed *through JTAG*
> 
> * Therefore, there are some wires for UART distinguished by prefix
>   "_pads_" and "_core_" such as "uart_pads_tx" and "uart_core_rx" which
>   go **IN** to ls180 then come **OUT** of ls180
> 
> * these double-routed wires go SPECIFICALLY into the JTAG "IOPad testing"
>   side.
> 
>   this is so that the JTAG core can "re-route" the IO Pads, taking them
>   AWAY from ls180 and SPECIFICALLY connecting them DIRECTLY to the
>   (real) actual IOPads through the Corona.
> 
>   this is done with MUXes, and they are, strictly speaking, not part
>   of the "core".
> 
>   although, if they are not, it would be a royal nuisance to have to
>   split them out into a separate file.

    Not sure I correctly see how the wiring is organized (I'm a visual
    guy, I understand more quickly schematics). 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).

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

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

> i *think*.... the main thing is that the JTAG clock should not be
> associated with (connected to or controlled by) the pxlib "ck" lines
> on the IO pads:
> 
> 
>   # this is good
> 
>   p_sys_clk_0 : pck_px
>   port map ( pad  => sys_clk
>            , ck   => cki
>            , vdde => vdde
>            , vddi => vddi
>            , vsse => vsse
>            , vssi => vssi
>            );
> 
> 
>   # 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
>            , vdde => vdde
>            , vddi => vddi
>            , vsse => vsse
>            , vssi => vssi
>            );
> 
> 
> therefore if similar to this:
> 
>    env.setCLOCK("sys_clk")
> 
> we could have:
> 
>    env.setOUTSIDEOFCORONACLOCK("jtag_tck")
> 
> and it to be treated completely differently, then that would i think work.
> 
> we also would need some of the PLL clock wires similarly.  we cannot
> have them under the control of sys_clk.
> 
> is this unreasonably complex, to work out which clock is associated
> with what, without splitting them into separate files?

  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). 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
  strategies? Before I upgrade the I/O pad "router" I would need a
  clear understanding of the I/O pads physical interface.

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