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

> pinmux_generator.py will now recognise the new chip module. I initially had
> issues as I didn't do steps 2 and 3 hahaha

wark-wark :)

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

like it.

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

sensible.

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

which is a copy of the auto-generated markdown.

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.

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

    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)

https://libre-soc.org/180nm_Oct2020/ls180/
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
result.

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

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