03:08 <CarlFK> can the Arty board work with the foss tools? (even a little, like blink and led) ?

03:22 <bjonnh> (Arty Z7-20 with a Zynq-7000 XC7Z020-1CLG400C )

03:23 <bjonnh> I'm installing the xilinx … thingies for now

03:23 <bjonnh> but if there are more open tools, I would be happy to use them

03:48 <bjonnh> CarlFK: https://github.com/timvideos/litex-buildenv/wiki/Xilinx-Vivado

03:48 <bjonnh> seems to have instructions that look familiar

03:49 <CarlFK> Carl Karsten edited this page on Feb 19, 2020 · 17 revisions

03:49 <CarlFK> :D

03:50 <CarlFK> almost 2 years old.

03:52 <bjonnh> that's promising

03:53 <bjonnh> I may just have to create a file with the pinout of that specific board

03:53 <bjonnh> if I understand how all of that is organized

03:54 <CarlFK> https://symbiflow-examples.readthedocs.io/en/latest/building-examples.html#xilinx-7-series

03:54 <tpb> Title: Building example designs — SymbiFlow examples documentation (at symbiflow-examples.readthedocs.io)

03:55 <CarlFK> no vava or other closed source needed

03:57 <bjonnh> but that's not those I think

04:07 <CarlFK> that link should show you how to make the arty do stuff with only foss tools

04:07 <CarlFK> and a bunch of other boards

04:08 <bjonnh> hmmm yeah not those arty I think, They are artix bazed

04:09 <bjonnh> based

04:09 <bjonnh> but I don't know maybe the fpga part is the same

04:09 <bjonnh> but symbiflow seems to handle the zybo z7 that has the same chip as my board

04:09 <bjonnh> so that's promising

04:16 <bjonnh> and the exact bitstream format seem to have been reversed as well according to https://github.com/SymbiFlow/prjxray-db/tree/master/zynq7/xc7z020clg400-3

08:29 <tcal> In LiteX/migen, is it possible to modify a "special" (wrapped instantiation) after it's been added? Specifically, to add more I/Os?

12:39 <_florent_> tcal: it's possible yes. For this, you can put the special in the do_finalize, as done in most CPUs, for example VexRiscv: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/vexriscv/core.py#L363

12:59 <emkat> Good afternoon. I was wondering how the internal clock of the LiteDRAM module works when using the simsoc target. The simsoc sets the internal clock frequency to 100 MHz by default, but where and how exactly is that 100 MHz clock created? It is my guess that it is somehow derived from the (default) 1 MHz system clock, but I was unable to find where this happens.

13:02 <somlo> _florent_: any recent success programming the ecpix5 with openocd? If you scroll up a bit I posted some logs of what I'm seeing -- used to work a few weeks ago, now I can't seem to get it to work; not sure if I'm screwing up something subtle enough that I can't notice, or if anything changed...

13:03 <_florent_> somlo: Sorry, saw it yesterday but forgot to answer today :)

13:04 <_florent_> somlo: So you are not able to load the bitstream with OpenOCD?

13:50 <somlo> _florent_: this https://pastebin.com/cJ7QiUQB is what I see on the terminal, and nothing happens with the board; also, this https://pastebin.com/Pj5wB64R is what I get in dmesg before and after running openocd

13:50 <tpb> Title: $ openocd -f openocd_ecpix5.cfg -c 'transport select jtag; init; svf lamdaconcep - Pastebin.com (at pastebin.com)

13:50 <somlo> curious if this is reproducible by anyone else but me

13:51 <_florent_> somlo: I'll try in 20-30 min

13:52 <somlo> btw, the nature of the bitstream .svf file doesn't seem to matter -- tried it with an old .svf I posted to linux-on-litex-rocket, which I know for a fact worked in the past

13:53 <somlo> so either I broke my board (again) when I unplugged it a few weeks ago, or (less likely) something changed in litex-boards or with openocd, or whatever

13:54 <_florent_> somlo: sadly I don't think anything changed on this in last week

13:54 <_florent_> weeks

