<azonenberg>
#1, why is writing a bitstream even multithreaded
<azonenberg>
that should not be a bottleneck
<azonenberg>
if it is, you're doing something seriously wrong
scrts has quit [Ping timeout: 260 seconds]
<nats`>
WUT ?
<nats`>
remind me the old days of thread unsafe library
<nats`>
it was 10years ago....
tecepe has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
<cr1901_modern>
"(6:37:28 PM) azonenberg: i prefer nsanamegenerator.com for that" STEPSONPTARMIGAN
<cr1901_modern>
Sorry I was asleep, so catching up on backlog
eric_j has quit [Excess Flood]
doomlord has quit [Excess Flood]
eric_j has joined ##openfpga
<whitequark>
nats`: which library
<cr1901_modern>
"azonenberg: like, figure out how sane it actually is to do in verilog" I don't see why it wouldn't be. Any parts of the design which rely on parasitic effects or something sensitive to board layout aren't going to show up on schematic capture anyway.
<cr1901_modern>
Certainly very possible that the schematic doesn't tell the whole story, and I wouldn't expect anything we come up with to do the same in 100% of cases
<whitequark>
no, I mean in verilog as opposed to python
<whitequark>
or something
<whitequark>
he means*
<cr1901_modern>
I vote for Python, regardless of whether we extend Migen or not
<cr1901_modern>
I'm not qualified to write a type checker tho, regardless of the language
<whitequark>
we do not extend migen for sure
<whitequark>
type checkers are easy.
<whitequark>
type *systems* are hard.
<whitequark>
and our problem domain is basically unlike any we know how to write type systems for with any degree of certainty
<cr1901_modern>
Is a type checker something like if(input_type != expected_type) { error() }?
<whitequark>
if you write C, sure.
<whitequark>
if you write a language that's actually written for people to use, it's more complex because you have to handle parametricity
<whitequark>
even in C++ you have `auto` so you have to elaborate that
<cr1901_modern>
See, I wouldn't know how to elaborate that. I would need context of the surrounding code for an arbitrary input to figure out whether the type is actually "okay", I would think.
<whitequark>
look up "unification based inference"
<whitequark>
and "union find algorithm"
<whitequark>
and "let polymorphism"
<whitequark>
the actual implementation is 100 lines if you're doing it in somehting extremely verbose like python
<whitequark>
that gets you to a basic ML that can do stuff like "list<int>" (in c++ syntax) and polymorphic functions
<whitequark>
if you want to have mutation then it gets a bit more complex but only a bit
<cr1901_modern>
Hmmm, I think I'll give that a shot tonight then (only using Python b/c it's "what I'm comfortable with").
<whitequark>
this is basically all you need for core Caml
<cr1901_modern>
Can I ask you about mutation when I get to that point?
<whitequark>
OCaml adds a lot of fluff on top of that like GADTs, row polymorphism, classes, and such
<whitequark>
those have considerable complexity and lots of parts of OCaml type system are still unsound
<whitequark>
haskell feels ridiculously clunky to me
<cr1901_modern>
Not qualified to comment, tbh. Some things that I'm starting to understand, such as monads, seem easier in Haskell, compared to OCaml. But I prefer learning the latter
digshadow1 has quit [Quit: Leaving.]
<whitequark>
ocaml doesn't have first-class monads
<whitequark>
it lacks typeclasses
<cr1901_modern>
Ahhh. I saw a blog post on how to "implement" them and it was beyond me.
<whitequark>
that was probably explaining how to implement them with modules
<whitequark>
first-class modules in ocaml have almost the same power as typeclasses, except there is no implicit derivation
<whitequark>
I don't blame you, most explanations of first-class modules are really bad, and on top of that the *implementation* is very inelegant
<whitequark>
1ML doesn't even have the distinction between modules and structs
<whitequark>
I could explain it in simple terms but it is probably irrelevant
<cr1901_modern>
The use case for me learning monads is that someone gave me a high-level overview of a monadic parser, chaining parsers that only recognize one symbol together in order to create the rules for parsing identifiers
<rqou>
hmm my programming languages course didn't actually go too much into type systems
<cr1901_modern>
And I was like "wow, this is really elegant!" Maybe *I* can make a parser
<cr1901_modern>
Then I try doing it in OCaml: I have no idea WTF I'm doing :D
<rqou>
i've never taken the time to learn ML-style type systems
<whitequark>
you don't need to understand monads to use or write a monadic parse
<whitequark>
first-class monads are only useful (barely, imo) if you want to abstract over control flow
<cr1901_modern>
":you don't need to understand monads to use or write a monadic parse" <-- just implement the pipeline action and calling a function in between on my own?
<whitequark>
kinda
<cr1901_modern>
I'll look up an article for OCaml and try it if I really get stuck. Might as well try to discover it "on my own"
<whitequark>
the point of typeclasses is basically existentials plus implicit derivation
<whitequark>
you want to pack a type t with the monad signature (return : 'a -> 'a t ; bind : 'a t -> ('a -> 'b t) -> 'b t))
<whitequark>
this is the part that needs existentials, and you can do that with first-class modules
<whitequark>
module T = struct type t val return : 'a -> 'a t val bind : 'a t -> ('a -> 'b t) -> 'b t end
<whitequark>
this can be used with let module M = (val m : T) in ...
<whitequark>
then using M.return x inside ...
<whitequark>
then there is code generation, where you basically want >>= to look up an appropriate module for the value you're binding
<whitequark>
and, in case of parametric types, actually synthesize that
<whitequark>
this is the part that mainline OCaml doesn't have (yet)
* cr1901_modern
is looking up what an existential type is
<cr1901_modern>
Other than that I understand everything you just said o.0;
<whitequark>
an existential type is "some type but i don't know which"
<whitequark>
so if you have "let module M = (val m : T) in ..." then M.t refers to some abstract type
<rqou>
i have no idea what is going on with that code :P (don't know the syntax at all)
<whitequark>
you can manipulate it like you would manipulate any abstract type
<whitequark>
and it cannot escape the "let module M = "
<whitequark>
it's also called "locally abstract type" in OCaml lingo
<whitequark>
that's it. the complexity is not in the definition, it's in typechecking it, because you have to be very careful that you don't let it escape
<cr1901_modern>
I wouldn't know how to make it escape deliberately, tbh. I've learned that let bindings were meant to limit scope
<cr1901_modern>
so they're invalid outside of the block where you defined the let binding
<whitequark>
uhm
<whitequark>
let module M = (val m : T) in M.return 1
<whitequark>
this returns an "int M.t"
<cr1901_modern>
Oh... I'm still not used to that.
scrts has quit [Ping timeout: 260 seconds]
<cr1901_modern>
azonenberg: I have nothing to add to the page currently. Everyone beat me to it lol
doomlord has joined ##openfpga
<cr1901_modern>
I'm used to only using let bindings in the scope I defined them in, as a "convenience" for defining my immutable (well not in Scheme :P) variables/values early. I'm still use to the Scheme mindset, so returning "1" would return, well "int", not "int M.t". Unless Scheme has this capability too and I just never understood it at all
<whitequark>
wat
<whitequark>
return isn't a keyword in ocaml
<whitequark>
it's just a function
<whitequark>
"M.return 1" if M is a global module will do the exact same thing
<whitequark>
just that the type is now legal to observe outside of the let expression
<cr1901_modern>
Bleh, ignore me lmao... I'm an idiot
digshadow has joined ##openfpga
<cr1901_modern>
"inrush current" <-- I'm not exactly sure how you're going to detect this without doing a spice simulation. Perhaps linearizing your circuit into equivalent input impedances given a known operating voltage and solving for transient equation.
<cr1901_modern>
s/detect/calculate/
<cr1901_modern>
Does spice even have an IC database?
<whitequark>
so we can search by case/voltage/capacitance/tolerance but cv graphs are no luck
<azonenberg>
yeah
<azonenberg>
thats why i was thinking, we might have no choice but to make a db of some sort
<azonenberg>
or simply not offer cv searching
<azonenberg>
and rely on the end user to derate as needed
<azonenberg>
but that sounds like it breaks the whole design paradigm we want
<whitequark>
i don't think so
<azonenberg>
fwiw in my last one i didnt have a part db or anything
<whitequark>
*some* manual tinkering will always be required
<azonenberg>
i explicitly coded parts by digikey p/n in the ip core :p
<whitequark>
yes, seen that
<whitequark>
i feel like we should aim for interactive flow
<whitequark>
we will already need that because:
<whitequark>
1) we need persistent refdes generation for re-running layout
<azonenberg>
yes, there has to be ERC support in that regard
<azonenberg>
i meant ECO support
<azonenberg>
cant type
<whitequark>
ECO?
<azonenberg>
engineering change order
<whitequark>
ah
<whitequark>
i think simpler.
<azonenberg>
as in, you have to be able to support modifying a mostly finished design
<azonenberg>
without disturbing it too severely
<whitequark>
refdes is generated and then cached by full path or something
<azonenberg>
well yeah
<azonenberg>
in the EDA industry in general though
<azonenberg>
"ECO" refers to modifications to a previously routed, or partially routed, design
<azonenberg>
with the intent of being minimally invasive
<azonenberg>
like, if you are doing a mask respin on an asic
<whitequark>
ahh i see
<whitequark>
2) lookup of passives etc from suppliers should be flexible
<whitequark>
you get from digikey, i don't have that in hk, i have farnell
<whitequark>
and rs
<whitequark>
so also cached
<azonenberg>
So there needs to be an abstraction layer for vendor APIs
<whitequark>
we can start with "just octopart"
<whitequark>
and have that be our abstraction layer
<azonenberg>
yes but i would still prefer to have some generic API that wraps it
<whitequark>
just don't assume it very deeply, have some abstract search terms
<azonenberg>
s.t. we can add other stuff as needed
<azonenberg>
As well as a clientside cache (in the home dir, not the project dir, since it can be shared across multiple projects
<azonenberg>
like if you look for a generic 10k 0402 jellybean resistor
<whitequark>
map "capacitance" "voltage" etc to octopart classification
<azonenberg>
that table of results should be cached for a while
<azonenberg>
also, we should factor cost into the search
<whitequark>
ok so after 2), there's 3) which is not all jellybean crap is created equal
<whitequark>
so we need manual overrides
<whitequark>
even if we search *perfectly* maybe this specific component turns out to be crap
<azonenberg>
you should be able to do things like "find the cheapest 0.1 uF X7R from samsung or TDK that is in 0402 or smaller package and rated for 6.3V or more"
<whitequark>
so we need to override that
<whitequark>
yup sure
<whitequark>
the cache won't work well with relational queries
<whitequark>
if you want to factor in cost
<azonenberg>
i was thinking only cache for a day or two
<whitequark>
meh, just make offline work possible
<azonenberg>
just to avoid hammering the server every rebuild
<whitequark>
in case you're on a flight
<whitequark>
oh, do cache it by all means in the design
<whitequark>
the cache is meant to be committed to VCS
<azonenberg>
i meant cache the whole search result
<azonenberg>
not just the one you picked
<azonenberg>
So you can go re-evaluate
<whitequark>
that doesnt seem optimal
<azonenberg>
and i thought it'd make more sense to be in ~/.v2pcb/
<azonenberg>
so its shared across all projects
<whitequark>
you can do very specific searches with octopart
<azonenberg>
we might have different ideas of the cache
<whitequark>
and you want these
<whitequark>
how do you cache them?
<azonenberg>
there is one thing for "R2 is 123-456-789-ND"
<azonenberg>
there's another one for "list of all the 10k 0402 resistors with 5% or better tolerance"
<azonenberg>
the latter is what i suggested caching
<azonenberg>
so that you dont hit octopart for every pullup every time you rebuild the design
<whitequark>
oh, you expect to have many exact same queries
<azonenberg>
Yes
<azonenberg>
For things like "generic decoupling cap"
<whitequark>
and by rebuild you mean add a few more passives
<azonenberg>
or "generic pullup"
<whitequark>
I agree
<azonenberg>
or "generic LED current limiting"
<azonenberg>
those will be common across ALL projects
<azonenberg>
not the current design only
<azonenberg>
and should be cached on the dev's workstation
<whitequark>
yup sure
<azonenberg>
so that if you want to later go back and say "oh, can I make the LED series resistors physically smaller?"
<azonenberg>
you might have a selection of "0603 or smaller 470 ohm resistors with 0.1W or better power rating, tolerance non-important"
<azonenberg>
This is way more ambitious than what i originally planned, lol
<azonenberg>
But at the same time sounds way more useful
<whitequark>
so I'm itching to start a prototype already
<whitequark>
might gonna start it like... today
<azonenberg>
Lol
<whitequark>
MVP: board with one connector, one LED and one resistor, all the way from "HDL" to Eagle board layout file
<whitequark>
with proper layering
<azonenberg>
Sounds good, but I think the majority of the work will be in the DRCing etc
<azonenberg>
Which is why i was using a multichannel SMPS as the testbed for my last iteration
<whitequark>
DRCing like what?
<azonenberg>
ERC*
<whitequark>
ah sure
<azonenberg>
Because there were a lot of complex requirements
<whitequark>
there's some work in packaging
<azonenberg>
like, if you cascade channels they have to be adjacent
<whitequark>
because I don't want to reuse backend packages
<azonenberg>
vin must be within range X
<azonenberg>
etc
<whitequark>
for one that's going to be inconsistent
<whitequark>
for another, i want to generate them
<azonenberg>
So it seems like the high level structure is going to be something like
<whitequark>
i want to write a dip description exactly once
<azonenberg>
front end: turn HDL of some kind into an abstract netlist
<azonenberg>
middle: run ERC on the abstract netlist
<azonenberg>
back end: turn netlist into layout file for PCB
<whitequark>
(brb, need to go away for a bit)
<azonenberg>
middle will probably also do bom elaboration
<azonenberg>
and refdes generation
<cr1901_modern>
Why don't we create a skeleton for a "part" class?
<cr1901_modern>
should have a name, a datasheet, a Pins vector
<cr1901_modern>
Part Entity could contain a reference to a part shared by all other parts of the same type, with a universal ID
* cr1901_modern
isn't really all that great at designing classes. Yea, knowing the language/writing programs that don't suck are two different things
<azonenberg>
lol yeah
<whitequark>
1yup
<cr1901_modern>
Whether I suck at one or both is up to interpretation
<cr1901_modern>
(complaints welcome)
<whitequark>
meh, OO is just the wrong abstraction most of the time
<cr1901_modern>
Well, I don't care for it. I like Rust's traits, tbh
<cr1901_modern>
azonenberg: I don't think we're getting around a database, unless you want to write a datasheet extractor which then looks for a "v" shaped curve in a box that also detects numbers on the x and y axis.
<whitequark>
traits ~ typeclasses
<whitequark>
what cr1901_modern describes is actually not outlandish
<azonenberg>
lol, depends on how bad the datasheet is
<azonenberg>
i guess if its a new machine generated one
<whitequark>
i've seen implementations of like, parsing of graphs, in siggraph papers or something
<whitequark>
no, hand-drawn
<azonenberg>
o_O
<azonenberg>
but not in the a0 release :p
<whitequark>
absolutely not
<cr1901_modern>
azonenberg: Fair enough
<cr1901_modern>
But something to think about. As long as it has a nice failure mode :)
<whitequark>
the problem with this kind of computer vision stuff is that it doesn't
<whitequark>
this is a "nice research project"
<whitequark>
but i really don't care for it until we are at feature parity with eagle schem
<azonenberg>
yeah exactly
<azonenberg>
in the meantime
<azonenberg>
if we can manually add c-v curves for certain common samsung caps
<azonenberg>
that would help dramatically
<azonenberg>
there's only maybe 10 caps i use in 95% of my designs
<azonenberg>
maybe 20
<whitequark>
we could just make it take parts from local partdb when cv is requested
<azonenberg>
but still
<azonenberg>
yeah
<whitequark>
which order are cv curves btw?
<whitequark>
2nd?
<cr1901_modern>
azonenberg: Might be worthwhile to use a rational regression to predict the poles/zeros
<whitequark>
polynomial
<azonenberg>
whitequark: dont know, i've always treated them as magic curves full of non-idealities that no sane person would want to model
<whitequark>
no
<whitequark>
not modeling
<whitequark>
fitting
<azonenberg>
oh
<azonenberg>
you mean if you type in a few values and want to interpolate?
<whitequark>
fit to within 10% of entire curve
<azonenberg>
hmm, they look fairly low order
<azonenberg>
2 is plausible
<whitequark>
in a few params
<azonenberg>
not more than 3
<whitequark>
better than storing the entire thingi n partfdb
<cr1901_modern>
Polynomial will work, but the actual equations (minus noise) are rationals
<whitequark>
doing a "screenshot this rect, input axe ranges, use computer to read the actual curve" is trivial
<cr1901_modern>
1/(1 + CRs) or whatever
<whitequark>
axis
<whitequark>
not axe lol
<azonenberg>
whitequark: now that isnt a bad idea
<azonenberg>
dont try to do cv to find the curve
<azonenberg>
have a human provide it
<cr1901_modern>
oh that works too. I doubt we'll be doing designs that cares about 5-10% difference. Prob just use the valley, and endpoints
scrts has joined ##openfpga
<azonenberg>
cr1901_modern: yeah whats more important is to be able to distinguish a 4.7 uF cap that's 4.5 uF at your target voltage
<azonenberg>
from one that's 1.2 uF
<azonenberg>
:p
<cr1901_modern>
lol
<cr1901_modern>
Tbh, in general I think if you have a design that works at 4.7 but 4.5, you have a problem. But that's just IMHO
<whitequark>
thats actually another issue we have to take care of
<whitequark>
well not necessarily in the EDA package
<cr1901_modern>
taking care of the dielectric type?
<whitequark>
dc bias derating
<cr1901_modern>
azonenberg: You weren't talking about "dc bias derating" in "C/V" curve?
<whitequark>
i *think* that's a different issue
<whitequark>
wait no he was
<whitequark>
nevermind
<cr1901_modern>
Just wanted to make sure. I didn't think the C/V curve was meaningful for an ac signal
<whitequark>
azonenberg: so X5R looks *definitely* 2nd order
<whitequark>
lol "For your information, it is not only our products that have aging characteristics; it is a phenomenon commonly observed in high dielectric constant capacitors."
<cr1901_modern>
I just remembered, I THINK murata has a nifty derating web applet for their capacitors?
<whitequark>
we can RE that I guess?
<whitequark>
*if* it's per ceramic
<whitequark>
and not per capacitor line
<cr1901_modern>
I DO hope that the curves are given for the whole range of voltages supported as well
<cr1901_modern>
Be a pretty bad oversight if not, but I wouldn't be surprised
<azonenberg>
whitequark: i think its per cap
<azonenberg>
it at least varies per package
<azonenberg>
the derating curves are way steeper for smaller packages
<whitequark>
shit
<azonenberg>
yeeah
<azonenberg>
look at a samsung 4.7 uF X7R for example
<azonenberg>
from 0402 to 0603 to 0805
<azonenberg>
at say 6.3V rating
* azonenberg
finds links
<whitequark>
oh LOL
<cr1901_modern>
"whitequark: we can RE that I guess?" What's this in reference to?
<whitequark>
you can just export the complete list of supported caps from murata
<cr1901_modern>
azonenberg: Perhaps you should generate a set of default IPC footprints ;)
<azonenberg>
cr1901_modern: lol
<whitequark>
ipc?
<azonenberg>
fixing all of EDA *does* seem to have kinda become my crusade...
<cr1901_modern>
it's a standard for pads that kicad doesn't follow
<whitequark>
which standard?
<azonenberg>
cr1901_modern: well some of the newer library stuff kinda-sorta does
<cr1901_modern>
Don't remember. I just remember the term IPC-compliant
<cr1901_modern>
And judging from ee.stackexchange questions on the topic, it's not a pleasant read
<whitequark>
IPC-7351B: Calculate high resolution IPC-7351B & RoHS compliant land patterns (footprints) directly from component dimensions
<whitequark>
hrm
<whitequark>
we could implement that but it's not a priority
<whitequark>
it should be trivial once basic stuff is in
<azonenberg>
We're making a schematic entry tool
<azonenberg>
Not a layout tool
<azonenberg>
design entry*
<azonenberg>
Making a good PCB library to go with it would be nice
<cr1901_modern>
I was kinda-but-not-really making a joke
<azonenberg>
cr1901_modern: i wasnt
<azonenberg>
:p
<cr1901_modern>
Well, then file under "nice to have"
<whitequark>
SMT passives in the stdlib are basically mandatory
<whitequark>
so we could as well fix that. but not in a0
<azonenberg>
as well as QFP/SOIC/BGA footprints
<azonenberg>
those are all pretty easy to do procedurally
<azonenberg>
weird custom packages can be hand created as required
<whitequark>
exactly
<azonenberg>
also IPC specifies several sizes for pads for passives
<azonenberg>
based on the density you are targeting
<cr1901_modern>
weird custom packages <-- like DIP :P
<azonenberg>
So we should support all 3
<azonenberg>
least/nominal/most
<whitequark>
and hand creation will be VASTLY easier than in eagle if we let the user entry e.g. top left coords
<whitequark>
instead of just the center like eagle
<azonenberg>
cr1901_modern: when was the last time you saw a dip used in a board?
<whitequark>
I also want automatic silkscreening
<whitequark>
so generate silkscreen that surrounds the pads
<cr1901_modern>
azonenberg: In 2016 when I made some
<azonenberg>
you mean automatic silkscreen gen for pin 1 markers etc?
<whitequark>
yup
<azonenberg>
yes that would be nice
<whitequark>
then put pin 1 dot
<whitequark>
then add name/value
<azonenberg>
my current library is a bit of a hackjob
<azonenberg>
i'd love to unify it
<cr1901_modern>
azonenberg: And tbqf, you're gonna need through-hole for connectors anyway
<azonenberg>
Yes but that isnt the same as dip ICs
<cr1901_modern>
Ahh, connectors! There's a nebulous yet essential parts type
<azonenberg>
not that a dip ic would be hard to do
<azonenberg>
yes
<azonenberg>
those will likely have to be done by hand
<azonenberg>
as they vary so widely
<cr1901_modern>
So, priority on making manual entry simple
<cr1901_modern>
One of the reasons I don't care for sch capture is making parts is a PITA
<whitequark>
pfff i'm going smt-only. if your connector sint available in smt it isnt worth using
<azonenberg>
whitequark: i use PTH for connectors that i think might get tugged on, etc
<whitequark>
/joke
<whitequark>
ahem ;p
<cr1901_modern>
Nice. I almost took the bair
<azonenberg>
or for things that have no viable alternative, like a SFP cage (the actual SFP connector is SMT but the cage is normally PTH)
<cr1901_modern>
bait* even
<cr1901_modern>
azonenberg: You can release the line now
<azonenberg>
Lol
<cr1901_modern>
"(12:35:30 AM) azonenberg: as they vary so widely" Yes, this is true. But I also don't think we need tens of versions of common connectors, such as "2 rows of pins"
<azonenberg>
that i agree
<whitequark>
if we can generatively define connectors
<cr1901_modern>
^this
<whitequark>
then its simple for custom ones
<whitequark>
because most of them don't have completely random pin spacings
<whitequark>
i mean some do.
<whitequark>
BUT
<openfpga-github>
[logtools] azonenberg pushed 1 new commit to master: https://git.io/vXYWu
<openfpga-github>
logtools/master fe8976e Andrew Zonenberg: Finished initial implementation of ColoredLogSink
<whitequark>
azonenberg: LOL
<azonenberg>
whitequark: ?
<azonenberg>
whitequark: whats so funny?
<whitequark>
azonenberg: the murata sim appears to have the entirety of their data in a single mlcc.z file
<whitequark>
yes, that's 'compress'
<azonenberg>
lol :p
<azonenberg>
and oh i thought you were laughing at my commit
<azonenberg>
i was wondering how you read it that fast :p
<whitequark>
$ uncompress mlcc.z
<whitequark>
gzip: mlcc.z: not in gzip format
<whitequark>
what
<cr1901_modern>
zip file?
<azonenberg>
is it the wrong file format?
<cr1901_modern>
with a crappy extension?
<azonenberg>
zcat?
<whitequark>
no
<whitequark>
mlcc.z: zlib compressed data
<azonenberg>
lol
<whitequark>
it's 'compress'
<azonenberg>
so raw zlib?
<whitequark>
... the windows 'compress'
<azonenberg>
...
<whitequark>
i think?
<cr1901_modern>
:D
<whitequark>
oh wait
<whitequark>
that's 'pack'
<whitequark>
azonenberg: amazing
<whitequark>
python's zlib.decompress handles it
<whitequark>
there's csv inside
<whitequark>
a 25-megabyte csv with the entire murata mlcc lineup
<whitequark>
2% voltage stepping or something like that
<cr1901_modern>
If the polynomial is in fact embedded in the app, by all means use it :). I just didn't think it would be there
<whitequark>
well it has to be
<whitequark>
i see what are the inputs and outputs
<cr1901_modern>
Cool!
scrts has joined ##openfpga
m_w has quit [Quit: leaving]
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<cr1901_modern>
I need to retire for the night, but I'll read the backlog. One q I'm thinking of tho: wrt to dc bias degradation, are we going to expect a user to put in the tolerance for the capacitor? Of course qualitatively, bigger cap is better, but that's not quantative.
<azonenberg>
cr1901_modern: yes i was thinking you'd ask for an actual capacitance and tolerance
<azonenberg>
it'd pick the cheapest/smallest/balanced part
<azonenberg>
that met the capacitance you asked for at the specified bias voltage
<azonenberg>
within that tolerance
<cr1901_modern>
Ahh, you can do balance between cheapest and smallest. Nice!
<azonenberg>
or you might do something like
<azonenberg>
pick the cheapest part, but no larger than 0402
<azonenberg>
all kinds of fun optimization possible if you have the data in the tool
<cr1901_modern>
these I assume would be parameters into your verilog instance?
<azonenberg>
yeah
<azonenberg>
if you didnt care it'd pick some sane defaults
<azonenberg>
like, no derating and 10% tolerance
<whitequark>
20%? i thought most X7Rs were that
<azonenberg>
whitequark: whatever
<azonenberg>
point is, pick some sane default
<whitequark>
yeah
<cr1901_modern>
I was gonna ask if sane defaults were provided
<azonenberg>
and then the user can override if it's important
<cr1901_modern>
or if this was a power-user tool only :P
<cr1901_modern>
i.e. if you're using this tool, chances are you need to know this info
<azonenberg>
cr1901_modern: power users still dont care about the tolerance of the series resistor on an indicator LED
<azonenberg>
in most cases
<cr1901_modern>
^ fair enough XD
<azonenberg>
whitequark: my vision is to eventually have IP cores for things like "xilinx 7 series FPGA"
<cr1901_modern>
And again, would probably be worried if they did
<azonenberg>
and can do things like migrating between devices
<whitequark>
but yup
<azonenberg>
so for example
<azonenberg>
pick only iobs that are usable in the 7a35t and 7a50t
<whitequark>
really excited about this
<azonenberg>
regardless of package
<azonenberg>
This has been one of my TODOs for a very long time
<azonenberg>
but lack of other people interested in the project meant it was never a priority
<azonenberg>
i tend to rebalance priorities if people actually want to do it
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<azonenberg>
whitequark: fwiw, i have several large pcb projects for my fpga cluster
<cr1901_modern>
I am certainly very interested. And I have a board that needs to be remade anyway I can use as a test
<azonenberg>
that i would like to do using this technology
<azonenberg>
i have first drafts of a lot of these boards done in pure kicad flows
<azonenberg>
but the requirements changed before i taped out
<azonenberg>
so i'll likely redo them anyway
<cr1901_modern>
Hell, I'm willing to discard my kicad design for my current board and wait till this tool is ready
<whitequark>
azonenberg: so for a0, i'm going with pure python all the wya
<whitequark>
rationale: less serdes code
<whitequark>
less hassle with generation
<whitequark>
if/when that becomes a problem i will gladly switch to something that improves upon it
<azonenberg>
ok
<azonenberg>
i've needed an excuse to learn python for a while
<azonenberg>
2 or 3?
<whitequark>
3 only
<cr1901_modern>
3, please for the love of God
<azonenberg>
ok, i like that
<cr1901_modern>
Oh
<cr1901_modern>
nevermind
<whitequark>
hm?
<cr1901_modern>
"cr1901_modern: 3, please for the love of God" <-- prayer answered :P
<whitequark>
oh yeah
<azonenberg>
whitequark: are you ok with using 3-clause BSD as the license for the project?
<azonenberg>
thats what i have in the initial repo but it's open to discussion
<azonenberg>
for the greenpak tools i wanted lgpl as it was something that had a serious risk of being assimilated by a vendor
<azonenberg>
but here, seems like less of a concern
<whitequark>
i've decided a while ago that i license all my new stuff as "something like CC0 but OSI-approved"
<whitequark>
as my IPpolicy is "IP is fundamentally harmful"
<azonenberg>
3-clause BSD is pretty much that
<azonenberg>
it requires attribution and disclaims liability
<azonenberg>
and thats about it
<whitequark>
that has the attribution requirement but i am not going to argue over that
<whitequark>
especially given that i actually dont know yet a license that fits my requirement
<whitequark>
ideally wait the "0-clause BSD"
<whitequark>
but its not OSI-approved
<whitequark>
s/wait/i want/
<azonenberg>
I think it's only fair that if someone uses my hard work in their product for free
<azonenberg>
that they acknowledge it was my work
scrts has quit [Ping timeout: 252 seconds]
<whitequark>
oh absolutely. the part i don't like is using the violent power of state to enforce that
<whitequark>
its an ideological thing pretty much
<azonenberg>
Well, copyright is not going away :p
<azonenberg>
My general policy is that any code i release as open source is a gift to the world
<whitequark>
does PRC even have copyright?
<azonenberg>
and a gift should come with as few strings attached as possible
<whitequark>
amazingly... yes, since 2010 actually
<azonenberg>
lol
<azonenberg>
since 2010?
<azonenberg>
whitequark: anyway, all i want is to make it clear that if you use my project you do so at your own risk
<whitequark>
oh no
<whitequark>
since 1990
<whitequark>
alomst as good
<whitequark>
sure. i am fine with BSD-3-clause for this project
<azonenberg>
and that you acknowledge my contribution, but not in a way that says I approve of whatever monster you made of it :p
<whitequark>
just stating my general IP policy
<azonenberg>
exactly
<cr1901_modern>
So if it burns your house down or eats your spouse, you absolve yourself of blame
<azonenberg>
whitequark: I went with the "scorched earth" IP policy for my thesis
<azonenberg>
publish early, publish often
<whitequark>
heh
<azonenberg>
i had archive.org crawl my repo to establish it was public
<azonenberg>
Become prior art against myself
<azonenberg>
before anyone could think of patenting it :p
<whitequark>
yeah i really dislike when PhD has proprietary code
<whitequark>
not really science
<azonenberg>
you misunderstand
<azonenberg>
i didnt just want it to be public
<whitequark>
yeah, I do understand
<azonenberg>
i wanted to ensure my institution didn't make a cent from it
<whitequark>
that was a slightly different gripe
<azonenberg>
And if i sacrificed my own right to profit from it
<azonenberg>
that's a price i was willing to pay to ensure they made no income from my work
<cr1901_modern>
Surprised they went thru with that, tbh
<whitequark>
ok yeah that's a lot of resentment over IP :p
<azonenberg>
If i could patent it in my own name with them having no claim, i *miiiiight* have done it
<azonenberg>
But i cared more about them not making money off it
<azonenberg>
IOW, given the choice of me getting $1M and them getting $1M
<azonenberg>
or neither of us getting a dime
<azonenberg>
i'd pick the second just to keep that million from them :p
<azonenberg>
cr1901_modern: well, it was kind of a gray area
scrts has joined ##openfpga
<azonenberg>
the tl;dr is that no institution is going to prohibit a phd from publishing research
<azonenberg>
And once published, it becomes hard to impossible to file a patent
<azonenberg>
So if i publish before the ask me to patent it, they have no recourse :p
<azonenberg>
whitequark: RPI's administration recently got a $50M or so unrestricted donation
<azonenberg>
they could have used it for anything
<azonenberg>
fixing the dorms that had broken windows with cardboard taped over them
* whitequark
enumerates worst possible uses in their head
<azonenberg>
Fixing the materials science lab that kept a trash can in a certain part of the room
<azonenberg>
so that summer thunderstorm induced roof leaks wouldn't flood the rest of the lab
<azonenberg>
Adding better cooling to the server rooms so the cisco academy wouldn't lose routers and switches every few weeks
<azonenberg>
due to fan failues and overheating
<azonenberg>
but noooo
<azonenberg>
they built a new performing arts center
<azonenberg>
At an engineering school
<whitequark>
priorities!
<cr1901_modern>
Something something "All EEs are musicians" something
<azonenberg>
A couple years later, they got another massive pile of cash, i forget if it was one donation or several
<azonenberg>
So what did they do? Build a new football stadium
<cr1901_modern>
at an engineering school :P
<azonenberg>
Because the green in the middle of campus was TOTALLY not an adequate place for our team that was barely able to *qualify* for the national college league to practice
<azonenberg>
i could maaaaybe kinda sorta understand if it was like the hockey team that was ranked near the top of the country
<cr1901_modern>
My high school didn't have a football stadium for 2.5 years I went to it
<azonenberg>
(although i still resent being forced to pay an activity fee that subsidized my classmates' game playing)
<cr1901_modern>
All games were away
<azonenberg>
but our football team wasnt even that good
<azonenberg>
oh, then another year
<cr1901_modern>
(I was in marching band.)
<whitequark>
marching band? is it one of the weird american things
<azonenberg>
they decided to institute a new program where all engineering majors would be encouraged/required (i forget) to study abroad for a semester or two
kuldeep has joined ##openfpga
<whitequark>
azonenberg: that one sounds sane actually
<azonenberg>
whitequark: yeah except... to balance the budget, they laid off the entire foreign language department
<azonenberg>
So they're sending kids overseas, to places that dont speak english... and firing the people who were supposed to teach them tthe local language before they went
<cr1901_modern>
I guess it's a weird American thing?
<azonenberg>
at one point, the faculty senate dared to issue a vote of no confidence in the president's leadership
<azonenberg>
Her response was to restructure things and abolish the faculty senate
<cr1901_modern>
Like Chancellor Palpatine :D
<azonenberg>
oh and the vote didnt even pass
<azonenberg>
it was the mere act of voting that was enough
amclain_ has quit [Quit: Leaving]
<azonenberg>
a few years later, student government dared to do the same thing
<whitequark>
... let me guess
<azonenberg>
they did not abolish stugov, no
<azonenberg>
But there was a quiet announcement in the student paper the next spring
<azonenberg>
congratulating some person for being appointed interim head of stugov
<cr1901_modern>
hah
<azonenberg>
to replace X, who "is no longer a student of RPI"
<cr1901_modern>
he got expelled?
<azonenberg>
she
<cr1901_modern>
excuse me
<azonenberg>
from what i understand, she needed to get into a class that had hit the enrollment cap
<azonenberg>
99% of times, profs sign the form on the spot
<azonenberg>
and approve it
<azonenberg>
but this one mysteriously did not
<azonenberg>
until the day after the enrollment deadline
<azonenberg>
at that point, she didn't have enough credits to be considered full time
<azonenberg>
lost her scholarship
<azonenberg>
and... yep
<azonenberg>
there's no proof the administration leaned on the prof to drag his feet
<cr1901_modern>
that... can't POSSIBLY be legal, let alone moral
<whitequark>
this is rather reminiscent of how USSR treated undesirables
<azonenberg>
cr1901_modern: our president has a personality reminiscent of a 3rd world dictator
<cr1901_modern>
Hrm
<azonenberg>
whitequark: lol, yep
<azonenberg>
there was an article in the local city newspaper a while back
<azonenberg>
with some interesting quotes from higher-ups in the Party^h^h^h^hadministration
<azonenberg>
Apparently whenever there's like a formal banquet in the ballroom to entertain big donors or something
<azonenberg>
she has VPs of various departments wait on her table
<azonenberg>
Just to remind them who's boss
<whitequark>
holy shit
<whitequark>
you aren't joking about the 3rd world dictator
<cr1901_modern>
she==president?
<azonenberg>
Yes
<azonenberg>
whitequark: nope
<azonenberg>
She also has private bodyguards, separate from the school police department
* cr1901_modern
looks up who this is out of morbid curiosity
<azonenberg>
cr1901_modern: Shirley Ann Jackson
<azonenberg>
our Dear Leader
<azonenberg>
whitequark: one time i had to go into the admin building to retrieve paperwork for some award i had been nominated to
<cr1901_modern>
For the Greator Good?
<cr1901_modern>
er*
<azonenberg>
It's a ~4 story building with her office on the 4th floor
<azonenberg>
on the side of a hill
<azonenberg>
so 2 and 1 both have ground access
<azonenberg>
main entrance is 2, 1 is a fire exit only
<azonenberg>
There are two classrooms on 2
<azonenberg>
whitequark: make sense so far?
<whitequark>
yup
<azonenberg>
So, i walked straight in rather than turning left or right into the classroom
<azonenberg>
There's an elevator and stairwell, both locked
<azonenberg>
with a guard in front
<azonenberg>
I had to show ID and explain my business, he called the office to confirm they were expecting me
<azonenberg>
Then buzzed open the stairwell
<azonenberg>
There were card readers at the 3rd and 4th floor stairwell exits
<cr1901_modern>
This reminds me of Dijkstra's private elevator, according to lore
<whitequark>
holy shit, $1.6 million salary
<azonenberg>
2nd and 1st were ground floors so by fire code had to be unrestricted
<azonenberg>
i exited the stairwell on the 1st floor where the office was
<azonenberg>
All doors were locked with card readers
<azonenberg>
had to ring the bell, show ID again, explain my business, then they let me in
<azonenberg>
then go through the whole rigmarole again on the way out
<whitequark>
rpi campus has a *house* for the *president*?
<azonenberg>
Yes
<azonenberg>
more like a mansion
<azonenberg>
they tore down the old one a few years back
<azonenberg>
spent $$$$ on a new one
<whitequark>
>In June 2010, it was discovered that the newest plans for the house showed a new size of 19,500 square feet (1,810 m2), causing the city of Troy to issue a stop-work order until additional building fees were paid.
<whitequark>
what the fuck
<azonenberg>
whitequark: i interviewed for a job with a US defense contractor that did classified work on site
<azonenberg>
(although i only interviewed in unclassified areas of the facility)
<azonenberg>
They were less paranoid than she is about her office
<azonenberg>
Anyway, as a result of all of this
<azonenberg>
any time they call to ask me to donate money
<azonenberg>
I ask if she's still in charge
<azonenberg>
then say "call me back when she's gone"
<azonenberg>
i've seriously discussed with alumni making a trust fund of some sort where we can put a large sum of cash
<cr1901_modern>
I don't blame you
<azonenberg>
to be donated to the institution effective the day she leaves
<azonenberg>
then write an open letter to them, CC the city newspaper etc
<azonenberg>
saying "hey, we have $2M ready for you guys to grab as soon as you kick her out..."
<azonenberg>
Not that it'd be enough to sway their budget, but it'd send a strong message :p
<whitequark>
indeed
<azonenberg>
in the meantime, if i ever donate anything
<azonenberg>
it will be physical goods, directly to a club or research group
<azonenberg>
i was thinking of giving their embedded hardware club some greenpak kits to beta test our tools on
<azonenberg>
they may have cut the budget or renamed things
<azonenberg>
but there is at least one employee i can find (used to be 2-3) with job title "executive protection specialist" working for the department of "special services"
<azonenberg>
Which is not under the jurisdiction of the public safety dept
<azonenberg>
it sat around in my garage for ages but we finally got to it
<cyrozap>
azonenberg: Oh, man, that's awesome :D
* cyrozap
helped with something!
<azonenberg>
the 7a35t is a pull from a board made by wbraun in ##fpga
<azonenberg>
did a respin and had two old artixes that werent worth the time to reball
<azonenberg>
so gave them to me
<rqou>
offtopic: why is it so hard to make a new folder in nautilus?!
<azonenberg>
right click, new folder?
<rqou>
not if your folder is already full of folders
<azonenberg>
lol
<rqou>
afaik once you have more than a screen's worth of stuff you have to use the stupid hamburger menu
<rqou>
i'm just about ready to drop all GNOME software at this rate
<rqou>
does anybody know if GNOME recently changed some stuff in some common component that is responsible for talking to the X server?
<rqou>
because not only is gnome-terminal somehow copying to the wrong X display, it's somehow managing to open its about/preferences dialogs on the wrong display too
<rqou>
gnome-screensaver is also locking the wrong display
<azonenberg>
lol
<azonenberg>
it might be GTK?
<azonenberg>
no idea
<azonenberg>
i have a triple monitor setup but all on one x screen
<rqou>
it doesn't seem to be just GTK
<rqou>
file roller is managing to open gedit on the wrong display
<rqou>
but not gimp
<rqou>
wtf are they even doing? it seems it should be MORE work to get it wrong than to get it right