zng has quit [Ping timeout: 244 seconds]
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
OmniMancer has joined ##openfpga
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined ##openfpga
Degi has quit [Ping timeout: 272 seconds]
Degi has joined ##openfpga
Richard_Simmons has joined ##openfpga
Hoernchen_ has joined ##openfpga
Hoernchen has quit [Ping timeout: 244 seconds]
Richard_Simmons2 has quit [Ping timeout: 260 seconds]
JSharp has quit [Ping timeout: 240 seconds]
JSharp has joined ##openfpga
emilazy_ has joined ##openfpga
Zorix_ has joined ##openfpga
emilazy has quit [Ping timeout: 240 seconds]
Zorix has quit [Ping timeout: 240 seconds]
emilazy_ is now known as emilazy
mwk has quit [Ping timeout: 240 seconds]
mwk_ has joined ##openfpga
flaviusb has quit [Ping timeout: 240 seconds]
flaviusb has joined ##openfpga
_whitelogger has joined ##openfpga
_franck_ has quit [Ping timeout: 246 seconds]
_franck_ has joined ##openfpga
Asu has joined ##openfpga
ziga has quit [Remote host closed the connection]
mwk_ is now known as mwk
<omnitechnomancer> Is it most likely that System Verilog support in Yosys will come via UHDM eventually?
<whitequark> UHDM?
<whitequark> oh interesting
<omnitechnomancer> I presume you found the repo
peeps[zen] has quit [Ping timeout: 256 seconds]
peepsalot has joined ##openfpga
smkz has quit [*.net *.split]
benreynwar has quit [*.net *.split]
russell-- has quit [*.net *.split]
benreynwar has joined ##openfpga
russell-- has joined ##openfpga
smkz has joined ##openfpga
enick_496 has quit [Ping timeout: 244 seconds]
wiizzard has quit [Ping timeout: 244 seconds]
eddyb has quit [Ping timeout: 245 seconds]
jevinskie[m] has quit [Ping timeout: 260 seconds]
notafile has quit [Ping timeout: 260 seconds]
enick_496 has joined ##openfpga
wiizzard has joined ##openfpga
notafile has joined ##openfpga
jevinskie[m] has joined ##openfpga
eddyb has joined ##openfpga
Bike has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
Hoernchen_ is now known as Hoernchen
mumptai has joined ##openfpga
kitten_nb_five has joined ##openfpga
<kitten_nb_five> another question about nextpnr for ECP5: If i use a PLL (file made by command ecppll) to make a faster clock and want to output this clock to my DRAM, do i need to specifiy a constraint for the speed somewhere?
<kitten_nb_five> i tried adding a Python-file as described here: https://github.com/YosysHQ/nextpnr/blob/master/docs/constraints.md but i get an error with "maximum clock 52MHz", so maybe i did something wrong?
<kitten_nb_five> the DRAM on the Colorlight 75-something can take up to 200MHz, it should be doable??
<tnt> "Maximum Clock" is the implementation result.
<tnt> How fast your design can run basically ...
<kitten_nb_five> i wrote this: ctx.addClock("_pll.clkout0", 180) and got this: ERROR: Max frequency for clock '$glbnet$CLK$TRELLIS_IO_OUT': 52.74 MHz (FAIL at 180.02 MHz)
<tnt> Yeah ...
<kitten_nb_five> so i thing the bottleneck is the output-buffer or something inside the FPGA? but 52MHz seems slow?
<tnt> your design is badly optimized. You're asking for it to run at 180 MHz but the max frequency it can reach is 52 MHz.
<kitten_nb_five> uh ok
<kitten_nb_five> i have a lot to learn...
<kitten_nb_five> i will try to dig into the details of the output of the toolchain to see what i can improve
<tnt> To go from 52 to 180 MHz is not going to be a small tweak ... you probably need a completely different architecture for whatever you're doing ...
<tnt> That's like a 3.5x factor.
<kitten_nb_five> yeah... i am trying to make a DRAM-controller from scratch. not an easy task. i had some promising results but sometimes it worked and sometimes not, so i wonder if there is some timing issue somewhere. seems like i was rigt
<kitten_nb_five> right*
<kitten_nb_five> but just to confirm: it's correct to add a timing/frequency-constraint using a python-file on the output of the PLL?
<kitten_nb_five> or does the toolchain figure this out by itself?
<Lofty> I don't think nextpnr figures it out, so a constraint is probably the right idea
<tnt> Actually I think nextpnr supports derived constraints for the ECP5 PLL.
<tnt> Assuming you constrained the _input_ clock obviously ...
<tnt> it can't just read your mind.
<tnt> but constraining the output is perfectly valid too.
<kitten_nb_five> i constrained the INPUT using nextpnr ... --freq 25 AND the OUTPUT using --pre-pack constraints.py
<tnt> it's fine. I mean the fact it reports the "FAIL at 180M" means it understood that this clock should meet 180 MHz.
<Lofty> It prints out the critical path for that domain, so I'd take that as a starting point
<kitten_nb_five> ok. thank you. i will look into optimization and stuff. FPGA is hard!
<Lofty> It is, but it's fun, too
<Lofty> I suspect if/when nextpnr learns how to retime designs, it'll be a bit easier on beginners
<Lofty> (register retiming moves flops to balance the delays on either side of them, and when people aren't aware of how to manually retime designs, it's pretty useful)
<Lofty> Oh, you don't have any latches in your design, do you?
<kitten_nb_five> i might, i am really a beginner with - as usual - a too big goal... i will take some time and look carefully at the output of the toolchain and read a lot of stuff on the internet
<Lofty> kitten_nb_five: grep through the Yosys synthesis log for (case-sensitive) "Latch inferred"
<kitten_nb_five> no results
<Lofty> Okay, that's a good start
<Lofty> Next, look through the part of the code that the nextpnr critical path is in
<Lofty> Do you think you can move any registers to shorten this logic area? (probably not, but, you never know)
<kitten_nb_five> i am looking at it. there are funny names like "read_req_pending_LUT4_C_Z_LUT4_Z_B_LUT4_C_Z_PFUMX_BLUT_Z_PFUMX_Z_1_BLUT_LUT4_Z_C_LUT4_Z_SLICE", this is easy to understand :-)
<kitten_nb_five> i think i wrote my Verilog like a software guy, this is not good
<kitten_nb_five> i will try again from scratch
<Lofty> What you're seeing there is the output of the `autoname` pass :P
<Lofty> If you're brave enough you could post it somewhere
<kitten_nb_five> no, not yet, it's too long and too messy :-)
<kitten_nb_five> but the final goal is to have something working on my github
<kitten_nb_five> ok. if i push an almost empty design trough the toolchain i am getting a maximum frequency of 815.66 MHz. sanity-check passed.
kitten_nb_five has quit [Quit: Leaving]
OmniMancer has joined ##openfpga
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined ##openfpga
Asuu has joined ##openfpga
Asu has quit [Ping timeout: 260 seconds]
mumptai has quit [Quit: Verlassend]
Asuu has quit [Ping timeout: 265 seconds]