05:52 <amstan> bentomo: i would totally read a blog post of what you're doing right now

09:24 <Melkhior> hello, looking at the decklink mini 4K for HDMI, I understand it's using a SN65DP159 (or 75DP159) to produce the HDMI output signal from the GPT pins. Presumably the DP159 is coupled by inline capacitor as in the datasheet. Should it be possible to use a TDP0604 (https://www.ti.com/product/TDP0604 ) instead ? It seems easier to handle as it only use one power rail and most configuration can be left floating when putting it in I2C

09:24 <Melkhior> mode it seems... but I'm not sure it will accept whatever signals the GTPs TX of an Artix-7 will output when using Litex' VideoS7GTPHDMIPHY...

09:24 <tpb> Title: TDP0604 data sheet, product information and support | TI.com (at www.ti.com)

09:24 <Melkhior> s/configuration/configuration pins/

09:25 <Melkhior> TIA

13:25 <_florent_> Melkhior: I would need to have a closer look, for info; on BlackMagic Atem Mini a TDP158 is used for similar purpose (this also seems to be a chip used (it also seems to be used on some consoles).

13:27 <_florent_> somlo: nice for the fix, that's probably the issue in https://github.com/litex-hub/linux-on-litex-vexriscv/issues/187

13:27 <_florent_> and https://github.com/enjoy-digital/litex/issues/1492

13:37 <Melkhior> _florent_: the TDP158 seems quite similar to the 65DP159 - and it also requires the 1.1V VDD in addition to the 3.3V VCC :-(

13:40 <Melkhior> there's a document to migrate between the 65DP159 and TDP158, but it seems the TDP0604 is different...

13:43 <Melkhior> any known-to-work-with-Litex schematic for the GTP-based HDMI out there ? The few boards I see are 'production' board with no schematics

13:59 <somlo> _florent_: I commented on #187, thanks for pointing it out. In retrospect, I should probably have cc-ed geertu on the irq stuff when I sent it to lkml anyway... :)

14:01 <geertu> somlo: _florent_: thx, will give it a try next Tuesday

14:01 <geertu> somlo: I did notice the IRQ stuff in litex-rebase earlier today ;-)

14:02 <somlo> _florent_: 1492 is probably unrelated, since they're complaining about loading a kernel into LiteX over the uart, that's before there's Linux running on the system

14:03 <somlo> geertu: it's what finally allowed me to boot Fedora on LiteX + Rocket

14:04 <geertu> somlo: Do I need a recent gateware? I haven't updated mine since Jul 2 2021

14:04 <somlo> when fbcon and/or agetty or whatever kicked in, the kernel started to panic in polling-only mode. Band-aid was to ensure the polling timer cycle was at least 70 jiffies (at 50 MHz), but the "right way" was to use irq :)

14:05 <somlo> geertu: I don't know for sure re gateware, but I don't expect that to be a problem

14:12 <somlo> _florent_: on second thought, they're trying to load applications into an already running linux system over the UART, so that may be applicable (gotta work on my reading comprehension :)

15:22 <MoeIcenowy> _florent_: BTW why is there litedram f6d6611a81bf9bc3015fefd280dad34fe455f2ed ("software/liblitedram: Introduce SDRAM_PHY_DELAY_JUMP and set to 4 on 7-Series instead of 1 to improve calibration robustness on some boards.") ?

