freemint has quit [Quit: Leaving]
CarlFK has joined #litex
rohitksingh has joined #litex
rohitksingh has quit [Ping timeout: 265 seconds]
rohitksingh has joined #litex
<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.
rohitksingh has quit [Ping timeout: 265 seconds]
rohitksingh has joined #litex
CarlFK has quit [Quit: Leaving.]
CarlFK has joined #litex
rohitksingh has quit [Ping timeout: 265 seconds]
CarlFK has quit [Quit: Leaving.]
rohitksingh has joined #litex
_whitelogger has joined #litex
<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:
<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...
<sajattack> is that bunnie huang?
<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...
<bunnie[m]> <sajattack "is that bunnie huang?"> hi, that's me!
<sajattack> hi dude
<sajattack> you rule
<sajattack> what are you using rust for, just curious?
<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.
<tpb> Title: betrusted-soc/sw at master · betrusted-io/betrusted-soc · GitHub (at github.com)
<bunnie[m]> xobs is implementing an OS in Rust for a secure comms device we are making
<sajattack> nice
<bunnie[m]> I am currently learning rust and writing low level drivers and validating the hardware with a toy Rust environment.
<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.
<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.
<sajattack> yeah I enjoy embedded rust a lot
<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.
<sajattack> yeah PACs are meant to have a framework built on top of them
<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.
<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...
<sajattack> you might get some inspiration from one of the embedded rust hals out there
CarlFK has joined #litex
<sajattack> I think this one is pretty good https://github.com/stm32-rs/stm32f1xx-hal
<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)
<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.
<bunnie[m]> cool, i'll have a look, thanks!
<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.
<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.
<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.
<sorear> far too much of borrowck is defined only by the behavior of one implementation
<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.
<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.
rohitksingh has quit [Ping timeout: 265 seconds]
m4ssi has joined #litex
<_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
<tpb> Title: software, integration/export: (re-)expose CSR subregister accessors · enjoy-digital/litex@ff2775c · GitHub (at github.com)
<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
<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...
<_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.
<tpb> Title: Issues · enjoy-digital/litex · GitHub (at github.com)
<bunnie[m]> that's great! thank you accepting @xobs suggestion, it helps me a lot too.
tumbleweed has quit [*.net *.split]
bunnie[m] has quit [*.net *.split]
tpb has quit [*.net *.split]
levi has quit [*.net *.split]
esden has quit [*.net *.split]
_florent_ has quit [*.net *.split]
Claude has quit [*.net *.split]
felix_ has quit [*.net *.split]
m4ssi has quit [*.net *.split]
proppy has quit [*.net *.split]
_franck_ has quit [*.net *.split]
sorear has quit [*.net *.split]
scanakci has quit [*.net *.split]
somlo has quit [*.net *.split]
daveshah has quit [*.net *.split]
kgugala has quit [*.net *.split]
miek has quit [*.net *.split]
xobs has quit [*.net *.split]
Dolu has quit [Ping timeout: 268 seconds]
esden has joined #litex
_florent_ has joined #litex
felix_ has joined #litex
Claude has joined #litex
tumbleweed has joined #litex
bunnie[m] has joined #litex
levi has joined #litex
tpb has joined #litex
proppy has joined #litex
m4ssi has joined #litex
scanakci has joined #litex
_franck_ has joined #litex
sorear has joined #litex
miek has joined #litex
kgugala has joined #litex
somlo has joined #litex
daveshah has joined #litex
Dolu has joined #litex
futarisIRCcloud has quit [Ping timeout: 260 seconds]
sorear has quit [Ping timeout: 244 seconds]
futarisIRCcloud has joined #litex
sorear has joined #litex
_franck_ has quit [Remote host closed the connection]
xobs has joined #litex
<xobs> mithro: I'm working on using toctree like you said we should, but I'm still really confused. Are you available to help?
<xobs> This is in preparation for merging it into litex.
_franck_ has joined #litex
<mithro> xobs: Sure
<xobs> Let me put what I've got online somewhere. Just a moment.
<xobs> Hmm... Actually, it seems like it's just a problem when using "material" as a theme.
<tpb> Title: Documentation for Fomu Bootloader Fomu Bootloader documentation (at doctest.xobs.io)
<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.
<mithro> xobs: Were are you installing the theme from?
<xobs> mithro: `pip install sphinx-material`
<tpb> Title: GitHub - SymbiFlow/sphinx_materialdesign_theme: Material Design Html Theme for Sphinx. (at github.com)
<xobs> mithro: doesn't work. It gives a `ValueError: bad marshal data (unknown type code)` error.
<mithro> xobs: Full error please?
<tpb> Title: python .\setup.py install · GitHub (at gist.github.com)
<mithro> Does `pip install git+https://github.com/SymbiFlow/sphinx_symbiflow_theme/` work?
<xobs> Yes, that does work. Should the docs be updated, then?
<mithro> I'm confused why the python setup.py install is installing `__pycache__` files...
<xobs> I'm not sure, either. There actually are two other commands I ran before running the installer: `git clone git@github.com: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.
<mithro> xobs: I just pushed a change which adds them to the exclude....
<mithro> xobs: Did that fix things?
<xobs> mithro: the last change I see in that repo was on 30/09/2019 620cf26b0d3c7919f04c1630cba782a204dfa21d
<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/)?
<tpb> Title: GitHub - SymbiFlow/sphinx_materialdesign_theme: Material Design Html Theme for Sphinx. (at github.com)
<mithro> xobs: I'm confused too...
<mithro> xobs: Try "pip install sphinx_materialdesign_theme" maybe?
<xobs> `pip install sphinx_materialdesign_theme` worked
rohitksingh has joined #litex
<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.
m4ssi has quit [Remote host closed the connection]
<_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
<acathla> _florent_, when the PHY transmits a frame of 1500bytes on ethernet cable it's only one byte at a time to the MAC?
<_florent_> acathla: yes, one byte at a time
rohitksingh has quit [Ping timeout: 265 seconds]
rohitksingh has joined #litex
fustini_ has joined #litex
rohitksingh has quit [Ping timeout: 265 seconds]
fustini_ is now known as pdp7
pdp7 is now known as fustini_
fustini_ is now known as pdp7
pdp7 has quit [Changing host]
pdp7 has joined #litex
tumbleweed has quit [*.net *.split]
bunnie[m] has quit [*.net *.split]
_florent_ has quit [*.net *.split]
esden has quit [*.net *.split]
Claude has quit [*.net *.split]
felix_ has quit [*.net *.split]
pdp7 has quit [Quit: Updating details, brb]
pdp7 has joined #litex
tumbleweed has joined #litex
bunnie[m] has joined #litex
felix_ has joined #litex
esden has joined #litex
_florent_ has joined #litex
Claude has joined #litex
CarlFK has quit [Ping timeout: 260 seconds]
CarlFK has joined #litex
rohitksingh has joined #litex
CarlFK has quit [Quit: Leaving.]
CarlFK has joined #litex
rohitksingh has quit [Ping timeout: 265 seconds]
CarlFK has quit [Ping timeout: 265 seconds]
CarlFK has joined #litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex