[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 #103 from Staf Verhaegen <staf at fibraservi.eu> ---
(In reply to Jean-Paul.Chaput from comment #102)
> (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).

Never wanted to imply my IO would be a full drop-in replacement for pxlib. What
I wanted to say is that pxlib could be used to setup up HDL for top block and
it should not be much work to convert it later to use my IO library.

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

In my library no special clock cell is present. It is a digital input cell that
needs to be connected to the clock pins in the CORONA as any other IO.
I don't have latching functionality inside my IO cells so I don't need to
distribute the clock over the IO ring. I assume all this functionality is
implemented inside CORONA.

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