[Libre-soc-bugs] [Bug 739] NGI POINTER Gigabit Router Pinout Considerations

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sat Nov 13 13:29:22 GMT 2021


--- Comment #11 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to andrey from comment #10)
> (In reply to Luke Kenneth Casson Leighton from comment #8)
> > (In reply to andrey from comment #6)
> > > Noted. Should I also consider GPIOs to be potential transient sources as
> > > well (and keep them away from clocks)?
> > 
> > mmmm probably not.
> Ok, I'll allow for having GPIO's close to various interfaces then.

EINTs PWMs yes, keepaway. GPIOs can often be spare or just deliberately GNDed

> > > Also, to add a new class/module (for a new chip pinout):
> > > 1. Create a .py file for the soc (for example "ngi_router.py"), using one of
> > > the previous chips as a template.
> > > 2. Import the new module to src/spec/__init__.py, "from spec import
> > > ngi_router"
> > > 3. Add a new entry to the modules dict in src/spec/__init__.py,
> > > "'ngi_router': ngi_router"
> > 
> > you probably saw i already did that, it does however need documenting.
> Where should this be documented?

strictly speaking in docstrings as a helpful rrminder but if part of a larger
sequence definitely on the wiki and the link in the src

> Should there be a page specifying how to use the pinmux repo scripts and
> setup pinspec module for a new project?

yes basically.

> Sure. First task is to get it to output the QFP for the router ASIC, then
> see how to turn the project-specific info into arguments.
> Do you know which lead frame is being used?

no not yet, assume 64 64 64 64 for now

> > 
> > which is a copy of the auto-generated markdown.
> Thanks
> > comments:
> > 
> > * bank E 64-64 is too close to the edge (corner).  actually, all power/gnd
> >   needs to be at least 4-6 pins away from the corners.
> What did you mean by "bank E 64-64"?

prosbly meant to be 64-65

> Sure, will make sure the pins are at least 4 pins away.

this will interfere directly with your desire to keep functions in a
sequential block.  VSS VDD however is higher priority.

now you know why i added the means to split functions.

> Do you mean that I should run the 3.3V and 1.8V power pins next to eachother?

yes, always.

> What's the reason for it? Easier to auto-route?

power balancing and stability on the IO Ring.  Staf knows details.
i just learned the rule from him and follow it.

> > * 15 pins numbered 106 to 120
> > * 6 pins numbered 96 to 101
> Sure I did see this, just that it might be better to keep the whole
> interface together.

notice how i made the address lines cross over the corner in ls180?
with power in between?

this is because you can drop some VIAs down to the POW/GND plane and
address lines, which are not as timing sensitive, don't get upset.

> I'll make sure to split them up though if running out of space.

you'll run out of space.  using smaller functions in between larger
ones can help with alignment.

> Is there also any advantage to keeping the pinout as close to LS180's as
> possible? 

not at all, other than the lessons i learned.

> I wondered if the PCB guy might have an easier time (although the
> package is different anyway).

packages are inserted into a nonsolder socket.

> > the reversing is to keep the ordering correct, bridging over
> > the VSS/VDD 102-105
> Not sure I understand why the reversing is necessary. I'll try splitting up
> without reversing, and see what the problem is.

because the order will go A0 A1 A2 A3 A9 A8 A7 A6 A5 if you don't.



> I see, so if there's room, I should provide more data lines. If not, I'll
> skip them however.

they're nonessential and add one hell of a lot of extra pads.

if there is time i do actually want to add a pinmux.  this because
i may have a client who wants a large number of PWMs for a robotics
application.  32 PWMs is dead easy to add.

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

More information about the libre-soc-bugs mailing list