<tpb>
Title: System Verilog case inside range expression support : yosys (at www.reddit.com)
emeb has quit [Quit: Leaving.]
citypw has joined #yosys
rohitksingh_work has joined #yosys
sxpert has quit [Ping timeout: 255 seconds]
sxpert has joined #yosys
svenn has joined #yosys
AlexDaniel has joined #yosys
citypw has quit [Ping timeout: 244 seconds]
emeb_mac has quit [Ping timeout: 240 seconds]
cr1901_modern has quit [Quit: Leaving.]
MoeIcenowy has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
MoeIcenowy has joined #yosys
GuzTech has joined #yosys
m4ssi has joined #yosys
cr1901_modern has joined #yosys
pie__ has quit [Remote host closed the connection]
pie__ has joined #yosys
leviathanch has joined #yosys
<somlo>
daveshah: the trellis versa5g soc example gets a 50MHz clock with the non-default (w.r.t. yosys/ecp5/cells_bb.v) settings of .CLKI_DIV(2), .CLKOP_DIV(12), .CLKOP_CPHASE(11). For a 10MHz clock (for the rocket chip), you got Diamond to come up with .CLKI_DIV(10), .CLKOP_DIV(65), .CLKOP_CPHASE(64).
<somlo>
Turns out, on a *real* 5g ecp5 the rocket chip can go as fast as 24MHz. I get CLKI_DIV (would need 5 for 20MHz), but what about CLKOP_DIV and CLKOP_CPHASE?
<somlo>
ecppll generates 10 and 50 MHz pll settings that are pretty radically different from the working ones we're currently using, so I'm wondering if there's just more than one canonical way to set the pll to generate a given frequency, or what...
<daveshah>
There are different feedback path options, which are the main difference
<daveshah>
The important thing is to keep the VCO in its 400-800MHz range
rohitksingh_work has quit [Read error: Connection reset by peer]
<somlo>
ecppll also generates different ICP_CURRENT and LPF_RESISTOR values (12, 8) vs. what's in the working examples (6, 16) respectively. Should I worry about that ? :)
<sxpert>
damned, things that work in simulation, and miserably fail on chip
<daveshah>
No one has figured out the algorithm to determine those values ye5
<daveshah>
*yet
<daveshah>
They don't seem to be critical, just optimising lock time and jitter I think
<somlo>
so the 20MHz clock as generated by ecppll seems to work (blinking twice as fast now :) )
<somlo>
nextpnr *sometimes* meets >= 24 MHz, but not always, so I think I'll stick with 20 for now...
leviathanch has quit [Remote host closed the connection]
rohitksingh has joined #yosys
citypw has quit [Ping timeout: 272 seconds]
proteusguy has quit [Ping timeout: 252 seconds]
kristianpaul has quit [Quit: leaving]
kristianpaul has joined #yosys
kristianpaul has quit [Quit: Lost terminal]
Cerpin has quit [Ping timeout: 250 seconds]
Cerpin has joined #yosys
kristianpaul has joined #yosys
m4ssi has quit [Remote host closed the connection]
<MoeIcenowy>
somlo: I think you can try to run a for loop to get nextpnr to try to meet 24MHz ;-)
<tnt>
(changing the seed ...)
rohitksingh has quit [Ping timeout: 252 seconds]
<somlo>
MoeIcenowy: if at first you don't succeed... :D
FL4SHK has quit [Ping timeout: 250 seconds]
promach_ has quit [Ping timeout: 246 seconds]
<MoeIcenowy>
I remember the Supra tool from AGM have such a function to run for a loop to reach timing
<tnt>
Multi Pass Place and Route is/was in Xilinx tools as well.
rohitksingh has joined #yosys
proteusguy has joined #yosys
FL4SHK has joined #yosys
rohitksingh has quit [Ping timeout: 246 seconds]
proteusguy has quit [Ping timeout: 252 seconds]
maikmerten has quit [Remote host closed the connection]
<corecode>
i should install trellis and figure out how fast my cpu can run on an ecp5
<sxpert>
mine looks like it can do 50MHz easily, on the good compilation days
<corecode>
and on the ice40?
<sxpert>
haven't tried for a while
<corecode>
ok
<sxpert>
need to update the script
<sxpert>
at this time it wouldn't fit in the ice40, am using up all of the brams for rom and ram ;-)
<corecode>
chubby
<sxpert>
that is 192 of them ;-)
<sxpert>
and only 1/2 the system rom ;(
<sxpert>
last run, 36Mhz prior to routing, 65.66 after
<corecode>
wow, it sped up
<sxpert>
yeah, it moves randomly
<sxpert>
with me adding stuff ;-0
<sxpert>
been re-writing from march 6, had some wierd behavior that I couldn't fix
<corecode>
so i want to build a generic debug adapter, which means mostly bit wiggling in different ways, and different control flows; i wonder whether i should try to avoid a mcu and do it in fpga
<sxpert>
so, branched from there, and slowly re-adding the bits from master