| sadoon_albader[m | I'm now installing the tools laid out in the HDL Workflow page, excited :D | 01:15 |
|---|---|---|
| sadoon_albader[m | Most of it I already have though heh | 01:15 |
| sadoon_albader[m | Is it normal for nmigen to fail a few test cases? | 01:50 |
| sadoon_albader[m | Getting 11 failures and 3 errors on both x86_64 devuan 4 (debian 11) and ppc64le also | 01:51 |
| sadoon_albader[m | Also where am I supposed to get the "/path/to/ieee754fpu/SoftPosit.patch" | 01:56 |
| lkcl | did you use the dev-setup scripts? | 09:31 |
| lkcl | it is much quicker | 09:32 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=hdl-dev-repos;hb=HEAD | 09:32 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=mk-deb-chroot;hb=HEAD | 09:33 |
| lkcl | in the ieee754 repository | 09:34 |
| lkcl | https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=SoftPosit.patch;hb=HEAD | 09:42 |
| octavius | lkcl, 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 |
| lkcl | yeah Platform.request - actually ResourceManager.request - is quite straightforward although could use some love in the form of code comments | 10:51 |
| lkcl | the yosys diagram can be shrunk a *lot* by reducing GPIO in dummy down to 4 | 10:51 |
| lkcl | also note i got "microtest" working again | 10:52 |
| lkcl | but, it is a pinmux test | 10:53 |
| lkcl | yes by default try sorting the SVG | 10:53 |
| lkcl | however if you want to make progress on the JTAG thing try "stage 3" - wiring up say an "input" (set_input) data structure | 10:54 |
| lkcl | here's where the Muxes get created | 10:56 |
| lkcl | https://git.libre-soc.org/?p=c4m-jtag.git;a=blob;f=c4m/nmigen/jtag/tap.py;h=1f3d424cbd7451c0434e0c71168f5aa0935af860;hb=c2bf4810f9f91ced7fcda777b92b86ab353da288#l585 | 10:56 |
| lkcl | you'll need to work out the direction from that | 10:56 |
| lkcl | make liberal use of print statements | 10:57 |
| sadoon_albader[m | <lkcl> "did you use the dev-setup..." <- I'll try following them later today and seeing how it goes | 12:12 |
| sadoon_albader[m | So far I've got most everything installed except softposit stuff | 12:13 |
| lkcl | we're not interested in (and not going to be using) posits | 13:28 |
| lkcl | the entire 3D GPU industry will need to shift to posits first | 13:29 |
| lkcl | otherwise we are burdened with 100+ man-years of compiler and library support work | 13:29 |
| lkcl | that's likely an order of magnitude underestimated if including the gaming industry (etc.) as well | 13:30 |
| lkcl | octavius, 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 what | 13:45 |
| lkcl | because Pins() creates Scan Register IOConn Records based on pinspec names | 13:45 |
| lkcl | but add_resource self._ports is by *Resource* name | 13:45 |
| lkcl | doh | 13:45 |
| lkcl | although it technically would be possible to back-construct one from the other | 13: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[m | I 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 work | 15:11 |
| lkcl | sfpy you will need if you want to run the ieee754 fp unit tests (for several days) | 15:13 |
| lkcl | for which, strictly, there is no need right now | 15:22 |
| sadoon_albader[m | So I guess I'm all set :D | 15:24 |
| sadoon_albader[m | I wonder if I can run the qemu stuff with KVM acceleration on my talos ii | 15:25 |
| lkcl | i don't see why not | 15:33 |
| octavius | lkcl, 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 |
| lkcl | octavius: :) | 17:05 |
| lkcl | IOConn is an "on-demand-created-Record" that can adapt | 17:05 |
| lkcl | https://git.libre-soc.org/?p=c4m-jtag.git;a=blob;f=c4m/nmigen/jtag/tap.py;h=1f3d424cbd7451c0434e0c71168f5aa0935af860;hb=c2bf4810f9f91ced7fcda777b92b86ab353da288#l163 | 17:06 |
| lkcl | see how it says, "if iotype contains I then add I to the layout" | 17:06 |
| lkcl | and, "if iotype contains O then add O to the layout" | 17:06 |
| lkcl | ? | 17:06 |
| octavius | In the layout method (line 197 onwards?) | 17:08 |
| lkcl | yes | 17:08 |
| lkcl | so the Record will actually contain only core.i and pad.i for IOConn=InType | 17:09 |
| octavius | ah ok | 17:09 |
| lkcl | core.o and pad.o for IoConnType=OutType | 17:09 |
| lkcl | etc | 17:09 |
| lkcl | etc | 17:09 |
| lkcl | etc | 17:09 |
| lkcl | etc | 17:09 |
| lkcl | obviously, that's variable-length and therefore down in elaborate_ios | 17:10 |
| lkcl | https://git.libre-soc.org/?p=c4m-jtag.git;a=blob;f=c4m/nmigen/jtag/tap.py;h=1f3d424cbd7451c0434e0c71168f5aa0935af860;hb=c2bf4810f9f91ced7fcda777b92b86ab353da288#l548 | 17:10 |
| lkcl | the length of the shift register has to take that into account | 17:10 |
| lkcl | it's hellishly confusing because core.i becomes an output as far as JTAG Boundary Scan's perspective is concerned | 17:11 |
| lkcl | and core.o becomes an input | 17:11 |
| lkcl | or maybe it's the other way round, i get really confused | 17:11 |
| lkcl | but, what you will find is: if you get it wrong, nmigen will produce a "driver conflict error" | 17:12 |
| lkcl | so it's actually - should be - impossible - to get it wrong | 17:12 |
| lkcl | note: set_input, you *only* get given an IOConn with core.i and pad.i | 17: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 |
| lkcl | this is a short-circuit | 17:15 |
| lkcl | pad is set equal to pin | 17:15 |
| lkcl | pin is set equal to core | 17:15 |
| lkcl | this the one that needs to be split | 17:16 |
| lkcl | + m.d.comb += io.pad.i.eq(self._invert_if(invert, port)) | 17:16 |
| lkcl | two lines only | 17:16 |
| lkcl | comb += pin.i.eq(SOMETHING1) | 17:16 |
| lkcl | comb += SOMETHING2.eq(self._invert_if(invert, port) | 17:16 |
| lkcl | there are only 2 possibilities | 17:16 |
| lkcl | SOMETHING1 = io.pad.i, SOMETHING2 = io.core.i | 17:17 |
| lkcl | or | 17:17 |
| lkcl | SOMETHING2 = io.core.i, SOMETHING2 = io.pad.i | 17:17 |
| octavius | What 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 |
| lkcl | i think | 17:18 |
| lkcl | no | 17:18 |
| lkcl | the mux is already inside JTAG boundary scan | 17:19 |
| octavius | I put the latest variation in bug 50 | 17:19 |
| octavius | It fails with an AssertionError | 17:19 |
| lkcl | got it | 17: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 |
| octavius | Is there some other magic that needs to be added? Or am I confusing the signals? | 17:22 |
| lkcl | honestly i am guessing just as much as you, here | 17:22 |
| octavius | But you're assigning to pin.i twice | 17:22 |
| octavius | that would overule the first assignment | 17:22 |
| lkcl | https://git.libre-soc.org/?p=pinmux.git;a=commitdiff;h=3906235b8a5f46004971e42e75f4fb9c44722b18 | 17:22 |
| lkcl | git pull | 17:23 |
| lkcl | https://git.libre-soc.org/?p=pinmux.git;a=blob;f=src/spec/testing_stage1.py;h=65c280ac61d97681a493a456da7b9b7ffaccf90f;hb=3906235b8a5f46004971e42e75f4fb9c44722b18#l261 | 17:23 |
| lkcl | really, only a unit test will tell if this is right or not | 17:24 |
| octavius | Does this work because the io jtag object internally connects the io.pad and io.core? | 17:24 |
| lkcl | yeeeees | 17:25 |
| lkcl | that's its entire purpose | 17:25 |
| octavius | The diagram looks promising | 17:25 |
| lkcl | to either: | 17:25 |
| lkcl | * directly wire io.pad to io.core | 17:25 |
| lkcl | OR | 17:25 |
| lkcl | split them and (just like in the diagram) connect one to the core SR boundary scan and the other to the pad SR boundary scan | 17:26 |
| octavius | So....profit? | 17:26 |
| octavius | I guess I can add the same for get_output now | 17:27 |
| lkcl | indeed. except, obviously (i say obviously... i mean "totally dyslexically confusingly retrospectively obviously") with o instead of i | 17:28 |
| octavius | That else: shouldnt work | 17:28 |
| lkcl | x.eq(y) rather than y.eq(x) | 17:28 |
| octavius | line 247 | 17:28 |
| lkcl | whoops that shouldn't have been in, just the comment | 17:29 |
| lkcl | git pull | 17:29 |
| octavius | Shall I make the change then? or are u editing? | 17:29 |
| lkcl | done already | 17:29 |
| octavius | thanks | 17:29 |
| lkcl | and it's git so conflicts are resolvable | 17:29 |
| lkcl | it's not like Visual Studio where files are "locked" | 17:30 |
| lkcl | btw please do check out PEP8 | 17:30 |
| lkcl | m=Module() should contain spaces | 17:30 |
| lkcl | when correcting that please do it as a single commit, "whitespace corrections" | 17:30 |
| lkcl | i leave that and get_output to you. have to focus on core.py | 17:31 |
| octavius | sure, will do | 17:31 |
| lkcl | thx octavius | 17:32 |
| lkcl | octavius, additions look great | 20:17 |
| lkcl | i need to do a little bit of thinking | 20:17 |
| lkcl | the $tristate needs to go | 20:18 |
| lkcl | and the *actual* output be "not a single $tristate instance" but "actual triple wires named i,o and oe" | 20:18 |
| octavius | Ah, I figured tristate was just tristate output (as was in nmigen plat.py) | 20:22 |
| octavius | " "not a single $tristate instance" but "actual triple wires named i,o and oe" | 20:30 |
| octavius | Does this mean the port will have 3 signals? (i, o, oe) | 20:30 |
| cesar | lkcl: Do you think we will continue accessing the Wishbone bus via JTAG, or we transition to DMI, like Microwatt seems to do? | 21:08 |
| lkcl | octavius: yes. | 21:34 |
| lkcl | cesar, 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 registers | 21:35 |
| lkcl | all of which seems quite a lot of work :) | 21:35 |
| lkcl | the end result of which is: as far as JTAG is concerned, there is no functional API change! | 21:35 |
| lkcl | cesar, i am currently doing the write-hazard vector set/clear logic, in core.py | 21:41 |
| lkcl | i have deliberately made the vector be *actual* regfile instances, even though they are 1 bit "registers" | 21:42 |
| lkcl | even given them the exact same names as the original regfiles, and the exact same number and named ports | 21:42 |
| lkcl | that 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 |
| lkcl | and 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 to | 21:44 |
| cesar | Don't all regfiles have a 1-clock latency? | 21:45 |
| cesar | ... for reading? | 21:45 |
| lkcl | there is a combinatorial bypass (called "operand forwarding") | 21:47 |
| lkcl | if 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 irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!