cross-reference bug #508 which was for ls180 pinout discussion.

andrey i added you to pinmux gitolite access

aliases (esp. more than one) make me slightly nervous.
better to use the wiki for crossreferencing.

jean-paul, one thing: when we discussed the additional clocks
coming from peripherals (JTAG TCK, RGMII CLK, ULPI CLK) these are inputs
that are planned to be routed through JTAG Boundary Scan, just like all
others.

later (in a future version) they may also be routed through
pinmux (4 peripherals MUXed
to/from the exact same IOpad, under GPIO control)

is that okay?

https://libre-soc.org/180nm_Oct2020/ls180/

Andrey notice how the Power is not completely in the corner,
but is not in the middle either, but also how they group
together.

also note, PLL is right in the top corner, and, also, note
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.

Staf, Jean-Paul: a 256-pin package is going to be 64 pins per side.

are there any special considerations for that?

(In reply to Luke Kenneth Casson Leighton from comment #5)
> https://libre-soc.org/180nm_Oct2020/ls180/
> 
> Andrey notice how the Power is not completely in the corner,
> but is not in the middle either, but also how they group
> together.
Will keep in mind.
 
> also note, PLL is right in the top corner, and, also, note
Same placement as LS180?

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

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"

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

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.

I looked at the function "create_sv", however I need more time before I figure out which scaling factors to tweak, 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/

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

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

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

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

(In reply to Luke Kenneth Casson Leighton from comment #11)

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

or, pin numbering goes up, while function numbering goes down.

or, the split point turns out to be forced to be in the middle
of the data lines.

definitely don't break up data lines.

(In reply to Luke Kenneth Casson Leighton from comment #4)
> jean-paul, one thing: when we discussed the additional clocks
> coming from peripherals (JTAG TCK, RGMII CLK, ULPI CLK) these are inputs
> that are planned to be routed through JTAG Boundary Scan, just like all
> others.
> 
> later (in a future version) they may also be routed through
> pinmux (4 peripherals MUXed
> to/from the exact same IOpad, under GPIO control)
> 
> is that okay?

  I've loosely followed this discussion up until now, I'm not sure
  to follow exactly what the question is. Are there specific
  routing constraints to manage? If so, could you draw a schematic
  or a figure of the layout you expect ?

  Best,

(In reply to Jean-Paul.Chaput from comment #13)

>   I've loosely followed this discussion up until now, I'm not sure
>   to follow exactly what the question is. Are there specific
>   routing constraints to manage? If so, could you draw a schematic
>   or a figure of the layout you expect ?

yes, here is a page i wrote in advance with some diagrams:
https://libre-soc.org/docs/pinmux/

all of this is combinatorial logic, no clocks at all.

https://libre-soc.org/docs/pinmux/gpio_block.png

the green (out) mux and the red (out) mux are *in addition* to
the JTAG Boundary scan muxes:

https://libre-soc.org/shakti/m_class/JTAG/jtag-block.jpg

so *after* going through the pair of JTAG Boundary Scan
"bypass" MUXes, if we want say 1,000 IO functions to be
shared access to say only 200 pins, there are *additional*
4:1 IN/OUT Muxes that must be added.

this gives *two* levels of MUXes (actually three) that
data *including incoming CLK lines* have to go through.

* JTAG PAD Mux 1:2
* JTAG Core Mux 2:1
* GPIO IN (or OUT) Mux 4:1

hence why i am asking, because this is all Combinatorial
Logic, and any delay/sync buffers due to clock trees would
actually cause the output data to get *out of sync* with
the external clock!

this is, funnily enough, a situation that is fully recognised
by the creators of the Gigabit Ethernet RGMII Specification:
they have special lines TXDLY and RXDLY which introduce 2ns
of clock delay *at the PHY*!

but, that is 125 mhz clock rates so hardly surprising.

(In reply to Luke Kenneth Casson Leighton from comment #14)
> (In reply to Jean-Paul.Chaput from comment #13)
> 
> >   I've loosely followed this discussion up until now, I'm not sure
> >   to follow exactly what the question is. Are there specific
> >   routing constraints to manage? If so, could you draw a schematic
> >   or a figure of the layout you expect ?
> 
> yes, here is a page i wrote in advance with some diagrams:
> https://libre-soc.org/docs/pinmux/
> 
> all of this is combinatorial logic, no clocks at all.
> 
> https://libre-soc.org/docs/pinmux/gpio_block.png
> 
> the green (out) mux and the red (out) mux are *in addition* to
> the JTAG Boundary scan muxes:
> 
> https://libre-soc.org/shakti/m_class/JTAG/jtag-block.jpg

  OK. I get the idea. One more question regarding the various clocks:
  how widespread are they *in* the design? I mean, making a whole
  H-Tree across *all* the area if only a very specific part is
  concerned would be a waste. We may want to either create a
  sub-block with it's localized H-Tree, or develop a specific
  ad-hoc buffering version for one clock.

(In reply to Jean-Paul.Chaput from comment #15)

>   OK. I get the idea. One more question regarding the various clocks:
>   how widespread are they *in* the design?

not at all.  if more than 1,000 transistors there is something very wrong.
(the exception being JTAG CLK but even there it can run at only 5khz or
gosh, maybe 1 mhz).

the external clocks are usually one side of a Clock-Domain-Crossing
FF or FIFO Synchroniser.  this will be for 4, 8 bit or 32 bit IO data
so it does actually need to be balanced timing on the FFs.

there is also a *little* bit of logic, usually things like "is this
ready to send" and so on.  for JTAG the entire Shift Registers are
driven by JTAG TCK and there are a lot of single bit FFs in a chain
there, with quite a few CDC Synchronisers too.

mostly, though, the PHYs work hard to get the data crossed over to
"main system clock" as quickly as possible.

>   I mean, making a whole
>   H-Tree across *all* the area if only a very specific part is
>   concerned would be a waste.

definitely.  more than that, these are the numbers:

* five RGMII clocks 2.5/25/125 mhz
* two ULPI clocks 60 mhz
* one JTAG TCK 5khz to 1mhx
* one I2C CLK 400 mhz max (hm we need pullup and Open Drain for that)
* one SPI which can go up to 25 mgz
* one for SDRAM, up to 133 mhz

each of these will have extremely local PHY logic, easily identifiable
by module.  except JTAG which might get a bit liberally distributed

>   We may want to either create a
>   sub-block with its localized H-Tree, or develop a specific
>   ad-hoc buffering version for one clock.

adhoc sounds like a fantastic idea for SDRAM RGMII ULPI SPI and I2C, it
would not interfere as trees 

one potential problem as trees is, there may be too many to manage
in one area because of pin layout.

(In reply to Luke Kenneth Casson Leighton from comment #16)
> * one I2C CLK 400 mhz max (hm we need pullup and Open Drain for that)

Standard mode I2C is 100 KHz, fast mode is 400 KHz. It seems 3.4 MHz is possible. Certainly not 400 MHz...

The pullup can be external, I think.

(In reply to Cesar Strauss from comment #17)
> (In reply to Luke Kenneth Casson Leighton from comment #16)
> > * one I2C CLK 400 mhz max (hm we need pullup and Open Drain for that)
> 
> Standard mode I2C is 100 KHz, fast mode is 400 KHz. It seems 3.4 MHz is
> possible. Certainly not 400 MHz...

whoops, i meant 400 khz :)

> The pullup can be external, I think.

yes.  2.2k is the nominal termination resistor for I2C i've seen in use,
some use 4.7k or 10k.  so it can't be internal because of differences
in practical real-world usage.

(In reply to Jean-Paul.Chaput from comment #15)

>   H-Tree across *all* the area if only a very specific part is
>   concerned would be a waste. We may want to either create a
>   sub-block with it's localized H-Tree, or develop a specific
>   ad-hoc buffering version for one clock.

raised as a coriolis lip6.fr bug.  cf:
https://gitlab.lip6.fr/vlsi-eda/coriolis/-/issues/50

quite a lot of commits, this is just one of them

https://git.libre-soc.org/?p=pinmux.git;a=commitdiff;h=a6e0377a3fdaa0dfc35bc2ce07536f74c7e6510b

irc logs:

https://libre-soc.org/irclog/%23libre-soc.2022-06-28.log.html#t2022-06-28T12:34:07

andrey remember also to add the SVG file and cross-link it to the top-level
wiki page https://libre-soc.org/crypto_router_pinmux/

(In reply to Luke Kenneth Casson Leighton from comment #21)
> andrey remember also to add the SVG file and cross-link it to the top-level
> wiki page https://libre-soc.org/crypto_router_pinmux/

Added the image, pinout mdwn, and added to the pinspec page:
https://libre-soc.org/crypto_router_asic/crypto_router_pinspec/

https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=97ae1ee86898743998d9c60096ed33ee86de8588

looks really good
https://libre-soc.org/crypto_router_asic/ngi_router.svg