Tuesday, 2018-09-04

*** tpb has joined #timvideos00:00
cr1901_modernmithro: 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
mithrocr1901_modern: Look at the MimasV2 set up?00:10
mithroOh wait no main_ram == no external DDR ram?00:10
cr1901_modernyes00:10
mithrocr1901_modern: Added some comments to the pull request and cleaned it up slightly :-P00:11
cr1901_moderncool, will take a look00:11
cr1901_modernand 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
CarlFKmithro: what sort of ps1 project?00:21
mithroSmall PCB board00:21
CarlFKoh great.  I already got yelled at about the last pcb board you sent me ;)00:21
CarlFKsomething about "why are these parts so small?!"00:21
mithroThis wouldn't be that small00:22
cr1901_modernmithro: All questions addressed00:26
CarlFKmithro: try to get it here by next mon, which is when I'll be in for Nerp, which has the most EE sorts hanging around00:26
CarlFKmithro: why does v4l2-ctl say the Opsis is 1024/768?  http://paste.ubuntu.com/p/ZZbXfMQm5v/00:27
mithrocr1901_modern: Except you didn't give me any numbers :-P00:27
tpbTitle: Ubuntu Pastebin (at paste.ubuntu.com)00:27
cr1901_modernI don'00:27
cr1901_modernt feel like waiting an hour to try all combinations00:27
mithrocr1901_modern: An hour?00:28
cr1901_modernmithro: Nevermind...00:29
mithrocr1901_modern: It should be pretty easy to compare minimal verse lite configuration in LUTs right?00:29
cr1901_modernYea, hold on, I misunderstood00:30
benreynwarI'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
mithrobenreynwar: Yes!00:32
mithrobenreynwar: Pretty much nothing at https://github.com/enjoy-digital/litex/tree/master/litex/soc/cores has many tests?00:32
tpbTitle: litex/litex/soc/cores at master · enjoy-digital/litex · GitHub (at github.com)00:32
mithrobenreynwar: The spiflash stuff might be a good thing to try? https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/spi_flash.py00:33
tpbTitle: litex/spi_flash.py at master · enjoy-digital/litex · GitHub (at github.com)00:33
benreynwarSweet.  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
mithrobenreynwar: I would love to see an example on a real core which does all three?00:37
mithrobenreynwar: There is some example tests here -> https://github.com/enjoy-digital/litex/blob/master/test/test_gearbox.py00:38
tpbTitle: litex/test_gearbox.py at master · enjoy-digital/litex · GitHub (at github.com)00:38
cr1901_modernmithro: https://github.com/enjoy-digital/litex/pull/95#discussion_r21476520000:39
tpbTitle: 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
mithrocr1901_modern: The reason I ask, is I care about the iCE40 UP5K00:40
mithrominimal --    Number of cells:               5166                          lite --   Number of cells:               589700:41
mithroright?00:41
cr1901_modernMany of those will be combined into ICESTORM_LCs though00:42
mithrocr1901_modern: Yeah - I just realized that...00:42
mithrocr1901_modern: Can you get arachne or nextpnr to output ICESTORM_LC counts?00:42
cr1901_modernSince 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_modernI don't think arachne says00:43
mithrocr1901_modern: Please log a bug report for nextpnr if you haven't already00:43
mithro     SB_RAM40_4K                    25      verse      SB_RAM40_4K                    31 ?00:43
cr1901_moderncache00:43
cr1901_modernI'll file a report when I have a chance to minimize it00:43
mithrocr1901_modern: What is using the 25 in the minimal config?00:44
cr1901_modernmostly block RAM00:44
cr1901_modern(10kb of Block RAM)00:44
cr1901_modernerr, SRAM*00:44
mithrobenreynwar: https://github.com/enjoy-digital/litex/tree/master/litex/gen/sim00:45
tpbTitle: litex/litex/gen/sim at master · enjoy-digital/litex · GitHub (at github.com)00:45
mithrobenreynwar: You should have a play around with SimPlatform (https://github.com/enjoy-digital/litex/blob/master/litex/boards/platforms/sim.py)00:46
tpbTitle: litex/sim.py at master · enjoy-digital/litex · GitHub (at github.com)00:46
mithrocr1901_modern: Do you remember a specification a wrote a long time ago about improvements I wanted to the SPI stuff?00:47
cr1901_modernYes, it's somewhere in my google docs00:49
mithrocr1901_modern: I can't find it :-P01:02
cr1901_modernhttps://docs.google.com/document/d/1l7wQvZ-wZv0lz0AThDUr-SG6JwArtYDg8KXhN4wrUNY This one?01:02
tpbTitle: SPI flash xmodem upload in firmware (cr1901) - Google Docs (at docs.google.com)01:02
mithrocr1901_modern: Oh btw -> https://docs.google.com/document/d/11uMIDI5HozuPZAIdIKmJmYP0BKjXn760Y4itEllbdtA/edit01:02
tpbTitle: Google Docs - create and edit documents online, for free. (at docs.google.com)01:02
mithrocr1901_modern: Nope!01:03
cr1901_modernRequested access. And remind me to check later, I'm a bit preoccupied right now01:03
mithrocr1901_modern: and https://docs.google.com/spreadsheets/d/1pNunBJX46jp6ClPFZA29GhlXJmb9lnG9_BEVej7XxL4/edit#gid=148207703201:05
tpbTitle: Google Sheets - create and edit spreadsheets online, for free. (at docs.google.com)01:06
cr1901_modernAlso requested access :)01:06
mithrocr1901_modern: They are public, so I'm unsure why you don't have access...01:07
mithroPublic on the web - Anyone on the Internet can find and comment01:07
cr1901_modernThis is a brave thing you're trying to do :)01:08
tinyfpgamithro: they aren’t public documents, google docs won’t let me view them01:11
mithroGoogle is lieing to me then...01:11
tinyfpgamithro: by the way, the new USB core easily meets timing01:12
cr1901_modern>Google is lieing to me then...01:12
cr1901_modernNah... too easy01:12
tinyfpgamithro: almost everything is in a much slower clock domain, and the “fast” 48MHz domain has very little left in it01:12
cr1901_modernCan the core portion meet 32Mhz?01:13
mithroJust unshared and reshared  - reload01:13
cr1901_moderntinyfpga: 32MHz is the target I'm trying to meet for the full SoC01:13
tinyfpgacr1901_modern: it should be able to meet 32MHz01:14
tinyfpgacr1901_modern: the current bootloader all01:14
tinyfpga...runs at 48MHz01:14
cr1901_moderncool01:15
*** Char0n has joined #timvideos01:15
*** Char0n has quit IRC01:16
mithrocr1901_modern: Guess I just rewrote it -> https://docs.google.com/document/d/1JZ7pU7roOaJwsv_LlXDKpWrLMSp254-tuof5KIFcC-I/edit?usp=sharing01:27
tpbTitle: LiteX SPI Flash Improvements - Google Docs (at docs.google.com)01:27
mithrobenreynwar: Might be worth looking at too01:27
cr1901_modernOkay I don't remember anything like this01:28
cr1901_modernexcept interestingly enough, something about using"tinyfpga data config" rings a bell01:28
cr1901_moderntinyfpga: 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 ROM01:28
mithrocr1901_modern: ROM or SPI Flash?01:34
shornemithro: sorry, I have been off and on over the weekend, staying home with a sick kid the last 2 days01:35
shorneI just replied to your mail01:35
mithroshorne: No worries01:35
cr1901_modernmithro: I meant SPIFlash; the linker section is called "rom"01:35
mithrocr1901_modern: Okay, then copy the MimasV2 I guess?01:44
cr1901_modernthe Mimasv2 loads it's program into SDRAM before running it01:44
cr1901_modernand the linker script present in litex-buildenv assumes "main_ram" exists01:45
mithroOh, sorry - your right01:46
cr1901_modernand my problem right now is: Idk if it's possible to conditionally define a single linker script based on what regions are available01:47
cr1901_modernlitex 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't01:48
cr1901_modernbut there's no such requirement for main RAM01:48
cr1901_modernMaybe a separate linker script is the best option. But how do I tell the build system which version to use?01:49
cr1901_modernhttps://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
tpbTitle: software/bios/linker: revert data section since required by RISC-V co… · enjoy-digital/[email protected] · GitHub (at github.com)01:50
mithrocr1901_modern: Okay01:54
*** Guest45420 has joined #timvideos02:14
*** Guest45420 has quit IRC02:17
*** puck is now known as puck_02:32
cr1901_modernmithro: My suggestion re: swapping linker files is to either:02:43
cr1901_modern1. 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_modern2. Automatically detect whether flash_boot_address and main_ram regions are defined.02:43
cr1901_modern3. Gate based on CPU variant. >>02:43
cr1901_modernIn all cases, we then set a Makefile variable "COPY_FROM_FLASH", which can be used to choose the linker script02:43
cr1901_modern /minddump02:43
cr1901_modernI 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 ifdef02:45
mithrocr1901_modern: Sounds reasonable to me?02:47
cr1901_modernwe already are tied to gnu make unfortunately, so an ifdef isn't going to be a big deal :P02:47
cr1901_modernmithro: Cool, can we work out the kinks of the current PR so I can pull master and work on this PR next?02:47
mithrocr1901_modern: Sure....03:02
mithrocr1901_modern: So, what do we need to do?03:14
cr1901_modernmithro: Accept the PR :)03:15
cr1901_modernSo I'm no longer blocked on it03:16
cr1901_modernUnless you have other complaints03:16
cr1901_modernOh, and mark all the conversations as resolved03:16
cr1901_modernif my responses are to your satisfaction.03:16
mithrocr1901_modern: Okay, merged03:19
mithrocr1901_modern: We can continue to tweak later03:19
cr1901_modernExcellent.03:19
cr1901_modernmithro: 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_modernerr tinyfpga b*. I'm still blocked on bx by tinyprog03:21
mithrocr1901_modern: What is blocking you?03:21
cr1901_modernhttps://github.com/tinyfpga/TinyFPGA-Bootloader/issues/2003:22
tpbTitle: Add `name` option to `tinyprog` · Issue #20 · tinyfpga/TinyFPGA-Bootloader · GitHub (at github.com)03:22
tinyfpgacr1901_modern: I don’t think that should block you03:22
mithrocr1901_modern: Why does that block you?03:22
tinyfpgacr1901_modern: i thought about it some more today, it should work fine without it03:23
cr1901_moderntinyfpga: Oh?03:23
tinyfpgacr1901_modern: when I implement the feature it will be a small pr to add support for passing on the -name arg03:23
cr1901_modernmithro: Strictly speaking, it doesn't block me. I'm trying to minimize the number of PRs I sent03:23
mithrocr1901_modern: Why?03:23
tinyfpgacr1901_modern: smaller and more frequent PRs are always better03:24
tinyfpgacr1901_modern: it’s way easier to merge small things often than huge things after a long time03:24
cr1901_modernB/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_modernMy workflow is "one branch per PR"03:25
mithrocr1901_modern: The smaller the pull requests, the quicker it will be merged03:25
cr1901_modernmithro: Alright, I'll keep that in mind then03:25
cr1901_modernIn any case, tinyfpga_bx/tinyprog support in litex is coming up03:26
mithrocr1901_modern: Just create a "merge everything" branch that you merge all your pull request branches into03:26
cr1901_modernYea that'll prob work03:28
mithrocr1901_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_modernyou mean cherry-pick them?03:29
cr1901_modernI'm not sure I understand03:29
mithrocr1901_modern: Yeah03:29
cr1901_modernmithro: Also keep in mind that while I don't use the submodules in litex-buildenv, most ppl do03:30
cr1901_modernso in that sense I _am_ truly blocked until all litex stuff I need is merged03:30
mithrocr1901_modern: Hence each pull request should be as small as possible then :-P03:31
cr1901_modernI can't point the submodules to my private copies b/c that only works for me.03:31
cr1901_modern /bikeshed03:31
mithrocr1901_modern: Put you can send pull requests with that03:31
mithros/Put/But/03:32
cr1901_modernWell, 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_modernwhich spoiler alert I've forgotten to do03:32
cr1901_modernAnyways I'm doing it your way, I'm just explaining how things work at my physical location lol03:33
mithrocr1901_modern: Also, shouldn't that tinyfpga thing only matter when you have multiple FPGAs installed?03:38
cr1901_modernof course, but it's still something I want to guard against03:39
mithrocr1901_modern: blocking == I can't get work done until this thing is fixed03:39
mithrocr1901_modern: Not, I would like this thing fixed before I'm happy :-)03:39
cr1901_modernwell is there a one word term for the latter?03:39
mithrocr1901_modern: Not sure?03:42
mithroI think I'm going to head home bblr...03:42
cr1901_modernI was kinda kidding03:42
cr1901_modernalright03:42
cr1901_modernMaking PR now03:45
mithrocr1901_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 support03:45
mithroAlso want to try out the UP5K03:47
tinyfpgamithro: yeah, the lm32 soc is right up at the limits of the UP5K logic cells03:47
cr1901_modernThat seems odd...03:48
mithroWill have to take a closer look03:48
mithroI would expect it to be pretty similar to VexRISCV03:48
tinyfpgacr1901_modern: that’s just based on your estimates of 5k logic cells used on the bx03:48
cr1901_moderntinyfpga: That's not a good metric. I want to see ICESTORM_LC usage03:49
tinyfpgacr1901_modern, mithro: or did I miss something?03:49
tinyfpgacr1901_modern: i see03:49
mithrocr1901_modern: oh, you didn't give use the icestorm_lc number in the end...03:49
cr1901_modernmithro: That's because I never ran it :)03:50
cr1901_modernGot distracted03:50
tinyfpgacr1901_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 bootloader03:50
tinyfpgacr1901_modern, mithro: hardware portion is nearly complete, will be driving it from my pc with python tonight if I’m lucky03:50
cr1901_modernexcellent03:51
mithrotinyfpga: awesome!03:51
cr1901_modernmithro: https://github.com/enjoy-digital/litex/pull/9603:52
tpbTitle: build/platforms: Add TinyFPGA BX board and programmer. by cr1901 · Pull Request #96 · enjoy-digital/litex · GitHub (at github.com)03:52
cr1901_moderntinyfpga: Well then, soon enough we'll be able to remove the UART IP from tinyfpga and replace with a USB version :P03:54
mithroLGTM03:55
cr1901_modernAwesome, now one last PR to make. I will have made it by the time you get home.03:56
mithroLooks like they both are merged now...03:56
mithroProductive public holiday it seems!03:57
cr1901_modernOh I still have to write the "Add COPY_FROM_FLASH" PR03:57
cr1901_modernmithro: Well, tinyfpga unblocked me (literally)  by solving my SPI flash woes so I've been manic trying to get this done03:58
mithrobenreynwar: oh, how did you find my talk?03:58
benreynwarmithro: Enjoyed it.03:59
mithrocr1901_modern: I would think of it more as a "COPY to main ram" patch?03:59
mithrobenreynwar: always open to feedback, that talk has gone through a bunch of iterations04:00
*** rohitksingh_work has joined #timvideos04:00
cr1901_modernYea fair enough04:01
mithroHey rohitksingh_work!04:01
benreynwarmithro: It was a nice sales pitch for open-source tools.04:01
mithrorohit: Did you see the recent FuPy / litex-buildenv (and soon ice40) stuff?04:02
mithroOh, cr1901_modern - if I have icecube installed, could I build using that to see the difference?04:04
benreynwarmitho: And it's always nice to watch a talk that confirms your own biases :).04:04
rohitksingh_workmithro: Hi!04:04
rohitksingh_workyup, I saw lot of activity on FuPy in last few days04:04
rohitksingh_workNick is also working on that04:05
mithroYeah!04:05
mithroBeing able to convince Nick when I was at PyCon AU was pretty big04:05
cr1901_modernmithro: icecube tends to choke on migen designs due to poor block ram inference04:05
rohitksingh_workhehe, but you managed to do that anyhow! \o/04:06
mithroPlus the UP5K looks really interesting for MicroPython04:06
cr1901_modernIf we _have_ to get rid of something for up5k to work, I-cache should be kept. That is essential for good perf04:07
rohitksingh_workand tinyfpga is also porting his USB core to UP5K...so it's better!04:07
mithroI actually think the MimasV2 is reasonable interesting for a FuPy too04:07
tinyfpgacr1901_modern: I’m not sure about that, the UP5K has 128 kilobytes if internal sram04:09
rohitksingh_workfor low-cost board, yeah!04:09
cr1901_moderntinyfpga: That's not enough to hold micropython, which needs 256kB04:09
tinyfpgacr1901_modern: I’d like to see what the resource difference is with and without I-cache04:09
cr1901_modernAbout 6 SB_RAM40_4Ks :)04:10
tinyfpgacr1901_modern: there’s got to be more logic utilization with the icache04:10
cr1901_modernOh and about 500 LUTs. But that's also _with_ the multiplier, divide, and barrel shifter04:11
tinyfpgacr1901_modern: ohh wow, barrel shifter must be large04:23
tinyfpgacr1901_modern: I-cache would work very well in the UP5K spram with one or two block RAMs as tag ram04:28
tinyfpgacr1901_modern: but I’m sure that would require a fair bit of work to implement04:30
cr1901_modernit's also not portable04:31
cr1901_modernlm32's source code is very readable (for a CPU impl in Verilog...), but it's not something I really would enjoy hacking on04:31
tinyfpgacr1901_modern: there should be a way to substitute specific RAM primitives in the cache modules04:32
tinyfpgacr1901_modern: yeah, I’m not really asking for anyone to do it, just thinking out loud04:32
cr1901_moderntinyfpga: 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
mithrocr1901_modern: It's much easier if you just expose everything to a soft CPU and write MicroPython code :-P04:35
tinyfpgamithro, cr1901_modern: exactly :)04:35
tinyfpgacr1901_modern: I’m going to add the i2c and SPI cores to the soc soon04:36
cr1901_modernhave 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 though04:37
cr1901_modernmithro: To clarify... all fupy targets currently run from DDR RAM, correct?05:32
mithrocr1901_modern: I believe so....05:32
*** jfng has quit IRC05:54
*** jea[m] has quit IRC05:55
*** deeprave has quit IRC05:55
*** deeprave has joined #timvideos05:56
*** jea[m] has joined #timvideos05:56
*** jfng has joined #timvideos05:56
mithroWell, bed time for me06:08
mithrognight everyone!06:08
*** TroniQ89 has joined #timvideos06:16
*** TroniQ89 has quit IRC06:17
*** sunxi_fan has joined #timvideos06:21
*** sunxi_fan has quit IRC06:25
xobsOn Arty, the FPGA can't directly drive USB right?  It always needs to go through the FTDI?06:49
tinyfpgaxobs: as far as I know that’s the case06:53
xobstinyfpga: alright, thanks.07:04
xobsWhat 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
xobsI can tell that loading bitstreams works, because I have a softcore that I can load and get a BIOS prompt.07:08
xobsI'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 #timvideos07:17
Shari2Hi.07:17
xobsHello07:18
_florent_hi07:22
_florent_xobs: i can probably help07:23
_florent_xobs: which etherbone soc are you testing in arty?07:23
_florent_xobs: i can do a quick test if you want07:23
xobs_florent_: I'm just trying to validate it works at all.07:24
xobshttps://gist.github.com/xobs/4064da5d24523092bf19c89bd42194a0 (you can remove the "lxbuildenv" from the top.)07:25
tpbTitle: arty.py · GitHub (at gist.github.com)07:25
_florent_xobs: on the arty, you need to generate a clock for the ethernet07:25
_florent_xobs: not sure the example_designs in liteeth are doing that07:26
_florent_xobs: this one should work: https://github.com/enjoy-digital/arty-soc/blob/master/arty_etherbone.py07:26
tpbTitle: arty-soc/arty_etherbone.py at master · enjoy-digital/arty-soc · GitHub (at github.com)07:26
xobsOh. Thanks!  I'll take a look at arty-soc then.07:27
xobsI 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
xobsIs 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 that07:37
_florent_xobs: you can ignore the assert for now07:37
_florent_xobs: fixed, thanks07:40
_florent_xobs: https://github.com/enjoy-digital/arty-soc/blob/master/arty_base.py#L106-L11007:41
tpbTitle: 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 arty07:41
xobsAh, 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 IRC08:55
*** thomas18 has joined #timvideos09:06
*** thomas18 has quit IRC09:09
*** futarisIRCcloud has quit IRC09:20
*** shenki has joined #timvideos09:59
*** ChanServ sets mode: +v shenki09:59
*** futarisIRCcloud has joined #timvideos10:08
*** ben_zen19 has joined #timvideos11:28
*** Guest45420 has joined #timvideos11:32
*** Guest45420 has quit IRC11:37
futarisIRCcloudIs it possible to enable a FPU co-processor for any of the cores in litex?12:15
*** rohitksingh_work has quit IRC12:31
shornefutarisIRCcloud: the openrisc core has fpu12:31
shorneon mor1kx its parameter FEATURE_FPU="ENABLE"12:32
shornehttps://github.com/openrisc/mor1kx12:32
tpbTitle: GitHub - openrisc/mor1kx: mor1kx - an OpenRISC 1000 processor IP core (at github.com)12:32
futarisIRCcloudshorne: Cheers. Only the older openrisc gcc port supports hard fpu, right?12:37
*** GigabytePro15 has joined #timvideos12:48
*** GigabytePro15 has quit IRC12:53
*** dysfigured22 has joined #timvideos14:00
*** dysfigured22 has quit IRC14:03
*** futarisIRCcloud has quit IRC14:48
*** Dworf has joined #timvideos15:07
*** Dworf has quit IRC15:11
*** thaytan has quit IRC15:16
*** thaytan has joined #timvideos15:32
*** ChanServ sets mode: +v thaytan15:32
mithroxobs: We have Etherbone software working in LiteX-BuildEnv15:57
xobsmithro: 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
mithroxobs: Did you see my question about an Etherbone C library?16:03
xobsno, where was that?16:03
mithroxobs: Earlier the other day16:05
cr1901_moderntinyfpga: 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 it16:06
cr1901_modern(b/c litex-buildenv expects a user to upload the bitstream+bios+payload concatenated together)16:07
mithroxobs: https://github.com/enjoy-digital/litescope/issues/816:10
tpbTitle: Support pulseview / sigrok directly · Issue #8 · enjoy-digital/litescope · GitHub (at github.com)16:10
mithroxobs: https://github.com/mithro/libsigrok/tree/litescope/src/hardware/litescope16:11
tpbTitle: libsigrok/src/hardware/litescope at litescope · mithro/libsigrok · GitHub (at github.com)16:11
cr1901_modernmithro: Bikeshed time: Did you originally write the mimasv2 base.py16:11
mithrocr1901_modern: No idea - git blame is your friend16:11
cr1901_modernIf you build a mimasv2 base.py, you'll get a regions.ld that looks like this: http://ix.io/1lXU16:14
cr1901_modernI wonder how much "bad practice" it is to define overlapping regions in a linker script16:14
cr1901_modernmithro: 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_modernI 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_modernTurns 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_moderna "main_flash" section, for litex-buildenv targets with a payload that runs from SPI flash*16:21
mithroxobs: I think we should have a good etherbone C only library (and maybe csr read/write)16:21
cr1901_modernI'll just eat the "overlapping sections"...16:22
xobsmithro: 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 bridge16:22
tpbTitle: 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_modernThat's good... arachne-pnr fails to route my soc on bx (b2 is fine), and nextpnr crashes16:27
xobsmithro: A more concise implementation made it into the SpinalHDL "vexriscv" implementation: https://github.com/SpinalHDL/openocd_riscv/blob/riscv_spinal/src/target/vexriscv.c#L92816:28
tpbTitle: openocd_riscv/vexriscv.c at riscv_spinal · SpinalHDL/openocd_riscv · GitHub (at github.com)16:28
CarlFKshorne: 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.html16:36
tpbTitle: GitHub - timvideos/qemu-litex (at github.com)16:36
CarlFKshorne: 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 doing16:37
*** Ckat11 has joined #timvideos16:56
*** Shari2 has quit IRC17:05
*** rohitksingh has joined #timvideos17:20
mithroxobs: Yeah17:31
*** rohitksingh has quit IRC17:33
mithroxobs: The API seems to turn out okay -> https://github.com/mithro/libsigrok/blob/litescope/src/hardware/litescope/protocol.c#L135-L14117:33
tpbTitle: libsigrok/protocol.c at litescope · mithro/libsigrok · GitHub (at github.com)17:33
mithroxobs: https://github.com/mithro/libsigrok/blob/litescope/src/hardware/litescope/protocol.c#L162-L18617:34
tpbTitle: libsigrok/protocol.c at litescope · mithro/libsigrok · GitHub (at github.com)17:34
*** rohitksingh has joined #timvideos17:34
mithrocr1901_modern: I have no idea about how bad overlapping regions in a linker script are17:35
*** rohitksingh has quit IRC17:46
*** rohitksingh has joined #timvideos18:04
*** rohitksingh has quit IRC18:14
tinyfpga_florent_: I need some CDC advice if you have a moment18: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 rate18: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 domain18:30
tinyfpga_florent_: the other option I’m looking at is a very small async fifo, maybe 2 deep18:31
tinyfpgamithro: 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
mithrotinyfpga: Try #m-labs - sb0 and whitequark are good18:45
mithrotinyfpga: Bunnie has some advice in his wiki doc too18:45
mithrotinyfpga: https://github.com/timvideos/litex-buildenv/wiki/LiteX-for-Hardware-Engineers#sync18:48
tpbTitle: LiteX for Hardware Engineers · timvideos/litex-buildenv Wiki · GitHub (at github.com)18:48
mithrotinyfpga: https://m-labs.hk/migen/manual/reference.html#module-migen.genlib.fifo19:00
mithrotinyfpga: BTW Did you find https://github.com/m-labs/migen/blob/master/migen/genlib/cdc.py ?19:05
tpbTitle: migen/cdc.py at master · m-labs/migen · GitHub (at github.com)19:05
tinyfpgamithro: thanks, those are what I’ve been referencing :)19:06
tinyfpgamithro: I think a tiny async fifo will be the best option19:07
mithrotinyfpga: 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#L10619:08
tpbTitle: 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
mithrotinyfpga: What this small bus for?19:11
_florent_mithro: i would need more information about the signals to advice for something else than asyncfifo19:11
mithrotinyfpga: I assume 48MHz -> slow speed?19:11
tinyfpgamithro, _florent_: yeah, it’s between an internal USB PHY running at 48MHz and the system clock domain which could be 12 - 100 MHz19:14
tinyfpgamithro, _florent_: it’s a small bus, 4 bits wide with an additional19:14
tinyfpga...valid signal19:14
mithrotinyfpga: Why 4 bits?19:15
tinyfpgamithro: this is not the data path, it’s the control path19:15
mithrotinyfpga: What's the control path look like?19:15
tinyfpgamithro: it’s the info needed to initiate a new packet19:15
tinyfpgamithro: just the usb packet type19:16
mithrotinyfpga: Is it expose via a CSR?19:16
mithroAnother random old doc -> https://docs.google.com/document/d/11uzjWRWk9-KuBFc7chUNUluL5ajysY2qfXvt1vttl7k/edit?usp=drivesdk19:20
tpbTitle: LiteX Firmware - Google Docs (at docs.google.com)19:20
tinyfpgamithro: no, this requires fast response for data ACK or NAK, CPU not fast enough19:25
mithroLunch time for me19:26
mithrotinyfpga: push the code somewhere?19:26
tinyfpgamithro: tonight19:27
*** puff3 has joined #timvideos19:55
*** puff3 has quit IRC19:59
*** rohitksingh has joined #timvideos20:11
*** rohitksingh has quit IRC20:21
*** Peng_18 has joined #timvideos20:32
*** Peng_18 has quit IRC20:37
*** [d__d] has quit IRC20:42
shorneCarlFK: 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
shornebut it sounds like a general issue that needs fixing, which compiler are you using?20:44
*** [d__d] has joined #timvideos20:44
shorneCarlFK: oh... I see it looks like you somehow are missing some linux headers20:45
shornelet me know if you still have the issue20:49
shorneCarlFK: oh... I see your patch.  Its already applied in upstream qemu20:50
shornefutaris[m]: Yes, on GCC, I haven't added FPU native support yet.  Was on todo list after initial upstreaming20:51
shorneHas anyone tried the new OpenRISC GCC port?20:52
shorneCarlFK: 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 memory20:56
CarlFK[m]shorne I'm trying to build the timvideos/qemu that was forked over a year ago20:59
shorneok, I guess due to recent glibc changes it doesnt build on new distro's we will need to rebase the patches21: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_modernmithro: https://github.com/YosysHQ/nextpnr/issues/6922:20
tpbTitle: Using `PLLOUTGLOBAL` on PLL results in :Assertion failure" · Issue #69 · YosysHQ/nextpnr · GitHub (at github.com)22:20
cr1901_moderntinyfpga: Have you been using arache or nextpnr for your SoCs?22:20
tinyfpgacr1901_modern: arachne22:20
cr1901_modernfascinating... arachne is pretty consistently failing to route for me22:21
cr1901_modernBX only22:21
cr1901_modernB2 works fine ._.22:21
tinyfpgacr1901_modern: it failed to route the cpu for me as well22:21
tinyfpgacr1901_modern: I’m just using the UART bridge for now22:21
cr1901_modernAhhh, I must've not noticed then22:21
tinyfpgacr1901_modern: I think I’ll have to move to nextpnr once I want to use a cpu core22:22
cr1901_modernarachne can route B2 just fine, but it's choking on BX. Looks like I never tested BX on arachne until today.22:22
cr1901_moderntinyfpga: See yosys chat, you won't want to route the PLL to an SB_GB if you're using PLLOUTGLOBAL22:38
cr1901_modernI didn't know this until now, so I've spent 2 years wasting an SB_GB22:38
mithrocr1901_modern / tinyfpga: Are you forcing the clock to use the global route?23:09
cr1901_modernmithro: Yes, but contrary to what I am _supposed_ to do, I'd been additionally routing the clock to _another_ global buffer23:10
cr1901_modernmeaning I've been wasting a SB_GB all this time.23:10
tinyfpgamithro, cr1901_modern: i just use PLLOUTGLOBAL23:11
cr1901_moderntinyfpga: Oh so you were smart enough to remove the SB_GB in my example code I showed you :P?23:12
*** futarisIRCcloud has joined #timvideos23:25
*** twoolie has joined #timvideos23:25
*** twoolie has quit IRC23:41
shorneCarlFK[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!