<_whitenotifier-1> [Glasgow] whitequark commented on issue #117: Pins for Addon-Boards - https://git.io/fjkM9
<_whitenotifier-1> [Glasgow] whitequark reopened issue #68: Expose on-board I2C for accessories - https://git.io/fhjiy
<_whitenotifier-1> [Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjkDc
flea86 has joined ##openfpga
unixb0y has quit [Ping timeout: 246 seconds]
_whitelogger has joined ##openfpga
emeb has quit [Quit: Leaving.]
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjkDA
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan 8cd719d - revC1: improve Sync change layout, fix silk/fab layers
<_whitenotifier-1> [Glasgow] marcan created branch route-remaining-fpga-pin - https://git.io/fhhGp
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to route-remaining-fpga-pin [+0/-0/±1] https://git.io/fjkyU
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan a33d360 - revC1: route remaining FPGA pin (do not merge)
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to route-remaining-fpga-pin [+0/-0/±1] https://git.io/fjkyL
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan b1ce868 - revC1: route remaining FPGA pin (do not merge)
Bike has quit [Quit: Lost terminal]
gsi__ has joined ##openfpga
gsi_ has quit [Ping timeout: 245 seconds]
<_whitenotifier-1> [Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjky0
<marcan> daveshah: just to confirm, 48MHz driven into a random IO pin and routed to a gclk through fabric shouldn't be an issue, right?
<marcan> (no skew requirement, just a reference clock)
<marcan> (ice40HX8K)
rohitksingh_work has joined ##openfpga
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±3] https://git.io/fjkyH
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan fe2ecfe - revC1: route FPGA pin D5 to CLKREF
<_whitenotifier-1> [Glasgow] marcan deleted branch route-remaining-fpga-pin - https://git.io/fhhGp
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan deleted branch route-remaining-fpga-pin
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjkyQ
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan e95cdc6 - revC1: get rid of squiggle on In2 layer
<_whitenotifier-1> [Glasgow] whitequark commented on issue #97: Make both PLLs usable in theory - https://git.io/fjky5
<_whitenotifier-1> [Glasgow] whitequark closed issue #97: Make both PLLs usable in theory - https://git.io/fjkyd
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjkyj
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan f5b0070 - revC1: tweak 1V2 plane and prettify some traces
<tnt> marcan: should be fine
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±2] https://git.io/fjkSY
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan 6293edb - revC1: change AUX pin header .05" -> .1"
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±1] https://git.io/fjkSs
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan de551f9 - revC1: update fab layers
OmniMancer has joined ##openfpga
emeb_mac has quit [Ping timeout: 250 seconds]
m4ssi has joined ##openfpga
m_w has quit [Quit: Leaving]
<daveshah> marcan: yeah, will be absolutely fine
<daveshah> Routed clocks via fabric many times, never seen any issues
<marcan> cool
<marcan> we threw another doubled up pin to make the remaining PLL flexible (can use the PLL with routed input, in that case we can get the refclk from an auxiliary pin into fabric)
<marcan> ice40 PLLs are such a pain
<marcan> I think with that Glasgow revC1 is basically done
<marcan> (so if anyone wants to review the design, hint hint!)
<azonenberg> daveshah, marcan: the main thing you might see is duty cycle distortion
<azonenberg> (i'd be interested to see numbers re that)
<marcan> I think it's supposed to be the main FPGA core logic clock, in which case I think it doesn't matter much since the flops should trigger off one edge only?
<marcan> whitequark: thoughts?
<tnt> there are some neg edge stuff in the fx2 interface
<azonenberg> well its more, idk how much DCD you'll see
<azonenberg> but i know they optimize the global clock tree for that
<azonenberg> and possibly not fabric routing
<azonenberg> wrt uneven rise-fall times
<tnt> timing numbers for negedge vs rise edge in icecube2 are +- 1ns
<tnt> (or in that order of magnitude)
<whitequark> marcan: yeah the fx2 interface has some negedge stuff
<whitequark> but the tolerances on that are fairly wide
<marcan> azonenberg: keep in mind this is just fabric to get it into the gclk tree
<whitequark> so i think it's fine
<marcan> so not a gclk input, but still becoming a gclk eventually
<azonenberg> marcan: yeah but if it's uneven going into the gclk, it will be uneven on the tree
<azonenberg> GIGO
<azonenberg> the question is a) how much distortion you see and b) how much your design cares
<azonenberg> I can't answer either, just pointing it out as a red lfag
<marcan> of course, but it's not going to spend much time outside the gclk is what I'm saying
<whitequark> we can test this easily enough
<tnt> whitequark: did you ever manage to create a design that fails reliably (wrt to the fx2 thing ?)
<whitequark> tnt: not yet
<marcan> are we still changing CLKIF to an output, btw? I think we don't *have* to any more, unless you want to open up that PLL to dual-output modes too
<whitequark> i think we have to, don't we?
<marcan> I don't think so, as long as the PLL is used in single output mode
<marcan> it only takes over the adjacent ibuf if you use that second output
<marcan> and the only useful mode there, since we already have CLKREF on another pin, is the dual output mode
<whitequark> oh, that simplifies things considerably
<whitequark> excellent then, this is as future-proofed as i can imagine
<daveshah> FWIW, I've seen picorv32 run fine at the usual 16MHz on an UltraPlus using no global clocking at all
<daveshah> I think a short stretch of routing will be fine
<whitequark> our clock is 48 MHz on CLKREF
<daveshah> But this is also a 2-3x faster HX
<whitequark> I guess...
<marcan> dammit I can't find the lattice doc that actually explained this
<daveshah> Yes, the second output isn't that useful
<marcan> right, so you get to pick 0deg with delay, 90deg with delaw, raw pll output, and raw pll output /2
<marcan> on each port
<marcan> so some design might want to use two options from those I guess, but it would have to be a pretty niche thing
<daveshah> A register is often good enough for /2 if phase & duty aren't important
<marcan> yeah
<tnt> Oh nice, I can get a picorv32 at 30.72 MHz on a UP5k, I'm hapilly surprised.
_whitelogger has joined ##openfpga
GuzTech has joined ##openfpga
<whitequark> ^ yep
<whitequark> daveshah: why wouldn't a register output a 50/50 duty?
<whitequark> wait
<whitequark> that could happen if the output stage is not symmetric
<daveshah> Yes
<whitequark> *is* it symmetric?
<daveshah> Not sure
<whitequark> it does seem like they could save a little bit of space by making them asymmetric
<whitequark> wait, no, that doesn't seem right
<daveshah> The timing data for the register output itself is symmetric for rising and falling
<whitequark> daveshah: so in ice40 all routing is made by unidirectional buffers
<daveshah> Some is bidirectional
<whitequark> if they made buffers asymmetric too, this would compound to potentially very high asymmetry
<whitequark> and if buffers are symmetric it makes no sense to make registers asymmetric, there are many more buffers than registers
<whitequark> 09:04 < daveshah> Some is bidirectional
<whitequark> clifford said they're all unidirectional
<daveshah> No, I did some further experiments with Radiant
<whitequark> oh?
<daveshah> Some are bidirectional, no idea which exactly
<whitequark> huh.
<daveshah> But definitely evidence that it uses "some" in the wrong way
<daveshah> Clifford originally thought all of the "routing" type connections are bidirectional
<daveshah> This isn't true
<daveshah> Some of those are bidirectional, but we treat all as unidirectional now
<daveshah> timing data for span4 muxes show about 10-20ps asymmetry between rising and falling btw
<whitequark> huh
<whitequark> okay
<whitequark> where does the nextpnr timing model come from, anyway?
<daveshah> sdf files from icecube
<daveshah> That were processed by icefuzz
<daveshah> Same as icetime
<whitequark> huh
<daveshah> ECP5 was a bit more complicated, as unlike iCE40 the timing netlist and SDF aren't split up with buffers per pip
<daveshah> So it was a case at comparing the whole delay and routed path of the net (assuming pips of a similar type have the same delay)
<daveshah> And obtaining a least squares solution to the resulting system
<whitequark> that's clever
<daveshah> Pretty sure people have done similar with Xilinx parts too
<tnt> The .lib files in icecube2 has plenty of timing data, not sure if anyone try to see if they're usable ?
<daveshah> Not something I would go near
<whitequark> yeah, you need to do a little bit of copyright laundering
<whitequark> people usually call it blackbox reverse engineering, i guess
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined ##openfpga
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+1/-1/±2] https://git.io/fjk7a
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark b12f7a9 - glasgow.platform.{rev_c→rev_c0}
<_whitenotifier-1> [Glasgow] electroniceel commented on issue #117: Pins for Addon-Boards - https://git.io/fjk7X
<_whitenotifier-1> [Glasgow] electroniceel commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjk5v
<_whitenotifier-1> [Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjk5u
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 245 seconds]
<_whitenotifier-1> [Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjk5d
<_whitenotifier-1> [Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjkdR
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 246 seconds]
cr1901_modern has quit [Ping timeout: 246 seconds]
cr1901_modern has joined ##openfpga
genii has joined ##openfpga
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
somlo has quit [Remote host closed the connection]
Asu has joined ##openfpga
rohitksingh has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
GuzTech has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 246 seconds]
azonenberg_work has joined ##openfpga
azonenberg_work has quit [Read error: Connection reset by peer]
azonenberg_work has joined ##openfpga
zem has quit [Ping timeout: 250 seconds]
zem has joined ##openfpga
<_whitenotifier-1> [Glasgow] whitequark commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjkxz
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan pushed 1 commit to master [+0/-0/±3] https://git.io/fjkxg
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] marcan 4963102 - revC1: make I/O connector pin 20 NC
somlo has joined ##openfpga
azonenberg_work has quit [Ping timeout: 245 seconds]
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjkps
<_whitenotifier-1> [GlasgowEmbedded/Glasgow] whitequark abf2a94 - platform.rev_c0: add aux pins.
emeb has joined ##openfpga
<_whitenotifier-1> [Glasgow] marcan commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjkpu
rohitksingh has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
azonenberg_work has joined ##openfpga
mumptai has joined ##openfpga
gsi__ is now known as gsi_
rohitksingh has quit [Remote host closed the connection]
balrog has quit [Ping timeout: 245 seconds]
ZipCPU has quit [Quit: ZNC 1.6.4 - http://znc.in]
ZipCPU has joined ##openfpga
ZipCPU|Alt has joined ##openfpga
ZipCPU|Alt has quit [Ping timeout: 240 seconds]
ZipCPU|Alt has joined ##openfpga
<_whitenotifier-1> [Glasgow] electroniceel commented on issue #68: Expose on-board I2C for accessories - https://git.io/fjIJT
balrog has joined ##openfpga
catplant has quit [Ping timeout: 252 seconds]
catplant has joined ##openfpga
mumptai has quit [Quit: Verlassend]
Asu has quit [Ping timeout: 250 seconds]
balrog has quit [Ping timeout: 245 seconds]
<_whitenotifier-1> [Glasgow] electroniceel opened issue #118: Improve ESD immunity - https://git.io/fjIUq
balrog has joined ##openfpga
sxpert has quit [Ping timeout: 246 seconds]
Bike has joined ##openfpga
<bubble_buster> what's the name of Clifford's verilog fuzzer? I don't see it on his website, I thought it used to be there
<cr1901_modern> vloghammer
<bubble_buster> ah, it's under yosys, thanks
genii has quit [Remote host closed the connection]
balrog has quit [Ping timeout: 250 seconds]
balrog has joined ##openfpga
vmedea has quit [Ping timeout: 246 seconds]
emeb_mac has joined ##openfpga
vmedea has joined ##openfpga
futarisIRCcloud has joined ##openfpga
azonenberg_work has quit [Ping timeout: 246 seconds]
ZipCPU|Alt has quit [Quit: Cap'n! The dilithium crystals are ...]
balrog has quit [Ping timeout: 246 seconds]
forrestv has quit [Ping timeout: 258 seconds]