GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #litex
<_florent_>
MoeIcenowy: The GW2DDRPHY is now working on the Tang Primer 20K with adjusted latencies, thanks a lot for the port from ECP5DDRPHY. As a quick test, I just tested a Linux boot with Linux-on-LiteX-VexRiscv and it works.
FabM has quit [Ping timeout: 246 seconds]
lexano has joined #litex
<whitequark[cis]>
one of the main issues wrt ASICs is the assumption that everything has a reset, which is not true for memories
<whitequark[cis]>
there's no "the value is not known" in simulation either
<sensille>
what would be the way to extract a pin from a record (acquired by self.platform.request)? i want to remove rst_n from the eth ports and hardwire it to high
<sensille>
so the driving-high part is there, but the original control code as well
<somlo>
weird, so your force-high statement went inbetween the force-low and the ~litehm2_ethphy_reset0
<somlo>
and if I remember my verilog, the last one always wins
<sensille>
i assume i have to create a new record from the old one, without rst
<somlo>
what happens if you do `self.comb += pads.rst_n.eq(1)` *after* calling `self.ethphy = LiteEthPhy...(... pads = pads ...)
<somlo>
?
<somlo>
if these things are inserted in the order in which they're "parsed" by migen, maybe doing that will place your statement last
<sensille>
nope. probably depends on the order in which they are finalized
<somlo>
right, so then see if you can add the `self.comb += pads.rst_n.eq(1)` somewhere in a finalize section of your own (this is already out of my depth as far as migen kung-fu is concerned)
<somlo>
the other thing would be to add a boolean argument to LiteEthPhy...() and tell *it* to wire rst_n to high (depending on your tolerance for having an out-of-tree patch against the LiteETH repo)
<sensille>
it already checks if there is a rst_n or not, so just not providing it would be fine
<somlo>
sorry, I don't know of a nice, "canonical" way, only thoughts of "throw stuff against the wall and see if it sticks" sorts of hacks :)
<somlo>
oh you mean removing the rst_n field from `pads` would work for you ?
<somlo>
I vaguely remember there might be examples in the code base on how to do that
<somlo>
I think I'll shut up now and let someone who actually speaks migen more fluently take a stab :D
<sensille>
yes, i want to remove it from 'pads'
<somlo>
would it make sense to `delattr(pads, 'rst_n')` before passing `pads` to `LiteEthPhy()` ?
<somlo>
and possibly after having done the `self.comb += pads.rst_n.eq(1)` bit?
<Hoernchen>
oh, 5s75e: how are you hititng your eth timings? i'm currently trying to get a 5a75b 8.2 to work and eth appears to be a bit ... lossy, but i have to crank down sysclk to 40Mhz to get both eth and sysclk to pass
nickoe has joined #litex
<nickoe>
Hello, any activity in here now a days?
<nickoe>
I was wondering if I could use litespi to interface with any generic SPI chip, that is not a flash chip, but I don't see any example anywhere, where it is just used to talk to some simple SPI device that is not a SPI flash device. Like for example SPI based read write via a demo like app.
<sensille>
and no, still plain abc, no abc9 flow something
<sensille>
you can also try to use an older yosys, like 2 years old
<sensille>
but timing jumps wildly with any design change
<Hoernchen>
yeah i basically tried a few versions and litex releases since 2020 and there are major differences as far as the timing is concerned
<Hoernchen>
but either sysclock or eth clock fail by a lot, apparently depending on 32b eth datapath or not
<Hoernchen>
can you share your tool versions?
<sensille>
oss-cad-suite-20230826
<Hoernchen>
oh, that new.. yeah.. that is what I am currently using
<sensille>
and i don't use etherbone, just ethernet from vexriscv
<Hoernchen>
ah
<sensille>
i need the new one due to ghdl improvements
<sensille>
you can also give that patch above a try
<Hoernchen>
yeah i'm on it
<sensille>
but i've also seen that with 105mhz eth still works fine
<nickoe>
Any of you two, who understands if class LiteSPI can be used as a generic spi controller? What I am not so sure about is how to define the phy argument. "phy : Module Module or object that contains PHY stream interfaces and a cs signal to connect the ``LiteSPICore`` to."
<Hoernchen>
no idea, the colorlight board is my first litex adventure
<sensille>
mine too. i use litespi with a flash, but controlled from software
nickoe86 has joined #litex
nickoe93 has joined #litex
nickoe has quit [Ping timeout: 246 seconds]
nickoe93 is now known as nickoe
<nickoe>
sensille, but how would you use it against a non-flash chip?
nickoe86 has quit [Ping timeout: 246 seconds]
<sensille>
Hoernchen: besides the 5a75 i also use the rv901t. there timing closure is a bit easier to achieve
<nickoe>
Do I need to define a Module for the phy with the stream things that does the logic for: "The LMX2594 is programmed using 24-bit shift registers. The shift register consists of a R/W bit (MSB), followed by a 7-bit address field and a 16-bit data field. For the R/W bit, 0 is for write, and 1 is for read. The address field ADDRESS[6:0] is used to
<nickoe>
decode the internal register address. The remaining 16 bits form the data field DATA[15:0]. While CSB is low, serial data is clocked into the shift register upon the rising edge of clock (data is programmed MSB first). When CSB goes high, data is transferred from the data field into the selected register bank."
<nickoe>
Above description is from the datasheet.
<Hoernchen>
is nextpnr-xilinx usable for the rv901t?
<Hoernchen>
mh, apparently not, only 7 series
<zyp>
sensille, on the 5a75, are you building for speedgrade 6 or 8?
nickoe11 has joined #litex
<sensille>
Hoernchen: no, ISE
<Hoernchen>
yeah the whole appeal is the open source toolchain (and the 15€ board)
<zyp>
ecp5 speedgrades doesn't seem to matter much in real life, so in practice you can just build for 8 regardless of what chip you've got
<Hoernchen>
oh, they do not?
<Hoernchen>
i'm kinda trying to, well, at least be on the safe side as far as timings are cocerned before trying to figure out why the eth is lossy
<sensille>
yeah, i also heard timing estimate in nextpnr is quite conservative
nickoe has quit [Ping timeout: 246 seconds]
<sensille>
oh, but the board actually has -7
<Hoernchen>
looks like the easiest way to ensure the timing works out is to go for 1.2v vcore and pretend it's a 5g part?
<zyp>
so far I haven't had any issues building my ethernet stuff for colorlight i5 for -8
nickoe11 has quit [Ping timeout: 246 seconds]
<Hoernchen>
interesting
<_florent_>
Hoernchen: On a colorlight, if you want to use Etherbone, use a 32-bit datapath, this will allow you to go down to 31.25MHz sys_clk_freq (125MHz/4)
<Hoernchen>
how?
<Hoernchen>
isn't that what the data_width for etherbone already does?
<zyp>
IIRC there's a `with_sys_datapath` argument somewhere
<_florent_>
yes, set data_width=32 in add_etherbone
<Hoernchen>
can I just go for 31.25 for sys_clk_freq or is there some magical way to specify this as fraction of the eth clock?
<_florent_>
I would still recommend a sys_clk_freq a bit higher than the minimum.
<Hoernchen>
40Mhz appears to work, at least one of 10 seeds manages to pass 40/125
<Hoernchen>
i'm just puzzled why the project defaults to 50/125 and older github issues make it sound like those frequencies used to work in the past
<Hoernchen>
but as i'Ve just learned the speed grade does not really matter so i guess violations should be fine anyway
<_florent_>
The project was tested on a 7.0, I'm not well aware of the difference with 8.2. Is the FPGA the same size? Also, the RGMII timings maybe also need to be adapted.