| *** tpb has joined #litex | 00:00 | |
| somlo | futarisIRCcloud: I had considered asciinema, but it would be a PITA to serve a self-sufficient "video" with no external dependencies, from a web server I don't control... | 01:28 |
|---|---|---|
| futarisIRCcloud | I've used it to record to a local file, and just run that through asciicasttogif for a smaller file... | 01:29 |
| somlo | I do like that it's just recording the ascii sequence -- probably orders of magnitude less "bloat" :) | 01:29 |
| somlo | what, make an animated gif? I guess that would pass the "self-sufficient" criterion :) | 01:29 |
| futarisIRCcloud | Yep. j.mp/futaris-riscv-syd19 for a example. | 01:31 |
| somlo | right now it's "fire up simplescreenrecorder; select a rectangle or window; hit record, get an mp4 video" | 01:31 |
| somlo | but I'll have to look into the animated gif thing, it does sound much cooler on the face of it :) | 01:32 |
| futarisIRCcloud | A ~1 minute text video ended up being a 1.6 MB GIF. | 01:32 |
| *** rohitksingh_work has joined #litex | 04:31 | |
| keesj_ | there is also typescript back from the ... 70's ( type script ) control -d to stop and then "cat typescript ; while read i ; do echo $i ; sleep 1 ; done" or perhaps even https://gist.github.com/tg123/6240128 | 11:03 |
| tpb | Title: Bash script to convert typescript to gif Origin from http://blog.fedora-fr.org/metal3d/post/typescript-to-gif · GitHub (at gist.github.com) | 11:03 |
| keesj_ | normally use obs now. add a camera that points to the board, once for my nice face and audio for .. audio | 11:04 |
| keesj_ | else also a tool called recordmydesktop | 11:04 |
| keesj_ | telnet towel.blinkenlights.nl | 11:07 |
| keesj_ | hm it currently ain't working for me | 11:07 |
| *** rohitksingh_work has quit IRC | 13:14 | |
| felix_ | what is the best way to have the data size of a stream element that is used in one core to have a size that isn't fixed, but depends on a build-time instantiation parameter of that core? the problem i'm trying to solve is that depending on the video format the link between the photonsdi core and the gtp transceivers has a different lenght; the width and configuration of the scrambler also depends on this | 15:11 |
| _florent_ | felix_: i'm generally just using a data_width parameter for that, ex: https://github.com/enjoy-digital/litesata/blob/master/litesata/phy/__init__.py#L22 | 18:01 |
| tpb | Title: litesata/__init__.py at master · enjoy-digital/litesata · GitHub (at github.com) | 18:01 |
| _florent_ | this way is similar to parameters in VHDL/Verilog | 18:03 |
| _florent_ | another way is also to pass the lower level modules to higher level modules and deduce higher level parameters from lower level modules | 18:04 |
| somlo | I just noticed libbase/spiflash.c -- addresses there are still "unsigned int", and should probably be "unsigned long" instead... | 18:10 |
| somlo | probably missed a bunch of places I'm not directly using with Rocket (yet)... | 18:11 |
| _florent_ | somlo: thanks, i'll check that | 18:15 |
| felix_ | _florent_: ah, https://github.com/enjoy-digital/litesata/blob/db5d2f7881161ce5b9a10a0ab42555f884b9d7c1/litesata/common.py#L58 answered my question. thx :) | 18:40 |
| tpb | Title: litesata/common.py at db5d2f7881161ce5b9a10a0ab42555f884b9d7c1 · enjoy-digital/litesata · GitHub (at github.com) | 18:40 |
| felix_ | and https://github.com/enjoy-digital/litesata/blob/db5d2f7881161ce5b9a10a0ab42555f884b9d7c1/litesata/phy/k7sataphy.py#L345 | 18:40 |
| tpb | Title: litesata/k7sataphy.py at db5d2f7881161ce5b9a10a0ab42555f884b9d7c1 · enjoy-digital/litesata · GitHub (at github.com) | 18:40 |
| _florent_ | felix_: ok good, also just for info, i'm trying to have generic transceivers wrappers here: https://github.com/enjoy-digital/liteiclink/tree/master/liteiclink/transceiver | 18:51 |
| tpb | Title: liteiclink/liteiclink/transceiver at master · enjoy-digital/liteiclink · GitHub (at github.com) | 18:51 |
| _florent_ | the aim is to be able to be flexible enough to be reused by cores requiring transceivers | 18:52 |
| felix_ | sounds good; will have a look when i've finished the higher levels of photonsdi | 18:53 |
| somlo | \o/ http://www.contrib.andrew.cmu.edu/~somlo/BTCP/LitexRocketNexys4ddrLinux.mp4 | 20:25 |
| somlo | need to figure out what the deal is with BBL's alleged ability to trap and emulate floating-point instructions -- busybox (init) was faulting because it *thought* it's runningon rv64imafdc, and was trying to access FP registers | 20:27 |
| somlo | once I got it to compile as rv64imac (no "fd"), it started working | 20:27 |
| _florent_ | somlo: great, congrats | 20:48 |
| somlo | LiteX is the best! :) | 20:50 |
| _florent_ | how much resources is your Rocket SoC using on the nexys4ddr? | 20:55 |
| somlo | _florent_: 15406 total LUTs, of which 12802 for the RocketChip (with mmu, no fpu) -- according to top_utilization_hierarchical.rpt | 22:46 |
| somlo | I also built it for an imaginary ecp5versa (with an 85k fpga), and utilization was somewhere in the 66% | 22:47 |
| somlo | daveshah: ^^ (also, I'd be curious if this could work on a trellis board) | 22:48 |
| daveshah | Yup, I'll have a play | 22:49 |
| daveshah | Incidentally, might be worth trying this PR and synth_ecp5 -abc9 | 22:49 |
| daveshah | https://github.com/YosysHQ/yosys/pull/726 | 22:50 |
| tpb | Title: write_verilog: inline internal cells that are used exactly once by whitequark · Pull Request #726 · YosysHQ/yosys · GitHub (at github.com) | 22:50 |
| daveshah | I was seeing a 25-30% area reduction for a basic Rocket config | 22:50 |
| daveshah | Might just squeeze it into a Versa | 22:50 |
| somlo | cool, I was gearing up to refreshing my local yosys RPM package, I'll give it a spin tomorrow | 22:50 |
| daveshah | Sorry, pasted the wrong PR | 22:52 |
| daveshah | I meant this one https://github.com/YosysHQ/yosys/pulls | 22:52 |
| tpb | Title: Pull Requests · YosysHQ/yosys · GitHub (at github.com) | 22:52 |
| daveshah | Gah, has github mobile changed what it copies | 22:52 |
| daveshah | https://github.com/YosysHQ/yosys/pull/1098 | 22:52 |
| tpb | Title: WIP "abc9" pass for timing-aware techmapping (experimental, FPGA only, no FFs) by eddiehung · Pull Request #1098 · YosysHQ/yosys · GitHub (at github.com) | 22:52 |
| daveshah | That's the one | 22:52 |
| somlo | got it, thanks! | 22:53 |
| daveshah | The plan is to merge this into master soon after the Yosys 0.9 release (which should be in the next few weeks) | 22:55 |
| daveshah | So that there is some kind of stable reference point before a big breaking change | 22:55 |
| somlo | oh, nice, an official yosys release -- might be what it takes to get the Fedora maintainer to refresh the official rpm :) | 22:56 |
| sorear | Has there been any work or discussion about FPGA optimized 64 bit cores (vex based or otherwise)? | 22:58 |
| somlo | I'll definitely take it for a spin first thing tomorrow morning | 22:58 |
| somlo | sorear: not sure about discussion, but as far as rv64* (and as far as I'm aware of), there's Rocket, and there's Ariane | 23:47 |
| somlo | then, if you want an actual full-featured linux distro like Fedora, you'd need support for (at least emulation of) F and D | 23:50 |
| somlo | which I am in the process of wrapping my head around, from a practical standpoint (I get how it ought to work in theory :) ) | 23:50 |
| sorear | before the unleashed boards were generally available a couple people were using xilinx dev boards for software work | 23:53 |
| sorear | the xilinx tools and the rocket FPU interact badly and while it fit, timing was dramatically better with the FPU removed | 23:53 |
| sorear | so I've seen bbl fpu emulation in actual use | 23:53 |
| somlo | IIRC, the original sifive unleashed thing was on a virtex 7 | 23:53 |
| somlo | before they made an ASIC | 23:54 |
| sorear | that was UCB's go-to board before sifive even existed so | 23:54 |
| somlo | but even an artix7 (nexys4ddr) can fit a single FPU-enabled core; I just happen to have a non-negotiable requirement to use F/OSS tools only, which means ECP5, which may or may not end up having enough room for a FPU-enabled core; right now it doesn't, and I'm working on the assumption I'll have to use emulation regardless | 23:56 |
| sorear | well the Rocket FPU is one or two 53x53 multipliers | 23:56 |
| sorear | which are going to be hell until DSP inference works | 23:56 |
| daveshah | Is it the Rocket FPU that basically shoves a load of registers after the whole thing and relies on retiming? | 23:58 |
| daveshah | That's going to be fun to fix even with DSP inference | 23:58 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!