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
(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.
(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.
(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.
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.
(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.
(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.
(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?
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'}
(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.
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
(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?
(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.
(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.
(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...
(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.
(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.
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: +------|-|-|-------+ | | | +|-|-|+ | | - -
(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
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.