st-gourichon-fid has quit [Read error: Connection reset by peer]
st-gourichon-fid has joined #litex
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
HoloIRCUser3 has joined #litex
HoloIRCUser2 has quit [Ping timeout: 265 seconds]
Skip has joined #litex
futarisIRCcloud has joined #litex
Degi has quit [Ping timeout: 264 seconds]
Degi has joined #litex
FFY00 has quit [Ping timeout: 260 seconds]
FFY00 has joined #litex
_whitelogger has joined #litex
Skip has quit [Remote host closed the connection]
HoloIRCUser2 has joined #litex
HoloIRCUser3 has quit [Ping timeout: 256 seconds]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 264 seconds]
kgugala_ has quit [Quit: -a- Connection Timed Out]
kgugala has joined #litex
<xobs>
gregdavill: bunnie recently got CDC working with eptri, in theory. If you're still looking for a USB core.
<xobs>
Hasn't been tested in hardware yet though! It passes the tests, which means it should work right?
gregdavill has joined #litex
<gregdavill>
xobs: Neat! I'll check it out. Is it up on the betrusted-soc github?
<gregdavill>
Yeah, any design that passes all the tests always works perfectly on hardware the first time </sarcasm>
<xobs>
Hmm... I may have jumped the gun, sorry... But yes, it's up in betrusted-io. Need to do some more testing to ensure it works with other clock domains.
kgugala has quit [Read error: Connection reset by peer]
<gregdavill>
It will be interesting to compare the resource usage differences between using discrete CDC primitives in the module.
kgugala has joined #litex
<xobs>
Yeah. He updated the DummyUSB driver so it meets timing better when using cdc, but it added about 20 LCs to the ICE40 implementation, so I had to switch it off for Fomu. But it works much better now on the Xilinx part. I'm curious to see how it'll work on ECP5.
<zyp>
I'm curious how my usb core compares in size to valentyusb
<zyp>
what's the best way to measure size of a particular core?
<xobs>
zyp: I've done synthesises of DummyUSB with nothing but a wishbone core that can enumerate over USB, and it clocks in at about 650 LCs on an ICE40.
<xobs>
It's not very useful, granted. The wishbone bridge kicks it up to about 1100 LCs. Then eptri adds more, because it's a proper USB device core.
<zyp>
if I take out the cpu and the litescope from my build, I'm at 1191 TRELLIS_SLICE, and if my understanding is correct, each of those are comparable to two LCs
<zyp>
but that's still leaving in the wishbone crossbar/memories and uart bridge
captain_morgan has quit [Quit: Ping timeout (120 seconds)]
captain_morgan has joined #litex
HoloIRCUser4 has joined #litex
HoloIRCUser2 has quit [Ping timeout: 272 seconds]
<disasm[m]>
xobs: you may want to switch to SERV to save a huge amount of space
<disasm[m]>
I found it really cool, especially for decreasing development cycle time
<disasm[m]>
I'm not sure it will play nicely with USB timings though
<xobs>
Does it have a debug port? The vexriscv debug port is fantastic, and while I'd have to add a module to `wishbone-tool` for SERV, it could be done.
<disasm[m]>
I don't think it has a debug port
<gregdavill>
I want to try out how well serv performs with the USB core. Due to it's architecture it's a lot slower than the vexriscv. It does not have a debug port.
<disasm[m]>
Well, when I was running vexriscv with the USB core, it was incredibly slow too :) In my current design with SERV I had to add a wishbone cache to compensate even bigger slowdown due to the FLASH latency
scanakci has quit [Quit: Connection closed for inactivity]
<zyp>
I'm thinking SERV will do well with USB, the software side of USB doesn't really impose super strict timings
<disasm[m]>
IIRC, there are some timing restrictions for control transfers, but bulk transfers should work fine
<zyp>
yes, there are timing restrictions, but the strictest ones are 50ms
<zyp>
how does the performance numbers for SERV look? I'd assume it to be on the order of 1/32 of a normal riscv at a given clock rate
HoloIRCUser has joined #litex
<gregdavill>
I'm not sure if it's exactly 32 clock cycle for every instruction, or if some instructions still require more than 32 cycles.
HoloIRCUser4 has quit [Ping timeout: 265 seconds]
<disasm[m]>
Yes, some instructions are more than 32 cycles
<zyp>
then again, with 32 cycles per computation, another cycle or two of latency doesn't matter all that much
<zyp>
I'm guessing a SERV running at 12 MHz should be able to execute somewhere between 10k and 20k instructions in 50ms, which should be more than enough to handle every standard control request
_whitelogger has joined #litex
<dkozel>
john_k[m]: I have two CEL-215s and they have different SN stickers, silkscreen, and PCB fab markings
<dkozel>
I have a Vivado supported JTAG interface so can interrogate them if needed. Also I talked with the Nitefury designer a year or two ago, can ping him if needed to see if there's info available.
<dkozel>
Just picked up an ORICO SCM2T3-G40 Thunderbolt 3 -> m.2 M-key enclosure, should arrive in 20-40 days :D It gets (ab)used for eGPUs so seems to be transparent PCIe. Will report back once it arrives.
<dkozel>
The wavlink UTE02 is cheaper but has less heatsinking. If the Orico works I'll get a wavlink to try as well since the CEL-215 has a good heatsink and fan already.
HoloIRCUser2 has joined #litex
HoloIRCUser has quit [Ping timeout: 260 seconds]
gregdavill has quit [Ping timeout: 244 seconds]
Skip has joined #litex
<john_k[m]>
dkozel: I'd be curious to see if the litex project works on both boards
HoloIRCUser has joined #litex
HoloIRCUser2 has quit [Ping timeout: 256 seconds]
<_florent_>
dkozel: interesting for the Thunderbolt3 enclosure, that could also be useful to avoid rebooting when re-loading the bitstream
<_florent_>
john_k[m]: do you see others differences between the boards? can you do some pictures if so? Otherwise to get the led-chaser, you only need the 200MHz input and the Leds. Can you check if the 200MHz clock is also there on the boards that are not working?
<CarlFK>
the netv2 is getting power from the pci buss and the pi - should I plug in the 12v barrel too?
<kgugala>
some time ago you said you have two netv2s (50t and 100t) can you try the other one? this will require rebuilding the bitstream for that part
<CarlFK>
sure
<kgugala>
the board should run fine powered from pcie only
<CarlFK>
oh hey, pi runs from that too
<CarlFK>
netv2-35, fresh out of the bag, no pi...
<CarlFK>
lspci - should I see anything?
<CarlFK>
because I don't
<CarlFK>
nothing loaded)
<CarlFK>
I have to run - more on this later.
<CarlFK>
loaded file top.bit to pld device 0 in 1s 636826us