[Libre-soc-bugs] [Bug 50] nmigen pinmux

[bugzilla-daemon at libre-soc.org]

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

--- Comment #51 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
okaaay done, but holy cow what a mess.

* the entire pair of pad and core ResourceManagers had to be duplicated
  inside the JTAG module

  (bear in mind: Platform *derives* from ResourceManager)

* these two resources still require duplicating resources.  therefore,
  add_resources is still overridden and still adds to *BOTH* jtag.pad_mgr
  *AND* jtag.core_mgr

* everything that was previously in Platform and used Platform-as-a-ResMgr
  was moved to the JTAG module

* the wiring up of ports-to-pads is now done *inside* JTAG Manager

* **ANOTHER** ResourceManager - this time the Platform one - has *yet another*
  duplicate set of resources

* this duplicate set of resources is *ONLY* wired up if a Platform is passed
  in.

* the duplicate set of resources in Platform is wired up "direct". strictly
  speaking it is totally unnecessary, but may in future replace coriolis2
  corona (hopefully not any time soon) creation and therefore would actually
  create $Instance("coriolis2_IOPAD") and wire them up.

* all bi-directional pads had to be converted to explicit triplet individual
  pins (named padname_i, padname_o and padname_oe) otherwise internal
  assumptions deep inside Platform about bi-directional pads got thoroughly
  in the way.

what a mess.  still, it works.  oh, and no, Simulation() of build fragment
still does not work, and won't.

however now that the JTAG module creates and manages the JTAG Boundary
Scan IO entirely itself, this is completely irrelevant.  a top module
*WITHOUT* calling Platform.build() can be used directly instead.

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