<marcan>
electronic_eel: revD should be "easy" to build in the sense that it's just revC1 with a different FPGA package, copypasta of parts, and one or two extra bits to make it work
<marcan>
so hopefully it won't take a year
<marcan>
tnt: not all of them (the PLL thing)
<marcan>
(revC0 has some restrictions on PLL usage that revC1 lifts)
<marcan>
(also the SYNC thing)
<electronic_eel>
marcan: but we want a proper addon-interface for revD and come up with a i2c bus isolator solution for that
<marcan>
yes, that's basically the only new thing for revD
<marcan>
i2c shenanigans
<tnt>
Where are the ECNs ? I can't find them anymore ...
<tnt>
nm, found them ... I thought there were in the repo itself as markdown.
<electronic_eel>
I'd also wait with revD layout until the production run of revC1 from esden is delivered and people had a bit of time to play with it, so any issues or improvement ideas from them could be incorporated into revD
<tnt>
I'm a bit confused as to what the PLL thing really is ... it seems to only restrict some very specific cases.
<tnt>
I mean, you have to want to use both PLLs both with clock inputs other than CLKREF, but you still want to use CLKREF for something else.
<tnt>
The fact you can't use both PLL outputs because CLKIF uses that IO site seems like a bigger limitation ...
<jer__>
esden: if you need a beta tester, ;)
<jer__>
happy to pay
<electronic_eel>
jer__: getting cold feet after you saw the tiny footprints? ;)
<jer__>
well to be honest
<jer__>
im mostly concerned about the BGA
<jer__>
I normally use high bismuth solder for my prototypes
<JJJollyjim>
^
<jer__>
so all of my gear is set for much lower temperatures
<jer__>
but with the BGA the balls are provided, so I don't get to choose the alloy :(
<jer__>
i really need to finish building my vapour phase oven i guess
Ekho has quit [Quit: An alternate universe was just created where I didn't leave. But here, I left you. I'm sorry.]
<whitequark>
11:10 < tnt> I mean, you have to want to use both PLLs both with clock inputs other than CLKREF, but you still want to use CLKREF for something else.
<whitequark>
11:11 < tnt> The fact you can't use both PLL outputs because CLKIF uses that IO site seems like a bigger limitation ...
<whitequark>
this is related
Ekho has joined #glasgow
<whitequark>
in theory you can flip the direction of CLKIF so that you use both PLL outputs
<whitequark>
then you'd use the other CLKREF input and route it to CLKIF as output through fabric
<whitequark>
and use both PLLs unrestricted
jer__ has quit [Remote host closed the connection]
<tnt>
"in theory" ... because that changes all the IO timings, so I'm curious to see if anyone would actually do that.
<whitequark>
tnt: well, hardware is forever
thaytan has quit [Ping timeout: 246 seconds]
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to travis-synth [+0/-0/±1] https://git.io/fjpUM
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark 855262c - Travis: build Yosys and nextpnr.
<gruetzkopf>
aaah, wq twitter mentions always lead to followers...
<whitequark>
is that bad
<gruetzkopf>
nah. they'll spawn anyways
<gruetzkopf>
(some of those people apparently also understand bad german ISDN jokes)
* hellsenberg
just remembered they were meant to upload a few things
<ar>
whitequark: because of that thread i now got hit with nostalgia. thanks
<ar>
those were fun times.
<whitequark>
which thread
<whitequark>
remember i have the attention span of a cat
<ar>
whitequark: oh. the two sub-threads - one ending with me writing very bad C; one with devs at the same company making questionable, but somewhat understandable, design decisions about storing raw java objects, without any serialization, in database