| *** tpb has joined #timvideos | 00:00 | |
| cr1901_modern | mithro: Also, I think there needs to be a linker.ld in litex_buildenv that accounts for "no main_ram" region? I'm not sure the best way to go about adding this though.. | 00:09 |
|---|---|---|
| mithro | cr1901_modern: Look at the MimasV2 set up? | 00:10 |
| mithro | Oh wait no main_ram == no external DDR ram? | 00:10 |
| cr1901_modern | yes | 00:10 |
| mithro | cr1901_modern: Added some comments to the pull request and cleaned it up slightly :-P | 00:11 |
| cr1901_modern | cool, will take a look | 00:11 |
| cr1901_modern | and flashboot in litex already accounts for no "main_ram" region, but it uses a C define for this. Idk how to notify a linker script about this (maybe there's a conditional ifdef for GNU ld?) | 00:12 |
| cr1901_modern | (Of course, the firmware in litex-buildenv is just a copy of HDMI2USB at present. And tinyfpga can't run that. But I assume this will change in the future). | 00:13 |
| CarlFK | mithro: what sort of ps1 project? | 00:21 |
| mithro | Small PCB board | 00:21 |
| CarlFK | oh great. I already got yelled at about the last pcb board you sent me ;) | 00:21 |
| CarlFK | something about "why are these parts so small?!" | 00:21 |
| mithro | This wouldn't be that small | 00:22 |
| cr1901_modern | mithro: All questions addressed | 00:26 |
| CarlFK | mithro: try to get it here by next mon, which is when I'll be in for Nerp, which has the most EE sorts hanging around | 00:26 |
| CarlFK | mithro: why does v4l2-ctl say the Opsis is 1024/768? http://paste.ubuntu.com/p/ZZbXfMQm5v/ | 00:27 |
| mithro | cr1901_modern: Except you didn't give me any numbers :-P | 00:27 |
| tpb | Title: Ubuntu Pastebin (at paste.ubuntu.com) | 00:27 |
| cr1901_modern | I don' | 00:27 |
| cr1901_modern | t feel like waiting an hour to try all combinations | 00:27 |
| mithro | cr1901_modern: An hour? | 00:28 |
| cr1901_modern | mithro: Nevermind... | 00:29 |
| mithro | cr1901_modern: It should be pretty easy to compare minimal verse lite configuration in LUTs right? | 00:29 |
| cr1901_modern | Yea, hold on, I misunderstood | 00:30 |
| benreynwar | I'm about to do some experimenting with writing unit tests for migen modules. Does anyone have any migen modules that could do with unit tests? That way I don't have to write a module just to have something to test. | 00:31 |
| mithro | benreynwar: Yes! | 00:32 |
| mithro | benreynwar: Pretty much nothing at https://github.com/enjoy-digital/litex/tree/master/litex/soc/cores has many tests? | 00:32 |
| tpb | Title: litex/litex/soc/cores at master · enjoy-digital/litex · GitHub (at github.com) | 00:32 |
| mithro | benreynwar: The spiflash stuff might be a good thing to try? https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/spi_flash.py | 00:33 |
| tpb | Title: litex/spi_flash.py at master · enjoy-digital/litex · GitHub (at github.com) | 00:33 |
| benreynwar | Sweet. I'm trying to decide whether cocotb, migen or migen/verilator makes most sense, so I'll pick one of the cores and try all three ways. | 00:34 |
| mithro | benreynwar: I would love to see an example on a real core which does all three? | 00:37 |
| mithro | benreynwar: There is some example tests here -> https://github.com/enjoy-digital/litex/blob/master/test/test_gearbox.py | 00:38 |
| tpb | Title: litex/test_gearbox.py at master · enjoy-digital/litex · GitHub (at github.com) | 00:38 |
| cr1901_modern | mithro: https://github.com/enjoy-digital/litex/pull/95#discussion_r214765200 | 00:39 |
| tpb | Title: Add lm32 "lite" variant, remove mult/div from "minimal" and update compiler flags accordingly. by cr1901 · Pull Request #95 · enjoy-digital/litex · GitHub (at github.com) | 00:39 |
| mithro | cr1901_modern: The reason I ask, is I care about the iCE40 UP5K | 00:40 |
| mithro | minimal -- Number of cells: 5166 lite -- Number of cells: 5897 | 00:41 |
| mithro | right? | 00:41 |
| cr1901_modern | Many of those will be combined into ICESTORM_LCs though | 00:42 |
| mithro | cr1901_modern: Yeah - I just realized that... | 00:42 |
| mithro | cr1901_modern: Can you get arachne or nextpnr to output ICESTORM_LC counts? | 00:42 |
| cr1901_modern | Since nextpnr actually lists ICESTORM_LC usages though, I'll disable the PLL for a bit (it crashes nextpnr) and see what nextpnr says. | 00:42 |
| cr1901_modern | I don't think arachne says | 00:43 |
| mithro | cr1901_modern: Please log a bug report for nextpnr if you haven't already | 00:43 |
| mithro | SB_RAM40_4K 25 verse SB_RAM40_4K 31 ? | 00:43 |
| cr1901_modern | cache | 00:43 |
| cr1901_modern | I'll file a report when I have a chance to minimize it | 00:43 |
| mithro | cr1901_modern: What is using the 25 in the minimal config? | 00:44 |
| cr1901_modern | mostly block RAM | 00:44 |
| cr1901_modern | (10kb of Block RAM) | 00:44 |
| cr1901_modern | err, SRAM* | 00:44 |
| mithro | benreynwar: https://github.com/enjoy-digital/litex/tree/master/litex/gen/sim | 00:45 |
| tpb | Title: litex/litex/gen/sim at master · enjoy-digital/litex · GitHub (at github.com) | 00:45 |
| mithro | benreynwar: You should have a play around with SimPlatform (https://github.com/enjoy-digital/litex/blob/master/litex/boards/platforms/sim.py) | 00:46 |
| tpb | Title: litex/sim.py at master · enjoy-digital/litex · GitHub (at github.com) | 00:46 |
| mithro | cr1901_modern: Do you remember a specification a wrote a long time ago about improvements I wanted to the SPI stuff? | 00:47 |
| cr1901_modern | Yes, it's somewhere in my google docs | 00:49 |
| mithro | cr1901_modern: I can't find it :-P | 01:02 |
| cr1901_modern | https://docs.google.com/document/d/1l7wQvZ-wZv0lz0AThDUr-SG6JwArtYDg8KXhN4wrUNY This one? | 01:02 |
| tpb | Title: SPI flash xmodem upload in firmware (cr1901) - Google Docs (at docs.google.com) | 01:02 |
| mithro | cr1901_modern: Oh btw -> https://docs.google.com/document/d/11uMIDI5HozuPZAIdIKmJmYP0BKjXn760Y4itEllbdtA/edit | 01:02 |
| tpb | Title: Google Docs - create and edit documents online, for free. (at docs.google.com) | 01:02 |
| mithro | cr1901_modern: Nope! | 01:03 |
| cr1901_modern | Requested access. And remind me to check later, I'm a bit preoccupied right now | 01:03 |
| mithro | cr1901_modern: and https://docs.google.com/spreadsheets/d/1pNunBJX46jp6ClPFZA29GhlXJmb9lnG9_BEVej7XxL4/edit#gid=1482077032 | 01:05 |
| tpb | Title: Google Sheets - create and edit spreadsheets online, for free. (at docs.google.com) | 01:06 |
| cr1901_modern | Also requested access :) | 01:06 |
| mithro | cr1901_modern: They are public, so I'm unsure why you don't have access... | 01:07 |
| mithro | Public on the web - Anyone on the Internet can find and comment | 01:07 |
| cr1901_modern | This is a brave thing you're trying to do :) | 01:08 |
| tinyfpga | mithro: they aren’t public documents, google docs won’t let me view them | 01:11 |
| mithro | Google is lieing to me then... | 01:11 |
| tinyfpga | mithro: by the way, the new USB core easily meets timing | 01:12 |
| cr1901_modern | >Google is lieing to me then... | 01:12 |
| cr1901_modern | Nah... too easy | 01:12 |
| tinyfpga | mithro: almost everything is in a much slower clock domain, and the “fast” 48MHz domain has very little left in it | 01:12 |
| cr1901_modern | Can the core portion meet 32Mhz? | 01:13 |
| mithro | Just unshared and reshared - reload | 01:13 |
| cr1901_modern | tinyfpga: 32MHz is the target I'm trying to meet for the full SoC | 01:13 |
| tinyfpga | cr1901_modern: it should be able to meet 32MHz | 01:14 |
| tinyfpga | cr1901_modern: the current bootloader all | 01:14 |
| tinyfpga | ...runs at 48MHz | 01:14 |
| cr1901_modern | cool | 01:15 |
| *** Char0n has joined #timvideos | 01:15 | |
| *** Char0n has quit IRC | 01:16 | |
| mithro | cr1901_modern: Guess I just rewrote it -> https://docs.google.com/document/d/1JZ7pU7roOaJwsv_LlXDKpWrLMSp254-tuof5KIFcC-I/edit?usp=sharing | 01:27 |
| tpb | Title: LiteX SPI Flash Improvements - Google Docs (at docs.google.com) | 01:27 |
| mithro | benreynwar: Might be worth looking at too | 01:27 |
| cr1901_modern | Okay I don't remember anything like this | 01:28 |
| cr1901_modern | except interestingly enough, something about using"tinyfpga data config" rings a bell | 01:28 |
| cr1901_modern | tinyfpga: So at this point, tinyfpga B2 will be in litex-buildenv pending my lm32 changes being committed, and figuring out how to get the default firmware in litex-buildenv to run strictly from ROM | 01:28 |
| mithro | cr1901_modern: ROM or SPI Flash? | 01:34 |
| shorne | mithro: sorry, I have been off and on over the weekend, staying home with a sick kid the last 2 days | 01:35 |
| shorne | I just replied to your mail | 01:35 |
| mithro | shorne: No worries | 01:35 |
| cr1901_modern | mithro: I meant SPIFlash; the linker section is called "rom" | 01:35 |
| mithro | cr1901_modern: Okay, then copy the MimasV2 I guess? | 01:44 |
| cr1901_modern | the Mimasv2 loads it's program into SDRAM before running it | 01:44 |
| cr1901_modern | and the linker script present in litex-buildenv assumes "main_ram" exists | 01:45 |
| mithro | Oh, sorry - your right | 01:46 |
| cr1901_modern | and my problem right now is: Idk if it's possible to conditionally define a single linker script based on what regions are available | 01:47 |
| cr1901_modern | litex and misoc BIOS don't run into this problem b/c your SoC _has_ to have "rom" and "sram" regions; the python code will error out if you don't | 01:48 |
| cr1901_modern | but there's no such requirement for main RAM | 01:48 |
| cr1901_modern | Maybe a separate linker script is the best option. But how do I tell the build system which version to use? | 01:49 |
| cr1901_modern | https://github.com/enjoy-digital/litex/commit/85308672d396111a07c70e0704c5c4191826d4ac Also, off-topic, but: WOW what in the world is the rationale for _this_ in riscv-land?! | 01:50 |
| tpb | Title: software/bios/linker: revert data section since required by RISC-V co… · enjoy-digital/litex@8530867 · GitHub (at github.com) | 01:50 |
| mithro | cr1901_modern: Okay | 01:54 |
| *** Guest45420 has joined #timvideos | 02:14 | |
| *** Guest45420 has quit IRC | 02:17 | |
| *** puck is now known as puck_ | 02:32 | |
| cr1901_modern | mithro: My suggestion re: swapping linker files is to either: | 02:43 |
| cr1901_modern | 1. Create a new soc member, a la soc.flash_boot_address, that indicates whether main_ram is present _or_ whether executing from flash is desired. | 02:43 |
| cr1901_modern | 2. Automatically detect whether flash_boot_address and main_ram regions are defined. | 02:43 |
| cr1901_modern | 3. Gate based on CPU variant. >> | 02:43 |
| cr1901_modern | In all cases, we then set a Makefile variable "COPY_FROM_FLASH", which can be used to choose the linker script | 02:43 |
| cr1901_modern | /minddump | 02:43 |
| cr1901_modern | I think #2 is best b/c it's in line w/ what litex (and misoc) does; if both flash_boot_address and main_ram regions are defined, we automatically copy to main RAM via a compile-time ifdef | 02:45 |
| mithro | cr1901_modern: Sounds reasonable to me? | 02:47 |
| cr1901_modern | we already are tied to gnu make unfortunately, so an ifdef isn't going to be a big deal :P | 02:47 |
| cr1901_modern | mithro: Cool, can we work out the kinks of the current PR so I can pull master and work on this PR next? | 02:47 |
| mithro | cr1901_modern: Sure.... | 03:02 |
| mithro | cr1901_modern: So, what do we need to do? | 03:14 |
| cr1901_modern | mithro: Accept the PR :) | 03:15 |
| cr1901_modern | So I'm no longer blocked on it | 03:16 |
| cr1901_modern | Unless you have other complaints | 03:16 |
| cr1901_modern | Oh, and mark all the conversations as resolved | 03:16 |
| cr1901_modern | if my responses are to your satisfaction. | 03:16 |
| mithro | cr1901_modern: Okay, merged | 03:19 |
| mithro | cr1901_modern: We can continue to tweak later | 03:19 |
| cr1901_modern | Excellent. | 03:19 |
| cr1901_modern | mithro: So I've been testing my own private fork of _florent_'s tinyfpga-soc. It has drastically diverged from _florent_'s, but I can basically copy and paste the final soc into the platforms/ and targets/ subdirectory for tinyfpga bx tonight. | 03:21 |
| cr1901_modern | err tinyfpga b*. I'm still blocked on bx by tinyprog | 03:21 |
| mithro | cr1901_modern: What is blocking you? | 03:21 |
| cr1901_modern | https://github.com/tinyfpga/TinyFPGA-Bootloader/issues/20 | 03:22 |
| tpb | Title: Add `name` option to `tinyprog` · Issue #20 · tinyfpga/TinyFPGA-Bootloader · GitHub (at github.com) | 03:22 |
| tinyfpga | cr1901_modern: I don’t think that should block you | 03:22 |
| mithro | cr1901_modern: Why does that block you? | 03:22 |
| tinyfpga | cr1901_modern: i thought about it some more today, it should work fine without it | 03:23 |
| cr1901_modern | tinyfpga: Oh? | 03:23 |
| tinyfpga | cr1901_modern: when I implement the feature it will be a small pr to add support for passing on the -name arg | 03:23 |
| cr1901_modern | mithro: Strictly speaking, it doesn't block me. I'm trying to minimize the number of PRs I sent | 03:23 |
| mithro | cr1901_modern: Why? | 03:23 |
| tinyfpga | cr1901_modern: smaller and more frequent PRs are always better | 03:24 |
| tinyfpga | cr1901_modern: it’s way easier to merge small things often than huge things after a long time | 03:24 |
| cr1901_modern | B/c without going into too much detail, it's overhead for me swapping branches, and having to have a private branch of "features that haven't been merged yet while I'm asynchronously waiting for ppl to get back to me" | 03:25 |
| cr1901_modern | My workflow is "one branch per PR" | 03:25 |
| mithro | cr1901_modern: The smaller the pull requests, the quicker it will be merged | 03:25 |
| cr1901_modern | mithro: Alright, I'll keep that in mind then | 03:25 |
| cr1901_modern | In any case, tinyfpga_bx/tinyprog support in litex is coming up | 03:26 |
| mithro | cr1901_modern: Just create a "merge everything" branch that you merge all your pull request branches into | 03:26 |
| cr1901_modern | Yea that'll prob work | 03:28 |
| mithro | cr1901_modern: Another option is to have a primary branch you do all dev on and then just pull things into the separate pull request branches you send upstream... | 03:29 |
| cr1901_modern | you mean cherry-pick them? | 03:29 |
| cr1901_modern | I'm not sure I understand | 03:29 |
| mithro | cr1901_modern: Yeah | 03:29 |
| cr1901_modern | mithro: Also keep in mind that while I don't use the submodules in litex-buildenv, most ppl do | 03:30 |
| cr1901_modern | so in that sense I _am_ truly blocked until all litex stuff I need is merged | 03:30 |
| mithro | cr1901_modern: Hence each pull request should be as small as possible then :-P | 03:31 |
| cr1901_modern | I can't point the submodules to my private copies b/c that only works for me. | 03:31 |
| cr1901_modern | /bikeshed | 03:31 |
| mithro | cr1901_modern: Put you can send pull requests with that | 03:31 |
| mithro | s/Put/But/ | 03:32 |
| cr1901_modern | Well, yes. And then I have to remember to point the submodules back to the new HEAD master before committing changes to litex-buildenv :) | 03:32 |
| cr1901_modern | which spoiler alert I've forgotten to do | 03:32 |
| cr1901_modern | Anyways I'm doing it your way, I'm just explaining how things work at my physical location lol | 03:33 |
| mithro | cr1901_modern: Also, shouldn't that tinyfpga thing only matter when you have multiple FPGAs installed? | 03:38 |
| cr1901_modern | of course, but it's still something I want to guard against | 03:39 |
| mithro | cr1901_modern: blocking == I can't get work done until this thing is fixed | 03:39 |
| mithro | cr1901_modern: Not, I would like this thing fixed before I'm happy :-) | 03:39 |
| cr1901_modern | well is there a one word term for the latter? | 03:39 |
| mithro | cr1901_modern: Not sure? | 03:42 |
| mithro | I think I'm going to head home bblr... | 03:42 |
| cr1901_modern | I was kinda kidding | 03:42 |
| cr1901_modern | alright | 03:42 |
| cr1901_modern | Making PR now | 03:45 |
| mithro | cr1901_modern: and while I'm not /technically/ blocked on adding the hx8k-env board to litex-buildenv, it becomes much simpler if you already have tinyfpga support | 03:45 |
| mithro | Also want to try out the UP5K | 03:47 |
| tinyfpga | mithro: yeah, the lm32 soc is right up at the limits of the UP5K logic cells | 03:47 |
| cr1901_modern | That seems odd... | 03:48 |
| mithro | Will have to take a closer look | 03:48 |
| mithro | I would expect it to be pretty similar to VexRISCV | 03:48 |
| tinyfpga | cr1901_modern: that’s just based on your estimates of 5k logic cells used on the bx | 03:48 |
| cr1901_modern | tinyfpga: That's not a good metric. I want to see ICESTORM_LC usage | 03:49 |
| tinyfpga | cr1901_modern, mithro: or did I miss something? | 03:49 |
| tinyfpga | cr1901_modern: i see | 03:49 |
| mithro | cr1901_modern: oh, you didn't give use the icestorm_lc number in the end... | 03:49 |
| cr1901_modern | mithro: That's because I never ran it :) | 03:50 |
| cr1901_modern | Got distracted | 03:50 |
| tinyfpga | cr1901_modern, mithro: right now I’m developing the USB core for UP5K since that’s the one that I haven’t been able to get working with the original bootloader | 03:50 |
| tinyfpga | cr1901_modern, mithro: hardware portion is nearly complete, will be driving it from my pc with python tonight if I’m lucky | 03:50 |
| cr1901_modern | excellent | 03:51 |
| mithro | tinyfpga: awesome! | 03:51 |
| cr1901_modern | mithro: https://github.com/enjoy-digital/litex/pull/96 | 03:52 |
| tpb | Title: build/platforms: Add TinyFPGA BX board and programmer. by cr1901 · Pull Request #96 · enjoy-digital/litex · GitHub (at github.com) | 03:52 |
| cr1901_modern | tinyfpga: Well then, soon enough we'll be able to remove the UART IP from tinyfpga and replace with a USB version :P | 03:54 |
| mithro | LGTM | 03:55 |
| cr1901_modern | Awesome, now one last PR to make. I will have made it by the time you get home. | 03:56 |
| mithro | Looks like they both are merged now... | 03:56 |
| mithro | Productive public holiday it seems! | 03:57 |
| cr1901_modern | Oh I still have to write the "Add COPY_FROM_FLASH" PR | 03:57 |
| cr1901_modern | mithro: Well, tinyfpga unblocked me (literally) by solving my SPI flash woes so I've been manic trying to get this done | 03:58 |
| mithro | benreynwar: oh, how did you find my talk? | 03:58 |
| benreynwar | mithro: Enjoyed it. | 03:59 |
| mithro | cr1901_modern: I would think of it more as a "COPY to main ram" patch? | 03:59 |
| mithro | benreynwar: always open to feedback, that talk has gone through a bunch of iterations | 04:00 |
| *** rohitksingh_work has joined #timvideos | 04:00 | |
| cr1901_modern | Yea fair enough | 04:01 |
| mithro | Hey rohitksingh_work! | 04:01 |
| benreynwar | mithro: It was a nice sales pitch for open-source tools. | 04:01 |
| mithro | rohit: Did you see the recent FuPy / litex-buildenv (and soon ice40) stuff? | 04:02 |
| mithro | Oh, cr1901_modern - if I have icecube installed, could I build using that to see the difference? | 04:04 |
| benreynwar | mitho: And it's always nice to watch a talk that confirms your own biases :). | 04:04 |
| rohitksingh_work | mithro: Hi! | 04:04 |
| rohitksingh_work | yup, I saw lot of activity on FuPy in last few days | 04:04 |
| rohitksingh_work | Nick is also working on that | 04:05 |
| mithro | Yeah! | 04:05 |
| mithro | Being able to convince Nick when I was at PyCon AU was pretty big | 04:05 |
| cr1901_modern | mithro: icecube tends to choke on migen designs due to poor block ram inference | 04:05 |
| rohitksingh_work | hehe, but you managed to do that anyhow! \o/ | 04:06 |
| mithro | Plus the UP5K looks really interesting for MicroPython | 04:06 |
| cr1901_modern | If we _have_ to get rid of something for up5k to work, I-cache should be kept. That is essential for good perf | 04:07 |
| rohitksingh_work | and tinyfpga is also porting his USB core to UP5K...so it's better! | 04:07 |
| mithro | I actually think the MimasV2 is reasonable interesting for a FuPy too | 04:07 |
| tinyfpga | cr1901_modern: I’m not sure about that, the UP5K has 128 kilobytes if internal sram | 04:09 |
| rohitksingh_work | for low-cost board, yeah! | 04:09 |
| cr1901_modern | tinyfpga: That's not enough to hold micropython, which needs 256kB | 04:09 |
| tinyfpga | cr1901_modern: I’d like to see what the resource difference is with and without I-cache | 04:09 |
| cr1901_modern | About 6 SB_RAM40_4Ks :) | 04:10 |
| tinyfpga | cr1901_modern: there’s got to be more logic utilization with the icache | 04:10 |
| cr1901_modern | Oh and about 500 LUTs. But that's also _with_ the multiplier, divide, and barrel shifter | 04:11 |
| tinyfpga | cr1901_modern: ohh wow, barrel shifter must be large | 04:23 |
| tinyfpga | cr1901_modern: I-cache would work very well in the UP5K spram with one or two block RAMs as tag ram | 04:28 |
| tinyfpga | cr1901_modern: but I’m sure that would require a fair bit of work to implement | 04:30 |
| cr1901_modern | it's also not portable | 04:31 |
| cr1901_modern | lm32's source code is very readable (for a CPU impl in Verilog...), but it's not something I really would enjoy hacking on | 04:31 |
| tinyfpga | cr1901_modern: there should be a way to substitute specific RAM primitives in the cache modules | 04:32 |
| tinyfpga | cr1901_modern: yeah, I’m not really asking for anyone to do it, just thinking out loud | 04:32 |
| cr1901_modern | tinyfpga: It might be. Tbh though I've kinda been turned off by the 5k based on other ppl's experiences with it. It's VERY slow and the cool features are difficult to use. | 04:33 |
| mithro | cr1901_modern: It's much easier if you just expose everything to a soft CPU and write MicroPython code :-P | 04:35 |
| tinyfpga | mithro, cr1901_modern: exactly :) | 04:35 |
| tinyfpga | cr1901_modern: I’m going to add the i2c and SPI cores to the soc soon | 04:36 |
| cr1901_modern | have fun! The base soc that will go into litex-buildenv will _not_ have those. I imagine the fupy one (which will subclass the base soc) will though | 04:37 |
| cr1901_modern | mithro: To clarify... all fupy targets currently run from DDR RAM, correct? | 05:32 |
| mithro | cr1901_modern: I believe so.... | 05:32 |
| *** jfng has quit IRC | 05:54 | |
| *** jea[m] has quit IRC | 05:55 | |
| *** deeprave has quit IRC | 05:55 | |
| *** deeprave has joined #timvideos | 05:56 | |
| *** jea[m] has joined #timvideos | 05:56 | |
| *** jfng has joined #timvideos | 05:56 | |
| mithro | Well, bed time for me | 06:08 |
| mithro | gnight everyone! | 06:08 |
| *** TroniQ89 has joined #timvideos | 06:16 | |
| *** TroniQ89 has quit IRC | 06:17 | |
| *** sunxi_fan has joined #timvideos | 06:21 | |
| *** sunxi_fan has quit IRC | 06:25 | |
| xobs | On Arty, the FPGA can't directly drive USB right? It always needs to go through the FTDI? | 06:49 |
| tinyfpga | xobs: as far as I know that’s the case | 06:53 |
| xobs | tinyfpga: alright, thanks. | 07:04 |
| xobs | What about examples of how to get liteeth to work on it? I'm trying the examples from liteeth/example_designs/ (specifically "etherbonesoc") and if I load etherbonesoc_arty.bit using openocd the Ethernet PHY never comes up (i.e. my network adapter says "unplugged".) | 07:07 |
| xobs | I can tell that loading bitstreams works, because I have a softcore that I can load and get a BIOS prompt. | 07:08 |
| xobs | I've given up trying to get etherbone-with-vexriscv working on this Arty for now and am trying to just get liteeth working. Since it synthesizes much faster. | 07:15 |
| *** Shari2 has joined #timvideos | 07:17 | |
| Shari2 | Hi. | 07:17 |
| xobs | Hello | 07:18 |
| _florent_ | hi | 07:22 |
| _florent_ | xobs: i can probably help | 07:23 |
| _florent_ | xobs: which etherbone soc are you testing in arty? | 07:23 |
| _florent_ | xobs: i can do a quick test if you want | 07:23 |
| xobs | _florent_: I'm just trying to validate it works at all. | 07:24 |
| xobs | https://gist.github.com/xobs/4064da5d24523092bf19c89bd42194a0 (you can remove the "lxbuildenv" from the top.) | 07:25 |
| tpb | Title: arty.py · GitHub (at gist.github.com) | 07:25 |
| _florent_ | xobs: on the arty, you need to generate a clock for the ethernet | 07:25 |
| _florent_ | xobs: not sure the example_designs in liteeth are doing that | 07:26 |
| _florent_ | xobs: this one should work: https://github.com/enjoy-digital/arty-soc/blob/master/arty_etherbone.py | 07:26 |
| tpb | Title: arty-soc/arty_etherbone.py at master · enjoy-digital/arty-soc · GitHub (at github.com) | 07:26 |
| xobs | Oh. Thanks! I'll take a look at arty-soc then. | 07:27 |
| xobs | I get a cryptic message when I try to build. "assert (not memtype == "DDR3" and nphases == 2) # FIXME: Needs BL8 support for nphases=2" inside litedram/phy/s7ddrphy.py. I'm not sure where those values are coming from. | 07:33 |
| xobs | Is it an order-of-operations issue? nphases is 4. Should it be "not (memtype == "DDR3" and nphases == 2))"? | 07:37 |
| _florent_ | xobs: yes, sorry, i'm going to fix that | 07:37 |
| _florent_ | xobs: you can ignore the assert for now | 07:37 |
| _florent_ | xobs: fixed, thanks | 07:40 |
| _florent_ | xobs: https://github.com/enjoy-digital/arty-soc/blob/master/arty_base.py#L106-L110 | 07:41 |
| tpb | Title: arty-soc/arty_base.py at master · enjoy-digital/arty-soc · GitHub (at github.com) | 07:41 |
| _florent_ | this is what was missing in the example design to get etherbone working on arty | 07:41 |
| xobs | Ah, I see. And if I build the arty-soc now, which obviously has that line, I get a carrier. Thanks for the help and the patch! | 07:43 |
| *** shenki has quit IRC | 08:55 | |
| *** thomas18 has joined #timvideos | 09:06 | |
| *** thomas18 has quit IRC | 09:09 | |
| *** futarisIRCcloud has quit IRC | 09:20 | |
| *** shenki has joined #timvideos | 09:59 | |
| *** ChanServ sets mode: +v shenki | 09:59 | |
| *** futarisIRCcloud has joined #timvideos | 10:08 | |
| *** ben_zen19 has joined #timvideos | 11:28 | |
| *** Guest45420 has joined #timvideos | 11:32 | |
| *** Guest45420 has quit IRC | 11:37 | |
| futarisIRCcloud | Is it possible to enable a FPU co-processor for any of the cores in litex? | 12:15 |
| *** rohitksingh_work has quit IRC | 12:31 | |
| shorne | futarisIRCcloud: the openrisc core has fpu | 12:31 |
| shorne | on mor1kx its parameter FEATURE_FPU="ENABLE" | 12:32 |
| shorne | https://github.com/openrisc/mor1kx | 12:32 |
| tpb | Title: GitHub - openrisc/mor1kx: mor1kx - an OpenRISC 1000 processor IP core (at github.com) | 12:32 |
| futarisIRCcloud | shorne: Cheers. Only the older openrisc gcc port supports hard fpu, right? | 12:37 |
| *** GigabytePro15 has joined #timvideos | 12:48 | |
| *** GigabytePro15 has quit IRC | 12:53 | |
| *** dysfigured22 has joined #timvideos | 14:00 | |
| *** dysfigured22 has quit IRC | 14:03 | |
| *** futarisIRCcloud has quit IRC | 14:48 | |
| *** Dworf has joined #timvideos | 15:07 | |
| *** Dworf has quit IRC | 15:11 | |
| *** thaytan has quit IRC | 15:16 | |
| *** thaytan has joined #timvideos | 15:32 | |
| *** ChanServ sets mode: +v thaytan | 15:32 | |
| mithro | xobs: We have Etherbone software working in LiteX-BuildEnv | 15:57 |
| xobs | mithro: I got etherbone working, and started working on getting CSR read/write support in vexriscv-openocd. I got read (once) support, but subsequent reads come out as 0. I'm wondering now if it's not caused by an error in implementing CSRR. Or maybe it's a bug in openocd. | 16:00 |
| mithro | xobs: Did you see my question about an Etherbone C library? | 16:03 |
| xobs | no, where was that? | 16:03 |
| mithro | xobs: Earlier the other day | 16:05 |
| cr1901_modern | tinyfpga: I should be putting up my copy of tinyfpga-soc with a proof of concept "payload from SPI flash" today. Note that although tinyprog is capable of automatically determining where to flash a payload, I don't think litex-buildenv can take advantage of it | 16:06 |
| cr1901_modern | (b/c litex-buildenv expects a user to upload the bitstream+bios+payload concatenated together) | 16:07 |
| mithro | xobs: https://github.com/enjoy-digital/litescope/issues/8 | 16:10 |
| tpb | Title: Support pulseview / sigrok directly · Issue #8 · enjoy-digital/litescope · GitHub (at github.com) | 16:10 |
| mithro | xobs: https://github.com/mithro/libsigrok/tree/litescope/src/hardware/litescope | 16:11 |
| tpb | Title: libsigrok/src/hardware/litescope at litescope · mithro/libsigrok · GitHub (at github.com) | 16:11 |
| cr1901_modern | mithro: Bikeshed time: Did you originally write the mimasv2 base.py | 16:11 |
| mithro | cr1901_modern: No idea - git blame is your friend | 16:11 |
| cr1901_modern | If you build a mimasv2 base.py, you'll get a regions.ld that looks like this: http://ix.io/1lXU | 16:14 |
| cr1901_modern | I wonder how much "bad practice" it is to define overlapping regions in a linker script | 16:14 |
| cr1901_modern | mithro: Right now, my tinyfpga-soc doesn't have an spiflash region; the "rom" section is still defined to begin where the bios starts. | 16:19 |
| cr1901_modern | I spent last night trying to extend the length of the "rom" section to the end of the SPI flash. >> | 16:19 |
| cr1901_modern | I figured it would be easier to create a linker script for a payload such as litex-buildenv by "reusing the ROM section plus a constant offset" than using overlapping sections. | 16:20 |
| cr1901_modern | Turns out, this is actually harder than it looks :P. So I'm probably going to define a "main_flash" section in the spirit of "main_ram" that litex-buildenv targets that boot from SPI flash use. | 16:20 |
| cr1901_modern | a "main_flash" section, for litex-buildenv targets with a payload that runs from SPI flash* | 16:21 |
| mithro | xobs: I think we should have a good etherbone C only library (and maybe csr read/write) | 16:21 |
| cr1901_modern | I'll just eat the "overlapping sections"... | 16:22 |
| xobs | mithro: I remember that. I also have some utilities that are useful for developing with etherbone, including https://github.com/xobs/wishbone-adapter/blob/master/etherbone-devmem2.c (which talks directly over Ethernet) and https://github.com/xobs/wishbone-adapter/blob/master/litex-devmem2.c which uses the bridge | 16:22 |
| tpb | Title: wishbone-adapter/etherbone-devmem2.c at master · xobs/wishbone-adapter · GitHub (at github.com) | 16:22 |
| xobs | (The kind of awful utilities you write when figuring out something for the first time.) | 16:24 |
| cr1901_modern | That's good... arachne-pnr fails to route my soc on bx (b2 is fine), and nextpnr crashes | 16:27 |
| xobs | mithro: A more concise implementation made it into the SpinalHDL "vexriscv" implementation: https://github.com/SpinalHDL/openocd_riscv/blob/riscv_spinal/src/target/vexriscv.c#L928 | 16:28 |
| tpb | Title: openocd_riscv/vexriscv.c at riscv_spinal · SpinalHDL/openocd_riscv · GitHub (at github.com) | 16:28 |
| CarlFK | shorne: https://github.com/timvideos/qemu-litex.git needs two sets of patches applied: #1 is memfd: fix configure test (here is it failing just now: http://paste.ubuntu.com/p/XRB54kRBSJ/ ) patch discussion: https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg05016.html | 16:36 |
| tpb | Title: GitHub - timvideos/qemu-litex (at github.com) | 16:36 |
| CarlFK | shorne: and #2 I don't have handy, would have to get past #1, and I'd rather have someone do it who knows what they are doing | 16:37 |
| *** Ckat11 has joined #timvideos | 16:56 | |
| *** Shari2 has quit IRC | 17:05 | |
| *** rohitksingh has joined #timvideos | 17:20 | |
| mithro | xobs: Yeah | 17:31 |
| *** rohitksingh has quit IRC | 17:33 | |
| mithro | xobs: The API seems to turn out okay -> https://github.com/mithro/libsigrok/blob/litescope/src/hardware/litescope/protocol.c#L135-L141 | 17:33 |
| tpb | Title: libsigrok/protocol.c at litescope · mithro/libsigrok · GitHub (at github.com) | 17:33 |
| mithro | xobs: https://github.com/mithro/libsigrok/blob/litescope/src/hardware/litescope/protocol.c#L162-L186 | 17:34 |
| tpb | Title: libsigrok/protocol.c at litescope · mithro/libsigrok · GitHub (at github.com) | 17:34 |
| *** rohitksingh has joined #timvideos | 17:34 | |
| mithro | cr1901_modern: I have no idea about how bad overlapping regions in a linker script are | 17:35 |
| *** rohitksingh has quit IRC | 17:46 | |
| *** rohitksingh has joined #timvideos | 18:04 | |
| *** rohitksingh has quit IRC | 18:14 | |
| tinyfpga | _florent_: I need some CDC advice if you have a moment | 18:28 |
| tinyfpga | _florent_: I want to move data from one cd to another it a pretty slow pace, about 1/8 to 1/32 the clock rate | 18:29 |
| tinyfpga | _florent_: I have a small bus that is qualified by a valid signal. I see BusSynchronizer, but this doesn’t appear to expose or take any external valid signal for either clock domain | 18:30 |
| tinyfpga | _florent_: the other option I’m looking at is a very small async fifo, maybe 2 deep | 18:31 |
| tinyfpga | mithro: do you know of any other migen/litex experts that may be able to chime in on clock domain crossing tools in migen? ^^^ | 18:32 |
| mithro | tinyfpga: Try #m-labs - sb0 and whitequark are good | 18:45 |
| mithro | tinyfpga: Bunnie has some advice in his wiki doc too | 18:45 |
| mithro | tinyfpga: https://github.com/timvideos/litex-buildenv/wiki/LiteX-for-Hardware-Engineers#sync | 18:48 |
| tpb | Title: LiteX for Hardware Engineers · timvideos/litex-buildenv Wiki · GitHub (at github.com) | 18:48 |
| mithro | tinyfpga: https://m-labs.hk/migen/manual/reference.html#module-migen.genlib.fifo | 19:00 |
| mithro | tinyfpga: BTW Did you find https://github.com/m-labs/migen/blob/master/migen/genlib/cdc.py ? | 19:05 |
| tpb | Title: migen/cdc.py at master · m-labs/migen · GitHub (at github.com) | 19:05 |
| tinyfpga | mithro: thanks, those are what I’ve been referencing :) | 19:06 |
| tinyfpga | mithro: I think a tiny async fifo will be the best option | 19:07 |
| mithro | tinyfpga: There is the "stream interface" stuff which uses valid and such signals? | 19:07 |
| _florent_ | tinyfpga: you can use an async fifo with the minimum depth (should be 4) | 19:07 |
| _florent_ | tinyfpga: https://github.com/enjoy-digital/litex/blob/master/litex/soc/interconnect/stream.py#L106 | 19:08 |
| tpb | Title: litex/stream.py at master · enjoy-digital/litex · GitHub (at github.com) | 19:08 |
| mithro | _florent_: Shouldn't he just be able to use a MultiReg for the ready and key off that? | 19:09 |
| mithro | tinyfpga: What this small bus for? | 19:11 |
| _florent_ | mithro: i would need more information about the signals to advice for something else than asyncfifo | 19:11 |
| mithro | tinyfpga: I assume 48MHz -> slow speed? | 19:11 |
| tinyfpga | mithro, _florent_: yeah, it’s between an internal USB PHY running at 48MHz and the system clock domain which could be 12 - 100 MHz | 19:14 |
| tinyfpga | mithro, _florent_: it’s a small bus, 4 bits wide with an additional | 19:14 |
| tinyfpga | ...valid signal | 19:14 |
| mithro | tinyfpga: Why 4 bits? | 19:15 |
| tinyfpga | mithro: this is not the data path, it’s the control path | 19:15 |
| mithro | tinyfpga: What's the control path look like? | 19:15 |
| tinyfpga | mithro: it’s the info needed to initiate a new packet | 19:15 |
| tinyfpga | mithro: just the usb packet type | 19:16 |
| mithro | tinyfpga: Is it expose via a CSR? | 19:16 |
| mithro | Another random old doc -> https://docs.google.com/document/d/11uzjWRWk9-KuBFc7chUNUluL5ajysY2qfXvt1vttl7k/edit?usp=drivesdk | 19:20 |
| tpb | Title: LiteX Firmware - Google Docs (at docs.google.com) | 19:20 |
| tinyfpga | mithro: no, this requires fast response for data ACK or NAK, CPU not fast enough | 19:25 |
| mithro | Lunch time for me | 19:26 |
| mithro | tinyfpga: push the code somewhere? | 19:26 |
| tinyfpga | mithro: tonight | 19:27 |
| *** puff3 has joined #timvideos | 19:55 | |
| *** puff3 has quit IRC | 19:59 | |
| *** rohitksingh has joined #timvideos | 20:11 | |
| *** rohitksingh has quit IRC | 20:21 | |
| *** Peng_18 has joined #timvideos | 20:32 | |
| *** Peng_18 has quit IRC | 20:37 | |
| *** [d__d] has quit IRC | 20:42 | |
| shorne | CarlFK: sorry, I didnt see your message (just saw on https://botbot.me/freenode/timvideos/) I dont remember the issue with util/memfd.c:40:12: error: static declaration of ‘memfd_create’ | 20:43 |
| shorne | but it sounds like a general issue that needs fixing, which compiler are you using? | 20:44 |
| *** [d__d] has joined #timvideos | 20:44 | |
| shorne | CarlFK: oh... I see it looks like you somehow are missing some linux headers | 20:45 |
| shorne | let me know if you still have the issue | 20:49 |
| shorne | CarlFK: oh... I see your patch. Its already applied in upstream qemu | 20:50 |
| shorne | futaris[m]: Yes, on GCC, I haven't added FPU native support yet. Was on todo list after initial upstreaming | 20:51 |
| shorne | Has anyone tried the new OpenRISC GCC port? | 20:52 |
| shorne | CarlFK: Which instructions are you following where the qemu build is failing? | 20:52 |
| CarlFK[m] | shorne both the typical ./configure; make and mithro s build-qumu.sh , I thought that is the name, on phone right now so all from memory | 20:56 |
| CarlFK[m] | shorne I'm trying to build the timvideos/qemu that was forked over a year ago | 20:59 |
| shorne | ok, I guess due to recent glibc changes it doesnt build on new distro's we will need to rebase the patches | 21:02 |
| CarlFK[m] | shorne right. I'm trying to help push this along, but I'm hoping someone else can touch the code. | 21:12 |
| cr1901_modern | mithro: https://github.com/YosysHQ/nextpnr/issues/69 | 22:20 |
| tpb | Title: Using `PLLOUTGLOBAL` on PLL results in :Assertion failure" · Issue #69 · YosysHQ/nextpnr · GitHub (at github.com) | 22:20 |
| cr1901_modern | tinyfpga: Have you been using arache or nextpnr for your SoCs? | 22:20 |
| tinyfpga | cr1901_modern: arachne | 22:20 |
| cr1901_modern | fascinating... arachne is pretty consistently failing to route for me | 22:21 |
| cr1901_modern | BX only | 22:21 |
| cr1901_modern | B2 works fine ._. | 22:21 |
| tinyfpga | cr1901_modern: it failed to route the cpu for me as well | 22:21 |
| tinyfpga | cr1901_modern: I’m just using the UART bridge for now | 22:21 |
| cr1901_modern | Ahhh, I must've not noticed then | 22:21 |
| tinyfpga | cr1901_modern: I think I’ll have to move to nextpnr once I want to use a cpu core | 22:22 |
| cr1901_modern | arachne can route B2 just fine, but it's choking on BX. Looks like I never tested BX on arachne until today. | 22:22 |
| cr1901_modern | tinyfpga: See yosys chat, you won't want to route the PLL to an SB_GB if you're using PLLOUTGLOBAL | 22:38 |
| cr1901_modern | I didn't know this until now, so I've spent 2 years wasting an SB_GB | 22:38 |
| mithro | cr1901_modern / tinyfpga: Are you forcing the clock to use the global route? | 23:09 |
| cr1901_modern | mithro: Yes, but contrary to what I am _supposed_ to do, I'd been additionally routing the clock to _another_ global buffer | 23:10 |
| cr1901_modern | meaning I've been wasting a SB_GB all this time. | 23:10 |
| tinyfpga | mithro, cr1901_modern: i just use PLLOUTGLOBAL | 23:11 |
| cr1901_modern | tinyfpga: Oh so you were smart enough to remove the SB_GB in my example code I showed you :P? | 23:12 |
| *** futarisIRCcloud has joined #timvideos | 23:25 | |
| *** twoolie has joined #timvideos | 23:25 | |
| *** twoolie has quit IRC | 23:41 | |
| shorne | CarlFK[m]: ok, If I get time I will try to build, which OS are you building on? i.e. libc version? | 23:48 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!