[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 #84 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
Created attachment 108
  --> https://bugs.libre-soc.org/attachment.cgi?id=108&action=edit
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.


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?

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