| *** tpb has joined #litex | 00:00 | |
| *** freemint has quit IRC | 00:22 | |
| *** CarlFK has joined #litex | 00:27 | |
| *** rohitksingh has joined #litex | 00:49 | |
| *** rohitksingh has quit IRC | 01:03 | |
| *** rohitksingh has joined #litex | 03:25 | |
| xobs | daveshah: I wonder if that has to do with the CSR changes. bunnie mentioned to me on Monday that he noticed the new CSR accessor methods weren't marked "volatile" anymore, so the compiler was optimizing out writes and reads. | 03:29 |
|---|---|---|
| *** rohitksingh has quit IRC | 03:33 | |
| *** rohitksingh has joined #litex | 04:09 | |
| *** CarlFK has quit IRC | 05:10 | |
| *** CarlFK has joined #litex | 05:11 | |
| *** rohitksingh has quit IRC | 05:12 | |
| *** CarlFK has quit IRC | 05:17 | |
| *** rohitksingh has joined #litex | 05:36 | |
| *** _whitelogger has quit IRC | 06:43 | |
| *** _whitelogger has joined #litex | 06:46 | |
| bunnie[m] | <xobs "daveshah: I wonder if that has t"> yah I'm running a slightly behind litex branch, 1f7549b4c0f7487ec5af94a32008c8c5004194a5, but I spent a whole day debugging this thing: | 06:48 |
| bunnie[m] | After I copied that into a local statement which includes a volatile, the loop worked. I thought for the longest time it was the CPU hanging on a bad memory access (problem in my peripheral block) until I finally broke out the PC/instruction registers and traced it back to the disassembled code... | 06:49 |
| sajattack | is that bunnie huang? | 06:49 |
| bunnie[m] | This was all just for the simulation environment which is in C, but for production we are using Rust which is why I haven't dug into the issue more... | 06:49 |
| bunnie[m] | <sajattack "is that bunnie huang?"> hi, that's me! | 06:50 |
| sajattack | hi dude | 06:50 |
| sajattack | you rule | 06:50 |
| sajattack | what are you using rust for, just curious? | 06:51 |
| bunnie[m] | oh. wow, thank you! There are many people in this channel who rule, and I can only do my things because of their awesomeness. | 06:51 |
| bunnie[m] | https://github.com/betrusted-io/betrusted-soc/tree/master/sw | 06:52 |
| tpb | Title: betrusted-soc/sw at master · betrusted-io/betrusted-soc · GitHub (at github.com) | 06:52 |
| bunnie[m] | xobs is implementing an OS in Rust for a secure comms device we are making | 06:52 |
| sajattack | nice | 06:52 |
| bunnie[m] | I am currently learning rust and writing low level drivers and validating the hardware with a toy Rust environment. | 06:53 |
| bunnie[m] | Interestingly, we have found that a 32-bit CSR bus is both faster and less resources in the FPGA, and also obviously better for the code. I haven't disentangled if the loss of "volatile" in the csr.h file could be an artetfact of that change, either. | 06:54 |
| levi | I am hoping to use rust to do drivers for some of my fgpa+riscv projects; still getting my peripheral support sorted out first though. | 06:55 |
| sajattack | yeah I enjoy embedded rust a lot | 06:56 |
| bunnie[m] | I can tell you I am not terribly happy with the PAC crate, but because it supports direct generation of accessors from SVDs that are autogenerated by Litex, I think we are going to continue using it. I'm currently wrapping it in macros to not suffer through the syntax as much. | 06:56 |
| sajattack | yeah PACs are meant to have a framework built on top of them | 06:56 |
| bunnie[m] | I see. that was not obvious to a Rust noob like me, I've been banging my head on that wall. But the good news is it gave me a reason to learn macro syntax in Rust. | 06:57 |
| bunnie[m] | The other problem with PAC is that it creates a single "peripheral" object for the entire peripheral system. So either you are allocating one master hardware object and passing it between every driver (including like, reading the timer periodically), or you're doing unsafe "steal" operations routinely. I feel like it would have been smarter to create an accessor on a per-peripheral basis. But I digress... | 06:59 |
| sajattack | you might get some inspiration from one of the embedded rust hals out there | 07:00 |
| *** CarlFK has joined #litex | 07:01 | |
| sajattack | I think this one is pretty good https://github.com/stm32-rs/stm32f1xx-hal | 07:01 |
| tpb | Title: GitHub - stm32-rs/stm32f1xx-hal: A Rust embedded-hal HAL impl for the STM32F1 family based on japarics stm32f103xx-hal (at github.com) | 07:01 |
| bunnie[m] | I think @xobs is figuring out ways to improve this in Xous, he has the misfortune of getting to hear me be grumpy in real time. | 07:01 |
| bunnie[m] | cool, i'll have a look, thanks! | 07:01 |
| levi | Something that's not immediately obvious is that you can move or borrow *partial* structs, and the compiler ensures that you don't do anything unsafe with the whole after parts are portioned out. | 07:10 |
| levi | The HAL crates do that pretty regularly in their implementations, and they also tend to do interesting macro things to build their friendlier interfaces across e.g. multiple pin config registers. | 07:12 |
| levi | Making a HAL crate that fits the pattern of the existing ones is definitely a bit daunting, but fortunately litex-based designs seem to provide way fewer csrs than your typical commercial microcontroller these days. | 07:15 |
| sorear | far too much of borrowck is defined only by the behavior of one implementation | 07:19 |
| bunnie[m] | I think because litex lets you build exactly the hardware you need, you can get rid of a ton of option registers. Like, it's no problem to build an i2s block in hardware that only supports 16-bit MSB-aligned stereo datatypes, because later on if you need to do something else, you can just reconfigure the FPGA. But if I were to commit the design to silicon, I imagine I'd probably add a lot more CSRs to configure other modes. | 07:30 |
| bunnie[m] | So I guess if litex ever wants to support a silicon tape-out flow, probably it will need to scale up to lots and lots of CSRs like a more "typical" SoC. And it would be neat if someday Litex were a foundry-qualified flow. | 07:30 |
| *** rohitksingh has quit IRC | 08:04 | |
| *** m4ssi has joined #litex | 08:12 | |
| _florent_ | xobs, bunnie: thanks for the feedback on CSRs, for the issue, was it with a LiteX version before the last CSR change https://github.com/enjoy-digital/litex/commit/ff2775c264cc452a05119dd895e25b559867dac2? With it the accesses are done with csr_write_simple/csr_read_simple that should be marked as volatile: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/include/hw/common.h#L40-L52 | 08:17 |
| tpb | Title: software, integration/export: (re-)expose CSR subregister accessors · enjoy-digital/litex@ff2775c · GitHub (at github.com) | 08:17 |
| bunnie[m] | yes, my version of litex is from Jan 24th, and this commit is from 6 days ago, so it seems it was from a version before that last CSR change | 08:19 |
| bunnie[m] | it looks like the CSR change got largely backed out, yes? that's good, i was very worried it could cause all kinds of subtle breakage... | 08:22 |
| _florent_ | yes, in your version, gsomlo created very generic CSR accessor that work for all endianness/csr_data_width cases and we were using this for the CSR read/write functions of csr.h, but as we figure dout discussing with xobs in https://github.com/enjoy-digital/litex/issues/365, csr.h should use dedicated accessors for performance, so we got back to a cleaned up version of what was used before. | 08:34 |
| tpb | Title: Issues · enjoy-digital/litex · GitHub (at github.com) | 08:34 |
| bunnie[m] | that's great! thank you accepting @xobs suggestion, it helps me a lot too. | 08:41 |
| *** tumbleweed has quit IRC | 11:15 | |
| *** bunnie[m] has quit IRC | 11:15 | |
| *** _florent_ has quit IRC | 11:15 | |
| *** esden has quit IRC | 11:15 | |
| *** Claude has quit IRC | 11:15 | |
| *** felix_ has quit IRC | 11:15 | |
| *** m4ssi has quit IRC | 11:15 | |
| *** proppy has quit IRC | 11:15 | |
| *** _franck_ has quit IRC | 11:15 | |
| *** scanakci has quit IRC | 11:15 | |
| *** sorear has quit IRC | 11:15 | |
| *** somlo has quit IRC | 11:15 | |
| *** daveshah has quit IRC | 11:15 | |
| *** kgugala has quit IRC | 11:15 | |
| *** miek has quit IRC | 11:15 | |
| *** mithro has quit IRC | 11:15 | |
| *** goran-mahovlic has quit IRC | 11:15 | |
| *** Xark has quit IRC | 11:15 | |
| *** _whitelogger has quit IRC | 11:15 | |
| *** futarisIRCcloud has quit IRC | 11:15 | |
| *** guan has quit IRC | 11:15 | |
| *** flammit has quit IRC | 11:15 | |
| *** dkozel has quit IRC | 11:16 | |
| *** CarlFK has quit IRC | 11:16 | |
| *** sajattack has quit IRC | 11:16 | |
| *** kbeckmann has quit IRC | 11:16 | |
| *** RaYmAn has quit IRC | 11:16 | |
| *** acathla has quit IRC | 11:16 | |
| *** Finde has quit IRC | 11:16 | |
| *** anuejn has quit IRC | 11:16 | |
| *** xobs has quit IRC | 11:16 | |
| *** rvense has quit IRC | 11:16 | |
| *** Xiretza has quit IRC | 11:16 | |
| *** vup has quit IRC | 11:16 | |
| *** keesj has quit IRC | 11:16 | |
| *** st-gourichon-fid has quit IRC | 11:16 | |
| *** spacekookie has quit IRC | 11:16 | |
| *** Dolu has quit IRC | 11:16 | |
| *** bonzibuddy has quit IRC | 11:16 | |
| *** davidc__ has quit IRC | 11:16 | |
| *** key2 has quit IRC | 11:16 | |
| *** gruetzkopf has quit IRC | 11:16 | |
| *** nrossi has quit IRC | 11:16 | |
| *** palmer has quit IRC | 11:16 | |
| *** loxodes has quit IRC | 11:16 | |
| *** bunnie[m] has joined #litex | 11:20 | |
| *** tumbleweed has joined #litex | 11:20 | |
| *** felix_ has joined #litex | 11:20 | |
| *** Claude has joined #litex | 11:20 | |
| *** _florent_ has joined #litex | 11:20 | |
| *** esden has joined #litex | 11:20 | |
| *** CarlFK has joined #litex | 11:20 | |
| *** _whitelogger has joined #litex | 11:20 | |
| *** sajattack has joined #litex | 11:20 | |
| *** loxodes has joined #litex | 11:20 | |
| *** futarisIRCcloud has joined #litex | 11:20 | |
| *** gruetzkopf has joined #litex | 11:20 | |
| *** kbeckmann has joined #litex | 11:20 | |
| *** RaYmAn has joined #litex | 11:20 | |
| *** st-gourichon-fid has joined #litex | 11:20 | |
| *** spacekookie has joined #litex | 11:20 | |
| *** Xiretza has joined #litex | 11:20 | |
| *** anuejn has joined #litex | 11:20 | |
| *** guan has joined #litex | 11:20 | |
| *** mithro has joined #litex | 11:20 | |
| *** rvense has joined #litex | 11:20 | |
| *** nrossi has joined #litex | 11:20 | |
| *** goran-mahovlic has joined #litex | 11:20 | |
| *** acathla has joined #litex | 11:20 | |
| *** Finde has joined #litex | 11:20 | |
| *** Xark has joined #litex | 11:20 | |
| *** palmer has joined #litex | 11:20 | |
| *** key2 has joined #litex | 11:20 | |
| *** flammit has joined #litex | 11:20 | |
| *** bonzibuddy has joined #litex | 11:20 | |
| *** keesj has joined #litex | 11:20 | |
| *** vup has joined #litex | 11:20 | |
| *** dkozel has joined #litex | 11:20 | |
| *** davidc__ has joined #litex | 11:20 | |
| *** m4ssi has joined #litex | 11:20 | |
| *** proppy has joined #litex | 11:20 | |
| *** _franck_ has joined #litex | 11:20 | |
| *** scanakci has joined #litex | 11:20 | |
| *** sorear has joined #litex | 11:20 | |
| *** somlo has joined #litex | 11:20 | |
| *** kgugala has joined #litex | 11:20 | |
| *** daveshah has joined #litex | 11:20 | |
| *** miek has joined #litex | 11:20 | |
| *** Dolu has joined #litex | 11:20 | |
| *** futarisIRCcloud has quit IRC | 11:23 | |
| *** sorear has quit IRC | 11:23 | |
| *** futarisIRCcloud has joined #litex | 11:23 | |
| *** sorear has joined #litex | 11:23 | |
| *** _franck_ has quit IRC | 12:35 | |
| *** xobs has joined #litex | 12:40 | |
| xobs | mithro: I'm working on using toctree like you said we should, but I'm still really confused. Are you available to help? | 12:40 |
| xobs | This is in preparation for merging it into litex. | 12:40 |
| *** _franck_ has joined #litex | 12:40 | |
| mithro | xobs: Sure | 12:41 |
| xobs | Let me put what I've got online somewhere. Just a moment. | 12:43 |
| xobs | Hmm... Actually, it seems like it's just a problem when using "material" as a theme. | 12:50 |
| xobs | https://doctest.xobs.io/_build/html/index.html vs https://doctest.xobs.io/_build/material/index.html | 12:50 |
| tpb | Title: Documentation for Fomu Bootloader Fomu Bootloader documentation (at doctest.xobs.io) | 12:50 |
| xobs | Notably, the "contents" on the right is incorrect in the material theme, but is correct in the normal theme. I'll just chalk that up to a theme error and call it a day. | 12:51 |
| mithro | xobs: Were are you installing the theme from? | 12:58 |
| xobs | mithro: `pip install sphinx-material` | 12:58 |
| mithro | xobs: Try this one -> https://github.com/SymbiFlow/sphinx_materialdesign_theme | 13:00 |
| tpb | Title: GitHub - SymbiFlow/sphinx_materialdesign_theme: Material Design Html Theme for Sphinx. (at github.com) | 13:00 |
| xobs | mithro: doesn't work. It gives a `ValueError: bad marshal data (unknown type code)` error. | 13:02 |
| mithro | xobs: Full error please? | 13:03 |
| xobs | mithro: https://gist.github.com/xobs/fb9edf7083801072464c4dfe3f8b559f | 13:04 |
| tpb | Title: python .\setup.py install · GitHub (at gist.github.com) | 13:04 |
| mithro | Does `pip install git+https://github.com/SymbiFlow/sphinx_symbiflow_theme/` work? | 13:10 |
| xobs | Yes, that does work. Should the docs be updated, then? | 13:11 |
| mithro | I'm confused why the python setup.py install is installing `__pycache__` files... | 13:11 |
| xobs | I'm not sure, either. There actually are two other commands I ran before running the installer: `git clone [email protected]:SymbiFlow/sphinx_materialdesign_theme.git` and `cd sphinx_materialdesign_theme`. I'm not sure what a __pycache__ directory is, but they do exist in that repo. | 13:14 |
| mithro | xobs: I just pushed a change which adds them to the exclude.... | 13:15 |
| mithro | xobs: Did that fix things? | 13:22 |
| xobs | mithro: the last change I see in that repo was on 30/09/2019 620cf26b0d3c7919f04c1630cba782a204dfa21d | 13:37 |
| xobs | Did you want me to use the first repo you sent that didn't work (https://github.com/SymbiFlow/sphinx_materialdesign_theme/) or the one you included as part of the pip command (https://github.com/SymbiFlow/sphinx_symbiflow_theme/)? | 13:37 |
| tpb | Title: GitHub - SymbiFlow/sphinx_materialdesign_theme: Material Design Html Theme for Sphinx. (at github.com) | 13:37 |
| mithro | xobs: I'm confused too... | 13:40 |
| mithro | WTF? `git+http://github.com/SymbiFlow/sphinx_materialdesign_theme.git@master#egg=sphinx_symbiflow_theme` | 13:43 |
| mithro | xobs: Try "pip install sphinx_materialdesign_theme" maybe? | 13:45 |
| xobs | `pip install sphinx_materialdesign_theme` worked | 13:50 |
| *** rohitksingh has joined #litex | 17:09 | |
| acathla | I'm doing open-air infrared communication between small robots. I modified the litex/soc/core/uart.py and it works, but only for 8 bits at a time. The modulated frequency is between 1 and 10MHz. I don't know if re-using the liteeth is a good idea or not (I won't have to write the CRC and headers stuffs again), it seems a bit complicated since I don't have a PHY chip. | 17:12 |
| *** m4ssi has quit IRC | 17:28 | |
| _florent_ | acathla: nice :), the LiteETH PHY interface is very similar to the UART (8-bit data + valid + ready + last), so it should be very similar to what you are already doing. The real difference is that you need to know if you are transmitting (or receiving) to generate the valid/last signals | 17:32 |
| acathla | _florent_, when the PHY transmits a frame of 1500bytes on ethernet cable it's only one byte at a time to the MAC? | 17:37 |
| _florent_ | acathla: yes, one byte at a time | 17:57 |
| *** rohitksingh has quit IRC | 18:39 | |
| *** rohitksingh has joined #litex | 18:45 | |
| *** fustini_ has joined #litex | 18:53 | |
| *** rohitksingh has quit IRC | 18:53 | |
| *** fustini_ is now known as pdp7 | 18:58 | |
| *** pdp7 is now known as fustini_ | 18:59 | |
| *** fustini_ is now known as pdp7 | 19:00 | |
| *** pdp7 has joined #litex | 19:01 | |
| *** tumbleweed has quit IRC | 19:01 | |
| *** bunnie[m] has quit IRC | 19:01 | |
| *** _florent_ has quit IRC | 19:01 | |
| *** esden has quit IRC | 19:01 | |
| *** Claude has quit IRC | 19:01 | |
| *** felix_ has quit IRC | 19:02 | |
| *** pdp7 has quit IRC | 19:02 | |
| *** pdp7 has joined #litex | 19:02 | |
| *** tumbleweed has joined #litex | 19:03 | |
| *** bunnie[m] has joined #litex | 19:03 | |
| *** esden has joined #litex | 19:03 | |
| *** _florent_ has joined #litex | 19:03 | |
| *** Claude has joined #litex | 19:03 | |
| *** felix_ has joined #litex | 19:03 | |
| *** CarlFK has quit IRC | 19:09 | |
| *** CarlFK has joined #litex | 20:32 | |
| *** rohitksingh has joined #litex | 20:37 | |
| *** CarlFK has quit IRC | 21:06 | |
| *** CarlFK has joined #litex | 21:16 | |
| *** rohitksingh has quit IRC | 21:29 | |
| *** CarlFK has quit IRC | 22:08 | |
| *** CarlFK has joined #litex | 23:11 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!