Monday, 2021-11-15

sadoon_albader[mI'm now installing the tools laid out in the HDL Workflow page, excited :D01:15
sadoon_albader[mMost of it I already have though heh01:15
sadoon_albader[mIs it normal for nmigen to fail a few test cases?01:50
sadoon_albader[mGetting 11 failures and 3 errors on both x86_64 devuan 4 (debian 11) and ppc64le also01:51
sadoon_albader[mAlso where am I supposed to get the "/path/to/ieee754fpu/SoftPosit.patch"01:56
lkcldid you use the dev-setup scripts?09:31
lkclit is much quicker09:32
lkclin the ieee754 repository09:34
octaviuslkcl, thanks for the updates to the pinmux code. I've noticed it's gotten a heck of a lot more complex (although nice idea moving pinparse out of the chip-specific module). I was able to view the yosys diagram in the build directory, however will need to look at the original request() method from Platform. I'll need to go for an hour and half, but after I'll continue looking. What should I focus on first? The SVG generation code?10:25
lkclyeah Platform.request - actually ResourceManager.request - is quite straightforward although could use some love in the form of code comments10:51
lkclthe yosys diagram can be shrunk a *lot* by reducing GPIO in dummy down to 410:51
lkclalso note i got "microtest" working again10:52
lkclbut, it is a pinmux test10:53
lkclyes by default try sorting the SVG10:53
lkclhowever if you want to make progress on the JTAG thing try "stage 3" - wiring up say an "input" (set_input) data structure10:54
lkclhere's where the Muxes get created10:56
lkclyou'll need to work out the direction from that10:56
lkclmake liberal use of print statements10:57
sadoon_albader[m<lkcl> "did you use the dev-setup..." <- I'll try following them later today and seeing how it goes12:12
sadoon_albader[mSo far I've got most everything installed except softposit stuff12:13
lkclwe're not interested in (and not going to be using) posits13:28
lkclthe entire 3D GPU industry will need to shift to posits first13:29
lkclotherwise we are burdened with 100+ man-years of compiler and library support work13:29
lkclthat's likely an order of magnitude underestimated if including the gaming industry (etc.) as well13:30
lkcloctavius, when you're back (or see this in IRC logs) i realised, you can't grab the Pins() info in order to find out what got created from what13:45
lkclbecause Pins() creates Scan Register IOConn Records based on pinspec names13:45
lkclbut add_resource self._ports is by *Resource* name13:45
lkclalthough it technically would be possible to back-construct one from the other13:46
sadoon_albader[m<lkcl> "we're not interested in (and not..." <- So I don't need to install softfloat and spfy?14:47
sadoon_albader[mI have everything installed except softfloat and sfpy now on my x86_64 machine and my ppc64le machine, only thing left is my laptop for on the go work15:11
lkclsfpy you will need if you want to run the ieee754 fp unit tests (for several days)15:13
lkclfor which, strictly, there is no need right now15:22
sadoon_albader[mSo I guess I'm all set :D15:24
sadoon_albader[mI wonder if I can run the qemu stuff with KVM acceleration on my talos ii15:25
lkcli don't see why not15:33
octaviuslkcl, read your msg's. Understood very little (I guess Scan Register IOConn Record is I/O/OE signals for a given pin). I accept the mission anyway.16:41
lkcloctavius: :)17:05
lkclIOConn is an "on-demand-created-Record" that can adapt17:05
lkclsee how it says, "if iotype contains I then add I to the layout"17:06
lkcland, "if iotype contains O then add O to the layout"17:06
octaviusIn the layout method (line 197 onwards?)17:08
lkclso the Record will actually contain only core.i and pad.i for IOConn=InType17:09
octaviusah ok17:09
lkclcore.o and pad.o for IoConnType=OutType17:09
lkclobviously, that's variable-length and therefore down in elaborate_ios17:10
lkclthe length of the shift register has to take that into account17:10
lkclit's hellishly confusing because core.i becomes an output as far as JTAG Boundary Scan's perspective is concerned17:11
lkcland core.o becomes an input17:11
lkclor maybe it's the other way round, i get really confused17:11
lkclbut, what you will find is: if you get it wrong, nmigen will produce a "driver conflict error"17:12
lkclso it's actually - should be - impossible - to get it wrong17:12
lkclnote: set_input, you *only* get given an IOConn with core.i and pad.i17:13
lkcl+            m.d.comb += pin.i.eq(io.pad.i)17:15
lkcl+            m.d.comb += io.core.i.eq(pin.i)17:15
lkclthis is a short-circuit17:15
lkclpad is set equal to pin17:15
lkclpin is set equal to core17:15
lkclthis the one that needs to be split17:16
lkcl+            m.d.comb += io.pad.i.eq(self._invert_if(invert, port))17:16
lkcltwo lines only17:16
lkcl       comb += pin.i.eq(SOMETHING1)17:16
lkcl       comb += SOMETHING2.eq(self._invert_if(invert, port)17:16
lkclthere are only 2 possibilities17:16
lkclSOMETHING1 = io.pad.i, SOMETHING2 = io.core.i17:17
lkclSOMETHING2 = io.core.i, SOMETHING2 = io.pad.i17:17
octaviusWhat you're saying is that I can't assign them to eachother, and I need some kind of mux? But what signal will control the mux?17:18
lkcli think17:18
lkclthe mux is already inside JTAG boundary scan17:19
octaviusI put the latest variation in bug 5017:19
octaviusIt fails with an AssertionError17:19
lkclgot it17:21
lkcl-            m.d.comb += pin.i.eq(io.pad.i)17:22
lkcl-            m.d.comb += io.core.i.eq(pin.i)17:22
lkcl+            m.d.comb += pin.i.eq(io.core.i)17:22
octaviusIs there some other magic that needs to be added? Or am I confusing the signals?17:22
lkclhonestly i am guessing just as much as you, here17:22
octaviusBut you're assigning to pin.i twice17:22
octaviusthat would overule the first assignment17:22
lkclgit pull17:23
lkclreally, only a unit test will tell if this is right or not17:24
octaviusDoes this work because the io jtag object internally connects the io.pad and io.core?17:24
lkclthat's its entire purpose17:25
octaviusThe diagram looks promising17:25
lkclto either:17:25
lkcl* directly wire io.pad to io.core17:25
lkclsplit them and (just like in the diagram) connect one to the core SR boundary scan and the other to the pad SR boundary scan17:26
octaviusI guess I can add the same for get_output now17:27
lkclindeed.  except, obviously (i say obviously... i mean "totally dyslexically confusingly retrospectively obviously") with o instead of i17:28
octaviusThat else: shouldnt work17:28
lkclx.eq(y) rather than y.eq(x)17:28
octaviusline 24717:28
lkclwhoops that shouldn't have been in, just the comment17:29
lkclgit pull17:29
octaviusShall I make the change then? or are u editing?17:29
lkcldone already17:29
lkcland it's git so conflicts are resolvable17:29
lkclit's not like Visual Studio where files are "locked"17:30
lkclbtw please do check out PEP817:30
lkclm=Module() should contain spaces17:30
lkclwhen correcting that please do it as a single commit, "whitespace corrections"17:30
lkcli leave that and get_output to you. have to focus on core.py17:31
octaviussure, will do17:31
lkclthx octavius17:32
lkcloctavius, additions look great20:17
lkcli need to do a little bit of thinking20:17
lkclthe $tristate needs to go20:18
lkcland the *actual* output be "not a single $tristate instance" but "actual triple wires named i,o and oe"20:18
octaviusAh, I figured tristate was just tristate output (as was in nmigen
octavius" "not a single $tristate instance" but "actual triple wires named i,o and oe"20:30
octaviusDoes this mean the port will have 3 signals? (i, o, oe)20:30
cesarlkcl: Do you think we will continue accessing the Wishbone bus via JTAG, or we transition to DMI, like Microwatt seems to do?21:08
lkcloctavius: yes.21:34
lkclcesar, i don't honestly know. if switching to DMI then some DMI registers need to be defined, followed by DMI connecting to wishbone, followed by adding a means for JTAG to understand the new DMI registers21:35
lkclall of which seems quite a lot of work :)21:35
lkclthe end result of which is: as far as JTAG is concerned, there is no functional API change!21:35
lkclcesar, i am currently doing the write-hazard vector set/clear logic, in core.py21:41
lkcli have deliberately made the vector be *actual* regfile instances, even though they are 1 bit "registers"21:42
lkcleven given them the exact same names as the original regfiles, and the exact same number and named ports21:42
lkclthat way, in the connect_rdports and connect_wrports functions, i can use the same dictionaries-of-regfile-ports to go, "oh, you want to write the result to such-and-such regfile? let me clear the corresponding vector bit for you"21:43
lkcland that can be done simply by looking up the *exact* same named bit-vector-regfile-port-name as the key used to look up the regfile port being written to21:44
cesarDon't all regfiles have a 1-clock latency?21:45
cesar... for reading?21:45
lkclthere is a combinatorial bypass (called "operand forwarding")21:47
lkclif a read is detected at the same time as a write, on the same cycle, the read returns the value being written to *in that cycle*21:48

Generated by 2.17.1 by Marius Gedminas - find it at!