15:25 <MoeIcenowy> (I am feeling my STLV7325's memory not so stable too, even with current litedram

15:25 <MoeIcenowy> sorry, this is not litedram commit, but litex commit (for software related to litedram)

15:29 <MoeIcenowy> well I do see something like 00001011111111110100000000000000 when doing read leveling

15:31 <MoeIcenowy> BTW as the external clock of STLV7325 is 200M, I am thinking whether it's possible to directly feed to to IDELAYCTRL

15:32 <MoeIcenowy> is there any phase requirement for IDELAYCTRL?

15:51 <MoeIcenowy> well I somewhat understood f6d6611a81bf9bc3015fefd280dad34fe455f2ed, but now I think it could be not so optimal

15:51 <MoeIcenowy> should we just count continous 1's?

15:51 <MoeIcenowy> consider the 1's seperated by 0's some error

17:55 <Melkhior> somlo: have you tried NaxRiscv as an alternative to Rocket for RV64?

19:21 <jersey99> Hi All, I know there has been a little bit work with integrating ghdl. But has anyone had good luck simulating vhdl code via a ghdl converter embedded in litex?

19:23 <jersey99> To be a bit more specific, I have a few vhdl modules embedded in litex, and would like to run a top-level simulation. This would require some sort of conversion of vhdl to verilog. Wondering if any of this work is automated

20:12 <_florent_> MoeIcenowy: That's indeed the pattern I saw with the STLV7325 and the reason of this commit. This was a quick solution for my board but could indeed probably be improved using what you suggest or some kind of low-pass filtering

20:13 <_florent_> Melkhior: I've also tried to convince somlo to test NaxRiscv, now we are two :)

20:15 <_florent_> jersey99: That was one of trabucayre's motivation for this work yes

20:16 <jersey99> _florent_ .. Ok, that's cool. Let me give it a try!

20:17 <_florent_> jersey99: if you do things similarly to what is done in NeoRV32 or Microwatt, LiteX should to the conversion by itself and allow you to simulate for example with Verilator

20:17 <jersey99> Yep. I am instantiating that vhd2vconverter thing

20:18 <jersey99> and hoping that Verilator is going to even give a speedup compared to the snail ghdl is :p

20:21 <_florent_> this should be faster yes :)

20:34 <somlo> _florent_ is there some writeup "for dummies" on how to build a NaxRiscv based LiteX? I would like to compare the ability to run things like e.g. Fedora (or at least the busybox/initrd based linux) vs. Rocket

20:35 <somlo> guess I could just look at litex/soc/cores/cpu/naxriscv/core.py and pick something that looks promising :)

20:37 <somlo> OTOH the core.py for naxriscv looks a bit scary and intimidating, with lots of args instead of stupid-simple variants like I'm used to from Rocket :)

20:37 <somlo> so after all, a "for dummies" writeup might still come in handy...

21:07 <jersey99> _florent_Is the dependency just out of the box ghdl for this? ghdl-mcode --out=verilog errors out with unknown command option.

21:17 <_florent_> jersey99: now that you say this, I have to admit I haven't tested myself the latest change: https://github.com/enjoy-digital/litex/pull/1475

21:17 <_florent_> jersey99: I could do tomorrow

21:18 <jersey99> Ok, thanks. Let me look around

21:20 <jersey99> Let me build ghdl

21:20 <jersey99> thanks

21:20 <_florent_> somlo: You can find some info here: https://spinalhdl.github.io/NaxRiscv-Rtd/main/NaxRiscv/hardware/index.html

21:20 <tpb> Title: Hardware — NaxRiscv documentation (at spinalhdl.github.io)

21:20 <_florent_> RV64IMAFDCSU:

21:21 <_florent_> python3 -m litex_boards.targets.digilent_nexys_video --cpu-type=naxriscv --bus-standard axi-lite --with-video-framebuffer --with-spi-sdcard --with-ethernet --xlen=64 --scala-args='rvc=true,rvf=true,rvd=true' --build --load

21:22 <_florent_> But NaxRiscv still does not have a DMA interface, so you'll have to use SDCard in SPI mode for now

21:22 <_florent_> Other than that, this should work since that's the configuration that has been used to boot Debian

21:25 <somlo> _florent_: interesting, thanks! I'll give that a shot over the next week or so

22:05 <zyp> DMA interface in what sense?

22:19 <jersey99> FYI, _florent_ I am able to get it going with ghdl built from master

22:21 <_florent_> zyp: At least for cache coherency (ie do the LiteSDCard DMA access through this interface)

22:45 <somlo> where the core(s)+L1cache "assembly" is a DMA slave that keeps both the internal cache and external DRAM updated when a master device (e.g., litesdcard, litesata, etc) transfers data through it

22:45 <somlo> rocket has one, not sure if vexriscv does