[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 #102 from Jean-Paul.Chaput at lip6.fr ---
(In reply to Staf Verhaegen from comment #101)
> > But, what we must be sure of, is the interface.
> 
> Still am not 100% sure what exactly you mean with interface here and want to
> avoid any possible misinterpretation.
> 
> > If I divert from HFNS to chip/corona creation, what's inside the I/O pads
> > is not important. From what you (Staf) said, that seems ok, but it would
> > be better if you can confirm.
> 
> My IO cells will have pins that will be connected directly to pins of the
> CORONA.
> The bonding pad is included in the IO cell.

  OK. Same structure as pxlib. Luke said your pads could be used as
  a direct replacement of pxlib. Is that so? pxlib have an unusual
  way of generating core clock(s).

  * pck_px     : external_ck (pad) ==> pad_ring_ck (ck)
  * pvddeck_px : pad_ring_ck (ck)  ==> ck_core (cko)
  * pvsseck_px : idem
  * pvddick_px : idem
  * pvssick_px : idem

  Name in parenthesis are the real pad names, vs their meaning.

  I can write plugins to manage different clock arrangements, like
  I do for AMS 350nm for example.

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