Bug 507 - ls180 asic needs an ioring, pads need defining and connecting
Summary: ls180 asic needs an ioring, pads need defining and connecting
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: 506
Blocks: 199
  Show dependency treegraph
 
Reported: 2020-09-28 12:04 BST by Luke Kenneth Casson Leighton
Modified: 2020-12-06 13:51 GMT (History)
1 user (show)

See Also:
NLnet milestone: NLNet.2019.Coriolis2
total budget (EUR) for completion of task and all subtasks: 1500
budget (EUR) for this task, excluding subtasks' budget: 1500
parent task for budget allocation: 199
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:
"lkcl"={amount=750, submitted=2020-12-06} "lip6"={amount=750 }


Attachments
iopads but not routed (487.85 KB, image/png)
2020-09-28 12:19 BST, Luke Kenneth Casson Leighton
Details

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:04:20 BST
an ioring corona is needed around the core, and the pads need to be
connected up, including bi-directional ones _i _o _oe.
Comment 1 Luke Kenneth Casson Leighton 2020-09-28 12:19:22 BST
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.
Comment 2 Luke Kenneth Casson Leighton 2020-09-28 12:38:47 BST
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.
Comment 3 Luke Kenneth Casson Leighton 2020-09-28 14:10:41 BST
(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.
Comment 4 Luke Kenneth Casson Leighton 2020-09-30 16:40:11 BST
jean-paul i can't connect up VDD / VSS, there must be some magic
voodoo incantation for ioring.py i can't find?
Comment 5 Jean-Paul.Chaput 2020-09-30 16:46:36 BST
(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).
Comment 6 Luke Kenneth Casson Leighton 2020-10-01 12:15:50 BST
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.
Comment 7 Jean-Paul.Chaput 2020-10-01 12:25:06 BST
(In reply to Luke Kenneth Casson Leighton from comment #6)
Have meetings this afternoon, works on it right after.
Comment 8 Luke Kenneth Casson Leighton 2020-10-01 12:40:37 BST
(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.
Comment 9 Luke Kenneth Casson Leighton 2020-10-01 16:40:54 BST
(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
Comment 10 Jean-Paul.Chaput 2020-10-02 10:04:41 BST
(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?
Comment 11 Luke Kenneth Casson Leighton 2020-10-02 10:41:17 BST
(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.
Comment 12 Luke Kenneth Casson Leighton 2020-10-02 11:09:00 BST
(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.
Comment 13 Jean-Paul.Chaput 2020-10-02 12:56:54 BST
(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.
Comment 14 Luke Kenneth Casson Leighton 2020-10-02 13:01:37 BST
(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.
Comment 15 Luke Kenneth Casson Leighton 2020-10-04 08:42:22 BST
(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
Comment 16 Luke Kenneth Casson Leighton 2020-12-06 13:50:39 GMT
JP with the pinmux created and with niolib in place i am declaring this one "done"