[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 #10 from andrey at technepisteme.xyz ---
(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.

> > 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?
Should there be a page specifying how to use the pinmux repo scripts and setup
pinspec module for a new project?


> (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.
Great fun :')

>  
> > 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
Ah yes the age ol' technique... I'll aim to improve readability as I understand
it more.

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


> excellent.  i added this:
> https://libre-soc.org/crypto_router_asic/ngi_router/
> 
> 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"?
Sure, will make sure the pins are at least 4 pins away.

Is there any reason I should keep the power pins *more than 4* pins away from
the edges?

> 
> * 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
Sure, if I'm tight on space I'll reduce the GPIO.

> * 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)
Do you mean that I should run the 3.3V and 1.8V power pins next to eachother?
What's the reason for it? Easier to auto-route?

> 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
Sure I did see this, just that it might be better to keep the whole interface
together.
I'll make sure to split them up though if running out of space.
Is there also any advantage to keeping the pinout as close to LS180's as
possible? I wondered if the PCB guy might have an easier time (although the
package is different anyway).

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

> 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.
I see, so if there's room, I should provide more data lines. If not, I'll skip
them however.


(In reply to Luke Kenneth Casson Leighton from comment #9)
> (In reply to Luke Kenneth Casson Leighton from comment #8)
> 
> > oh btw these pages should be merged, whoops
> > https://libre-soc.org/crypto_router_asic/
> 
> or partially merged, and crypto_router_pinmux moved to
> crypto_router_asic/pinouts or something.
Renamed pinmux page to "crypto_router_pinspec" (since no pinmux is involved,
and that page is more a specification/notes, as opposed to the auto-generated
pinout)
https://libre-soc.org/crypto_router_asic/crypto_router_pinspec/

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