<NotHet>
Is there a good way to share a LiteEth between a softcore and other logic? I'd like to use softcore for management and send UDP out quickly from logic. I am thinking of just accessing the liteeth across the wishbone, and making sure my software isn't using it at the same time. Is this a reasonable approach?
<_florent_>
The integration still need to be simplified but you can use the code above.
mc6808_ has joined #litex
mc6808_ has quit [Client Quit]
mc6808_ has joined #litex
mc6808_ has quit [Client Quit]
mc680898 has joined #litex
<mc680898>
_floent_: No cahange in symptoms with Eitherbone when I tried with master today. Still dies if I specify a trigger. Didn't get much time on that today but I have a skeleton for efinix xyloni Dev board thrown together as that is what I had on hand. Bit space constraints though, bios won't fit...
mc680898 has quit [Client Quit]
<leons>
I'm currently trying to use JTAGbone for the first time. I have an FPGA board which has both the actual FPGA (Virtex 7) and a programming CPLD on the JTAG chain. Is there anything special to watch out for?
<leons>
I've added the jtagbone core into my design, but the litex_server isn't too happy about it
<leons>
I suppose the unexpected ID errors are from the CPLD ID which OpenOCD doesn't know (at least not with the current configuration) but it does seem to try to continue with the ID it recognizes, just to fail at "Error: auto0.tap: IR capture error; saw 0x0000 not 0x0001"
<leons>
Yeah, just confirmed the IDs with Vivado, "33691093" really is the FPGA 😕
cr1901 has quit [Read error: Network is unreachable]
cr1901 has joined #litex
<_florent_>
leons: It's possible it will work even if OpenOCD does not officially support this FPGA. I think I've been able to use JTAGBone/JTAGUart on Utlrascale(+) this way and was having the same warnings/errors
<leons>
_florent_: that's a good point. I actually tried using it and ran into some other errors in `litex_client.py`, given I've never used all this I didn't really investigate further. At least I now have UARTbone somewhat working with `litex_client` so I can try JTAG again as well 🙂
<_florent_>
mc6808: For the Etherbone/LiteScope issue, could you try to revert LiteEth to 2021.08 (https://github.com/enjoy-digital/liteeth/releases/tag/2021.08). I'm wondering it it could be related to the recent changes to support a wider data-path
<leons>
LiteX doesn't by any chance have a hardware I2C core, or even better a core for a PCA9548A I2C switch and Si5324C clock chip lying around? 🙂
<_florent_>
it should be possible to only revert LiteEth
<_florent_>
mc6808: For the xyloni dev board, you can maybe try to switch to SERV CPU (--cpu-type=serv), having the BIOS XiP from SPI Flash would also avoid using BlockRams, but this hasn't been tested on Efinix yet
<leons>
Haha I knew it would be a good idea to ask!
<leons>
Did I just not manage to find it before or is this the first time you publish this?
<_florent_>
I just published it
<leons>
Awesome, thank you so much
<_florent_>
That's the kind of code that is a bit specific to applications but happy to share it it can be useful
<leons>
Yeah, apart from the actual configuration of the clock chip it's exactly what I need. If and when I have spare time I can try to make it generic but for know it's awesome to get me off the ground
<leons>
These two chips seem to be a very common configuration though. The KCU116, NetFPGA SUME and apparently also your KC705 use them
jryans has quit [Quit: Bridge terminating on SIGTERM]
promach[m] has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
amstan has quit [Quit: Bridge terminating on SIGTERM]
Crofton[m] has quit [Quit: Bridge terminating on SIGTERM]
dcallagh has quit [Quit: Bridge terminating on SIGTERM]
Las[m] has quit [Quit: Bridge terminating on SIGTERM]
CarlosEDP has quit [Quit: Bridge terminating on SIGTERM]
kaji has quit [Quit: Bridge terminating on SIGTERM]
leons has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
sajattack[m] has quit [Quit: Bridge terminating on SIGTERM]
willcode4[m] has quit [Quit: Bridge terminating on SIGTERM]
dmiller[m] has quit [Quit: Bridge terminating on SIGTERM]
HumbertoJimenez[ has quit [Quit: Bridge terminating on SIGTERM]
vomoniyi[m] has quit [Quit: Bridge terminating on SIGTERM]
david-sawatzke[m has quit [Quit: Bridge terminating on SIGTERM]
a3f has quit [Quit: Bridge terminating on SIGTERM]
bluecmd has quit [Quit: Bridge terminating on SIGTERM]
DerekKozel[m] has quit [Quit: Bridge terminating on SIGTERM]