| octavius | lkcl, the ls180 pinout (on the wiki and in the spec file) specifies the package having 32 pins on each side, with width 2 (no units). What does the width correspond to? | 14:05 |
|---|---|---|
| lkcl | width 2? i don't understand what you mean | 14:29 |
| lkcl | Bank N (32 pins, width 2) | 14:29 |
| lkcl | ignore it | 14:29 |
| octavius | The spec python file creates tuples like this: ('N', (32, 2)) | 14:30 |
| octavius | Do I still need to include this parameter 2? | 14:30 |
| lkcl | 1 sec i need to examine the source code | 14:30 |
| octavius | pinmux/src/spec/ls180.py | 14:31 |
| octavius | I tried to look for the usage of it, but couldn't figure it out | 14:31 |
| lkcl | the entirety of that program is undocumented and quite complex | 14:31 |
| octavius | Ah ok | 14:31 |
| lkcl | i suspect it is the number of mux options | 14:32 |
| lkcl | where because the code fails if it is set to 1 it is set to 2 instead | 14:32 |
| octavius | hahaha | 14:32 |
| lkcl | pinbanks = OrderedDict(( | 14:32 |
| lkcl | ('N', (32, 2)), | 14:32 |
| lkcl | yes. | 14:32 |
| lkcl | set to 2. | 14:32 |
| lkcl | look at the i_class file | 14:32 |
| octavius | in base.py, self.muxwidths[bank] = muxwidth | 14:33 |
| lkcl | pinbanks = { | 14:33 |
| lkcl | 'A': (28, 4), | 14:33 |
| lkcl | 'B': (18, 4), | 14:33 |
| lkcl | 'C': (24, 1), | 14:33 |
| lkcl | 'D': (93, 1), | 14:33 |
| lkcl | ok so it probably does cope with a mux value of 1 | 14:33 |
| octavius | yeah, so that means bank A has a 4-way mux? | 14:33 |
| lkcl | yes | 14:33 |
| lkcl | for such compact code it is quite ridiculously complex data structures | 14:34 |
| lkcl | with a lot of reordering of dicts-of-something-of-something-else | 14:35 |
| lkcl | into lists-of-dicts-of-the-something-else-by-the-first-thing | 14:35 |
| lkcl | dict[a][b] -> dict[b][a] | 14:35 |
| lkcl | because of the mappings from functions to pins | 14:35 |
| lkcl | you also need to know which pins have which functions | 14:36 |
| lkcl | therefore | 14:36 |
| lkcl | starting out from dict[pins][functions] | 14:36 |
| lkcl | you have to create dict[functions][pins] | 14:36 |
| lkcl | *and* then verify that there is no overlap | 14:36 |
| lkcl | *and* identify missing (unused) pins | 14:37 |
| lkcl | *and* identify missing functions from a specification (called a "scenario") | 14:37 |
| lkcl | imagine you are designing an SoC | 14:37 |
| lkcl | it has a complex multiplexer | 14:37 |
| lkcl | because you have 1,000 actual functions but only say 250 pins (to save cost) | 14:38 |
| lkcl | if you get *ONE* of those pins wrong, for a particular scenario (one multiplexed function that is needed which the customer can't bring out because it conflicts with another function for the same pin) | 14:38 |
| lkcl | your customer will simply go "well that's useless, i'll buy a competitor's product instead" | 14:39 |
| lkcl | hence you actually have to *specify and test* the scenarios | 14:39 |
| lkcl | which means being able to say what functions you want | 14:39 |
| lkcl | then be able to *remove* them from the available pinset | 14:39 |
| lkcl | and, if at the end of removing all pins from "available" you have completed that without any being missing | 14:40 |
| lkcl | then the scenario can be declared a "success" | 14:40 |
| lkcl | (and, it acts as a Reference Design for that customer, for that scenario) | 14:40 |
| lkcl | frickin complicated in other words | 14:41 |
| octavius | Let's see if I understood what you were talking about. The user of the script specifies the functions (sdram, uart, vdd, etc.) and where they connect to on the package (by instantiating them in the "ps" or PinSpec object). The code then has to create the opposite dictionary (pins to functions) and confirm for any collisions? | 14:42 |
| octavius | In this specific case (ngi router), as we are NOT using muxing atm, the problem should be a little bit simpler for the code to test, correct? | 14:43 |
| lkcl | correct, and correct | 15:17 |
| lkcl | ah... actually there's a 3rd phase | 15:17 |
| lkcl | "scenarios" | 15:17 |
| lkcl | and that's what doesn't need to be done | 15:17 |
| lkcl | because, duh, the pinouts are one-to-one, yes. | 15:18 |
| octavius | 3-phase is muxing conflicted functions? | 15:18 |
| lkcl | checking multiple scenarios | 15:18 |
| lkcl | https://git.libre-soc.org/?p=pinmux.git;a=blob;f=src/spec/m_class.py;hb=HEAD | 15:18 |
| lkcl | line 247: an "Industrial" scenario | 15:19 |
| lkcl | btw, this is where memory-maps would be specified: | 15:21 |
| lkcl | https://git.libre-soc.org/?p=pinmux.git;a=blob;f=src/spec/i_class.py;hb=HEAD#l63 | 15:21 |
| lkcl | for the peripherals to have their CSRs (Control Status Registers) memory-mapped | 15:21 |
| lkcl | if not specified, the memory-map locations are auto-generated | 15:22 |
| octavius | ok. So in the i_class line 63 example, jtag and fb peripherals don't have CSRs? Or are they left to be auto-generated | 15:23 |
| octavius | sorry, meant memory-mapped CSRs | 15:24 |
| lkcl | jtag is totally separate yes | 15:24 |
| lkcl | and FlexBus (motorola) is a general-purpose Memory Bus | 15:25 |
| lkcl | covers AT/XT, MCU 8080, SDRAM, and several more | 15:25 |
| lkcl | octavius, i just updated to python3 | 15:33 |
| lkcl | there may be some things missing | 15:33 |
| lkcl | the conversion is necessary because jean-paul converted coriolis2 to python3 as well | 15:34 |
| octavius | My system has both Python 2 and 3. Should I keep using 2 while getting the router pinout made? | 15:38 |
| lkcl | both work fine | 15:38 |
| lkcl | i added the spec, the markdown file generates great | 15:39 |
| lkcl | PLL goes into the top leeeeft... | 15:41 |
| lkcl | https://git.libre-soc.org/?p=pinmux.git;a=commitdiff;h=56dd5b1bbb700166caf845253fbc4f3b6295a36d | 15:41 |
| lkcl | couple of RGMII interfaces added so you can see how it's done | 15:51 |
| lkcl | they're 18 pins each. not 20. close. | 15:52 |
| octavius | Thanks, should be easier now | 15:52 |
| lkcl | https://git.libre-soc.org/?p=pinmux.git;a=commitdiff;h=07755e054bf3e11af20500b742b0e86edab9aea9 | 15:52 |
| octavius | I'll add the steps you did to add a new chip class to the bug as well (as I didn't add the import statements after creating ngi_router) | 15:52 |
| lkcl | ok good idea. | 15:53 |
| lkcl | really should be documented | 15:53 |
| lkcl | 5x20-5x18 = err... 5x2=10 | 15:55 |
| lkcl | that's 10 spare | 15:56 |
| octavius | nice | 15:56 |
| lkcl | btw you saw how it was + ps.rgmii("1", ('N', 10), 0, 0, 18) | 15:56 |
| lkcl | the 1st argument "1" is the suffix | 15:56 |
| lkcl | RG1 | 15:57 |
| lkcl | so for adding 2 USB/ULPI interfaces it would be ps.ulpi("0"....) and ps.ulpi("1"....) | 15:57 |
| lkcl | although... | 15:57 |
| lkcl | sigh | 15:57 |
| lkcl | i don't think the USB3300 is properly ULPI, but UTMI | 15:57 |
| lkcl | ULPI is DDR (double data rate) and the pincount for data buses is 4 (UTMI is 8) | 15:58 |
| lkcl | datasheets. | 15:58 |
| lkcl | datasheets need to go into ngi_router.py towards the end | 15:58 |
| lkcl | so that they end up in the markdown file | 15:58 |
| octavius | How should datasheet URLs be included? as a variable or a print statement? | 15:59 |
| lkcl | like the others | 16:00 |
| lkcl | see m_class.py for one of the larger ones | 16:00 |
| lkcl | 1 sec | 16:00 |
| octavius | ok will do | 16:00 |
| lkcl | urrr | 16:00 |
| lkcl | apparently i have it in the template for the mdwn | 16:00 |
| lkcl | doh | 16:00 |
| lkcl | grep the source for "datasheets" | 16:01 |
| octavius | so what do the "c_" and "m_" prefixes mean ("c_class.py" and "m_class.py")? M for module? | 16:02 |
| lkcl | IIT Madras Shakti Project prefixes | 16:03 |
| lkcl | mobile class | 16:03 |
| lkcl | embedded class | 16:03 |
| lkcl | industrial class | 16:03 |
| octavius | I don't see "e_class" | 16:03 |
| lkcl | not important | 16:05 |
| lkcl | hmmm... the USB3300 is 8-way bi-directional | 16:06 |
| lkcl | whereas the TUSB1210 is 4-pin TX DDR, 4-in RX DDR | 16:06 |
| octavius | yeah, the direction is specified by USB3300 | 16:06 |
| lkcl | odd | 16:06 |
| lkcl | where the heck have i seen DDR?? | 16:08 |
| lkcl | it was on the Allwinner A20 i'm sure | 16:08 |
| lkcl | TUSB1210 is likewise 8-bit | 16:08 |
| lkcl | ST's ULPI as well https://www.st.com/en/interfaces-and-transceivers/stulpi01a.html | 16:09 |
| octavius | base.py and c_class.py both write the "# Reference Datasheets", however I don't see how the datasheet string can be adjusted on a per-project basis. Should I just append the new datasheets to base.py? | 16:11 |
| lkcl | yes go for it | 16:11 |
| lkcl | use the links at https://ftp.libre-soc.org | 16:12 |
| lkcl | ahh NXP do a DDR ULPI. ah ha! it _is_ part of the spec | 16:12 |
| lkcl | hmm but they are max 1.9v. arse | 16:13 |
| lkcl | ah ha! | 16:15 |
| lkcl | ISP1504 | 16:15 |
| lkcl | arse. | 16:16 |
| lkcl | but no DDR | 16:16 |
| octavius | I'm a little confused why you mention DDR with the USB phy. Is ULPI compatible with DDR? | 16:17 |
| lkcl | https://media.digikey.com/pdf/Data%20Sheets/NXP%20PDFs/SAF1508BET_July23,2012_DS.pdf | 16:20 |
| lkcl | two last possibilities to explore then screw it | 16:21 |
| lkcl | https://www.digikey.co.uk/en/products/detail/microchip-technology/USB3318-CP/4755388 | 16:21 |
| lkcl | https://www.digikey.co.uk/en/products/detail/stmicroelectronics/STULPI01BTBR/2772231 | 16:21 |
| lkcl | gaah i used to do this kind of fast research all the time | 16:22 |
| lkcl | STULPI01A, hooraaaay | 16:24 |
| lkcl | 3.3v (actually 3.6 max) Digital IO | 16:25 |
| lkcl | and it's capable of 4-pin bi-directional DDR | 16:25 |
| lkcl | hooraaay | 16:25 |
| lkcl | b | 16:25 |
| lkcl | out damn time | 16:25 |
| octavius | Ah, Double-Data Rate just means data coming on both edges of the clock, doesn't specifically mean DDR RAM (that's the only association I had) | 16:28 |
| lkcl | RAM buses are also double data rate | 16:28 |
| octavius | Yeah, I didn't realise that other buses come in a DDR flavour as well | 16:29 |
| octavius | although it makes sense | 16:29 |
| lkcl | this one https://ftp.libre-soc.org/STULPI01BTBR.en.CD00201527.pdf | 16:30 |
| lkcl | opentapeoutdev conference in... 1.5 hours? | 16:31 |
| octavius | correct | 16:31 |
| lkcl | awesome | 16:32 |
| octavius | Do you have the LAN PHY datasheet on ftp? | 16:32 |
| lkcl | where's the link (youtube)? | 16:32 |
| lkcl | yes. | 16:32 |
| lkcl | LAN PHY? ah no | 16:32 |
| lkcl | 1 sec | 16:32 |
| octavius | https://www.youtube.com/watch?v=wvPZREaP7E0 | 16:32 |
| octavius | Link to the stream day 1 | 16:32 |
| lkcl | https://ftp.libre-soc.org/1912111437_Realtek-Semicon-RTL8211F-CG_C187932.pdf | 16:36 |
| octavius | Thanks, I couldn't find it on their website: https://www.realtek.com/en/products/communications-network-ics/item/rtl8211f-i-cg | 16:36 |
| lkcl | fantastic | 16:36 |
| lkcl | finding china-sourced datasheets is a f*****g nuisance | 16:36 |
| octavius | XD | 16:36 |
| lkcl | you often have to go to things like sparkfun or adafruit | 16:36 |
| octavius | or look at dodgy datasheet sites | 16:37 |
| lkcl | fortunately i spent 5+ years doing this so know... yeah | 16:37 |
| octavius | which usb phy did you decide on? | 16:38 |
| octavius | usb3300 | 16:38 |
| octavius | ? | 16:38 |
| lkcl | the RTL8211 doesn't seem to have collision | 16:39 |
| lkcl | STULPI01A | 16:39 |
| lkcl | although if we fit 12 pins the USB3300 can be used fine | 16:39 |
| lkcl | nice. TXDLY and RXDLY add 2ns timing delay to clock xmit / rx | 16:41 |
| octavius | Do we need a delay? | 16:42 |
| lkcl | so if you screw up inside your ASIC you can botch-fix it | 16:42 |
| octavius | hahahaha | 16:42 |
| octavius | Also, I don't see the difference in USB3300 and STULPI01A ULPI interfaces (same 12 pins). | 16:44 |
| octavius | Can you use half the data lines or something? | 16:44 |
| tplaten | I'm currently testing MTSPR and MFSPR. Those instructions get issued to the mmu/fsm but issuer.insn_done never goes 1 | 16:54 |
| lkcl | tplaten, look at how the DIV FSM works. the code is unfinished so it is unlikely to be setting ready/valid signalling | 17:48 |
| octavius | Perhaps a noobie question, but what does the [m] suffix mean after some people's usernames? | 17:58 |
| jn | it usually means someone is joining from Matrix | 17:58 |
| jn | (as in https://matrix.org/) | 17:58 |
| octavius | thanks, I had a hunch | 17:59 |
| octavius | but wasn't sure | 17:59 |
| tplaten | I first thaught about gender | 17:59 |
| tplaten | No its matrix | 17:59 |
| tplaten | As there is no [f] or [nb] | 18:00 |
| jn | the OpenTapeout conference is starting NOW (livestream @ https://www.youtube.com/watch?v=wvPZREaP7E0) | 18:01 |
| octavius | ^^^^ | 18:01 |
| Veera[m] | Did anyone used symbiflow-install and got benefit? Asking for personal satisfaction for work! | 23:32 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!