Bug 506 - 8x VDD VSS pins needed in ioring
Summary: 8x VDD VSS pins needed in ioring
Status: RESOLVED FIXED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Hardware Layout (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Jean-Paul.Chaput
URL:
Depends on:
Blocks: 199 507
  Show dependency treegraph
 
Reported: 2020-09-28 12:00 BST by Luke Kenneth Casson Leighton
Modified: 2021-04-24 18:24 BST (History)
2 users (show)

See Also:
NLnet milestone: NLNet.2019.Coriolis2
total budget (EUR) for completion of task and all subtasks: 600
budget (EUR) for this task, excluding subtasks' budget: 600
parent task for budget allocation: 199
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:
"lkcl"={amount=450, submitted=2021-04-24} "staf"={amount=150, submitted=2021-04-21}


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2020-09-28 12:00:54 BST
in the coriolis2 chip plugin, coronablock.py, it looks like it's only
possible to do 2x VSS and 2x VDD.

we will need a lot more than that (2 each on each edge of the QFP)
and they need to go all the way to the corners
Comment 1 Luke Kenneth Casson Leighton 2020-09-30 19:38:28 BST
(In reply to Jean-Paul.Chaput from comment #5)
> (In reply to Luke Kenneth Casson Leighton from comment #4)
> > jean-paul i can't connect up VDD / VSS, there must be some magic
> > voodoo incantation for ioring.py i can't find?
> 
>   Ah, unlunky! I didn't see that there was a new bug for I/O ring...

199 is getting a bit too long.

>   I think I did reply to that question in bug 199 (with a lot of
>   questions).

you mean https://bugs.libre-soc.org/show_bug.cgi?id=199#c81

you might have said it indirectly, that you are implementing a new
"HNFS" block plugin.
Comment 2 Jean-Paul.Chaput 2020-10-01 10:57:28 BST
(In reply to Luke Kenneth Casson Leighton from comment #1)
> you might have said it indirectly, that you are implementing a new
> "HNFS" block plugin.

  Yes, I was planning to port the current chip/corona system to
  the new "block" plugin (making a "alpha/chip" plugin).

  It was not clear to me what you need for the QFP.
  Do you want *different net* VDD/VSS or do you want *more*
  external VDD/VSS pad (2 per sides) on the package. If it is the
  latter, it can already be done. You may want to add as many
  "pvdde_ck" and "pvsse_ck" as you like. It's just that the
  little script doing the "core -> (chip+corona)" by default
  only makes two. That is easily correctable.
Comment 3 Luke Kenneth Casson Leighton 2020-10-01 11:33:37 BST
(In reply to Jean-Paul.Chaput from comment #2)
> (In reply to Luke Kenneth Casson Leighton from comment #1)
> > you might have said it indirectly, that you are implementing a new
> > "HNFS" block plugin.
> 
>   Yes, I was planning to port the current chip/corona system to
>   the new "block" plugin (making a "alpha/chip" plugin).

great.

>   It was not clear to me what you need for the QFP.
>   Do you want *different net* VDD/VSS 

no.

> or do you want *more*
>   external VDD/VSS pad (2 per sides) on the package.

yes.

> If it is the
>   latter, it can already be done. You may want to add as many
>   "pvdde_ck" and "pvsse_ck" as you like.

ah that was the name i could not find.  none of the examples use those names so i was not able to know what to add.

am2901 does not have those pins in its list.

> It's just that the
>   little script doing the "core -> (chip+corona)" by default
>   only makes two. That is easily correctable.

if this is quick and easy for you yes please then i can see the git diff.
Comment 4 Staf Verhaegen 2020-10-01 14:27:51 BST
Actually for the 0.18um tape-out the core voltage will be 1.8V and the IO voltage 3.3v. So separate supply have to also be foreseen for the VDDIO and VSSIO. Let's also take 2 VDDIO/VSSIO pairs on each side for the moment. This may be reduced in the future to one pair on each side.

To reduce bond wire loop area it is also best to put the VDD/VSS pins next to each other in the IO-ring.
Comment 5 Luke Kenneth Casson Leighton 2020-10-01 15:06:51 BST
(In reply to Staf Verhaegen from comment #4)
> Actually for the 0.18um tape-out the core voltage will be 1.8V and the IO
> voltage 3.3v.

ah.  that's why i asked about level-shifting.

this would imply that it would be best to also have env.setGROUND() take
a dictionary and env.setPOWER() also.

so just to be clear: *even though* the pxlib drop-in replacement is in
fact a drop-in replacement, is it the case that the IOpads are designed to:

* take 3.3v IO pad voltage supply
* but, accept an input signal at a 1.8v supply, to output 3.3v at the pad?
* and, convert an incoming pad voltage to the 1.8v "core'?

is that correct?  let's take an example:


  spisdcard_miso : pi_px
  port map ( ck   => cki      # ignore that this should be spisdcard_clk
           , pad  => spisdcard_miso         # to pad, @ 3.3v
           , t    => spisdcard_miso_core    # from core, @ 1.8v
           , vdde => vdde                   # this is IO GND?
           , vddi => vddi                   # this is core GND?
           , vsse => vsse                   # pad 3.3v IOVSS?
           , vssi => vssi                   # core 1.8v COREVSS?
           );


is that right?


> So separate supply have to also be foreseen for the VDDIO and
> VSSIO.

ok this i would be *very* happy to see, it is what i expected,
i was just surprised not to find it, and hadn't mentioned it
because you said "no there are no level-shifters".


>  Let's also take 2 VDDIO/VSSIO pairs on each side for the moment. This
> may be reduced in the future to one pair on each side.

actually... if it is not too inconvenient i would very much like to see proper allocation of different number - and type - of VDDIO/VSSIO right now.

in particular, it may be a good idea to separate SDRAM IO VSS/VDD to stop
possible power-spikes from other peripherals if they were on the same
power ring.

(even if both general IO VSS *and* SDRAM IO VSS are both 3.3v, it is still
good practice to separate them).


Staf: can the pxlib that you are designing go as low as an external
IO voltage of 1.8v?  if so that would be absolutely fantastic because
a separate VDD_SDCARD can be created which would allow for an external
PMIC (Power Management IC) to drop the SD/MMC Card I/O voltage to 1.8v
under software control.

(e.g. the AXP-209 PMIC can be controlled by I2C commands to tell different
IO voltage domains to change voltages).



> To reduce bond wire loop area it is also best to put the VDD/VSS pins next
> to each other in the IO-ring.

good point.
Comment 6 Jean-Paul.Chaput 2020-10-01 23:28:52 BST
(In reply to Luke Kenneth Casson Leighton from comment #5)

I will divert two or three days to make the port of the chip/corona
plugin and the implementation of the new features. Would it be
possible to have a shrunk down core but still with all the
different I/O domains.
Comment 7 Luke Kenneth Casson Leighton 2020-10-02 12:03:31 BST
(In reply to Jean-Paul.Chaput from comment #6)
> (In reply to Luke Kenneth Casson Leighton from comment #5)
> 
> I will divert two or three days to make the port of the chip/corona
> plugin and the implementation of the new features. Would it be
> possible to have a shrunk down core but still with all the
> different I/O domains.

done.  lvx and cougar still take a massive amount of time despite there
being literally only one cell in the 9000x9000 lambda area, however i have
found that they can be interrupted (they are non-essential)

i have updated build.sh for you.

my thoughts overnight here are that clock and voltage domains should be part of
the ioring.py "chip" dictionary.

chip = {'chip.domains': {'SDRAM': ['p_list', 'of', 'iopads', 'for', 'sdram'],
                         'JTAG': ['p_list', 'of', 'jtag', 'pads']
                        },
        'chip.clocks': {'SDRAM': 'p_sdram_clock',
                        'JTAG': 'p_jtag_tck'
                        },
       }

and leave env.setCLOCK(), env.setPOWER() and env.setGROUND() alone
(do not modify) using them to specify "defaults"

the above dictionary format *should* be enough information to determine
the nets, by parsing the chip['pads.instances'] and pads.south/east/n/w
information.

IoPadConf contains the "lookup" information to turn p_xxx_xxx into NETs,
particularly for the _i, _o and _oe net names.

what do you think, jean-paul?
Comment 8 Luke Kenneth Casson Leighton 2020-10-02 12:27:30 BST
jean-paul this is what i have created.  it is... "excessive" however
will illustrate the point, very well.  a "real" (28/14/7nm) SoC will
have *more* clock/voltage domains than this!

i will push this to pinmux and soclayout so you can run it yourself and
see what you think.

the results will be displayed by "make pinmux" before being put into
coriolis2/ls180/litex_pinpads.json


chip['chip.domains'] = {'GPIO': ['p_gpio_8',
          'p_gpio_9',
          'p_gpio_10',
          ....
          .....
          'p_gpio_6',
          'p_gpio_7'],
 'JTAG': ['p_jtag_tms', 'p_jtag_tdi', 'p_jtag_tdo', 'p_jtag_tck'],
 'SD': ['p_sdcard_cmd',
        'p_sdcard_clk',
        'p_sdcard_data0',
        'p_sdcard_data1',
        'p_sdcard_data2',
        'p_sdcard_data3'],
 'SDR': ['p_sdram_dm_0',
         'p_sdram_dq_0',
         'p_sdram_a_2',
         'p_sdram_a_3',
         'p_sdram_a_4',
         ...
         ]
 'TWI': ['p_i2c_sda', 'p_i2c_scl'],
 'UART': ['p_uart_tx', 'p_uart_rx']}

and:

chip['chip.clocks'] = 
     {'MSPI': 'p_spi_master_clk',
      'SD': 'p_sdcard_clk',
      'SDR': 'p_sdram_clock',
      'TWI': 'p_i2c_scl'}
Comment 9 Staf Verhaegen 2020-10-02 13:02:40 BST
(In reply to Luke Kenneth Casson Leighton from comment #7)

> my thoughts overnight here are that clock and voltage domains should be part
> of
> the ioring.py "chip" dictionary.
> 
> chip = {'chip.domains': {'SDRAM': ['p_list', 'of', 'iopads', 'for', 'sdram'],
>                          'JTAG': ['p_list', 'of', 'jtag', 'pads']
>                         },
>         'chip.clocks': {'SDRAM': 'p_sdram_clock',
>                         'JTAG': 'p_jtag_tck'
>                         },
>        }

FYI, my IO cell library currently won't support different power domains. Although implementation may seem trivial it actually is not. Thing is that you may not fully isolate the domains because then you get ESD problems between pins of different voltage domain.
So the prototype will have on 3.3V domain and one 1.8V domain.
Comment 10 Luke Kenneth Casson Leighton 2020-10-02 13:13:18 BST
jean-paul, note especially!

* JTAG will not have a separate p_vdde_jtag / p_vsse_jtag!  its VDDE/VSSE
  should therefore be the "default" (currently p_vddeck_0 / p_vsseck_0)

  however it *does* have a clock entry!

* GPIO *will* have a separate p_vdde_gpio / pvsse_gpio

  however it will *not* have a separate clock entry!  therefore the
  clock should be the "default", set and identified by env.SETCLOCK().

* SDRAM might need two vss/vdd because it is high-speed: p_vdde_sdr_0/1
  and p_vsse_sdr_0/1

  it *does* also have a clock entry in chips['chips.clocks'] dictionary

so there are these four completely separate possibilities:

* no clock domain, no power domain.  default comes from env.SETCLOCK/SETPOWER
* clock domain, no power domain.
* no clock domain, power domain
* clock domain *and* power domain

all external power domain rings will be the 3.3v

all internal (vddi, vssi) however are *one* power domain, but we will need
multiple of them.  these will be 1.8v
Comment 11 Luke Kenneth Casson Leighton 2020-10-02 13:31:35 BST
(In reply to Staf Verhaegen from comment #9)

> FYI, my IO cell library currently won't support different power domains.
> Although implementation may seem trivial it actually is not. Thing is that
> you may not fully isolate the domains because then you get ESD problems
> between pins of different voltage domain.

is that the case even if there are multiple IO 3.3v domains?

is that related to how close the 3.3v IO power rings are to each other?

what if the power connection is not a ring, but is instead just a line?

it does not make a lot of sense to have 8 or 16 GPIOs, for a "ring" to go
round the entire chip, when the IOpads for GPIO - and its VSS/VDD - are
isolated to one small section.

N20-N29 for example are VDD_GPIO GPIO0..7 VSS_GPIO

lines would be separated by much greater distance because the pads
have a huge distance, and therefore each different voltage domain would
in fact be hugely separated.

(except 1.8v VDDI/VSSI of course which would still remain a ring)


> So the prototype will have on 3.3V domain and one 1.8V domain.

questions:

* are we using pxlib (alliance, original) or the C4M alternative?  if
  jean-paul has to redesign the coriolis plugin to suit the C4M replacement
  (and it has a different API - not the same ck mappings) we should discuss
  that, work out how much time it takes.

* if you have to adapt the C4M alternative to suit the (exact) API of the
  (original, alliance) pxlib, how long will this take and can it be done
  in time?

* can we even use the (original, alliance) pxlib for this prototype?
  (alliance pxlib _is_ silicon-proven @ 180nm, is it not?)

* can the (original, alliance) pxlib handle ESD for multiple 3.3v domains?

  i.e. is the ESD problem unique to C4M alternative pxlib or is it a
  general problem for *all* IO pad libraries?

* can "lines" instead of "rings" solve the ESD isolation between different
  3.3v domains?
Comment 12 Luke Kenneth Casson Leighton 2020-10-02 14:25:49 BST
(In reply to Staf Verhaegen from comment #9)

> So the prototype will have on 3.3V domain and one 1.8V domain.

rright.  if that's the case - and there is no other option - then there
is no point doing multiple IO domains at all, we might as well stick
with the current chip plugin.

jean-paul i *really* cannot get multiple p_vsseck_0/1 / p_vddeck_0/1 working,
it is beginning to piss me off.

can i ask you the favour of modifying experiments4 ioring to show me how
it is supposed to be done?

absolutely every single thing that i have tried has failed and i have
been trying for several weeks.

add to pads.north fail.

add to pads.instances fail.

add vdde fail.

add p_vddeck_0 fail.  

add p_vddeck_1 fail.


if you can add it to experiments4 (which i updated to take pads.instances)
i can see how it works.
Comment 13 Staf Verhaegen 2020-10-02 14:43:37 BST
(In reply to Luke Kenneth Casson Leighton from comment #11)
> (In reply to Staf Verhaegen from comment #9)
> 
> > FYI, my IO cell library currently won't support different power domains.
> > Although implementation may seem trivial it actually is not. Thing is that
> > you may not fully isolate the domains because then you get ESD problems
> > between pins of different voltage domain.
> 
> is that the case even if there are multiple IO 3.3v domains?

Yes.

> 
> is that related to how close the 3.3v IO power rings are to each other?

No, ESD is small charge but a few kV between any two pins on a chip. Distances on a chip are never big enough to not having arcs caused by this high voltage. This means one need to foresee an ESD path between any two pins on a chip to not have the current flow through unwanted paths.
Typically this is done by sharing the ground between the different domains but allow the possibility to have different supply voltages. More details I don't have time to provide now.

> 
> what if the power connection is not a ring, but is instead just a line?

Normally IO cells are arranged in a ring. In theory, you could reduce this to one line. You can't have multiple disconnected lines.
Comment 14 Jean-Paul.Chaput 2020-10-02 15:00:11 BST
(In reply to Luke Kenneth Casson Leighton from comment #12)
> (In reply to Staf Verhaegen from comment #9)
> 
> > So the prototype will have on 3.3V domain and one 1.8V domain.
> 
> rright.  if that's the case - and there is no other option - then there
> is no point doing multiple IO domains at all, we might as well stick
> with the current chip plugin.
> 
> jean-paul i *really* cannot get multiple p_vsseck_0/1 / p_vddeck_0/1 working,
> it is beginning to piss me off.
> 
> can i ask you the favour of modifying experiments4 ioring to show me how
> it is supposed to be done?
> 
> absolutely every single thing that i have tried has failed and i have
> been trying for several weeks.
> 
> add to pads.north fail.
> 
> add to pads.instances fail.
> 
> add vdde fail.
> 
> add p_vddeck_0 fail.  
> 
> add p_vddeck_1 fail.
> 
> 
> if you can add it to experiments4 (which i updated to take pads.instances)
> i can see how it works.

  I'm still in another meeting... So very quickly and from memory,
  core2chip is quick helper to avoid manually writing chip and
  corona netlists. So it allows *only* one pvddeck, pvsseck, pvddick
  and pvssick. To have more, you have to manually edit the chip
  netlist and add more power pads. Then reload the nestlist
  along with an updated ioring.py...
Comment 15 Luke Kenneth Casson Leighton 2020-10-02 15:14:20 BST
(In reply to Staf Verhaegen from comment #13)
> (In reply to Luke Kenneth Casson Leighton from comment #11)

> > is that the case even if there are multiple IO 3.3v domains?
> 
> Yes.

ok.

> Typically this is done by sharing the ground between the different domains
> but allow the possibility to have different supply voltages.

ok.

> More details I
> don't have time to provide now.

no problem.

> > 
> > what if the power connection is not a ring, but is instead just a line?
> 
> Normally IO cells are arranged in a ring. In theory, you could reduce this
> to one line. You can't have multiple disconnected lines.

ok scratch that idea, i thought the distance for pads was not large enough for ESD to jump.
Comment 16 Luke Kenneth Casson Leighton 2020-10-02 15:24:59 BST
(In reply to Jean-Paul.Chaput from comment #14)

>   I'm still in another meeting... So very quickly and from memory,

ok

>   core2chip is quick helper to avoid manually writing chip and
>   corona netlists. So it allows *only* one pvddeck, pvsseck, pvddick
>   and pvssick.

arg ok. this is what i found.

> To have more, you have to manually edit the chip
>   netlist and add more power pads.

hand-edit autogenerated chip.vst? yuk :)

> Then reload the nestlist
>   along with an updated ioring.py...

yuk :)

i have a feeling that because for ESD only one 3.3v and one 1.8v is possible, the new domains idea is not going to be useable anyway.

therefore if the current core2chip can be quickly modified to allow N 3.3v vdde and N 1.8v vddi i think we are good.

except for the PLL i think we just have to put up with one clock, and if no PLL is ready that one is solved too.
Comment 17 Luke Kenneth Casson Leighton 2020-10-04 07:18:23 BST
got bored, decided to add the option:
https://gitlab.lip6.fr/vlsi-eda/coriolis/-/issues/29

you'll need to review that, jean-paul, i tend to add random print
statements in to check what is going on.

i also disabled the "error" which prevents pads from being added
beyond the edge of the core.  *with care* there should be no overlap.

it would be better to be able to specify that the IOpads start *exactly*
from the width of the core *NOT* from the width of the corona:

+------|-|-|-------+
       | | |
      +|-|-|+
      |     |
      -     -
Comment 18 Luke Kenneth Casson Leighton 2020-10-04 14:45:52 BST
(In reply to Luke Kenneth Casson Leighton from comment #17)

> it would be better to be able to specify that the IOpads start *exactly*
> from the width of the core *NOT* from the width of the corona

done also.  patch updated at https://gitlab.lip6.fr/vlsi-eda/coriolis/-/issues/29
Comment 19 Luke Kenneth Casson Leighton 2021-04-20 10:12:36 BST
sorted and implemented, alternative ioring system created which supports
multiple clocks and multiple power domains.  only two separate power domains
for ESD purposes though, at the moment.