<azonenberg>
tpw_rules: are you doing lcd driver stuff?
<tpw_rules>
LCD? no
emeb has quit [Quit: Leaving.]
<TD-Linux>
got my colorlight "devkit". only problem with this is I need to get a parallel video bus onto it somehow
emeb_mac has joined ##openfpga
<TD-Linux>
is there a current recommended way to use litex cores from nmigen? I remember heavyx did some import rewriting hacks
OmniMancer has joined ##openfpga
_whitelogger has joined ##openfpga
OmniMancer1 has joined ##openfpga
Patater_ has joined ##openfpga
lexano_ has joined ##openfpga
parport0 has quit [Ping timeout: 240 seconds]
OmniMancer has quit [Read error: Connection reset by peer]
Patater has quit [Remote host closed the connection]
lexano has quit [Ping timeout: 272 seconds]
keesj has joined ##openfpga
keesj has quit [Ping timeout: 272 seconds]
ZirconiumX has quit [Ping timeout: 272 seconds]
ZirconiumX has joined ##openfpga
parport0 has joined ##openfpga
<TD-Linux>
ZirconiumX, yeah but that means I have to have my own fork of litex
<ZirconiumX>
Again: HeavyX just patches the imports
<ZirconiumX>
And that's what you're doing here too
<emily>
TD-Linux: litex is planning to move to nmigen i think
<emily>
so "wait a while" might also be a valid strategy
<TD-Linux>
emily, I considered it but then I just drank a ton of caffeine so
<OK_b00m3r>
lol
<TD-Linux>
I'm excited to say that it seems that lattice might almost have figured out devkits
<emily>
TD-Linux: imo if you maintained one canonical litex-nmigen fork with a big sed for the imports and opportunistically fixed stuff that's still broken people would appreciate that
<emily>
(as an interim thing)
* awygle
would appreciate that
<emily>
could go in the nmigen org if people wanted to contribute maybe?
* awygle
would probably contribute
<TD-Linux>
sure once I figure out what I'm doing
<tpw_rules>
i would appreciate that too
<tpw_rules>
and might could contribute
<TD-Linux>
this is the politest way I've ever been trolled into maintaining something
<ktemkin>
I mean, I don’t really have a strong opinion on the matter; but if the guiding is too polite I’m sure someone would be willing to be a bit tsundere about it~
<ktemkin>
“It’s not like I want you to m-maintain it or anything”
OmniMancer1 has quit [Read error: Connection reset by peer]
_whitelogger has joined ##openfpga
keesj has quit [Quit: leaving]
keesj has joined ##openfpga
_whitelogger has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
Asu has joined ##openfpga
ZombieChicken has joined ##openfpga
OmniMancer1 has joined ##openfpga
rrika has joined ##openfpga
OmniMancer1 has quit [Quit: Leaving.]
<mwk>
so it seems that I'll have to do some parsing of SDF and (structural) Verilog files in python quite soon; are there some reasonable libraries for that?
<mwk>
I imagine for Verilog, my best bet would probably be running that through yosys and parsing json instead; no idea about sdf though
<daveshah>
I wrote a somewhat impromptu SDF parser for parsing Diamond back-annotation in trellis
<mwk>
heh, this is exactly what I'm planning to do as well :p
<mwk>
yep, that looks like something I'm about to steal, thanks
edbordin has quit [Ping timeout: 260 seconds]
emeb has joined ##openfpga
Zorix has quit [Ping timeout: 256 seconds]
Zorix has joined ##openfpga
Jybz has joined ##openfpga
Asu has quit [Remote host closed the connection]
pie_[bnc] has quit [Quit: pie_[bnc]]
pie_[bnc] has joined ##openfpga
Maya-sama has joined ##openfpga
Maya-sama is now known as Miyu
hackkitten has quit [Ping timeout: 272 seconds]
Miyu is now known as hackkitten
mumptai_ has quit [Quit: Verlassend]
mumptai has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale has joined ##openfpga
X-Scale` has quit [Ping timeout: 240 seconds]
mumptai has quit [Quit: Verlassend]
Jybz has quit [Quit: Konversation terminated!]
Asu has joined ##openfpga
<ZirconiumX>
So, keeping in mind that "all models are wrong", does it seem reasonable to model output Fmax spread as a Poisson distribution?
<ZirconiumX>
Well, I suppose Fmax is technically continuous, so it should be a boring Gaussian
<sorear>
if each transistor on the critical path is independent, the critical path delay will be Gaussian bc CLT, which means that Fmax is the reciprocal of a gaussian
<sorear>
of course the transistors are not independent, there are correlated process fluctuations across the chip
<ZirconiumX>
I mean, I'm mostly observing Gaussian-like distribution of Fmax given random seeds
<sorear>
oh, for some reason I was thinking "single layout, ensemble of chips"
<sorear>
if each stage in the critical path is placed independently the same would apply
<ZirconiumX>
I wasn't very clear, sorry
<ZirconiumX>
Essentially I'm trying to fit an observed Fmax data distribution to a theoretical distribution
<sorear>
my bias would be to convert them into min cycle time, and then try to fit a gaussian to that
<sorear>
although if fitting fmax directly works better, go for it
<TD-Linux>
I assume this is in the context of nextpnr seeds and not chip binning?
<ZirconiumX>
The former, yeah
<ZirconiumX>
Basically I've been trying to get an actually data-driven approach to quantifying a change to Yosys/nextpnr
* TD-Linux
thought about this for a bit and while the poisson seems more intuitive, he can't think of any way to back that up
<whitequark>
emily: awygle: TD-Linux: there should be a package that dispatches to migen or nmigen-compat depending on configuration; I'll implement it soon-ish and this is what litex would prefer to use
<emily>
whitequark: why "depending on configuration"? it can just route to nmigen and you can use the real migen if you want the real migen?
<emily>
if "because global package installations", well... that's why everyone uses virtualenvs etc.
<TD-Linux>
guaranteeing nmigen-compat compatibility with some of the really big cores in litex might be difficult
<whitequark>
emily: the problem it solves is that litex maintainers want to be able to switch easily between migen and nmigen.compat