<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.
<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
<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.
<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.
<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>
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>
`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?