Hootch has quit [Read error: Connection reset by peer]
specing has quit [Ping timeout: 260 seconds]
specing has joined ##openfpga
kiboneu is now known as mike_pizza
mike_pizza is now known as Guest61638
Guest61638 is now known as kiboneu
kiboneu is now known as kiboronni
<rqou>
why is "configuring network interfaces" one of the best ways to trigger race conditions?
<trap15>
because broadcom
<rqou>
it has nothing to do with broadcom in this case
<rqou>
all intel hw
<rqou>
it's not even in the driver layer
<rqou>
it's in the "distro glue" layer
<trap15>
you can still blame broadcom, probably
<qu1j0t3>
:)
<trap15>
I'm also willing to blame systemd, but maybe that's not relevant
* qu1j0t3
smiles harder
<rqou>
as someone who worked (briefly) at broadcom, i don't think they're that incompetent
<rqou>
i don't know about systemd though
<rqou>
my personal experience with systemd was "wow, everything changed and nobody thought about migration plans or documentation"
<rqou>
went from ubuntu 14.04 to 16.04 and everything exploded
<rqou>
checked release notes; not a mention
<rqou>
(of systemd)
<rqou>
started googling the errors i was getting and eventually realized, "oh, i have this systemd thing now"
specing has quit [Ping timeout: 268 seconds]
<mtp>
the desktop linux people have done a real good job of badly reinventing Windows 95
<rqou>
eh, my personal experience was basically "sure, it's pretty broken but it 'works' a little bit"
<rqou>
except when you try to file bugs
<rqou>
then they basically get ignored until the bug gets perturbed away
<rqou>
and then somebody looks and says "can't repro"
<rqou>
because they perturbed it away
<mtp>
CADT model
specing has joined ##openfpga
<rqou>
except i don't even know if "rewrites" were involved
<pie_>
so i managed to figure out that i can start planahead from the open project and then things are better haha
<rqou>
yeah the xilinx tools somehow manage to "magically" communicate with each other
<pie_>
magically being via temporary files iirc? :P
<pie_>
ok i still have no idea where on this UI i can pair signals and pins
<pie_>
or inputs or whatever theyre called
<pie_>
oh maybe i need to do the post sysnthesis one
<rqou>
are you trying to assign HDL signals to a physical pin on the package?
<rqou>
you need to create a "UCF" file
<rqou>
UCF = User Constraints File
<rqou>
otherwise iirc the tools will assign pins randomly
<pie_>
yeah thats was i was told i need to do
* pie_
is going to break something with just a blinkenleds
<rqou>
there is a gui tool to write UCF files, but it sucks hard
<rqou>
you should just write it in a text editor
<pie_>
ok, yeah i should
_whitelogger has joined ##openfpga
promach has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
specing has quit [Ping timeout: 240 seconds]
specing has joined ##openfpga
amclain has quit [Quit: Leaving]
digshadow has joined ##openfpga
<cyrozap>
pie_: And not the ISE text editor, because it sucks.
<pie_>
btw i got it to wor \o/ now i cant figure out how to upload it
<pie_>
*work
promach has quit [Quit: Leaving]
<cyrozap>
pie_: What board are you using?
<pie_>
almost got success now \o/
<pie_>
spartan 3an dev board
<pie_>
* starter kit
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
promach has joined ##openfpga
pie_ has quit [Ping timeout: 256 seconds]
l0ser has joined ##openfpga
pie_ has joined ##openfpga
digshadow has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
<rqou>
azonenberg_work: why are you on a tmobile connection?
<cr1901_modern>
defparam_: I think perhaps it's time to send 21fx/it's sequel to a bunch of potential archivists :/?
<azonenberg_work>
rqou: tethering off my phone while traveling
<azonenberg_work>
i'm also using webchat
<rqou>
oh? where?
<azonenberg_work>
normally i'd use pidgin but freenode doesnt like some tmobile IP ranges
<azonenberg_work>
So it forces me to auth with sasl
<azonenberg_work>
and for reasons unknown any time i try to sasl to freenode with pidgin i get an "incorrect password" error
<azonenberg_work>
probably a libpurple bug but i havent had time to investigate
<azonenberg_work>
LA area
<rqou>
anyways, i'm _still_ fighting with ipv6 routing tables
<rqou>
this is apparently quite hard
<pie_>
btw i got a working led blink earlier :D
<pie_>
so it finally works
<pie_>
now for sleep
<pie_>
rqou, its like going from arithmetic to algebra eh? now theres letters everywhere!
<pie_>
:P
<azonenberg_work>
lol
<rqou>
the problem is that i'm technically "multihomed"
<rqou>
but using vlans
<rqou>
so all of the heuristics that operate on mac addresses produce the same answer
<azonenberg_work>
lol
<azonenberg_work>
i have a kinda-sorta similar problem i never fully debugged
<azonenberg_work>
tl;dr my desktop gets a SLAAC address on three vlans
<azonenberg_work>
only one of which routes to the internet
<azonenberg_work>
and it tries to assign the default route in sometimes unpredictable ways
<rqou>
guess what?! i have the exact same problem!
<rqou>
:P
<azonenberg_work>
lol
<azonenberg_work>
Well in that case let me know if you figure it out, lol
<pie_>
what do you do that for? :O
<azonenberg_work>
So far the only solution i've found is to manually remove and re-add the default route when it guesses wrong
<azonenberg_work>
all of my single-homed boxes are fine
<azonenberg_work>
pie_: test network that doesnt route outside for prototype hardware
<pie_>
ah
<azonenberg_work>
bridge to DMZ for talking to a couple of VMs etc there
<azonenberg_work>
then the main LAN
<pie_>
wel anyway, bailing2bed.exe
* pie_
dies
<azonenberg_work>
rqou: it'd work fine if i was running slaac only on the upstream subnet
<azonenberg_work>
maybe i should just statically assign an ip on testnet
<rqou>
apparently hosts are allowed to ignore you and use a slaac address anyways
<rqou>
even if the RA doesn't have the A bit set
<azonenberg_work>
what i meant was
<azonenberg_work>
have the host ignore RAs
<azonenberg_work>
on those subnets
<azonenberg_work>
and then do an /etc/network/interfaces config statically
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<rqou>
blargh i have an iptables problem as well
<rqou>
alright, i have a setup that "works" now but i have no idea why it works
<rqou>
it's also pretty improper
<rqou>
right now if you go from outside and ping my desktop
<rqou>
it'll receive the ping on vlan x
<rqou>
and reply on vlan y
<openfpga-github>
[openfpga] azonenberg pushed 2 new commits to master: https://git.io/vDDQh
<openfpga-github>
openfpga/master fddaeed Andrew Zonenberg: Continued initial work on PCF file support. Can now pass PCF files in test cmake script and parse the arg in gp4par, but the contents are ignored still
<openfpga-github>
openfpga/master 26ff199 Andrew Zonenberg: Updated to latest logtools
<azonenberg_work>
i thought whitequark was working on that one
<azonenberg_work>
if they're not i'll investigate in a bit
<azonenberg_work>
but bugs causing incorrect PAR results are higher priority than ones that cause an incorrectly set up dev machine to fail compiling
<azonenberg_work>
i.e. i care more about being silently wrong
<azonenberg_work>
than blowing up obviously
<rqou>
btw does anybody know of a non-polling-based dynamic dns client for linux?
<whitequark>
oh yeah I should fix #60
<whitequark>
last time I tried I couldn't figure out how to coerce pdflatex into running in a *true* batch mode
<azonenberg_work>
i think those two are the main "bug" tickets we still have open
<azonenberg_work>
the remaining issues are "X isnt a great practice" or "we really should support feature Y"
<rqou>
"bug: azonenberg_work needs to order more devkits" :P
<azonenberg_work>
and i guess there's #56 but i may close that as "cant reproduce"
<azonenberg_work>
rqou: lol
<azonenberg_work>
hey if i asked for one i'd probably get it
<azonenberg_work>
i just want to give them a bit more to show first
<azonenberg_work>
if i can get full gp4 support that'd be nice
<azonenberg_work>
i dont think i'm THAT far from it
<azonenberg_work>
sorry i meant, full 46620 support
<azonenberg_work>
#23 is another biggie i have to work on, not yet sure what the best way to handle it is
<azonenberg_work>
tl;dr i dont do true simulated annealing, i stop at the end of the process and dont revert to the best local minima found
<azonenberg_work>
so sometimes i get to a really good placement then get worse
<azonenberg_work>
and cant roll back
<azonenberg_work>
this isnt as high a priority b/c it isnt an incorrect par, it's just suboptimal QoR
<azonenberg_work>
But i keep forgetting to work on it
<rqou>
i don't know how i keep getting stuck doing bullshit sysadmin-ing
<rqou>
i guess i must be a masochist
<azonenberg_work>
Innnnteresting
<azonenberg_work>
I dont think this is a gp4par bug
<azonenberg_work>
the LOC attribute isn't being propagated to the JSON netlist post-synthesis
m_w has joined ##openfpga
<azonenberg_work>
So this is a yosys issue
<azonenberg_work>
going to investigate further but i am probably going to close #63 as invalid
<azonenberg_work>
while it's definitely a bug that has to get fixed, gp4par is behaving correctly given garbage input (it even warns about the missing constraint)
<azonenberg_work>
The second bug is, why did my cmake script not print the warning to the console during build? Or did i just miss that
<azonenberg_work>
" The resistive magnet produces 33.5 T and the superconducting coil produces the remaining 11.5 T. This magnet requires 30 MW of power. This magnet must be kept at 1.8 K (-456 degree Fahrenheit) using liquid helium. The magnet takes 6 weeks to cool to temperature and thus once cooled the cooling system it is run continuously. It costs $1452 an hour to run at full field."
<azonenberg_work>
30 megawatt electromagnet
<cr1901_modern>
Even 11 T magnet isn't trivial to make, IIRC
<azonenberg_work>
inside a cryogenic superconductor
<azonenberg_work>
So you have one part of the system at liquid helium temps and another part in close proximity dissipating 30 megawatts
<azonenberg_work>
that... must be nontrivial :p
<azonenberg_work>
i actually thought the power bill would be higher than that
<whitequark>
azonenberg_work: interestingly the current strongest field is 60T
<whitequark>
at NIF I think
<whitequark>
we've discussed this recently with @bofh453
<azonenberg_work>
Soooo
<azonenberg_work>
latest yosys doesnt seem to have fixed it
* azonenberg_work
digs further
<cr1901_modern>
Ahhh I thought the record was like 45T cool
<azonenberg_work>
assign a = dir ? b|d : 1'bz; assign b = ~dir ? ~a : 1'bz;
<azonenberg_work>
This is not a combinatorial loop, right?
<cr1901_modern>
Too tired to check
<azonenberg_work>
depending on dir you either have a as a function of b and d (with b/d input)
<azonenberg_work>
or b as a function of a (with a input)
<azonenberg_work>
it looks like yosys may be having problems with this
<azonenberg_work>
at least the DRC
<azonenberg_work>
i *think* it synthesizes correctly but havent confirmed yet
<azonenberg_work>
the bug i'm hunting is related to a different part of the design
<azonenberg_work>
but i notice the DRC is yelling about this
<azonenberg_work>
i think its a false positive
<azonenberg_work>
it looks for loops in the connectivity and doesnt do any checking to see if all legs of the loop are ever active at once
<azonenberg_work>
i.e. its not a combinatorial loop if you have an edge from A to B and B to A, but they're conditional on mutually exclusive values
<azonenberg_work>
The real bug is, somewhere during synthesis
<azonenberg_work>
before that step i have a GP_OBUFT with a LOC constraint
<azonenberg_work>
After it, I have a GP_IOBUF without on
<azonenberg_work>
one*
<azonenberg_work>
So somehow when it remaps the OBUFT to an IOBUF it loses the LOC constraint
<azonenberg_work>
this now makes me wonder if all cells_map techmapping is dropping attributes somehow
<azonenberg_work>
And this is the first time it's caused visible symptoms
<cyrozap>
rqou: You aren't using `ip link set`?
<rqou>
er, ip link set is used in a lot of places
<cyrozap>
I thought ifconfig et. al. was deprecated?
<rqou>
yeah i'm not using ifconfig
<cyrozap>
I don't even have ifup/ifdown on my system
<rqou>
afaik it's part of debian's glue
<cyrozap>
Oh, I see
<cyrozap>
In other news, I'm nearing completion on the OpenOCD KitProg driver. Ironically, it works better with most non-PSoC targets than it does with PSoCs...
<azonenberg_work>
we'll see how clifford responds to this
<azonenberg_work>
i'm looking at the techmap code and a little lost, he probably can code it up faster than i can figure out what needs to be done lol
<cr1901_modern>
azonenberg_work: Probably something along the lines of "you didn't read paragraph 1, subsection b, subsubsection j of the Verilog standard"
<azonenberg_work>
lol
<azonenberg_work>
no this is very specifically a techmapping issue
<azonenberg_work>
it
<azonenberg_work>
it's purely structural
<azonenberg_work>
Anyway since that's tabled a bit
<azonenberg_work>
time t oget back to working on constraint files
m_w has quit [Quit: leaving]
<azonenberg_work>
Woopwoop
<azonenberg_work>
Applying PCF constraint LOC (with value P15) to wire f
<azonenberg_work>
Wire is driven by cell $auto$iopadmap.cc:330:execute$144, constraining that instead
<pointfree>
Well, I've been working on a PSoC 5LP USB driver, on the ARM side. I think I just got the clock setup correct so that I actually get a usb_bus_reset interrupt.
Hootch has quit [Ping timeout: 264 seconds]
mifune has quit [Ping timeout: 240 seconds]
<pointfree>
cyrozap: These two documents describe a compact bitstream/configuration format for the PSoC configuration area: https://github.com/kiml/PSOC_programmer/tree/master/docs The format is simple and already has everything needed for startup configuration ...except for delays.
<pointfree>
If a new record type was added for delays, pretty much all of the startup config could be stuffed into the configuration area compactly.
<pointfree>
Anyone have recommendations for representing delays?
<lain>
time is usually good for representing delays
<lain>
sorry, I'll see myself out
<nats`>
pointfree what do you mean ?
<nats`>
representing delay$
<nats`>
like inv erilog with #X
<nats`>
?
* cr1901_modern
gets out the hook for lain
* qu1j0t3
hears a rapid whoosh
* nats`
takes the sponge to remove blood everywhere
<pointfree>
nats`: Like should I use some kind of compact scientific notation for the number of Hz? What kind of min & max range should it support?
<pointfree>
nats` During start up configuration I often have to churn the butter for a few cycles before continuing.
<nats`>
I think I miss some context
<pointfree>
nats`: The configuration area is flashed with a list of base addresses, and offset/value pairs for each base address. This is so you can use one loop to configure the PSoC on startup instead of setting each of the registers individually with ARM assembly.
<nats`>
but you want to represent that in a document or in code ?
<pointfree>
nats` In an array in non-volatile memory on the PSoC 5LP.
<pointfree>
So in data.
<pointfree>
The two documents linked above describe the format which is like the one Cypress uses but with few enhancements added by kiml.
<nats`>
ahhh I miss backlog
<pointfree>
...or should the new record type be another (address, value) pair where, at configuration time, the address is polled until the polled register's bit matches value?
<pointfree>
*bits
<pointfree>
Will it always be possible to poll for some bit wherever a wait loop is needed?