an ioring corona is needed around the core, and the pads need to be connected up, including bi-directional ones _i _o _oe.
Created attachment 107 [details] iopads but not routed jean-paul i have a first iteration corona done (still need to commit it) however it is slightly odd: none of the wires to the pads are routed. what's going on, there? this is the same for experiment4, it's not wired up, either.
i've drastically cut back the core (as in: it's gone) so that the time taken to investigate ioring is also reduced. interestingly there is only one failed-routed segment: o Routing did not complete, unrouted segments: 1| &<id:2240633 Horizontal core.main_sdcore_cmd_argument_storage(30) METAL2 [12490l 10295l] [12580l 10295l] 2l rpD:5 -----CG------A----tt- [12489l:12581l] 92l 1----s-> it takes a lot less time to repro this one.
(In reply to Luke Kenneth Casson Leighton from comment #1) > jean-paul i have a first iteration corona done (still need to commit it) > however it is slightly odd: none of the wires to the pads are routed. > > what's going on, there? this is the same for experiment4, it's not > wired up, either. worked it out: ioring chip dictionary has to have pads.instances entries for every pad-core connection.
jean-paul i can't connect up VDD / VSS, there must be some magic voodoo incantation for ioring.py i can't find?
(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, unluncky! I didn't see that there was a new bug for I/O ring... I think I did reply to that question in bug 199 (with a lot of questions).
moving from here: https://bugs.libre-soc.org/show_bug.cgi?id=199#c96 (In reply to Jean-Paul.Chaput from comment #96) > Not sure I correctly see how the wiring is organized (I'm a visual > guy, I understand more quickly schematics). that is why i drew it https://bugs.libre-soc.org/attachment.cgi?id=108 > Nevertheless, the > strategy here is: > > * Put everything that contains gates under ls180. It will be flat > placed & routed. So *below* ls180, you can have whatever > hierarchy you like. > > * Complex wiring between pads and core (ls180) will take place > inside the "corona" level (like the 'oe' signal for all pads > part of the same bus). right. except - see picture i drew - JTAG has to have "control" over what goes to the IOPads. i have "solved" this by making JTAG part of ls180 (core) so in effect as far as coronais concerned JTAG is like an opaque block that might as well not exist. > * Connexion betweens "corona" and I/O pads (that is, at "chip" > level) go *almost* straight (in our case, they go straight > because both side are symbolic layout). > > * And finally, a dedicated "router" connect the I/O pad ring > connectors together, including corners. to understand this fully: is this basically exactly what the AM2901 and experiments4 examples do? > NOTE: This partitionning also has the advantage to *not* include > the I/O pad area inside the general routing area, which > allows me to remove all special cases related to I/O pads > from Katana (and they are hellish). :) > > # this is bad > > > > p_jtag_tck : pi_px <- nooo! must be of type pck_px! > > port map ( ck => cki <- baaaad, noooo! > > , pad => jtag_tck > > , t => jtag_tck_core > I understand. To avoid putting extra specifications, the fact that > there is different clocks could be directly guessed from the I/O pad > netlist (at "chip" level). ah, goood. then there are several (if we include PLL, not decided yet, it has to be ready) * sys_clk - this is 24 mhz input * jtag_tck - completely independent of sys_clk, also input outputs: * pll_48mhz, a digital divided testing signal. must be slaved to JTAG clock: * jtag_tms, tdo, tdi i.e. the iopad must be this: p_jtag_tdi : pi_px port map ( ck => jtag_cki <-currently cki! ) without this, from what i understand, if every pad is "controlled" by cki (which links from corona to sys_clk) then we have a problem. likewise, for SDRAM if sys_clk is 24mhz but PLL generates 300mhz then it is *really* bad to try to link the 24mhz sys_clk to pxlib pi_px and other IOpads. it should really be sdram_clock > I think it is not very difficult to > create disjoined parts in the I/O pad ring. great. > The big question is, will each part be made of an assembly of pxlib > pads *or* will Staf add some other kind with different wiring > strategies? Staf said he wants to stick with a drop-in pxlib. no change to pxlib API. i see no reason why it should change. the only thing is, extra pxlib pck_px IOpads must be created that are NOT connected to "default always assumed sys_clk", and the IO associated with rhrm must also be completely independent. this then also means that the "ring" connecting all ck, pck_px to ck pi_px etc, must ALSO be independent and not cross-wired to each other. * jtag_cki ring must be independent * sdram_cki ring must be independent actually i now realise that sys_clk 24mhz is exclusively routed to the PLL, and it is the INTERNAL clock (300mhz from PLL) that must be connected to ioring cki GPIO, I2C, SPI etc! > Before I upgrade the I/O pad "router" I would need a > clear understanding of the I/O pads physical interface. * PLL runs from external sys_clk, generates FASTER internal clock (300mhz) than 24mhz sys_clk * pll_48mhz_o runs from PLL FASTER than 24mhz sys_clk * JTAG runs from external clock jtag_tck * SDRAM runs from *internal* clock sdram_clock which is FASTER than sys_clk * I2C runs from internal clock but is SLOWER than sys_clk so can be ignored * SDMMC sd0_ck runs at 50mhz from digital divide of PLL 300mhz CLK which is FASTER than 24mhz sys_clk we basically need a way to say "these pins are covered by this clock". i can set that up as a dictionary, it is easy to do from pinmux. i think it will not be possible to determine from examining netlists, it is defined by the designer.
(In reply to Luke Kenneth Casson Leighton from comment #6) Have meetings this afternoon, works on it right after.
(In reply to Jean-Paul.Chaput from comment #7) > (In reply to Luke Kenneth Casson Leighton from comment #6) > Have meetings this afternoon, works on it right after. ok i leave this with you for after meeting. for the dictionary spec, env.SETCLOCK could take an example: env.setCLOCK({'default': '^internal_pll_clk$', 'jtag_pck': ['jtag_tms', 'jtag_tdo', 'jtag_tdi'], 'sys_clk': [], # TODO 'sd0_clk': ['sd0_cmd_i', "sd0_cmd_o", "sd0_cmd_oe", 'sd0_data_i', "sd0_data_o", "sd0_data_oe", "sdram_clock": "^sdram_.*" }) notes: * any IOPad (corona) signal not in any list or patternmatch uses "default" * each of these pck_px rings is completely independent! * notice that sys_clk the external 24 mhz is not the default! this would get you started while i generate the "real" one. hm i must make a dummy PLL for you with an input of "sys_clk" and an output "internal_pll_clk" i will do that before afternoon.
(In reply to Luke Kenneth Casson Leighton from comment #8) > hm i must make a dummy PLL for you with an input of "sys_clk" and an output > "internal_pll_clk" i will do that before afternoon. this is now done, it is: * sys_clk input from ioring thru corona * sys_clk connects to "dummy" PLL * pll_out connects to clksel module * clksel outputs "core" (internal) clock * core clock drives most of ls180
(In reply to Luke Kenneth Casson Leighton from comment #9) > (In reply to Luke Kenneth Casson Leighton from comment #8) > > > hm i must make a dummy PLL for you with an input of "sys_clk" and an output > > "internal_pll_clk" i will do that before afternoon. > > this is now done, it is: > > * sys_clk input from ioring thru corona > * sys_clk connects to "dummy" PLL > * pll_out connects to clksel module > * clksel outputs "core" (internal) clock > * core clock drives most of ls180 If not already done, could you make a "trimmed down" core version so the outer interface (to the CORONA / I/O pads) is the same, but with a much smaller core so I can speed up my debug cycle?
(In reply to Jean-Paul.Chaput from comment #10) > If not already done, could you make a "trimmed down" core version so the > outer interface (to the CORONA / I/O pads) is the same, but with a much > smaller core so I can speed up my debug cycle? i did! :) this cut the time from 1hr to 10mins (?) the problem is that yosys destroys ("optimises") unconnected signals. my feeling is that it would be easier to take the vst - ls180.vst - created by alliance and just use that. i will see what i can do.
(In reply to Luke Kenneth Casson Leighton from comment #11) > (In reply to Jean-Paul.Chaput from comment #10) > > > If not already done, could you make a "trimmed down" core version so the > > outer interface (to the CORONA / I/O pads) is the same, but with a much > > smaller core so I can speed up my debug cycle? > > i did! :) this cut the time from 1hr to 10mins (?) > > the problem is that yosys destroys ("optimises") unconnected signals. > > my feeling is that it would be easier to take the vst - ls180.vst - created > by alliance and just use that. i will see what i can do. done. please re-run git submodule update, and re-run "make pinmux" then manually copy ls180.vst from non_generated.
(In reply to Luke Kenneth Casson Leighton from comment #12) > > done. please re-run git submodule update, and re-run "make pinmux" > > then manually copy ls180.vst from non_generated. Thanks, now it will take two or three days for me to adapt the plugin.
(In reply to Jean-Paul.Chaput from comment #13) > (In reply to Luke Kenneth Casson Leighton from comment #12) > > > > done. please re-run git submodule update, and re-run "make pinmux" > > > > then manually copy ls180.vst from non_generated. > > Thanks, now it will take two or three days for me to adapt > the plugin. ok cool. i just realised, i have left off p_vdde_sdr_0/1/2 and p_vsse_sdr_0/1/2 and others based on the chip.domains dictionary keys (SDR, SD, JTAG). i will add those.
(In reply to Jean-Paul.Chaput from comment #13) > Thanks, now it will take two or three days for me to adapt > the plugin. jean-paul if you can review this and if we do not need different clock connection rules for jtag_tck etc then it is done for now, because Staf mentioned we can only do a single 3.3v and a single 1.8v due to ESD. https://bugs.libre-soc.org/show_bug.cgi?id=506#c17
JP with the pinmux created and with niolib in place i am declaring this one "done"