00:57 <subthreshold> Hello and hope everyone is doing well! I have a couple of questions regarding the LPDDR4 DRAM model in the LiteDRAM repo.

00:58 <subthreshold> I would like to be able to use the Verilog generated by the toolchain in simulations with other PHYs.

01:01 <subthreshold> However, currently I am having issues extracting this. I have instantiated an isolated LPDDR4Sim and have given it "pads = LPDDR4SimulationPads()" in a barebone main function, and am using the convert function to emit verilog.

01:02 <subthreshold> However, the inputs and outputs ports are missing/ incorrect and I suspect this is because of a lack of proper source-sink connection? Is there a recommened way for doing this.

01:02 <subthreshold> Thanks!

06:30 <_florent_> Hi subthreshold (if you read the logs), the PHYs have a DFI interface, but the generator to extract only the core would need to be written. This could probably be based on the LiteDRAM generator https://github.com/enjoy-digital/litedram/blob/master/litedram/gen.py and a fake PHY that would just expose the DFI interface. This would be at least a few hours to a few days of work, so I can only give direction on this. In the long term

06:30 <_florent_> it would also be nice to be able to use Xilinx's MIG PHYs (or Intel PHY) with LiteDRAM, but I'm waiting for an opportinity to do this (need on a project).

06:51 <subthreshold> Hi Florent, thanks for the guidance on this! So if I am understanding correctly, essentially i would need to sort of wrap the LPDDR4 DRAM model within a generator similar to the one you linked.

06:53 <subthreshold> Also, I am having a bit of trouble understanding (and perhaps this is arising from unfamiliarity with migen) why a barebones initialization of the LPDDR4 Model yields incorrect (or strange) ports. What is the underlying mechanism needed to generate these ports correctly?

06:54 <subthreshold> In a more concrete way, coming from a Verilog, if I declared input/outputs they would show up at the synthesized top-level.

06:55 <_florent_> To do what you want, you could create a fake LPDDR4 with just the DFI interface and expose it as IOs (ie use the top part of S7LPDDR4PHY and replace the IOs primitives with exposition of DFI interfaces)

06:56 <_florent_> or start from the model and do the same: https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/model.py

06:57 <_florent_> Here in LiteDRAM generator, you first have to create the IOs in the Sim platform

07:02 <subthreshold> Thanks - i will do some legwork on my side and see how it pans!

07:31 <subthreshold> Hi Florent, I went to take a look at your links and I think I have a slightly different target in mind. In the system chain here:

07:31 <subthreshold> MC --> LPDDR4 -->  // CUT //  LPDDR4 DRAM DEVICE

07:31 <subthreshold> I would like to be able to utilize the LPDDR4 Device model as a standalone in another testbench. In essence, I'

07:31 <subthreshold> d

07:34 <subthreshold> like to be able to expose the device ports (CKE, CA, DQ, DQS, etc.).  I'm actually trying to remove anything upstream (including the DFI interface) as I need to generate verilog representing the device alone for use in a standalone testbench outside the LiteX ecosystem

07:35 <subthreshold> I just realized I made a typo in that tool chain word art. MC --> LPDDR4 PHY --> // CUT // LPDDR4 DRAM DEVICE

09:12 <_florent_> subthreshold: ok sorry, I see now. So you would need to create a generator for LPDDR4Sim.

09:12 <_florent_> subthreshold: you could use the LiteSDCard generator as a basis (easier to follow than LiteDRAM generator): https://github.com/enjoy-digital/litesdcard/blob/master/litesdcard/gen.py

09:12 <_florent_> subthreshold: replace the SDCard pads with the LPDDR4 pads

09:13 <_florent_> https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/lpddr4/simphy.py#L16-L28

09:13 <_florent_> Then integrate the LPDDR4Sim in replacement of the SDCard core.

09:14 <_florent_> And see here for the LPDDR4Sim parameters: https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/lpddr4/simphy.py#L39-L43

09:14 <_florent_> https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/lpddr4/sim.py#L41-L55

09:14 <_florent_> Sorry I was just passing by, I have to go

20:51 <Guest94> Hi Florent (subthreshold here)! Thanks for guidance on that. I've more or less managed to do what you mentioned!

20:52 <Guest94> However, one element that is difficult is:

20:52 <Guest94> How we handle the tristate IO.

20:53 <Guest94> For example, in the pads declaration there is: SimPad("dq", databits, io=True),

20:53 <Guest94> converting to verilog, it turns this into: output reg [15:0] lpddr4simulationpads,

20:54 <Guest94> and internally within the module it creates:

20:54 <Guest94> reg [15:0] lpddr4simulationpads_dq_o = 16'd0;

20:54 <Guest94> reg [15:0] lpddr4simulationpads_dq_i;

20:54 <Guest94> reg lpddr4simulationpads_dq_oe = 1'd0;

21:12 <Guest94> I've tried searching for an attribute in the generator code where I can find where SimPad is transformed into output, input and OE but currently unsuccessful

22:17 <Guest94> Just a quick update: was able to scape the dq_i, dq_oe, dq_o from the vars of the instantiation of  LPDDR4SimulationPads() itself. Not sure if this is recommended but it appears to be working.

23:11 <Guest63> Hi, I have done the setup up to the point that I wanna do a simulation. The issue I have right now is with the riscv elf binaries. I don't think it's seeing them in my path variable even though I added it to the $PATH. I have an m1 mac, and those riscv elf files are compiled for x86, so I thought that was the issue!

23:12 <tpw_rules> erm, macos does not use ELF

23:19 <Guest63> ok, but that's not the point, I mean what is the alternative here

23:19 <tpw_rules> well it's unclear to me what you've done. what files did you download?