[Libre-soc-bugs] [Bug 739] NGI POINTER Gigabit Router Pinout Considerations
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Mon Nov 8 21:51:25 GMT 2021
--- Comment #8 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to andrey from comment #6)
> > also note, PLL is right in the top corner, and, also, note
> Same placement as LS180?
yes, i did it already (you probably saw).
> > that any clock lines are (or should) be away from unrelated
> > high speed transients. e.g. ULPI CLK should not be directly
> > next to an EINT which might be for an external button with a
> > lot of "bounce" on the contacts.
> Noted. Should I also consider GPIOs to be potential transient sources as
> well (and keep them away from clocks)?
mmmm probably not.
> 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
> 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.
> pinmux_generator.py will now recognise the new chip module. I initially had
> issues as I didn't do steps 2 and 3 hahaha
(In reply to andrey from comment #7)
> Added most of the peripherals into the ngi_router class, however still need
> to work on formatting the svg image as it's a little difficult for debug.
welcome to code thrown together in a hurry in a couple of hours.
> I looked at the function "create_sv", however I need more time before I
> figure out which scaling factors to tweak,
don't ask me, i was just winging it as quickly as i could
> as well adjust the package type.
> My plan is to add some sort of argument (or perhaps field in the ngi_router
> module?) to indicate which package will be used for creating the SVG.
> For the moment, I've created a second function called "temp_create_sv", so
> that the generation of LS180 SVG is not affected while I modify the scaling
> for the ngi router.
> The pinmux wiki page now has the current draft SVG image (formatting not
> fixed yet): https://libre-soc.org/crypto_router_pinmux/
excellent. i added this:
which is a copy of the auto-generated markdown.
* 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.
* cutting down GPIO to 8 would leave some NC (not-connected) free pins
to distribute in suitable locations that will help keep power/gnd
away from corners
* VSSE_4/VDDE_4 should be grouped with VSSI_4 and VDDI_4
* there are two VSSE_4/VDDE_4 (84-85 & 104/105)
* there are two VSSE_0/VDDE_0 (56-57 & 64-65)
a trick is that you can use the latter arguments of the ps.sdram()
(or any other function) to limit the range and specify a different
ps.sdram1("", ('W', 0), 0, 15, 6, rev=True) # AD4-9, turned round
ps.sdram1("", ('W', 10), 0, 0, 15, rev=True) # SDRAM DAM0, D0-7, AD0-3
this splits SDRAM1 into two sets:
pins 0-14 (15 pins starting at numbering 0 of the peripheral)
pins 15-20 (6 pins, starting at numbering 15 of the peripheral)
you can see these end up at
* 15 pins numbered 106 to 120
* 6 pins numbered 96 to 101
the reversing is to keep the ordering correct, bridging over
the VSS/VDD 102-105
this trick will keep VSS/VDD away from the corners, but it's
a bit of a pain.
also, you probably noticed: sdram2 is the "continuation" of
sdram1 - it provides an extra 16-bit of data to give up to
32-bit data (which strictly speaking we can do without if
necessary) and there are some extra bank-address lines and
data-byte-write-enable that can be skipped as well as a
this would bring down the pincount from 39 to 21 for sdram,
bringing the total pincount down to around 220
oh btw these pages should be merged, whoops
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs