02:44 <bl0x_> _florent_: I've tried a few things, changing clock speed and in general looking about the cmod_a7 related code. Also tried sending serial.tx to another pin as suggested. I can't see any serial output. I see that litex_buildenv claims to have working support for cmod_a7, so I might try that as well. Shouldn't the LEDs also blink a pattern by default? I only see the RGB LEDs at ~30% brightness.

06:28 <sajattack[m]> so this is probably a dumb question, but could litesata be used for ide/pata? is it backwards compatible?

07:58 <tnt> with an external sata -> pata you mean ?

08:37 <_florent_> bl0x_: I merged your PRs, by default the LedChaser should be blinking and only requires a valid clock/reset to do so. The issue could also be related to Symbiflow, if you have Vivado install it could be interesting to test with it. (Or I could generate a bitstream for you)

08:41 <_florent_> sajattack[m]: LiteSATA has a specific user interface and I'm not very familiar with ide/pata. Some chips are doing bridge between SATA and other interfaces, so this could also be an option if such chips exists for ide/pata. With a client on a design we for example used LiteSATA to interface with a SDCard through a DB300 chip: http://www.d-broad.com/db300_eg.html

08:41 <tpb> Title: d-broad Inc. (at www.d-broad.com)

08:43 <sajattack[m]> I was just looking at the ide controller here https://github.com/MiSTer-devel/ao486_MiSTer/blob/master/rtl/soc/ide.v and found it rather incomplete, and was curious if litesata could be used as a replacement, sounds like not without external hardware. tnx.

10:19 <bl0x_> _florent_: Thanks for the merge. I don't have Vivado on my laptop, only on a Windows machine. Tried to install litex there, but that turned out to be a rabbit hole. I might be able to set up an environment with Vivado on a more capable machine, but that'll take a couple of days. Which version of Vivado is currently preferred with litex? ... Generate bitstream for me: Only if it is quick for you to

10:19 <bl0x_> do.

13:24 <leons> Just to confirm my understanding of the LiteDRAM native ports / DMA frontend: LiteDRAM itself does not provide any mechnism to prevent data races, right? I have multiple ports accessing a shared chunk of memory, so I'm wondering what types of guarantees LiteDRAM can give me vs. what protections I need to implement myself.

14:22 <_florent_> leons: LiteDRAM doesn't provide a mechanism for this. The only guarantee currently is that there is no write data buffering internally, so the write order will be the similar to the order it accepts the data on the user ports

14:23 <_florent_> bl0x_: I'm going to generate a bitstream

14:24 <_florent_> https://github.com/litex-hub/litex-boards/files/7882457/digilent_cmod_a7_2022_01_17.zip

14:24 <bl0x_> _florent_: thx

14:24 <leons> _florent_: Thanks, that already helps me a lot. I have a small hazard detection component which is suboptimal but constant-size and time, exactly what I need for my usecase.

14:24 <_florent_> result of ./digilent_cmod_a7.py --build

14:25 <leons> _florent_: The only thing which would be really helpful to know is the latency which an accepted `wdata` transaction takes until it is committed to memory and can be read again. Is that latency known somehow?

14:29 <bl0x_> _florent_: I get nice blinking lights now! And a litex prompt when using lxterm. great! Now, the question is what's going wrong with symbiflow?

14:31 <_florent_> leons: this latency is fixed yes (the reason is still similar: there is no buffering, the data is accepted one it is emitted). If you want to measure it, you could put a LiteScope instance in your design and observe the ready from the wdata port and some internal control path signals of the PHY: https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/s7ddrphy.py#L490-L502

14:32 <leons> Thanks for the pointers! I'll look into that :)

14:37 <_florent_> bl0x_: You should probably report this to the symbiflow project, since you had to do some adaptation to the LiteX build backend, I imagine it's something that hasn't been tested with LiteX

14:40 <bl0x_> _florent_: Will do. Thanks again

16:11 <Wolfvak> I just noticed that on the orangecrab, the linux project uses a spi driver to interface with the SD card rather than the dedicated controller, is there any reason for that?

16:37 <Wolfvak> nvm just found https://github.com/litex-hub/linux-on-litex-vexriscv/issues/255

20:51 <Guest48> Hi there, I hope this is the right place to seek help. Im trying to send bits to ttyACM from fomu with litex. These bits are generated from migen code, so in hardware, not from a programm running on the cpu. Currently litex seems to be using its own fork of valentyusb, however I have trouble to understand where exactly I can send the bits, meaning

20:51 <Guest48> how the valentyusb api works. A snippet would be greatly appreciated. Or can I not use valentyusb in this manner? So far I've been trying with the serv cpu, because it fit. And when I tried --cpu-type=None it gave me csr collision errors, which I didnt know how to resolve. For my design I dont actually need a cpu though (I think). Help is greatly

20:51 <Guest48> appreciated. And thanks for the work in litex it seems quite awesome, although I only understand a fraction of it.

21:55 <bl0x_> I'm wondering what the cd_sys4x is used for. Looking around litex I find that this is mostly associated with litedram? Boards without DRAM would not need these clock, or am I wrong?

21:58 <bl0x_> Perhaps that is just a general thing to always have a CD ready for serdes?