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]
<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]