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

[bugzilla-daemon at libre-soc.org]

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

--- 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"?

https://libre-soc.org/crypto_router_asic/ngi_router/
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.

or

A0 A1 A2 A3 SOMEOTHERGARBAGE A4 A5 A6...

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