_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://freenode.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
CarlFK has quit [Ping timeout: 256 seconds]
CarlFK has joined #litex
Degi has quit [Ping timeout: 265 seconds]
Degi has joined #litex
tcal has joined #litex
scanakci has joined #litex
<_florent_> zyp: yes the provided configuration is like this because i was just testing UART over Etherbone, which avoid using a regular UART, but constraints the design a lot more.
<_florent_> zyp: if you want something that meets timings and with SDRAM working, you can lower the sys_clk_freq to 40-60MHz here:
<tpb> Title: litex-boards/colorlight_5a_75b.py at master · litex-hub/litex-boards · GitHub (at github.com)
<_florent_> and use a regular UART by defining serial pins to the plaform, similar to this:
<tpb> Title: litex-boards/ulx3s.py at master · litex-hub/litex-boards · GitHub (at github.com)
<_florent_> all the IOs are output only on this board, you could use the button IO for the serial.rx
<_florent_> also here, the Ethernet is running at 125MH because we are using the hardware stack, when using the Ethernet MAC with the CPU, the frequency can be lowered. So with a regular UART, you could have SDRAM + Ethernet working and pass timings.
<_florent_> i'll try to update the target today to allow this configuration
peepsalot has left #litex ["Connection reset by peep"]
<zyp> already did that last night :)
<tpb> Title: JVnV Pastebin View paste – Untitled (at paste.jvnv.net)
<_florent_> zyp: ah ok great, i just did something similar and pushed it to the repo: https://github.com/litex-hub/litex-boards/commit/a7fbe0a724a1b2fd788699def52c89a05cd556e5
<tpb> Title: colorlight_5a_75b: add SoC with regular UART (on J19). · litex-hub/litex-boards@a7fbe0a · GitHub (at github.com)
<zyp> I also thought about using the button/led for uart, but decided against that and removed one of the buffers instead: https://bin.jvnv.net/file/8L4wZ.jpg
<_florent_> zyp: yes, also thought about removing a buffer, for now i used the option that requires the minimal hardware changes, but then we can't use the button/led in the SoC, we'll see in the future what's the best
<zyp> speaking of frequency, is it possible to get an accurate 48MHz from the 25MHz clock input? the closest the PLL config is getting is *21/11 giving 47.73 MHz
<zyp> it's a bit unclear to me whether the CLKI range refers to before or after the CLKI divider - I guess after which makes it impossible to satisfy the ranges
<zyp> otherwise, /5*96/10 should work
<_florent_> for now CLKI_DIV is fixed to 1, we could add support for the supported divider range (1 to 128) but i also think the CLKI range refers to after the CLKI divider since it makes more sense (ie real input of the PLL)
<zyp> that was my reasoning too
<zyp> but I think I just solved it by chaining two PLLs :)
<zyp> I don't really know what I'm doing, but this looks reasonable to me: https://paste.jvnv.net/view/OvL4K
<tpb> Title: JVnV Pastebin View paste – Untitled (at paste.jvnv.net)
<_florent_> zyp: looking at FPGA-DS-02012-2.1 that's indeed not clear, maybe the 128 max divider is already taken into account in the provided fIN Min
<_florent_> zyp: i could try to add support for CLKI_DIV in ECP5PLL
<tpb> Title: soc/cores/clock/ECP5PLL: add CLKI_DIV support. · enjoy-digital/litex@6043108 · GitHub (at github.com)
<tpb> Title: gist:7e9b12d584c1f5c287fc83725e23df13 · GitHub (at gist.github.com)
<_florent_> in your case, the frequency input of the PLL will be 5MHz
<_florent_> so even if fIN Min is not taking into account the possible 128 divider, it's not far from the 8MHz so could work
<_florent_> you have to use margin=0 because for now we are taking the first value that satisfies the margin, i'll need to improve that and use the config that minimize the errors
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<zyp> I figured I'd check what clarity designer suggests, and somehow it's refusing to give me anything better than *26/13 for 50 MHz
<_florent_> ok thanks, so it means the Fin range is after the divider as we were guessing?
<zyp> I wouldn't draw that conclusion yet, it should have found the 47.73 MHz option
HoloIRCUser has joined #litex
HoloIRCUser3 has quit [Read error: Connection reset by peer]
<zyp> if I'm asking clarity designer for 24 -> 128, it's giving me /3*80/5, if I'm asking clarity designer for 12 -> 128 it can't solve it, even though /1*64/3 should be a valid solution
<_florent_> zyp: hmm strange, not sure if clarity designer is aware of other un-documented constraints or if it's not flexible/clever enough...
<zyp> ah, I figured out why, I missed the part where VCO freq is decided by CLKFB, and my selected feedback source couldn't generate the appropriate freq
<zyp> it looks like I can't persuade clarity to divide CLKI down below 8 MHz, so I guess that means the lower bound applies after the division
scanakci has quit [Quit: Connection closed for inactivity]
<_florent_> zyp: ok thanks, then i should probably update the ECP5PLL code to reflect that
<zyp> my cascaded PLLs didn't appear to work in practice either, but I'll play more with that later
<zyp> I don't need 48 MHz right now, but I'm planning to play with usb later
<zyp> and 47.73 is not gonna work for that :)
pdp7_ has left #litex [#litex]
pdp7 has joined #litex
futarisIRCcloud has joined #litex
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Read error: Connection reset by peer]
HoloIRCUser has joined #litex
HoloIRCUser2 has joined #litex
HoloIRCUser1 has quit [Ping timeout: 256 seconds]
HoloIRCUser has quit [Ping timeout: 250 seconds]
rohitksingh has quit [Ping timeout: 240 seconds]
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #litex