<_florent_>
I'll look at this, thanks. I probably broke the no CPU case when adding the FIFO mode for the UART
<benh>
_florent_: yup, my PR fixes the generation but the test cases are somewhat failing :-)
<benh>
I also did a small PR for liteeth to support GMIIMII
<_florent_>
ok thanks
<leons>
benh: you mean 10/100Mbit/s speeds over GMII?
<leons>
benh: ah nevermind :)
<benh>
Hrm ... so it looks like there are a number of issues with the definition for the wukong board in LiteX ...
<benh>
for example the clock pin doesn't match the doc and examples :-)
<benh>
also the FPGA is unfortunately a -1 speed grade
<benh>
which is problematic since GMIIMII requires a sysclk of 125Mhz, which might be difficult to attain with Microwatt at that speed
<benh>
is that a hard limit of the PHY ?
<leons>
benh: what do you mean by GMIIMII? I still don't understand :D
<benh>
gen.py didn't have an option to instanciate LiteEthPHYGMIIMII
<benh>
btw, is that expected ?
<benh>
build/microwatt_0/wukong-a100t-vivado/microwatt_0.runs/impl_1/runme.log:WARNING: [DRC RPBF-3] IO port buffering is incomplete: Device port eth_mdio expects both input and output buffering but the buffers are incomplete.
<benh>
build/microwatt_0/wukong-a100t-vivado/microwatt_0.runs/impl_1/runme.log:WARNING: [DRC RPBF-3] IO port buffering is incomplete: Device port eth_mdio expects both input and output buffering but the buffers are incomplete.
<benh>
there's also a pile of warnings about litedram IOBUF having no load on IBUF
<_florent_>
benh: I don't have the Wukong board but Melkhior here has been playing with it quite a bit IIRC
<_florent_>
benh: you can also probably restrict operation to MII mode on this board
<benh>
Ok. Well there are definitely mismatches in the pin assignment between LiteX and the doc I got
<benh>
or example clock on M21 vs M22
<benh>
ahhhh... QMTECH replied to me, it's a board "v2"
<benh>
clock has moved and CLOCK_DEDICATED_ROUTE FALSE is not needed
<leons>
benh: regarding the CPU clock speed, why don't you just let the PHY run in a different clock domain? GMII requires 125MHz given it's 8bit per cycle and you need 1Gbit/s
<leons>
Your CPU can presumably run at much lower speeds, e.g. 50MHz if the clock domain crossing has a large enough buffer or you increase the data width
<leons>
I'd advise you to look at the 32bit MAC data path PR by david-sawatzke
<benh>
because crossing clock domains with wishbone sucks :_)
<benh>
and afaik the clock passed to the PHY has to be the sys_clk no ? Unless there's a clock domain gap already inside liteeth ? I haven't looked in details
<benh>
it would be good indeed if the PHY had an async fifo to the MAC
<benh>
or MAC to buffers
<benh>
so that the wishbone interface can be in a different clock domain from the rest of the eth
<zyp>
that's already supported
<leons>
There is such a FIFO
<zyp>
etherbone got a 32b datapath, so it can run down to 125/4
<somlo>
_florent_: btw, PR 1040 is good to go as far as my ability to clean it up :) Please have a look and merge if you agree, whenever you get a chance
<leons>
And if even running the MAC path at 125MHz has too tight timing for you, david-sawatzke and I have been working on 32 and 64-bit data path through the MAC (which then also allows running it with 10Gbit/s at 156.25Mhz)
<benh>
zyp: I'll have to look at the details, the stuff spat out by gen.py doesn't seem to support that
<benh>
leons: thanks, I think the MAC at 125 should be fine
<benh>
its the rest of the system that will probably struggle past 100 :-) we'll see...
<leons>
benh: look at mac/core.py
<benh>
I'll send another PR to add Wukong v2 support as well, but now bed time
<benh>
thanks I will
ilia__s has joined #litex
<mm001>
_florent_ I have finally managed to switch on and off the LED of the RV901T board using the linsn_rv901t.py with etherbone by putting the LED to a GPIOOut like in the colorlite example and using litex_server and the scripts. Now I would like to switch on and off the LED only by UDP data. Like you suggested on 2021-09-15, I used a LiteEthUDP2StreamRX, but it does not work yet. In the class BaseSoc, I defined udp_streamer = LiteEthUDP2StreamRX(
<mm001>
ip_address=convert_ip("192.168.1.50"),udp_port=1122) then I add it with self.submodules.udp_streamer = ClockDomainsRenamer("eth_rx")(udp_streamer) and in the self.sync i do If(udp_streamer.source.valid, my_led.eq(udp_streamer.source.data[0])
ilia__s has quit [Ping timeout: 256 seconds]
<_florent_>
mm001: nice, I'm currently working on an example for this! I'll push it in a couple of minutes :)
<mm001>
however, I think I miss something. Is the LiteEthUDP2StreamRX connected? I guess not. I tried self.comb += self.ethphy.source.connect(udp_streamer.sink) but without success.
<mm001>
_florent_ GREAT!! Thanks a lot!
<mm001>
by the way, building linsn_rv901t.py with ethernet enabled gives a region overlap...
<mm001>
and if I remove self.add_ethernet, the ping response works, but only if I change the sys_clk to 133e6 like in rgmii_test.py.
<_florent_>
But now that I started looking again at the code after a > 5 years, I see things to improve, so I'm also improving some parts...
<_florent_>
mm001: I'll look at the region overlap, I fixed something similar a few days ago IIRC
<mm001>
_florent_ no problem. it's just difficult to start using LiteX without working examples, but I don't give up... :-)
<_florent_>
mm001: sure, we are trying to improve this
<mm001>
I don't understand yet what has to be connected to what and how. And every change needs a new build, just to see that it still does not work...
<mm001>
But anyway, it's great we have LiteX in the first place and thank you very much for all the work and putting it open source!
<mm001>
just another question: where are you going to push your example to?
<_florent_>
mm001: if you want to speed up iterations, you can also use litex_sim that has etherbone support
<mm001>
_florent_ ah, great, I'll have to have a look at litex_sim!
<mm001>
_florent_ Thanks a lot! I think I understand what you did in those lines and I adapted it to take it into linsn_rv901t.py. It does build without errors but I can't get the udp data onto the LED yet. I'll continue to try. Just to check that I'm doing everything right: In the file linsn_rv901t.py, I deleted the lines 87-91 (the LED Chaser) and in this place I added:
<_florent_>
mm001: but while looking at the code earlier I was wondering if we should really keep this check
<mm001>
_florent_: That means 'valid' is only 1 when the sender has the right address...
<_florent_>
yes because with LiteEthUDPStreamer we want to create a link between the FPGA and Host
<_florent_>
for both TX and RX
<mm001>
Ok, got it. but that's easy enough to change...
<mm001>
thanks a lot!
<_florent_>
but if you just want to received UDP data, you can also just use the UDP port directly
<_florent_>
with udp.crossbar.get_port(udp_port, dw=8)
<_florent_>
and then use the udp_port.source
<mm001>
Ok, will try that
<mm001>
Would also be nice to find out why rgmii_test.py crashes on udp packet :-)
michalsieron has joined #litex
michalsieron has quit [Client Quit]
Martoni42 has joined #litex
<Melkhior>
benh: yes the current support is for the V1 Wukong (w/o the on-board micro-sd)
<Melkhior>
Ethernet works for me as-is, but 1 GBiT is too fast for the soft-cores - so I plugged it into a 100 MBit switch, where it works perfectly
<Melkhior>
I only ever tried with VexRiscv, not microwatt, usually running them at 100 MHz
ilia__s has joined #litex
C-Man has joined #litex
ilia__s has quit [Remote host closed the connection]
ilia__s has joined #litex
geertu has quit [Ping timeout: 264 seconds]
ilia__s has quit [Ping timeout: 256 seconds]
<jevinskie[m]>
I took a risk and got two of those arria 10 accelerator boards. I can remove the onboard ddr to get the pinout while the rest (e.g. pcie and dimm should be able to be probed externally, boundary scan to find the clocks, etc). Let’s hope I don’t get discouraged and give up :)
Martoni42 has quit [Ping timeout: 260 seconds]
<gatecat>
jevinskie[m]: ooh which ones, Microsoft ones?
<benh>
Melkhior: so what PHY do you instanciate for the ethernet ?
<benh>
because GMII_MII which is the "theorical" fit, asserts if you try to use a speed lower than 125Mhz... ah wait the assert is in gen.py
<benh>
so if you use directly in LiteX it won't assert, only when generating standalone cores
<benh>
Melkhior: how do you want me to add support for v2 ? a different target/platform or a --version argument to the existing one ?
ilia__s has joined #litex
ilia__s has quit [Ping timeout: 256 seconds]
<benh>
zyp: as usual LiteX confuses me :-) How do you create a standalone liteeth wishbone slave at 125Mhz with a wishbone at a different freq (100Mhz) ?
<benh>
I can't quite see how that's put together
<benh>
zyp: I see how to pass a freq to LiteEthPHYGMIIMII constructor but it's just used to calculate timings for the detection, it doesn't do anything else, I assume the actual clock is coming from elsewhere ?
<benh>
zyp: I never understood how clocks work in LiteX...
<benh>
zyp: LiteEthPHYGMIIMII uses PulseSynchronizer and looks explicitely for "sys" ...
<benh>
zyp: ok I think I get it .. the PHY is clocked externally, the MAC uses sys_clk, so I could have the MAC at 100Mhz and the PHY at 125Mhz, rigjt ?
<benh>
however in the middle I have LiteEthGMIIMIIModeDetection() which is the state machine that flips between GMII and MII, and this works by "measuring" the rx_clk from the PHY compared to the sys_clk
<benh>
now, I can't quite get my head around the LiteX constructs in there, so I don't know how that FSM is itself clocked, that said, there's a 5% margin, we could in theory use a much bigger margin no ? Since there a 5x difference between MII and GMII clocks
<benh>
I'll try hacking that formula, I think I understand what it does, and use a much bigger margin, see how that works here
<benh>
bah.. .that might just work (and also work better for non integer sys_clk/125e6 ratios too)
<benh>
@@ -162,8 +162,8 @@ class LiteEthGMIIMIIModeDetection(Module, AutoCSR):