<azonenberg_work> yeah i thought so too
azonenberg has quit [Ping timeout: 245 seconds]
m_w has quit [Quit: leaving]
talsit has joined ##openfpga
azonenberg_work has quit [Ping timeout: 244 seconds]
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
azonenberg_work has joined ##openfpga
<azonenberg_work> So, next on the quick-and-easy TODO is to fix the pin 2 reset
<azonenberg_work> the docs are unclear as to how it funcitons
<azonenberg_work> so i just have to fix that
<azonenberg_work> whitequark: how would you suggest configuring core power stuff
<azonenberg_work> like "bypass internal LDO"?
<azonenberg_work> gp4par argument?
<rqou> a hot comment in the verilog? :P
<rqou> hdl synthesis tools seem to love hot comments
<whitequark> fuck hot comments
<whitequark> they'll be in gp4par over my dead body
<whitequark> *cough*
<rqou> doesn't it already by default support synopsys translate_[on|off]?
<whitequark> azonenberg_work: I feel like we should move away from gp4par options towards attributes on the module
<whitequark> rqou: well, yosys does
<azonenberg_work> whitequark: Hmm, ok
<azonenberg_work> What about userid then?
<azonenberg_work> or code protect?
<whitequark> let me think
<whitequark> azonenberg_work: how about having attributes either in verilog file, or alternatively in a constraint file?
<whitequark> this way we get both "per design" attributes
<whitequark> as well as "per deployment" attributes
<whitequark> azonenberg_work: basically what I'd like to avoid is a) having vital information about design stuck in some build.sh file
<whitequark> b) having two separate supplementary configuration parsers
<whitequark> so we'd treat attributes as the sole source of truth, and also allow overriding them from command line and/or constraint files, as a convenience
<azonenberg_work> Makes sense
<azonenberg_work> wqell
<azonenberg_work> constraints have one advantage
<azonenberg_work> more granularity
<rqou> but I like having vital information spread between .sh files, perl files, tcl files, and custom config files :P :P
<azonenberg_work> a constraint file*
<azonenberg_work> attributes in verilog cannot apply, afaik, to one net in a bus
<azonenberg_work> So for example to LOC a multi-bit signal
<whitequark> that is true
<whitequark> but I feel that the ergonomics offered by having the .v file be the single source for design is worth it
<azonenberg_work> You misunderstand
<whitequark> it=having a custom-ish syntax for specifying that for buses
<azonenberg_work> Oh
<azonenberg_work> So maybe
<whitequark> something like (* LOC[0]="P0" *)
<whitequark> or w/e the grammar allows
<azonenberg_work> (* LOC = "{P8, P7, P6}" *)
<azonenberg_work> is what i'd prefer
<whitequark> drop the {} ?
<azonenberg_work> well, i figure it looks more like a verilog bus that way
<azonenberg_work> but i guess
<whitequark> seems pointless, just complicates parsing
<whitequark> why have error messages if you can have simpler grammar? :p
<whitequark> we won't support nesting there anyway
<azonenberg_work> True
<azonenberg_work> ok so yeah, comma separated list
<azonenberg_work> with a single net being the degenerate case
<whitequark> yup
<azonenberg_work> about to watch a movie w/ $WIFE, will code that up right after
<azonenberg_work> do a simple test of like a 2-bit NAND or something
<whitequark> and require, for buses, to have exactly as many elements as the bus
<azonenberg_work> Yep
<whitequark> to avoid ambiguity
<azonenberg_work> Sounds good
<azonenberg_work> i'll also double check how we handle non-LOC'd signals
<azonenberg_work> i think that should be a DRC error
<azonenberg_work> if it isnt already
<azonenberg_work> i forget if i implemented that yet
<whitequark> they're routed wherever
<whitequark> I'd make that a warning
<whitequark> maybe I *want* the router to minimize the cost and then lay out the PCB
<whitequark> and for some signals there's only one way to place them anyway
azonenberg has joined ##openfpga
azonenberg_work has quit [Ping timeout: 260 seconds]
<cyrozap> pointfree: I've uploaded a new OpenOCD KitProg patch to handle SWD failures: https://github.com/cyrozap/OpenOCD/commit/8bf756d270432c7fda2e55ddb40d6ec0969c3c10
<cyrozap> You'll need that for the driver to be able to handle invalid memory accesses, etc. without forcing you to restart OpenOCD when that happens
carl0s has joined ##openfpga
<cr1901_modern> "lay out the PCB"?
<whitequark> er
<whitequark> I take whatever pin assignment the router did and then lay out my PCB to respect that
<cr1901_modern> Oh, makes sense. In fact that's what Xilinx recommends for their CPLDs
<whitequark> this mostly matters for gp4 because of the cross-switch
<whitequark> well, the crossbar between matrices, that is
<cr1901_modern> Yea, there's only 10 connections each way IIRC?
<whitequark> yes
<azonenberg> So, you want to allow unconstrained IOs?
<azonenberg> I guess there's an argument to be made for that
<azonenberg> although i agree more with the xilinx philosophy there, iirc for 7 series devices they warn/error if you have unconstrained IOs
<rqou> iirc it doesn't warn on the older devices and/or the cplds
<azonenberg> Correct
<azonenberg> only vivado warns
<azonenberg> ise does not
<rqou> vivado also replaced ucf files iirc
<azonenberg> yeah they use synopsys constraints
<azonenberg> its making a big headache for me as a user of both s6 and newer
<azonenberg> and having to support two tool suites
azonenberg_work has joined ##openfpga
<azonenberg> I think the best option is to detect it, and do a DRC warning
<azonenberg> but allow it
<azonenberg> that way you can find an optimal placement, do the PCB, then LOC the pinout and if you have to respin the design you have a locked pinout
<azonenberg> and any unconstrained IOs will warn
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
azonenberg_work has quit [Ping timeout: 250 seconds]
<whitequark> agreed
Bike has quit [Quit: leaving]
Bike has joined ##openfpga
<openfpga-github> [yosys] azonenberg pushed 3 new commits to master: https://git.io/vPPql
<openfpga-github> yosys/master 189fbd4 Clifford Wolf: cleanup in write_smt2 log messages (-bv and -mem are now default)
<openfpga-github> yosys/master 74702b0 Clifford Wolf: Build fixes for VS 2015
<openfpga-github> yosys/master 3a09d6b Clifford Wolf: Improvements and bugfixes in clk2fflogic
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vPPqd
<openfpga-github> openfpga/master 01213bf Andrew Zonenberg: gp4par: Now show DRC warning if a top-level port is not constrained
<azonenberg> whitequark: so at some point soonish
<azonenberg> i want to refactor the gp4prog code a bit
<azonenberg> move all of the board I/O logic into a shared library
<azonenberg> Such that I can write unit tests that do things like driving test vectors
<azonenberg> Where do we stand on reading signals from the board?
<azonenberg> last i recall you confirmed there are two ADC channels, but don't seem to be getting readings from them?
<azonenberg> Do we have digital GPIO yet?
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 92186a2 to b8a86be: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages b8a86be Travis CI User: Update documentation
<azonenberg> One-way unit tests (that just light up a pass/fail LED or something) would be a start but i would really prefer to eventually have fully automated CTest based tests
<azonenberg> We just have to figure out how to set a Travis node up somewhere that has an actual devkit plugged in
<travis-ci> azonenberg/openfpga#103 (master - 01213bf : Andrew Zonenberg): The build passed.
<whitequark> azonenberg: "Travis node" ?
<whitequark> their frontend is either closed-source or open-source but so obnoxious to install that it might as well be
<whitequark> buildbot is ok
<azonenberg> Let me rephrase
<azonenberg> How would I go about adding a CTest test that works on actual hardware?
<azonenberg> and logs to the travis dashboard
<azonenberg> is that not practical?
<whitequark> it's impossible
<whitequark> well, in a sane way
<whitequark> you *can* ssh out from travis but ugh
<azonenberg> Grr
mifune has joined ##openfpga
<whitequark> I suggest replacing Travis with Buildbot installed somewhere
<azonenberg> And this is why I insist that embedded/hardware is ~20 years behind desktop software dev in terms of maturity
<azonenberg> So replace travis 100%?
<whitequark> another advantage is that Buildbot actually is possible to configure decently
<azonenberg> is there a way to host a dashboard and integrate with IRC somehow?
<whitequark> yes
<whitequark> we do this for m-labs http://buildbot.m-labs.hk/waterfall?reload=5
<whitequark> we also have HIL tests
<azonenberg> Might want to look into doing that
<azonenberg> b/c HiL is going to be key down the road
<whitequark> I have all the configs arleady
<azonenberg> Excellent
<whitequark> it's a simple matter of extracting them from m-labs repos
<whitequark> and adding uh
<whitequark> there's a configuration management tool, ansible
<azonenberg> So, once we get to that point
<whitequark> if I write the config using it, you'll be able to roll out the entire thing (required packages, buildbot, etc) wherever
<azonenberg> if i were to set up a vmware instance in my DMZ
<whitequark> even if I say do this for my RPI
<whitequark> and it dies
<azonenberg> that is plugged into my dev board via usb forward
<whitequark> then you can simply point ansible at any debian vm and it'll set that up from scratch
<azonenberg> could i give you a login and have you set it up?
<azonenberg> oh even better
<azonenberg> We'd have to figure out some way of autodetecting what greenpak is present in that board
<whitequark> sure. it would be one command. `ansible-playbook silego-hil-test.yml`
<azonenberg> down the road i want, somewhere across the internet
<whitequark> oh
<whitequark> that already works I think
<azonenberg> you misunderstand
<azonenberg> for job scheduling
<whitequark> mhm
<azonenberg> we have to know which board/instance to push the job to
<azonenberg> Not just fail when we try to run on the wrong board
<azonenberg> Not a difficult problem, but has to be done
<whitequark> how many do you have
<azonenberg> Right now only one
<azonenberg> But i want one with each supported device down the road
<whitequark> would it be cheaper to spin a crossbar board with a few connectors
<whitequark> and more analog switches
<azonenberg> Depends on how many we can get silego to give us :p
<whitequark> capacitance seems to be a problem
<whitequark> ah
<whitequark> right
<azonenberg> If we can show a fully working toolchain for the 46620
<azonenberg> i think i'd have no problem bumming a few devkits and samples for say the 46140 and 46621
<azonenberg> Things are moving nicely now that i'm settling back into development
<azonenberg> Anyway, where do we stand on getting data off the board?
<azonenberg> that seems to be the big block for HiL
<azonenberg> unless you solved it without telling me :p
<whitequark> I actually don't remember the status
<whitequark> let me finish whatever I'm doing and I'll look into it
<whitequark> hm
<whitequark> who owns https://github.com/openfpga ?
<azonenberg> Not a clue
<whitequark> doubt it
<whitequark> they won't host debit
<azonenberg> ah good point
<azonenberg> no idea
<whitequark> azonenberg: ah I did in fact solve it
<whitequark> we have ADC capability for any pin
<azonenberg> :D
<openfpga-github> yosys/master d6feb4b Andrew Zonenberg: greenpak4: Changed parameters for GP_SYSRESET
<openfpga-github> [yosys] azonenberg pushed 1 new commit to master: https://git.io/vPPYC
<azonenberg> excellent
<azonenberg> so thats separate from the A/B "board voltage"?
<whitequark> WRITE 33 / WRITE 47 / READ 47
<whitequark> yes
<azonenberg> In that case, if/when you've got time
<azonenberg> can you refactor all of the board protocol stuff out from gp4prog into a separate library?
<azonenberg> s.t. we can link it to HiL tests in the future?
<whitequark> ack
<whitequark> ping me tomorrow on that
<azonenberg> i'll continue working on support for hard IP blocks
<azonenberg> i'm running down the bitstream description from 2047 down
<azonenberg> adding support one bit at a time if not already present
<azonenberg> i just want to get this done
<azonenberg> first things first, fixing the reset behavior (my GP_SYSRESET block doesn't quite do what it was supposed to)
<azonenberg> Then refactoring some of the error handling code so that it returns false and doesn't exit(-1) the whole app
<azonenberg> (this makes librarizing PAR essentially impossible as your first erroneous code compiled kills the whole IDE/host app_)
tecepe has quit [Ping timeout: 250 seconds]
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vPPOs
<openfpga-github> openfpga/master 2b3ea05 Andrew Zonenberg: greenpak4: Fixed Greenpak4SystemReset to accurately reflect behavior described in latest (r085) datasheet.
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from b8a86be to d1c6a65: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages d1c6a65 Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#104 (master - 2b3ea05 : Andrew Zonenberg): The build passed.
mifune has quit [Quit: Leaving]
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vPP3m
<openfpga-github> openfpga/master 2e8b739 Andrew Zonenberg: Refactoring: greenpak4: CommitChanges() now returns false instead of aborting on bad parameters
<rqou> opinions on jenkins vs buildbot btw?
<rqou> I have jenkins installed in a (nested) VM
<rqou> but I never had hardware in the loop set up
<rqou> i know that jenkins understands how to use build slaves with different configs
<azonenberg> i have not used either directly
<azonenberg> only whitequark's jenkins setup
<whitequark> jenkins?
<whitequark> I never used jenkins
<azonenberg> sorry i meant travis
<azonenberg> guess i'm getting sleepy
<whitequark> rqou: i stay free of jenkins simply because of its massive footprint
<rqou> in terms of memory or?
<whitequark> which isn't inherently a bad thing, i just don't like overpaying for VPSes
<whitequark> memory
<whitequark> buildbot is alright. buildbot is *vastly* better than travis
<whitequark> most things are
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from d1c6a65 to 93cc325: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 93cc325 Travis CI User: Update documentation
<azonenberg> Well, if we are going to run buildbot or similar
<rqou> i'm running jenkins on a linode 4gb and there's still plenty of memory left
<azonenberg> i can spin up a VM on my desktop with a board always attached
<azonenberg> i trust you guys enough to not drop a vmware 0day into the repo and pwn my native OS :p
<rqou> how about an intel x86 alignment trap DoS? :P
<rqou> thanks google :P
<travis-ci> azonenberg/openfpga#105 (master - 2e8b739 : Andrew Zonenberg): The build passed.
<azonenberg> well you also dont have commit access to the main repo
<azonenberg> :p
<whitequark> lol
<azonenberg> aaanyway dont make me go buy a beaglebone or something just to host my greenpak board...
<rqou> anyways, fun story about my linode 4gb
<rqou> it used to be a linode 512mb several years ago
<rqou> then moore's law kept happening
<azonenberg> and they just kept upgrading you? lol
<azonenberg> yeah i have a vps like that
<azonenberg> i actually need to shut it down, not using it anymore
<whitequark> i have, too
<whitequark> but linode kept getting owned
<azonenberg> not with linode though
<whitequark> and being not transparent about it
<azonenberg> smaller host
<whitequark> so i migrated almost eeverthing off it
<whitequark> except https://rxr.whitequark.org
<azonenberg> So, that refactoring fixes one of the two main sources of exit(2) calls in the codebase
<azonenberg> the other is json netlist parsing
<azonenberg> i'll try and fix that tomorrow after work, need to get some sleep now
<rqou> be glad you're not a particular emulator project using amd gpu drivers :P
<rqou> random exit(123) everywhere
carl0s has quit [Quit: Leaving]
<azonenberg> lol
<azonenberg> That was a hack job from day one
<azonenberg> i just never got aroudn to fixing it
<azonenberg> until now
Bike has quit [Quit: leaving]
maaku has quit [Quit: No Ping reply in 180 seconds.]
maaku has joined ##openfpga
<felix_> azonenberg: vivado and synopsys both use tcl for constraints, but the constraint files aren't compatible, since they use different commands for stuff
eightdot has quit [Ping timeout: 258 seconds]
eightdot has joined ##openfpga
<openfpga-github> [openfpga] whitequark pushed 1 new commit to master: https://git.io/vPPHM
<openfpga-github> openfpga/master 8ede4a7 William D. Jones: Allow Windows builds using MSYS2 Environment (#41)
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 93cc325 to 07d2286: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 07d2286 Travis CI User: Update documentation
doomlord has joined ##openfpga
m_w has joined ##openfpga
digshadow has quit [Ping timeout: 250 seconds]
tecepe has joined ##openfpga
<azonenberg> felix_: lol oh joy
<azonenberg> felix_: i'm writing a constraint generator in Splash that hides some of the toolchain differences
<azonenberg> and will produce UCF or XDC as necessary depending on the selected compiler
<azonenberg> but that is a ways out
<azonenberg> my current/legacy version only does UCF
<azonenberg> this is most important for 7 series xilinx parts
<azonenberg> where both ise and vivado are legal targets
amclain has joined ##openfpga
digshadow has joined ##openfpga
Bike has joined ##openfpga
rvense has joined ##openfpga
azonenberg_work has joined ##openfpga
mifune has joined ##openfpga
amclain has quit [Quit: Leaving]
zpataki has joined ##openfpga
mifune has quit [Ping timeout: 256 seconds]
mifune has joined ##openfpga
m_w has quit [Quit: leaving]
m_w has joined ##openfpga
m_w has left ##openfpga [##openfpga]
m_w has joined ##openfpga
zpataki has quit [Read error: Connection reset by peer]
Zoltan_ has joined ##openfpga
Zoltan_ has quit [Read error: Connection reset by peer]
Zoltan_ has joined ##openfpga
Zoltan_ has quit [Read error: Connection reset by peer]
Zoltan_ has joined ##openfpga
Zoltan_ has quit [Remote host closed the connection]
Zoltan_ has joined ##openfpga
Zoltan_ has quit [Remote host closed the connection]
<azonenberg> whitequark: poke to do the gp4prog refactoring we talked about last night
zpataki has joined ##openfpga
amclain has joined ##openfpga
zpataki has quit [Read error: Connection reset by peer]
zpataki has joined ##openfpga
zpataki has quit [Read error: Connection reset by peer]
zpataki has joined ##openfpga
zpataki has quit [Read error: Connection reset by peer]
m_w has quit [Quit: leaving]
m_w has joined ##openfpga
m_w has quit [Quit: Leaving]
mifune has quit [Ping timeout: 250 seconds]
tecepe has quit [Remote host closed the connection]
ylm has joined ##openfpga
<rqou> random question for the chip RE people: does anybody know which group is behind the Capcom arcade (Kabuki/CPS1/CPS2) reverse engineering (http://arcadehacker.blogspot.com/)? Or is this guy independent?
<azonenberg> That would be ArcadeHacker on this network
<azonenberg> i'm sure he collaborated with the siliconpr0n folks
<azonenberg> but you can ask him for details :p
mifune has joined ##openfpga
mifune has quit [Changing host]
mifune has joined ##openfpga
<rqou> so it's all the same several people again :P
<azonenberg> Lol
<rqou> i guess not too many people have chip RE labs :P
<azonenberg> Yeah its a tight knit community
<azonenberg> the siliconpr0n IRC is 36 people including ChanServ and a couple of duplicate nicks
<azonenberg> right now
<azonenberg> and... wow bushing is still idling there
<rqou> um...
<azonenberg> He died months ago and is still haunting the channel
<rqou> yeah I knew that
<azonenberg> guess he left the vps on autopay or something
<azonenberg> kinda fitting for a hacker's legacy to include a floating IRC instance in a silicon RE channel
<cr1901_modern> I'm surprised how many people I know from the MAME project and emulation forums. It really *IS* a small world
<rqou> I don't follow MAME/emulation nearly as closely
<rqou> I only know that large parts of it are drama-filled :P
<rqou> especially MAME
<cr1901_modern> No comment :)
<rqou> *cough* *cough* Chris Tarnovsky
<azonenberg> lol
<azonenberg> MAME isnt the only ones who have had drama involving him
<azonenberg> $DAYJOB bought his company, flylogic, a few years back
<azonenberg> The breakup was not pretty
<cr1901_modern> Okay, but outing him when he clearly didn't want his identity known wasn't cool
<cr1901_modern> It turned a bad situation into a "now you're never getting these chips back"
<azonenberg> yeah
<cr1901_modern> That said, he doesn't strike me as someone easy to get along with.
<cr1901_modern> digshadow is MUCH more charitable in this respect. Though perhaps that's b/c he actively avoids the drama :P
mifune has quit [Ping timeout: 260 seconds]
<azonenberg> Lol yes
<azonenberg> That does help
<rqou> is siliconpr0n also behind the quietust nes chip images (https://www.qmtpro.com/~nes/chipimages/)?
<azonenberg> Dont remember hearind about that
<azonenberg> hearing*
<azonenberg> oh wait
<azonenberg> is this the visual6502 guy?
<rqou> it seems to me somewhat?? associated with the visual 6502 group
<azonenberg> yeah no idea but i dont tink we work with them directly
<azonenberg> or... no wait a minute
<azonenberg> he's talking about some folks we know
<azonenberg> i dont think he hangs out in our chan
<azonenberg> but probably collaborates with us
<digshadow> azonenberg: bushing disconnected
<digshadow> and reconnected
<digshadow> he must have something setup to do that
<digshadow> cr1901_modern: sort of yeah
<digshadow> I've taken the dr decap incident as a warning
<digshadow> try not to overcommit
<azonenberg> digshadow: i think its probably a network glitch or something
<azonenberg> causing the vps to drop off and come back
<digshadow> maybe
<azonenberg> either way, will be a sad day when it finally disconnects for good
<digshadow> cr1901_modern: and try to be very transparaent
<digshadow> and maintain communication
<digshadow> but filter who it goes through
<rqou> another random curiosity question: are you guys associated at all with the Mifare Crypto-1 RE people?
<digshadow> you mean the mit students or w/e from a while back?
<digshadow> karsten knoll
<digshadow> (spelling)
<rqou> i don't remember the details. iirc some group discovered the algorithm by looking at the gates and a different group did cryptanalysis
<digshadow> yeah
<digshadow> nohl
<digshadow> anyway hes not the primary
<digshadow> but that was sort of my inspiration
<digshadow> I've talked to karsten a bit, but not in a while
<rqou> oh wait now I remember this guy
<digshadow> haven't had contact with the primary guy in that project
<rqou> he did a bunch of stuff with sim cards as well
<digshadow> "Henryk Plötz"
<digshadow> never talked to him
<rqou> also TPMs
<digshadow> wonder if I could bug him for the die images
<rqou> do you by any chance have FeliCa card images?
<rqou> *die images
<digshadow> if its only used in japan
<digshadow> probably not
<rqou> it's not only used in japan, but not too many people know of the other uses :P
<rqou> HK's Octopus card is FeliCa
<digshadow> i do have a war chest of smart cards though
<rqou> but HK's card obviously isn't on the same networks as the japanese cards
<digshadow> including a lot of subway cards
<digshadow> the thing I want to hit next
<digshadow> is I have a stack of different yubikey varients
<rqou> Clipper :P
<rqou> oh
<digshadow> I have clipper die shots
<digshadow> (NSA and the other one)
<cr1901_modern> digshadow: but filter who it goes through <-- Well, in general, I don't like to fight/argue, so I'm okay being a proxy :P
<rqou> I meant the Clipper bay area transit card
<rqou> iirc it's desfire
<digshadow> cr1901_modern: I already have some proxies though
<digshadow> unless they step down
<digshadow> they'll continue to be that role
<cr1901_modern> okay cool :)
<digshadow> minding you there has been a lot of drama in my personal ife
<digshadow> looks like that might be settling down
<digshadow> hence why operations are starting to come up again
<azonenberg> digshadow: oh? the tank situation is stabilizing?
<azonenberg> :p
<digshadow> azonenberg: uh yeah
<digshadow> I have an access card
<azonenberg> :D
<digshadow> and don't have to break into my property every night now
<azonenberg> about time
<digshadow> its not final yet
<digshadow> but progress
<azonenberg> Did it end up in court or did they see reason before it came to that?
<digshadow> also job situation has stabalized a bit
<digshadow> don't know what the correct term is
<digshadow> but it went to court where they have a short term thing against them
<digshadow> but I think there's going to be a larger case coming up
<azonenberg> So a preliminary injunction was issued in your favor
<digshadow> yeah
<azonenberg> well, have fun with that lol
<rqou> do I want to ask what this is about?
<digshadow> rqou: oh just a petty squabble with the neighbors
<digshadow> we rent from the third wife
<digshadow> neighbor is daughter from the first wife
<digshadow> and some stuff that came out of that
<rqou> ah ok
<azonenberg> a "petty squabble" that almost ended in a tank battle with the neighbors? :P
<rqou> this was mentioned earlier, but I'm currently renting an apartment in Berkeley that is indirectly controlled/owned by a convicted human trafficker
<azonenberg> rqou: tl;dr is that getting to his place requires crossing the neighbor's property
<azonenberg> and the neighbor turned off their keys
<rqou> apparently that happens with some regularity actually
<azonenberg> despite the property deed saying they had to grant access
<rqou> there's a famous reddit thread with a similar story
<cr1901_modern> Where's the second wife?
* cr1901_modern is totally lost
<azonenberg> rqou: the difference is
<azonenberg> in dig's case, there was a formal easement on file with the deed
<azonenberg> which *obligated* them to grant access
<azonenberg> and they were not doing so
<digshadow> azonenberg: i'm not sure about that
<digshadow> but anyway, I don't want to get into details
<digshadow> i'm sick of the issue
<azonenberg> ah ok
<azonenberg> On topic... i'm going to finish refactoring gp4par to remove the last exit()s on error cases now
<cr1901_modern> What algorithm does gp4par use? Is it similar to the simulated annealing in aranche-pnr?
<cr1901_modern> It seems like for every FPGA family one targets, one has to write a totally new pnr tool
<azonenberg> It's an annealing based algorithm, but different from FPGA based
<azonenberg> VPR is actually a pretty well established PAR for 2D tile architectures
<azonenberg> clifford is looking at using it for his next project instead of arachne
<azonenberg> since it's more standard
<azonenberg> The big issue is all of the technology libraries and bitstream generation
<azonenberg> also, in the case of greenpak specifically
<azonenberg> it was a crossbar architecture, not a 2D tile
<azonenberg> and i am not aware of any free PARs for crossbar archiectures
<cr1901_modern> Hmmm, I vould've tried adding a target to arachne PNR tbh
<rqou> just googled VPR: "by V Betz - Cited by 1100"
<rqou> so it's indeed quite popular :P
<azonenberg> Yes
ylm has quit [Quit: leaving]