| *** lx0 is now known as lxo | 00:26 | |
| programmerjake | my first pull request to Rust's standard library: https://github.com/rust-lang/rust/pull/83917 | 08:18 |
|---|---|---|
| lkcl | programmerjake, that's great - i do have to ask, how does it help the Libre-SOC Project? | 09:43 |
| lkcl | is it something that is related to development of Kazan? | 09:43 |
| programmerjake | not related to kazan in particular ... it's a general utility function that works with all iterators. | 10:03 |
| programmerjake | mostly just posted here cuz I wrote it and it's somewhat interesting | 10:04 |
| lkcl | nice | 10:27 |
| lkcl | it's quite something to contribute to a big project. i had the same feeling working on samba | 10:28 |
| lkcl | we do however need more input from you on this project. we are extremely short on people and have limited time where NLnet PET grants will no longer be available (end of this year) | 10:29 |
| programmerjake | yeah, sorry, keep getting distracted... virtual machines with llvm backends and all... :) | 10:35 |
| lkcl | :) | 10:36 |
| programmerjake | well, ttyl, see you at the meeting! gotta get some sleep. | 10:39 |
| cesar[m]1 | Is it allowed to load src/dst step with a value greater than or equal to VL? If so, the loop termination condition must be step >= VL, not just step == VL. | 11:48 |
| lkcl | cesar[m]1, no it isn't allowed. strictly speaking it should be an illegal instruction exception, treating this as a Sub-PC, it is as if executing something out of memory bounds | 12:08 |
| cesar[m]1 | Got it. | 12:10 |
| cesar[m]1 | I guess setting step=VL is allowed, it's the same as setting VL=0. It's setting step > VL which isn't allowed. | 12:49 |
| cesar[m]1 | In fact, the vector instruction skip loop on Fetch could be VL==src/dst step, instead of just VL==0. | 12:50 |
| cesar[m]1 | On the other hand, the "predicate mask skip zeros" step already checks for VL==step, and terminates the VL loop. So, we don't really need the VL==0 loop on Fetch anymore. | 12:59 |
| lkcl | the VL==0 test on fetch is there as a reminder that when we go to a pipelined design it can entirely skip that instruction | 13:27 |
| lkcl | in pipelines all information is forward-progressing only | 13:31 |
| lkcl | Chips4Makers: urrrr cocotbext wishbone by wallento is out of date | 15:26 |
| lkcl | and there's no "backwards compatibility support" in cocotb | 15:27 |
| lkcl | cocotb.drivers has moved to a separate repo cocotb_bus | 15:27 |
| lkcl | sigh | 15:27 |
| Chips4Makers | lkcl: I know changes that happened in cocotb but I was busy with something you may be able to guess :) This is for after tape-out. | 15:31 |
| lkcl | :) | 15:34 |
| lkcl | i'd like to try testing the wishbone bus via cocotb | 15:35 |
| lkcl | however now i just realised that cocotbext.wishbone is for co-simulating and it's not actually needed in the test i want to do | 15:36 |
| lkcl | because the unit being tested *actually has* a wishbone memory in it | 15:37 |
| Chips4Makers | lkcl: Yeah, I think you should be able to initialize the memory with a program in it and then let the simulation run. | 15:57 |
| Chips4Makers | I looked myself and the only Wishbone cocotb test I could find is still using cocotbext. | 15:57 |
| Chips4Makers | You can also use the JTAG as Wishbone master if what you want to test if accessible by a JTAG Wishbone master. | 15:58 |
| lkcl | i realised, actually, yes: we aren't testing the wishbone capability of c4m-jtag | 15:59 |
| lkcl | we are simply sending JTAG commands, oh look! they happen to be ones that involve requesting from the black box called "libresoc.v" to return data over a wishbone bus | 15:59 |
| lkcl | the cocotbext.wishbone was for when there *is* no actual wishbone endpoint | 16:00 |
| lkcl | and you need to simulate one (either wb slave or wb master) | 16:01 |
| lkcl | we *do* have one in libresoc.v | 16:01 |
| lkcl | several. | 16:01 |
| lkcl | the peripherals (UART at 0xc000800 or something like that) | 16:01 |
| lkcl | DFF SRAM (at 0x00000 and 0x700) | 16:02 |
| lkcl | etc. etc. | 16:02 |
| lkcl | anyway: that's in. it doesn't _work_ but it's in :) | 16:02 |
| lkcl | https://git.libre-soc.org/?p=soc-cocotb-sim.git;a=commitdiff;h=cde41ed200c5e1c2cfe264a80ed5ebba7c1005a8 | 16:03 |
| Chips4Makers | Yes, cocotbext wishbone is for unit testing subblocks. | 16:03 |
| Chips4Makers | It would be nice though to be able connect some watchers that check if all signaling on the bus conforms to the WB spec. | 16:05 |
| lkcl | yyeah good point | 16:07 |
| lkcl | i need to take a look at the vcd output, see if it's at least functioning. | 16:09 |
| lkcl | might need to do DMI start/stop (stop the core, run "reset") | 16:10 |
| lkcl | i did that here | 16:10 |
| lkcl | https://git.libre-soc.org/?p=libresoc-litex.git;a=blob;f=sim.py;h=3c5a254fcb4da8f847e13538e52af08150344420;hb=1f083d172b74de119dd1524aee00323885a74fc2#l220 | 16:10 |
| lkcl | just not over JTAG - that was direct to DMI. | 16:11 |
| lkcl | used it to enumerate (and print-dump) the entire register file | 16:11 |
| Chips4Makers | lkcl: I added support for prelayout cocotb sim on version with 4K SRAM blocks. I get several warnings of mismatched signals sizes in the verilog which seem suspicious. | 19:43 |
| lkcl | Chips4Makers: let me take a look | 21:06 |
| lkcl | how are those generated? | 21:09 |
| lkcl | also: on the testwb.py i'm getting a lock-up (of iverilog) | 21:10 |
| lkcl | the moment the wb ibus_sel is raised | 21:10 |
| Chips4Makers | What generated ? The VHDL/Verilog simulation models are now part of the c4m-flexmem code. | 21:11 |
| lkcl | ./run_iverilog_ls180.sh is now joined by ./run_iverilog_wb_ls180.sh | 21:12 |
| lkcl | i modified testwb.py to use dut.ls180 | 21:12 |
| lkcl | dut.ls180.test_issuer bypasses the pin pads | 21:13 |
| lkcl | and may not be starting up the ls180.sys_clk properly | 21:13 |
| lkcl | so i took a copy of test.py, called testwb.py | 21:14 |
| lkcl | and modified it to connect to ls180.jtag_* and to ls180.sys_clk/rst | 21:14 |
| lkcl | which means that it should be properly initialising the litex infrastructure, including the wishbone buses and peripherals | 21:15 |
| Chips4Makers | I do have /run_iverilog_wb_ls180.sh but I did not update it. I don't have testwb.py. | 21:22 |
| Chips4Makers | My run of run_iverilog_ls180 with 4K SRAM version: https://nextcloud.stafverhaegen.be/index.php/s/rRGDJtEc5jEpYx2 | 21:32 |
| Chips4Makers | You may need to run clean.sh to see warnings. | 21:32 |
| lkcl | ok great | 21:33 |
| lkcl | i'm currently sorting out jtag_wb__sel | 21:33 |
| Chips4Makers | Also iverilog may not be locked but just very slow. If you don't keep the CPU in reset the simulation is very slow. Would likely be good to get verilator also working. | 21:35 |
| lkcl | ahh ok | 21:35 |
| lkcl | that makes sense | 21:35 |
| lkcl | ahh forgot to add a granularity argument to TAP.add_wishbone | 21:37 |
| Chips4Makers | I did not add because you only read or write JTAG instruction. Thought was that people would add the master to an arbiter that would be able to handle the granularity conversion. | 21:44 |
| Chips4Makers | ..you only have read or write JTAG instruction.. | 21:44 |
| lkcl | at 64-bit width. makes sense | 21:52 |
| lkcl | (or... width-of-bus) | 21:52 |
| lkcl | okaaaay now begins the fun of debugging vcd traces | 21:53 |
| lkcl | i'm currently hand-patching ls180.v with this: | 21:53 |
| lkcl | initial begin | 21:53 |
| lkcl | $dumpfile("ls180.vcd"); | 21:53 |
| lkcl | $dumpvars(0,ls180); | 21:53 |
| lkcl | end | 21:53 |
| lkcl | and it DoesTheJob(tm) under ivv | 21:53 |
| lkcl | Chips4Makers: jtag wb sel and SPBlock 4K SRAM we sorted | 22:07 |
| programmerjake | meeting in few min: cesar lxo klys Daniel Peterson jn__ | 22:58 |
| programmerjake | lkcl ^ | 22:58 |
| lkcl | programmerjake, thx | 23:01 |
| lkcl | we are on. cesar david cole | 23:02 |
| lkcl | maybe refresh if you are "sitting waiting" | 23:02 |
| lxo | calling in | 23:04 |
| danielp3344 | hi | 23:22 |
| danielp3344 | did I miss the meeting? | 23:22 |
| * danielp3344 only has 2 more days of this job, can hardly wait to do some stuff here | 23:23 | |
| cesar[m]1 | Daniel Peterson: The meeting is ongoing. | 23:24 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!