_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
benh has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
benh has joined #litex
shenki has quit [Remote host closed the connection]
bl0x has quit [Ping timeout: 240 seconds]
bl0x has joined #litex
Degi_ has joined #litex
Degi has quit [Ping timeout: 272 seconds]
Degi_ is now known as Degi
shenki has joined #litex
linear_cannon has quit [Read error: Connection reset by peer]
linearcannon has joined #litex
shenki has quit [Quit: leaving]
linear_cannon has joined #litex
linearcannon has quit [Read error: Connection reset by peer]
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #litex
shenki has joined #litex
shenki_ has joined #litex
FabM has joined #litex
<_florent_> tnt: Thanks for the LiteScope PR. I'm currently debugging a design with LiteScope so will switch to it to do some initial tests with it.
<tnt> _florent_: ack. Curious to see how it works out for you. Is that through UART or JTAG or Ethernet or ?
<tnt> I guess most gain are for narrow deep captures. ( I was using < 96 signals but over 65k samples )
<tnt> I mean, it's WIP, but it works ... just unusably slow.
<_florent_> tnt: I'm debugging over JTAGBone on this design. I did a first review of the code in the PR, it looks good, thanks!
<_florent_> tnt: I just also did a first capture with it, it seems to work (and faster than before)
<_florent_> tnt: for your ZynqMP/JTABone, you can do a PR if it's working. I'll review it and will also test it on 7-Series/ECP5. If working on other FPGAs, we could merge and we could then see how to improve speed.
<tnt> _florent_: huh no, it's working on ZynqMP, pretty sure it breaks everything else :)
<_florent_> tnt: ok, I now see you still have different implementations
<tnt> yeah, I kept them here just to easily switch.
<tnt> The second one should work in all cases (with openocd changes), but I suspect will slow things quite a bit when used with openocd.
<tnt> The third one with 'bypass' set to 0 should work on non-zynqmp stuff, but it's not tested.
<_florent_> ok, I could help do some test on other boards if this can be useful
<tnt> (err, I meant 'offset' not 'bypass' above).
<tnt> You can try that commit on any other board, just setting offset=0 and check if it still works and if it's the same speed as before (in case I screwed up something that affects efficiency but not correctness).
<tnt> I'll say that speed with the litescope improvements doing long bursts is much more tolerable than before. It's about 4x slower than UART but that's much better than 20x slower.
<_florent_> ok, I'll do some tests when I'll be done with other things (maybe this afternoon or tomorrow)
<_florent_> LiteScope over JTAGBone indeed seems much faster from the captures I'm currently doing
<cr1901> _florent_: Btw, your explanation on source-to-source makes sense now, thanks. Sorry for delay. Very distracted
benh has quit [Remote host closed the connection]
benh has joined #litex
Las[m] has quit [Quit: You have been kicked for being idle]
FabM has quit [Quit: Leaving]
felix_ has quit [Read error: Connection reset by peer]
<tnt> Bit of a migen question. I'm trying to do a platform.add_false_path_constraints(sys_ck, ...). But I don't have the 'sys_clk' signal handy there in the code.
<tnt> I tried passing ClockSignal('sys') directly, but that doesn't work.
<tnt> The only way I found so far is to create a new signal. Use comb += new_sig.eq(ClockSignal('sys')) and then use new_sig in the add_false_path_constraint.
<tnt> Am I missing something or a more convenient way to do that ?
<_florent_> tnt: not sure there is a more convenient way, but I could have a look tomorrow
<_florent_> tnt: I've been using LiteScope quite a bit today and haven't had issue with the new code
<tnt> _florent_: Great, good to hear it's working good :)
<tnt> Only thing I forgot to test is if Constant(0,0) (i.e. zero width signal constant) is valid / accepted in migen. (would happen is the # of monitored signals is an exact multiple of 32).
zjason` has joined #litex
zjason has quit [Ping timeout: 240 seconds]
linear_cannon has quit [Read error: Connection reset by peer]
linear_cannon has joined #litex