X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Po-ta-to, boil em, mash em, stick em in a stew.]
X-Scale has joined ##openfpga
<TD-Linux> how d oyou all deal in kicad with capacitors with a wide range of different voltage ratings? stuff it in the value field, or a separate field?
Bike has quit [Quit: Lost terminal]
emeb_mac has left ##openfpga [##openfpga]
<Zorix> i actually left it out of my last project
<Zorix> personally id probably put it in the value field too
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 246 seconds]
<adamgreig> TD-Linux: I alwys have a 'Voltage' field and specify it for all caps, and for anything else that matters
<adamgreig> I spec it to the actual voltage of the part rather than whatever it operates at
<adamgreig> then for unusual votlages i set the field to visible, and for boring logic voltages i leave it hidden
<TD-Linux> ok cool. only downside is that it doesn't appear on the schematic
<TD-Linux> oh can I set arbitrary user fields to be visible?
<adamgreig> yea
<adamgreig> tick 'Visible' against that field
<TD-Linux> oh okay cool. that's the only reason I was trying to cram it into value :D
<adamgreig> sorry it's "Show" in the edit dialogue
<adamgreig> and 'Visible' in the single field edit dialogue, lol
SpaceCoaster_ has quit [Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in]
SpaceCoaster has joined ##openfpga
Jybz has joined ##openfpga
emeb_mac has joined ##openfpga
<azonenberg> TD-Linux: Generally I put it in the value field if I care
<azonenberg> if it's a low voltage part like 3.3V or something i normally leave it blank
OmniMancer has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
emeb_mac has quit [Quit: Leaving.]
freemint has joined ##openfpga
freemint has quit [Ping timeout: 250 seconds]
mifune has joined ##openfpga
Stary has quit [Ping timeout: 252 seconds]
Stary has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined ##openfpga
freemint has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
rohitksingh has quit [Ping timeout: 250 seconds]
freemint has joined ##openfpga
freemint has quit [Ping timeout: 250 seconds]
Bird|ghosted has quit [Ping timeout: 240 seconds]
freemint has joined ##openfpga
freemint has quit [Ping timeout: 264 seconds]
freemint has joined ##openfpga
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
Bird|otherbox has joined ##openfpga
mumptai_ has quit [Quit: Verlassend]
mumptai has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
finsternis has quit [Remote host closed the connection]
freemint has joined ##openfpga
eightdot has quit [Remote host closed the connection]
eightdot has joined ##openfpga
carl0s has joined ##openfpga
maciejjo has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
Asu has joined ##openfpga
finsternis has joined ##openfpga
freemint has quit [Ping timeout: 250 seconds]
freemint has joined ##openfpga
somlo has quit [Ping timeout: 250 seconds]
somlo has joined ##openfpga
emeb has joined ##openfpga
freemint has quit [Ping timeout: 268 seconds]
freemint has joined ##openfpga
freemint has quit [Ping timeout: 268 seconds]
freemint has joined ##openfpga
rohitksingh has joined ##openfpga
genii has joined ##openfpga
rohitksingh has quit [Ping timeout: 264 seconds]
freemint has quit [Ping timeout: 245 seconds]
mumptai has quit [Quit: Verlassend]
freemint has joined ##openfpga
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined ##openfpga
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined ##openfpga
<rvense> i'm attempting to learn verilog, and a stumbling block is that it seems like it's often like this... tedious? repetitive?
<qu1j0t3> perhaps why so many HLHDLs now exist
<whitequark> rvense: verilog is bad, yes
<whitequark> that said
<whitequark> ok yeah i'm not sure if there's an idiomatic way to do this with a `generate` or something
<mwk> rvense: you know that these two are not equivalent, right?
<mwk> (different results for 'h3a)
<rvense> heh, yes, i just spotted htat
<rvense> but will that change the output?
<mwk> a bit, but I don't think it will actually *help*
<daveshah> The main problem here is "picking when to use hard carries is non-trivial"
<mwk> the core of the problem here is that the synthesizer doesn't understand it can do an equality comparison on the high 4 bits
<daveshah> Try "synth_ice40 -nocarry" just for fun
<mwk> instead of two inequality comparisons
<rvense> daveshah: same output, as far as i can tell
<daveshah> rvense: same on the second case; not on the first
<rvense> huh, no, 7 cells! how does it do that?
<daveshah> Without carries in the way it can optimise the soft logic much more aggressively (this is very much a microbenchmark thing, -nocarry will not usually give better delay or area on more complex designs)
<whitequark> something something flowmap can optimize whiteboxes
<lain> but can it optimize whitequarks
<whitequark> evidently not
<daveshah> But how does it know when it will be best not to use the carry
<daveshah> Given in any nontrivial case timing also matters (carries are much faster than LUTs)
<whitequark> daveshah: it currently uses an unit timing model, but it's naturally extensible to non-unit
<whitequark> it'd take some work, but i think it's straightforward to implement
<rvense> daveshah: oh, so i can't just expect to pass -nocarry in the larger design that this was extracted from and get 3/4s of my logic cells back?
<daveshah> I'm also not sure what gains you'll see without actual logic optimisation (something like freduce)
<whitequark> daveshah: that's true
<whitequark> if the default case was <= 'x it would work better
<whitequark> i think?
<daveshah> Because this is more about "don't use a carry and suddenly various parts of logic can get swept away"
<daveshah> I've thought about this a bit and making that decision a priori is quite hard
<whitequark> yeah, whitebox-aware lut mapping is quite a bit weaker than whitebox-aware optimization
<whitequark> interesting problem
<daveshah> There are probably some gains with a decent timing model but not the large gains something like that could give
<daveshah> As far as I can tell, Vivado is much less keen to infer carries in the first place
<whitequark> daveshah: actually, i've added a pass that fixes *some* of this
<daveshah> yes
<whitequark> "cmp2lut"
<daveshah> imo, carries probably shouldn't be inferred for compare-with-constant at all
<daveshah> because it's a case that almost certainly ends up being optimisable or foldabale
<daveshah> *foldable into other logic
<whitequark> i *think* cmp2lut would be completely subsumed by flowmap
<whitequark> among with all other 1-output k-variable-of-n input functions
<whitequark> (whitebox-aware flowmap)
<daveshah> Yes, for the packing into LUTs case
<whitequark> oh I see what you mean
<daveshah> A white-box-aware SAT-type optimisation pass would still probably be needed
<daveshah> based on freduce, at least in concept if not codebase
<whitequark> yeah, would be neat
rohitksingh has joined ##openfpga
mumptai has joined ##openfpga
lexano has joined ##openfpga
Bob_Dole has quit [Ping timeout: 245 seconds]
rohitksingh has quit [Ping timeout: 265 seconds]
Jybz has quit [Ping timeout: 268 seconds]
emeb_mac has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
freemint has joined ##openfpga
sgstair has quit [Read error: Connection reset by peer]
sgstair has joined ##openfpga
rombik_su has joined ##openfpga
sgstair_ has joined ##openfpga
sgstair has quit [Ping timeout: 265 seconds]
sgstair_ is now known as sgstair
Flux42 has quit [Quit: Patch BRB]
Flux42 has joined ##openfpga
Flux42 has quit [Client Quit]
genii has quit [Quit: Welcome home, Mitch]
Asu has quit [Quit: Konversation terminated!]
rohitksingh has joined ##openfpga
mumptai has quit [Remote host closed the connection]
Bike has joined ##openfpga
carl0s has quit [Ping timeout: 260 seconds]
lolsborn has quit [Ping timeout: 276 seconds]
lolsborn has joined ##openfpga
rombik_su has quit [Quit: Leaving]
emeb has quit [Quit: Leaving.]