14:08 <somlo> weird thing is when plugging in I get the usual two ttyUSB (0 and 1) devices recognized, power goes to the board, so I'm having a hard time imagining *how* I might have broken it :)

16:47 <acathla> somlo, I don't know how it's wired on the icebreaker, but on the lattice up5k breakout board, with the same FTDI, I also have two ttyUSB but none are usable for an uart in litex, so I use an external one.

17:12 <somlo> acathla: the weird thing is that the ecpix5 worked great for *weeks*; then I unplugged it for the last two weeks (cleaning up and moving stuff around in my office), now it no longer works

17:13 <gatecat> it sounds like something changing in openocd tbh

17:13 <gatecat> could you try reverting the openocd version to an older package ?

17:13 <somlo> so either I broke it (but then why the heck can it still speak usb on both jtag and uart, ttyUSB0 *and* ttyUSB1) to the linux host?!?), or something changed (not in litex-boards, but maybe some other related bit of software or library or something)

17:19 <somlo> gatecat: I might have updated my fedora once while the ecpix5 card was packed away, but `dnf updateinfo list` doesn't seem to suggest openocd was part of it... In fact, openocd hasn't been updated at all since f34 was released, so that can't be it. At least not the openocd package itself, maybe one of its dependencies, who knows...

17:20 <gatecat> it looks suspiciously like it's reporting a syntax error in the svf command, which is very strange

17:20 <gatecat> the ttyUSB0 disconnected thing is normal - that's just openocd taking over from the usb serial driver on interface 0

17:22 <somlo> gatecat: yeah, I noticed that on the trellisboard too (now that I started paying attention) -- and happily the trellisboard still works, so I can check the "before" and "after" I package the new yosys release as an rpm (which is why I started dusting off my ecp5 cards in the first place)

17:22 <somlo> * the ttyUSB0 disconnect thing, to be precise

17:24 <somlo> gatecat: do you have an ecpix5 (specifically, the 85k version)? If so, can *you* program a current litex .svf to it ?

17:24 <gatecat> unfortunately not

17:25 <somlo> no worries, worth a question :)

17:27 <somlo> http://mirror.ini.cmu.edu/litex/lambdaconcept_ecpix5.svf.xz in case anyone else reading this wants to give it a shot

17:29 <somlo> gatecat: re. syntax error in the .svf, I tried an old .svf posted for linux-on-litex-rocket which worked when I uploaded it, so I have no reason to believe recent generated .svf files are somehow broken where they weren't earlier

17:32 <tnt> somlo: in https://pastebin.com/cJ7QiUQB the svf filename is wrong.

17:32 <tpb> Title: $ openocd -f openocd_ecpix5.cfg -c 'transport select jtag; init; svf lamdaconcep - Pastebin.com (at pastebin.com)

17:32 <tnt> missing the 'b' of lambda

18:01 <tnt> So ... was that the problem ?

18:01 <somlo> tnt: thanks! I suspected it's something silly that I'm perceptually unable to notice (I once spent a few days chasing a missing semicolon in some code I was working on :) )

18:03 <somlo> would have been nice if openocd threw a more useful error message (such as "I can't find your file named <foo>"), but since it turns out my board isn't broken after all, I'm willing to forgive it for that :D

18:03 <somlo> thanks for spoting my typo for me, and sorry to everyone for the noise :D

18:04 <tnt> hehe. Yeah, when I saw the help message, I thought "Ok ... what would make it believe that this is not a <file> ..."

19:27 <tcal> _florent_: Thanks! So once you do the `self.specials += Instance("xxxx", self.xxx_params)`, you can't modify i/o/p. But if you hold off doing that until the very end, then `self.xxx_params` can be tweaked between the time it is created and the finalization step.

19:28 <tcal> _florent_: So, for the CFU, instead of doing it like this: https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/vexriscv/core.py#L299-L315, I should create a `self.cfu_params` that can be updated, and then not actually add the CFU as a special until finalization.

19:32 <tcal> ....if I understand correctly..

19:37 <tnt> _florent_: I'm looking at the jesd example you provided last week. The S7MMCM and the BUFGMUX are not really needed right ? If I don't need any dynamic way to change the user clock freq.