_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
zjason` is now known as zjason
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #litex
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #litex
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
<CarlFK> can the Arty board work with the foss tools? (even a little, like blink and led) ?
<bjonnh> (Arty Z7-20 with a Zynq-7000 XC7Z020-1CLG400C )
<bjonnh> I'm installing the xilinx … thingies for now
<bjonnh> but if there are more open tools, I would be happy to use them
<bjonnh> seems to have instructions that look familiar
<CarlFK> Carl Karsten edited this page on Feb 19, 2020 · 17 revisions
<CarlFK> :D
<CarlFK> almost 2 years old.
<bjonnh> that's promising
<bjonnh> I may just have to create a file with the pinout of that specific board
<bjonnh> if I understand how all of that is organized
<tpb> Title: Building example designs — SymbiFlow examples documentation (at symbiflow-examples.readthedocs.io)
<CarlFK> no vava or other closed source needed
<bjonnh> but that's not those I think
<CarlFK> that link should show you how to make the arty do stuff with only foss tools
<CarlFK> and a bunch of other boards
<bjonnh> hmmm yeah not those arty I think, They are artix bazed
<bjonnh> based
<bjonnh> but I don't know maybe the fpga part is the same
<bjonnh> but symbiflow seems to handle the zybo z7 that has the same chip as my board
<bjonnh> so that's promising
<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
linear_cannon has quit [Read error: Connection reset by peer]
Degi has quit [*.net *.split]
cr1901 has quit [*.net *.split]
TMM_ has quit [*.net *.split]
Emantor has quit [*.net *.split]
joseng has quit [*.net *.split]
tcal has quit [*.net *.split]
Wolf0 has quit [*.net *.split]
shorne_ has quit [*.net *.split]
trabucayre has quit [*.net *.split]
lexano has quit [*.net *.split]
nats` has quit [*.net *.split]
Xesxen has quit [*.net *.split]
jeffdi has quit [*.net *.split]
guan has quit [*.net *.split]
alanvgreen has quit [*.net *.split]
somlo has quit [*.net *.split]
simeonm has quit [*.net *.split]
key2 has quit [*.net *.split]
philpax_ has quit [*.net *.split]
kbeckmann has quit [*.net *.split]
kgugala has quit [*.net *.split]
bjonnh has quit [*.net *.split]
pavelow_ has quit [*.net *.split]
tpw_rules has quit [*.net *.split]
TMM_ has joined #litex
bjonnh has joined #litex
nats` has joined #litex
lexano has joined #litex
Degi has joined #litex
Emantor has joined #litex
cr1901 has joined #litex
guan has joined #litex
philpax_ has joined #litex
kgugala has joined #litex
joseng has joined #litex
pavelow_ has joined #litex
jeffdi has joined #litex
tpw_rules has joined #litex
shorne_ has joined #litex
alanvgreen has joined #litex
trabucayre has joined #litex
simeonm has joined #litex
Xesxen has joined #litex
Wolf0 has joined #litex
kbeckmann has joined #litex
somlo has joined #litex
key2 has joined #litex
tcal has joined #litex
linear_cannon has joined #litex
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
benh has quit [*.net *.split]
zyp has quit [*.net *.split]
mtretter_ has quit [*.net *.split]
zyp has joined #litex
mtretter has joined #litex
benh has joined #litex
_whitelogger has joined #litex
a3f has joined #litex
mikolajw has joined #litex
tumbleweed has joined #litex
CarlosEDP has joined #litex
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #litex
essele has joined #litex
FabM has quit [Ping timeout: 252 seconds]
<tcal> In LiteX/migen, is it possible to modify a "special" (wrapped instantiation) after it's been added? Specifically, to add more I/Os?
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
FabM has quit [Ping timeout: 265 seconds]
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
ilia__s has joined #litex
<_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
emkat has joined #litex
<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.
<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...
<_florent_> somlo: Sorry, saw it yesterday but forgot to answer today :)
<_florent_> somlo: So you are not able to load the bitstream with OpenOCD?
<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
<tpb> Title: $ openocd -f openocd_ecpix5.cfg -c 'transport select jtag; init; svf lamdaconcep - Pastebin.com (at pastebin.com)
<somlo> curious if this is reproducible by anyone else but me
<_florent_> somlo: I'll try in 20-30 min
<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
<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
<_florent_> somlo: sadly I don't think anything changed on this in last week
<_florent_> weeks
<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 :)
Melkhior has quit [Read error: No route to host]
Melkhior_ has joined #litex
ilia__s0 has joined #litex
ilia__s has quit [Ping timeout: 240 seconds]
ilia__s0 is now known as ilia__s
ilia__s4 has joined #litex
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #litex
ilia__s has quit [Ping timeout: 265 seconds]
ilia__s has joined #litex
ilia__s4 has quit [Ping timeout: 265 seconds]
peeps has joined #litex
peeps[zen] has quit [Ping timeout: 256 seconds]
<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.
indy has quit [Read error: Connection reset by peer]
indy has joined #litex
<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
<gatecat> it sounds like something changing in openocd tbh
<gatecat> could you try reverting the openocd version to an older package ?
<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)
<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...
<gatecat> it looks suspiciously like it's reporting a syntax error in the svf command, which is very strange
<gatecat> the ttyUSB0 disconnected thing is normal - that's just openocd taking over from the usb serial driver on interface 0
<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)
<somlo> * the ttyUSB0 disconnect thing, to be precise
<somlo> gatecat: do you have an ecpix5 (specifically, the 85k version)? If so, can *you* program a current litex .svf to it ?
<gatecat> unfortunately not
<somlo> no worries, worth a question :)
<somlo> http://mirror.ini.cmu.edu/litex/lambdaconcept_ecpix5.svf.xz in case anyone else reading this wants to give it a shot
<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
<tnt> somlo: in https://pastebin.com/cJ7QiUQB the svf filename is wrong.
<tpb> Title: $ openocd -f openocd_ecpix5.cfg -c 'transport select jtag; init; svf lamdaconcep - Pastebin.com (at pastebin.com)
<tnt> missing the 'b' of lambda
<tnt> So ... was that the problem ?
<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 :) )
<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
<somlo> thanks for spoting my typo for me, and sorry to everyone for the noise :D
<tnt> hehe. Yeah, when I saw the help message, I thought "Ok ... what would make it believe that this is not a <file> ..."
<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.
<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.
<tcal> ....if I understand correctly..
<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.
FabM has quit [Quit: Leaving]
Martoni42 has joined #litex
Martoni42 has quit [Ping timeout: 240 seconds]