04:19 <promach3> _florent_: however I suppose `tWR` is not needed for `WRITE_AP` where it is using AUTO-PRECHARGE mechanism ?

04:20 <promach3> I mean no need to manually compute the Precharge Time

04:27 <promach3> by the way, for Micron definition on `DM` , it is a bit confusing on how exactly `DM` works ?

05:26 <j4cbo> hi! i'm trying to run linux-on-litex-vexriscv on my ecpix5, and i've got the gateware built from litex_boards and found prebuilt linux images at https://github.com/litex-hub/linux-on-litex-vexriscv/issues/164 but am stuck on getting the device tree `rv32.dtb`... is there a way to generate that from the litex_boards repo or do i need to rebuild with linux-on-litex-vexriscv/make.py ?

08:50 <_florent_> promach3: DM is a data mask for writes, similar to Wishbone's sel, AXI's strobe. Writing a DRAM controller can be complicated since there are lots of things to do correctly and as you see, reading datasheets does not always give you a clear understanding. Before writing your own, I would first recommend playing with one controller in simulation: Xilinx's MIG, LiteDRAM, Ultraembedded's DDR3 controller, etc...

08:51 <_florent_> promach3: This will gives you a better understanding of things and you could then implement your own ideas

08:53 <_florent_> promach3: For LiteDRAM, with LiteX installed, it's pretty easy to create a simulation with various DRAM modules (can be SDR/DDR/DDR2/DDR3/DDR4): litex_sim --with-sdram --sdram-module=xxyy --trace

08:53 <_florent_> This will allow you to see the internal signals and how the DFI interface should behave

09:11 <promach3> _florent_: See https://gist.github.com/promach/2c477b1dbc39f04a1271fb229e6d678c

09:13 <promach3> why need to mask ? What will happen if user choose to pull DM to low logic during write cycle ? and is this allowed at all ?

09:25 <_florent_> promach3: this is allowed yes to have DM always pulled low (some boards are wired like this) but will make you loose the byte granularity on writes, your granularity is then on DRAM's burst words.

09:27 <_florent_> promach3: DM is just here to have byte granularity on the write accesses (ie you only want to update some bytes of the DRAM word)

09:29 <promach3> _florent_: you mean `DM` has the purpose or meaning of `bit-select` in verilog ?

09:36 <_florent_> promach3: When writes are done on bus with a data-width > 8, you are doing a single write for multiple bytes and then need to be able to indicate which bytes are valid and need to be updated in memory, which bytes should be ignored. That's the purpose of DM.

09:46 <pftbest> j4cbo: when you run linux-on-litex-vexriscv/make.py it will generate a dtb file in the images directory.

09:47 <promach3> _florent_: so, for simplicity, just hardwire `DM` to low logic ?

09:50 <promach3> but `DM` (or `TDQS` pin) is of `inout` nature

10:08 <_florent_> promach3: yes start simple with DM as output hardwired to 0

10:08 <promach3> but the pin itself is `inout` ?

10:08 <promach3> _florent_:

10:16 <_florent_> You can just use it as an output

11:09 <promach3> _florent_: but `TDQS_n` needs to be `High-Z` ?

12:24 <pftbest> How to stop litex_sim ?

12:27 <pftbest> is Ctrl+C a good way to stop it?

13:09 <_florent_> pftbest: yes, that's the way to do it. (We should probably improve this)

18:57 <zyp> has anybody tried integrating the luna usb stack with litex?

20:06 <_florent_> zyp: I think Greg Davill did some tests with Luna and LiteX

20:17 <_florent_> https://github.com/gregdavill/ButterStick-projects/commit/7c3a714b6e6817bd1d430d6ba120dde419d1e3a0

20:19 <zyp> ah, nice

21:21 <zyp> not having any luck with etherbone on ecpix-5, getting neither ping nor arp replies