azonenberg_work has quit [Ping timeout: 244 seconds]
eddyb_ has joined ##openfpga
plaes_ has joined ##openfpga
kristian1aul has joined ##openfpga
fseidel_ has joined ##openfpga
jn___ has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
unixb0y_ has joined ##openfpga
pie__ has joined ##openfpga
Bike has joined ##openfpga
plaes has quit [Ping timeout: 240 seconds]
Bike has quit [Ping timeout: 240 seconds]
lexano has quit [Ping timeout: 240 seconds]
brizzo has quit [Ping timeout: 240 seconds]
Ekho has quit [Ping timeout: 240 seconds]
fseidel has quit [Ping timeout: 240 seconds]
eddyb has quit [Ping timeout: 260 seconds]
kristianpaul has quit [Ping timeout: 260 seconds]
fseidel_ has joined ##openfpga
eddyb_ has joined ##openfpga
unixb0y has quit [Ping timeout: 260 seconds]
stefanct__ has quit [Ping timeout: 260 seconds]
grummel has quit [Ping timeout: 260 seconds]
digshadow has quit [Ping timeout: 260 seconds]
pie_ has quit [Ping timeout: 260 seconds]
nurelin has quit [Ping timeout: 260 seconds]
jn__ has quit [Ping timeout: 260 seconds]
eddyb_ has quit [Changing host]
fseidel_ has quit [Changing host]
eddyb_ is now known as eddyb
digshadow has joined ##openfpga
stefanct has joined ##openfpga
nurelin has joined ##openfpga
unixb0y_ is now known as unixb0y
brizzo has joined ##openfpga
brizzo has quit [*.net *.split]
Bike has quit [*.net *.split]
grummel has joined ##openfpga
fseidel_ is now known as fseidel
stefanct has quit [Changing host]
stefanct has joined ##openfpga
Bike has joined ##openfpga
brizzo has joined ##openfpga
rohitksingh has joined ##openfpga
lexano has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
<esden>
reportingsjr: ? you pinged me a while ago ... :)
rohitksingh has joined ##openfpga
Ekho has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
<rqou>
esden: not the same person, but i did ping you about some T1/E1 test equipment
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined ##openfpga
rohitksingh has quit [Client Quit]
noobineer has quit [Ping timeout: 244 seconds]
<rqou>
azonenberg: btw, what type/thickness of pcb stencil do you use?
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 240 seconds]
<awygle>
Stainless
<rqou>
what thickness?
<awygle>
Whatever osh stencils has
<awygle>
They don't really have options do they?
<rqou>
they do
<rqou>
3/4/5/6/8 mil
<awygle>
Huh. Is that new?
<rqou>
idk
<awygle>
Well idk. 4mil maybe? Stainless for sure tho
pie__ has quit [Ping timeout: 244 seconds]
<azonenberg>
4 mil stainless
<azonenberg>
is my default
<azonenberg>
i dont use kapton anymore
rohitksingh_work has joined ##openfpga
<openfpga-github>
[Glasgow] whitequark commented on issue #51: Hrm, I might have been looking at the wrong package. 300 mV rise seems pretty low too, that's not enough to sync using e.g. external LMVCMOS 3.3 circuitry... Let's aim at 800 mV rise above ground then. https://github.com/whitequark/Glasgow/issues/51#issuecomment-403692386
<esden>
rqou: ohh yes! I saw the picture. I will eventually be interested. Things are currently on ice as sharebrained is now busy with other projects. So we will have to go back into the topic some time after DefCon...
<rqou>
ah ok
<esden>
But I am glad to know that you have the hardware.
<esden>
That might come in ultra handy eventually.
<rqou>
i guess my father didn't spend ages making T1 stuff for nothing :P
<esden>
:D
<rqou>
azonenberg: any downsides to making the border as small as possible on oshstencils?
<rqou>
azonenberg: also, is board outline just ignored?
<azonenberg>
rqou: no, i do that all the time
<azonenberg>
Board outline is used to size the stencil i thought
<azonenberg>
could be wrong
<rqou>
what is a framed vs frameless stencil?
<azonenberg>
Framed means there's a solid aluminum extrusion around it for mounting in a stencil-printing machine
<rqou>
ah ok, so i don't need that
<azonenberg>
unless you're sending this to a production fab, theres no reason to do that
<azonenberg>
it also means your min size is like 8x8 inches :p
<rqou>
i mean, i'm pretty close to that already
<rqou>
PMODs are big
<rqou>
also, it seems to totally ignore my board outline for sizing
<rqou>
maybe it's because i have the mounting holes as cutouts
<rqou>
so that's unnecessary
<rqou>
wtf why does this need a liability disclaimer?
<rqou>
of course stainless steel is sharp you idiots
ZombieChicken has quit [Ping timeout: 250 seconds]
<azonenberg>
lol
<azonenberg>
"your pcb might short out and set your house on fire"
<rqou>
ugh even stencils are expensive
<rqou>
also i just realized that it's been ages since i last bought solder paste (and didn't use any of it lol) so i should probably buy more
<rqou>
azonenberg: did you say you just use the kester paste that oshstencils stocks?
<daveshah>
The DSP units split across four tiles like the RAM is split across two
<mithro>
daveshah: That is what I was about to ask - are they 4 tiles high?
<daveshah>
mithro: yeah
<mithro>
daveshah: dsp0, dsp1, dsp2, dsp3 it seems?
<daveshah>
mithro: yes
<daveshah>
dsp0 having the lowest Y coordinate
<daveshah>
One signal, CO, is routed through the IPConnect tile above the dsp3 tile
<daveshah>
This is documented in the UltraPlus icestorm doc I linked above
<mithro>
Yeap
<daveshah>
Also beware some of the configuration bits have a different location in one of the DSPs only
<azonenberg_work>
rqou: welp
<openfpga-bot>
[jtaghal] azonenberg pushed 2 new commits to master: https://git.io/fNT0s
<openfpga-bot>
jtaghal/master d7a7461 Andrew Zonenberg: ARMDebugMemAccessPort: Fixed infinite recursion when a CoreSight ROM contains a pointer to itself
<openfpga-bot>
jtaghal/master a8f2731 Andrew Zonenberg: ARMDebugPort: Fixed handling of devices with no APB bus
<azonenberg_work>
working on bringing up stm32 support in jtaghal
<rqou>
um... _jtag_ hal?
<azonenberg_work>
rqou: yeah what about it?
<azonenberg_work>
stm32f4xx has full 4-wire jtag
<azonenberg_work>
not just swd
<azonenberg_work>
(i in fact do not support swd right now)
<daveshah>
Yeap, I've been caught out by not disabling it or something once and some pins weren't working
<rqou>
I've never seen/built a board capable of doing full JTAG on stm32s
<rqou>
since i don't care about boundary scan
<azonenberg_work>
well it can also do arm debug via jtag
<azonenberg_work>
slightly more efficiently than swd actually since full duplex
<rqou>
yeah, but that's not helpful if nobody actually uses that
<rqou>
anyways, azonenberg_work what problem are you running into?
<azonenberg_work>
the most recent one was, stm32f411's coresight ROM contains a pointer to itself
<azonenberg_work>
which threw my code into infinite recursion
<rqou>
coresight ROM?
bitd has quit [Remote host closed the connection]
<rqou>
(nsfw, offtopic) why are a bunch of people on birbsite all upset about ahegao t-shirts? is this just something that happened at AX or something?
<rqou>
i love how i seem to follow enough people on birbsite to see people alluding to all the drama, but i don't follow enough to ever know what the drama is actually about
* shapr
has wandered into the bad part of the internet
<cr1901_modern>
I mean anime is on topic. Even... that part... and Idk, I couldn't find the original tweet other than it was someone at a con
<rqou>
azonenberg_work we should make ##openfpga-afterdark :P
<cr1901_modern>
(Possibly not the same con where ppl were violating a blowup doll in public recently)
<rqou>
i mean, that's weeeird, but idk why people are freaking out about it
<azonenberg_work>
rqou: arm coresight specifies a descriptor ROM that you use to figure out what all of the fun debug stuff is
<azonenberg_work>
it can contain pointers to other roms
<azonenberg_work>
this one pointed to itself :p
<rqou>
ah
<rqou>
i didn't even know about that
<rqou>
i thought everything was normally at a fixed address
<azonenberg_work>
no
<azonenberg_work>
how would you handle multiple cpu systems?
<azonenberg_work>
there's a register in the MEM-AP that contains the address of the root rom table
<rqou>
huh
<azonenberg_work>
Which then contains descriptors for various coresight IP and pointers to other rom tables
<azonenberg_work>
for example, the cortex-a9's on the zynq both contain their own rom table
<azonenberg_work>
in addition to the root one
<rqou>
i never knew about this
mumptai has joined ##openfpga
<rqou>
it's not obviously from the normal "how 2 program the chip" manuals
<rqou>
azonenberg_work: you should try out the code protect race condition on other stm32s
<azonenberg_work>
This is the low level AMBA / ADI / CoreSight stuff,
<azonenberg_work>
Not all of the registers you poke to write flash etc
<azonenberg_work>
And that is kinda the endgame of this tool, being able to screw with jtag on various things
<azonenberg_work>
but to start i need to build a framework
<azonenberg_work>
its time jtaghal expanded beyond fpgas
<rqou>
not urjtag/openocd? :P
<azonenberg_work>
I wanted a permissively licensed tool, end of story
<balrog>
azonenberg_work: when software someone contributes to gets sold to someone else, then closed-sourced, that discourages said contributors to contribute to permissively licensed codebases
<balrog>
I've had that happen a few times
<balrog>
:/
<azonenberg_work>
balrog: my rule is, the official codebase is mine and will remain open
<balrog>
until you decide to sell it to LARGE_COMPANY
<azonenberg_work>
and someone making a proprietary-licensed fork in no way detracts from the usabilityo f mine
<balrog>
not you personally, but "you" as the owner/maintainer
<azonenberg_work>
basically, i like to compete on the basis of cost
<azonenberg_work>
And if somebody makes a commercially licensed close-source fork with new features
<azonenberg_work>
My users have every right to decide if they prefer those features or being free and open
<balrog>
people often get bored of maintaining something, and especially when it's something that's widely used or has gained traction they may want to cash out
<balrog>
and the new owners are often not trustworthy
<azonenberg_work>
that and, i *want* to encourage commercial reuse of my tooling
<azonenberg_work>
that means more people using it
<azonenberg_work>
pretty much all of my tools i build to solve a problem i, personally, have
<azonenberg_work>
somebody else using it, in almost any manner, does not harm my ability to solve that problem
<azonenberg_work>
So why would i want to attach more strings to my gift to the world?
<azonenberg_work>
thats the difference in ideology, my goal isnt to build a community
<azonenberg_work>
it's to get my job done
<azonenberg_work>
and i lose nothing by sharing the code i use to get there
<rqou>
but this is why your code is always painful to reuse
<balrog>
abusive behavior is what leads me more and more towards preferring copyleft :/
<balrog>
not ideology
<azonenberg_work>
rqou: no, it's painful to jam into a non-OO codebase because you dont like layered OO designs :p
<rqou>
layered OO designs lead to everything being all tangled up and hard to reuse :P
<balrog>
rqou: they can, they don't have to
<balrog>
what is causing you problems anyway?
<balrog>
azonenberg_work: at this point I'd probably take a hard look at MPL 2.0 if I wanted a relatively permissive but still copyleft license
<azonenberg_work>
balrog: he just doesnt like C++
<rqou>
azonenberg really really likes abusing inheritance to allow for widespread "hook points"
<azonenberg_work>
its not abusing, and they're not hook points
<balrog>
rqou: source code example?
<azonenberg_work>
most of the time the base class has no code at all in that function
<rqou>
instead of just defining a real api boundary
<azonenberg_work>
polymorphism is a by-design feature of c++ :p
<rqou>
polymorphism is fine
<azonenberg_work>
balrog: he doesnt like virtual functions basically
<balrog>
rqou: link me?
ZombieChicken has joined ##openfpga
<rqou>
balrog: look at how xbpar/gp4par interact
<rqou>
azonenberg: it's not about virtual functions
<balrog>
rqou: more specifically?
<azonenberg_work>
yes, xbpar is the core library for technology-independent CPLD graph isomorphism P&R
<balrog>
like, where in gp4par
<azonenberg_work>
and gp4par implements all of the greenpak stuff
<azonenberg_work>
The function for creating devices can probably be rfactored a bit but that has nothing to do with my use of OO design
<azonenberg_work>
it was on my to-fix list anyway
<balrog>
rqou: the pattern of inheriting from the more generic base class?
<balrog>
or something more specific than that
* awygle
is with balrog w.r.t. copyleft
<awygle>
but you all knew that
<balrog>
awygle: it irks me because I wish that wouldn't be necessary
<rqou>
basically that, but more specifically: everything being protected with no clear boundary what should be changed, every single function being virtual and open to being overridden
<shapr>
copyleft meaning GPL vs BSD?
<balrog>
then there are groups like grsecurity which abuse GPL licensed code with contract reqstrictions, and I don't know how one should deal with that
<awygle>
yeah i sympathize with people who use permissive licenses because they reject the entire notion of copyright/IP law as assigned to software, i just don't think we're there
<azonenberg_work>
rqou: it's protected because the base class *is expected* to extend it
<azonenberg_work>
there is almost no case where i want to protect something from a derived class and would use "private"
<azonenberg_work>
i consider the derived class within the API boundary
<rqou>
yeah, and this style leads to code that is all tangled up
<azonenberg_work>
and the functions are virtual not because they *can* be overridden
<azonenberg_work>
but because they *must* be overridden
<azonenberg_work>
if you look, most are pure-virtual
<rqou>
but even functions that don't have to be overridden are virtual
<azonenberg_work>
like what?
<awygle>
and i also sympathize with people who (correctly) think they don't have the resources to actually fight a gpl violation, i just think it's closing off options too soon
<azonenberg_work>
the base and derived classes are tightly coupled, yes
<rqou>
yeah, but this makes extending it really painful
<balrog>
awygle: it's difficult to fight if you don't have a sufficient copyright stake in the code in question
<azonenberg_work>
it's not painful at all, the base class basically explains exactly what has to be overridden
<rqou>
not PAREngine
<azonenberg_work>
That's me being too busy to document it properly
<azonenberg_work>
not an architecture issue
<rqou>
almost everything is virtual (not pure virtual) and it's not at all clear how extending it is supposed to work
<azonenberg_work>
That, to me, seems mostly like an issue of inadequate documentation
<azonenberg_work>
this is what i consider a more mature codebase
<azonenberg_work>
in this case, i make the mid-level (for example EnterShift1IR()) functions virtual so that network-transparent applications can override them at a higher level of abstraction and do the TMS operations server-side
<azonenberg_work>
But 98% of the time, the base class implementation is adequate
<rqou>
that's a bit better
<rqou>
last time i looked at it specific issues i had were *) how does "deferred mode" work isn't really explained
<azonenberg_work>
gp4par was written in a rush with limited time to get it right, and i havent spent a ton of time on the codebase
<rqou>
*) and ShiftTMS not being public
<azonenberg_work>
jtaghal is a ten-year-old mature codebase
<azonenberg_work>
#1: basically, it lets you batch transactions that you don't need readback data from
<rqou>
but that's not an OO problem but a "design philosophy" problem
<azonenberg_work>
then push them out to the adapter later, to avoid lots of tiny usb transfers
<azonenberg_work>
when you call Commit(), or do an operation requesting a readback which commits automatically
<azonenberg_work>
or when the buffer hits some size
<azonenberg_work>
as far as ShiftTMS not being public, that was an intentional decision to ensure that the library always knew what state the TAP was in and could perform various optimizations
<rqou>
there was also the "no way to get SVF as a backend" issue
<rqou>
but in general the code style is better here
<rqou>
or at least i dislike it a lot less :P
<azonenberg_work>
The "no way to get SVF as a backend" is because i do error checking
<azonenberg_work>
and print detailed messages
<azonenberg_work>
SVF is inherently a fire-and-forget backend that doesnt let you print any errors other than "didnt get expected data back"
<azonenberg_work>
jtaghal is intended for online, though potentially remote, use
<azonenberg_work>
*playing* svf is plausible to implement
<azonenberg_work>
*generating* less so
<rqou>
balrog: so yeah, another thing is that azonenberg and i seem to have completely different philosophies of how to design and structure APIs
<balrog>
which is?
<rqou>
afaict azonenberg prefers "be very careful and check explicitly that you did the correct thing"
<rqou>
"don't let wrong things happen"
<rqou>
whereas i prefer "let the user do whatever they want; try to only catch things that are definitely impossible"
<rqou>
also, i seem to prefer fancy data structures over fancy code structures
<rqou>
which seems to be the opposite of azonenberg
<openfpga-bot>
[jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fNTVA
<openfpga-bot>
jtaghal/master 5601a0d Andrew Zonenberg: Initial class hierarchy for STM32 device support
<azonenberg_work>
rqou: well i prefer encapsulated data structures that ensure their own validity
<azonenberg_work>
the API is the user-facing boundary, not the data structure itself
<rqou>
i prefer the opposite
<rqou>
with the data structure being the interface
<openfpga-bot>
[jtaghal-cmake] azonenberg pushed 1 new commit to master: https://git.io/fNTw3
<openfpga-bot>
jtaghal-cmake/master baefc69 Andrew Zonenberg: Updated to latest jtaghal
<rqou>
if i need invariants, i prefer encoding them in the type system
<azonenberg_work>
Good luck encoding "this list must always contain four elements more than that one" in the type system
<azonenberg_work>
or something like that
<awygle>
that sounds like a bad invariant lol
<rqou>
some type systems can do that, but yes i currently don't check things like that
<rqou>
and i agree with awygle :P
<awygle>
what's the rust term for that? integer generics or something? i know they don't have it and a lot of people want it :p
<rqou>
I've just been calling it type-level integers
<rqou>
and yeah, i definitely want to see it
<rqou>
you can currently pretend with church numerals :P
<awygle>
dat feel when you have a dll, and you have some source, but the dll was not built from the source
<rqou>
lolol
<rqou>
windoze
<awygle>
"this can't possibly be happening, it's in a critical section!" dll: *doesn't have a mutex*
<qu1j0t3>
azonenberg_work: that can be encoded as a list and four values, if you are that keen.
<rqou>
wait, is this for your $WORK? why are they using windows?
<awygle>
everybody uses windows rqou
<rqou>
do people run windows on production lines?
<rqou>
do they... pay for the licenses?
<awygle>
lol
<rqou>
i take that as a no? :P
<azonenberg_work>
awygle: that was just an example
<awygle>
yes they pay for licenses
<awygle>
azonenberg_work: i know. i don't agree with either of you and find the debate exhausting. i just pop up to mock :p
<rqou>
awygle how would you design interfaces?
<awygle>
depends on the thing. i'd probably end up similar to azonenberg_work for jtaghal, except with explicit APIs using composition between layers instead of inheritance. for xc2par, something like a pipeline, transforming an object from one state to another, with each state having invariants that are enforced.
<awygle>
jtaghal much more api-oriented, xc2par much more data-oriented
<rqou>
um... that's exactly how i built it?
<awygle>
yes, but i don't think that's always the solution. just like i don't think "hella virtual functions" is always the solution.
<rqou>
i more-or-less agree with you on this
<rqou>
i don't know why "C++/traditional-OO people" like inheritance so much
<awygle>
inheritance is great, sometimes
* cpresser
prefers interfaces over inheritance if possible
<awygle>
interfaces are also great sometimes
<awygle>
although i'm personally annoyed anytime i run into an interface with exactly one implementation
<azonenberg_work>
i consider interfaces to be a restricted subset of inheritance
<awygle>
yeah same
<azonenberg_work>
from my perspective an interface is simply a class with only virtual functions
<azonenberg_work>
So i like that C++ allows you to do this, while not forcing you to
<azonenberg_work>
i.e. if i want a class where 95% of the functions are pure virtual but one has an implementation, i can do that
<awygle>
i would expand that to "only virtual functions and no state", which is _technically_ covered by "only virtual functions" but may not be inferred properly
<azonenberg_work>
well yeah
<azonenberg_work>
only pure virtual functions
<azonenberg_work>
and nothing else
<awygle>
the biggest thing i hate about object-oriented code is how much implicit state sits around in most objects. if your object has more than, like, maybe 4 fields, i feel like you're doing it wrong
<awygle>
small objects are great but too many objects end up as miniature spaghetti-coded programs to themselves
<awygle>
this is especially bad in languages like C# or Java that don't allow free methods, so you can't even implement the functions that _are_ pure functions _as_ pure functions
<awygle>
... thank you for coming to my ted talk.
<azonenberg_work>
yes
<azonenberg_work>
henec why you have the "math" class
<azonenberg_work>
because sqrt is totally a method on an object
<awygle>
or Utils.TimeoutHelper, as the case ~may be~ is
<shapr>
I agree, I don't much like OOP
<shapr>
I prefer explicitly passed in state
<awygle>
the best part is that oop reinvented passing in state as "dependency injection" :p
<awygle>
"gee, i'm glad we got away from global variables. these giant objects sure are hard to test though! they end up with a ton of dependencies on these globally-accessible things!"
<shapr>
yeahhh
<azonenberg_work>
lol
<awygle>
whine whine complain, you can be an idiot in most languages.
* awygle
gets back to work
<shapr>
awygle: try Haskell, explicit state is what you get
Bike has quit [Ping timeout: 252 seconds]
<awygle>
shapr: and a paycheck isn't :p
<shapr>
depends, if you want to work on blockchain, Haskell pays extremely well
<shapr>
at least twice what a senior dev makes in a Atlanta
<awygle>
huh, interesting
<awygle>
i have no desire to work on blockchain but i do have a desire to get paid twice what a senior dev makes in Seattle
<shapr>
IOHK and Digital Asset pay *extremely* well
<shapr>
so does JP Morgan
<shapr>
They're all doing blockchain / distributed ledger projects in Haskell
<shapr>
I've heard that BlueSpec does work for Xilinx and Intel, and the BlueSpec product is a hacked up version of the primary Haskell compiler.
<shapr>
ok, I'll stop shouting into the void now :-P
<awygle>
:p
<shapr>
team lead told me I could write things in Haskell if the rest of my team was okay with it... they weren't
* shapr
sighs
<awygle>
i can't remember the last time i had a "how big is a 32-bit int" bug but i've had like five in the last two weeks
<awygle>
poor shapr :( i've considered trying to smuggle some rust into our projects but i think i don't yet have the social capital for that
<sorear>
i met a guy in Boston who claimed to do Haskell and then clarified that he meant blockchain
<qu1j0t3>
!!
digshadow has joined ##openfpga
<sorear>
well, Haskell-for-blockchain-applications, he wasn't making a category error
<azonenberg_work>
rqou: welp
<azonenberg_work>
Turns out the rom table is *not* a pointer to self
<azonenberg_work>
the MEM-AP was incorrectly configured and i was getting truncated results
<azonenberg_work>
i'll leave the sanity check in there but it shouldn't have triggered
Bike has joined ##openfpga
mumptai has quit [Remote host closed the connection]
<awygle>
dangit past me. i have a note in my todo list that says "test $case, it's probably wrong". turns out it is wrong, but i didn't write down why i thought it might be wrong.
DingoSaar has quit [Remote host closed the connection]
DingoSaar has joined ##openfpga
<openfpga-bot>
[jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fNTMl
<openfpga-bot>
jtaghal/master c617ea2 Andrew Zonenberg: Fixed handling of MEM-APs that default to non-word access size
<openfpga-bot>
[jtaghal] azonenberg pushed 2 new commits to master: https://git.io/fNTS4
<openfpga-bot>
jtaghal/master 269a0d6 Andrew Zonenberg: Refactoring: moved serial number routines to SerialNumberedDevice class since not just FPGAs can have per-die serial numbers
<openfpga-bot>
jtaghal/master 9f66272 Andrew Zonenberg: Initial STM32 serial number support
<openfpga-bot>
[jtaghal] azonenberg pushed 1 new commit to master: https://git.io/fNT9X
<openfpga-bot>
jtaghal/master a80961a Andrew Zonenberg: STM32Device now has proper SerialNumberedDevice support