<rqou>
the interconnect fuzzing i was proposing the other day doesn't require a lut at all
<rqou>
you can literally just write `assign o = a;` and mess around with what path is used for thhat
<rqou>
although a lut will be required for fuzzing the tracks going into a lab eventually
digshadow has quit [Ping timeout: 245 seconds]
ZombieChicken has joined ##openfpga
unixb0y has quit [Ping timeout: 264 seconds]
unixb0y has joined ##openfpga
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
rohitksingh_work has joined ##openfpga
soylentyellow_ has joined ##openfpga
soylentyellow__ has quit [Ping timeout: 256 seconds]
Bike has quit [Quit: Lost terminal]
balrog has quit [Ping timeout: 256 seconds]
digshadow has joined ##openfpga
balrog has joined ##openfpga
mwk has quit [Ping timeout: 248 seconds]
mwk has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 260 seconds]
balrog has quit [Quit: Bye]
rohitksingh_work has joined ##openfpga
balrog has joined ##openfpga
<rqou>
azonenberg: woot!
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 260 seconds]
<azonenberg>
rqou: still a long journey ahread
<azonenberg>
but a major milestone
<rqou>
hope you don't fail inspection
<rqou>
how exactly were you planning to have moved in by end of may exactly? :P
<azonenberg>
rqou: let me count the ways
<azonenberg>
We weren't planning to spend a month removing the old attic insulation
<azonenberg>
We weren't planning to have an office that wanted to be a lake
<rqou>
wait, that took a month?
<azonenberg>
Yes
<azonenberg>
almost
<rqou>
wut
<rqou>
how?
<azonenberg>
up there in a bunny suit and respirator for 8 hours a day, minus water/cooling breaks, for a week off work
<azonenberg>
then evenings after work
<azonenberg>
shoveling and vacuuming the stuff a few cubic feet at a time
<azonenberg>
Imagine a house a foot deep in toxic cotton balls
<azonenberg>
Some of them jammed in tight corners you can't reach with anything bigger than an arm or vacuum cleaner hose
<azonenberg>
poor visibility
<azonenberg>
a floor you can't put your weight on
<azonenberg>
And limited access to get the stuff in and out of the attic
<azonenberg>
also moving slowly because of being roped up and having to leapfrog between anchor points any time i was going somewhere
<azonenberg>
It wasn't a month of JUST insulation though
<azonenberg>
The other unplanned thing was, having positive (trace) asbestos results on the ceilings OUTSIDE the closets
<azonenberg>
meaning, after insulation was out
<azonenberg>
i had to quarantine each room and wear a full suit with taped seams to remove the old sheetrock, bag it up as i went
<azonenberg>
minimize breaking it
<azonenberg>
i'd spend a full day after work doing prep, building the containment for a room
<azonenberg>
another day ripping down the sheetrock
<azonenberg>
Then another day or two removing stuff over the ceiling for the next room
<azonenberg>
We demoed the first floor in a week, i was expecting the second to be just as fast
<azonenberg>
i wasnt expecting to have to remove the old insulation fully either
<azonenberg>
But turns out it was R-11 and once you expose wall cavities, you have to put in R-15
<azonenberg>
In retrospect that was a wise move, the old stuff reeked of smoke and having it gone made rewiring a ton easier
<rqou>
so dumb question:
<rqou>
how the f*** were the previous owners dealing with all of this?
<azonenberg>
And the old insulation was a scratchy, prickly cactus of fiberglass
<azonenberg>
The old owners smoked packs a day and didnt mind the smell
<azonenberg>
The leaky roof went unnoticed because the sawdust insulation sponged it up
<azonenberg>
it was slowly rotting and going moldy but hadnt soaked through the sheetrock muhc
<azonenberg>
much*
<azonenberg>
The leaky floor, i'm not entirely sure - but it sounded like that may have been a recnet thing, drainage changed when the new apartments up the hill got built
<azonenberg>
And by the time that happened it sounded like she wasnt really living there much
<azonenberg>
i dont know when the husband got lung cancer from all the smoking but the wife moved down to wherever the cancer center was to be with him
<azonenberg>
and left the house largely vacant
<azonenberg>
The outlets with no power probably just didnt get used
<azonenberg>
The outlets with no ground were probably unnoticed
<azonenberg>
The inadequate insulation just meant they spent more on power than they would have otherwise, it only became an issue once the sheetrock came down
<azonenberg>
once the wall cavity is open your hands are tied, you can't put it back together until it meets code
<rqou>
but i thought the insulation "just" has to be shoved in with a stick?
<azonenberg>
The walls were fiberglass batts
<azonenberg>
And the stuff they had in there was R-11, new code wants R-15
<azonenberg>
You can't stack it without increasing the thickness, when squished it insulates less well
<azonenberg>
So the old stuff had to come out before the new went in
<rqou>
wait, is this all the "wall crap" you were telling me about that was already gone when i visited?
<azonenberg>
Yes
<rqou>
oh
<rqou>
nvm
<rqou>
so only the ceiling insulation was the easy part
<azonenberg>
The super itchy prickly stuff
<azonenberg>
no, the wall stuff was fairly easy
<azonenberg>
the ceiling stuff was the blow-in BS that i spent weeks on
<azonenberg>
this is what the old insulation looked like - put on a suit, gloves, and mask so none of the itchy stuff gets on you, then pull it out and shove into trash bags
soylentyellow__ has joined ##openfpga
<rqou>
ah and some of it was in the ceiling too
<azonenberg>
only a little bit
<azonenberg>
seemed like they had extra and shoved it up in the attic
<azonenberg>
which to be fair, can't hurt
soylentyellow_ has quit [Ping timeout: 268 seconds]
<azonenberg>
That pile looks to be about 6 feet wide x 4 feet high
<rqou>
that looks fun
<azonenberg>
Which comes out to a volume of... 37 cubic feet, approximately
<azonenberg>
The house is roughly 38 x 22 feet or 836 square feet footprint
<azonenberg>
not counting the garage
<azonenberg>
Filled ~18 inches deep is 1254 cubic feet of this
<azonenberg>
Or about 33 times that pile
<rqou>
that sounds... unpleasant
<azonenberg>
now imagine snow-shoveling that through an opening in the ceiling the size of a manhole while wearing a level c hazmat suit
<azonenberg>
And roped to anchors that you have to keep moving between
<azonenberg>
It was taking forever, moving to the vacuum system was a slight improvement
<azonenberg>
i'd take ~10 minutes to vacuum up a laundry-basket-sized volume of stuff
<azonenberg>
then spend several minutes moving it to the closest ladder access
<azonenberg>
slide it down the ladder, wait a few mins for ally to scoop the contents into a trash bag
<azonenberg>
slide it back up, spend another few mins getting back in position
<azonenberg>
But at least i wasnt bucket-brigading the stuff 20 feet a scoop at a time from a sitting position
<azonenberg>
Or spending QUITE so much time on my belly with 2x4s pressing uncomfortably in various parts of my anatomy trying to reach a shovel or vacuum wand into an opening a few inches high to get all the insulation out
<azonenberg>
in some of the tighter spots i couldnt even turn my head upright
<azonenberg>
i had to go sideways or the hard hat wouldn't fit
<azonenberg>
Soooo yeah very glad that is over
<azonenberg>
rqou: also on topic
<azonenberg>
did you see my verilog std::set?
<rqou>
i remember you mentioned making one
<azonenberg>
std::unordered_set*
<azonenberg>
i tweeted a github link
<azonenberg>
curious what you think
<azonenberg>
not fully tested but works ok in a preliminary sim test
<azonenberg>
OO HDL? lol
* azonenberg
hides
<azonenberg>
(seriously, i tend to write my RTL in a bit of an OO-esque design in which I have encapsulated modules that have a well defined API of some sort)
<azonenberg>
the set has ~3 methods on it right now (depending on how you count): insert a new element and return success/full status
<azonenberg>
remove an element pointed to by a given iterator (always succeeds, removing an unused iterator is a legal no-op)
<rqou>
i don't have too many comments about HDL coding styles because i actually don't write _that_ much HDL
<azonenberg>
and iteration over the elements of the set
<rqou>
and i never opposed encapsulation of objects
<azonenberg>
Which is subdivided into two sub-operations, "increment existing iterator" and "get iterator to the first element in the set"
<rqou>
just the more java-esque way of doing it
<azonenberg>
But i consider them semantically to be the same operation
<azonenberg>
Since both spit out "new value of iterator", "element pointed to by that iterator", and "are we at the end of the set yet"
<azonenberg>
rqou: personally, i consider HDL to be almost more amenable to "extreme OO" than something like C++
<azonenberg>
Because in C++ you can just declare members public and anybody can read/write them etc
<azonenberg>
whereas in a HDL you have to actually provide an input port for the new value of a register, a write enable, and so on
<azonenberg>
And all internal state is encapsulated by default unless you bring it out
<rqou>
not in vhdl trololol
<azonenberg>
wait what?
<rqou>
vhdl 2008 has "hierarchy-piercing signal names"
<azonenberg>
i mean hierarchial references across object boundaries exist in verilog too
<rqou>
(not the official name)
<azonenberg>
but almost no synthesizers support them
<azonenberg>
i've never seen one that does
<rqou>
oh idk if it's supported for synthesis
<rqou>
the intended use case is to pull out a really deep signal in testbenches
<azonenberg>
And i would consider use of them for any purpose other than chipscope/logic analyzer type cores to be absolutely prohibited
<rqou>
without having to wire it all the way out
<azonenberg>
yeah i know why its there
<azonenberg>
last time i checked the verilog equiv was not supported by ise or vivado
<azonenberg>
Thankfully
<rqou>
i was intending to support it (but we all know how well that effort went)
<azonenberg>
This is also a very useful property for formal verification
<rqou>
i don't understand why so many "simple desugars" are not supported by HDL tools
<azonenberg>
It allows you to prove, in isolation
<azonenberg>
that a module satisfies some properties and know that the proof will hold when integrated too
<azonenberg>
and its not simple necessarily because (for example) it inhibits parallel synthesis of different modules
<azonenberg>
what if you build one module first then do an incremental build?
<azonenberg>
what if the register you wanted to look at was optimized out during the incremental build?
<rqou>
hmm
<rqou>
i think you would hit analogous issues when handling generics though?
<azonenberg>
no, because at elaboration time generics/parameterized modules are turned into separate module instantiations
<azonenberg>
you dont synthesize the generic module
<azonenberg>
you synthesize each instance of it as it appears, if you dont have a pre-synthesized version of that because another module instantiated the same configuration of it
<azonenberg>
in yosys this is done by the "hierarchy" pass iirc
<rqou>
hmm i think i see the issue now
<azonenberg>
it turns a single generic module into a bunch of $paramod$ modules
<azonenberg>
one per set of generic/parametr configs
<azonenberg>
Each of those is optimized
<azonenberg>
And this can remove internal registers
<azonenberg>
Or rename them, or absorb them into other hard IP, etc
<azonenberg>
now imagine a more sophisticated synthesizer like vivado's that does this in parallel for different modules in your codebase
soylentyellow_ has joined ##openfpga
<rqou>
it's probably doable with a hack that looks for all such hierarchy-bypassing references ahead of time
lutsabound has left ##openfpga [##openfpga]
<azonenberg>
yeah but again, it breaks things like incremental synthesis
<azonenberg>
which is commonly used for large asic/fpga projects
<rqou>
no?
<rqou>
adding such a references does cause the module to need to be resynthesized though
<azonenberg>
it means you have to re-synthesize that module based on what the parent code does
<azonenberg>
So it breaks the optimization
<rqou>
but that's unavoidable
<azonenberg>
even if you do add such a hack
<rqou>
it doesn't have to resynthesize the entire design
soylentyellow__ has quit [Ping timeout: 265 seconds]
<azonenberg>
My point is, i consider it an antifeature that you shouldn't bend over backwards to support
<azonenberg>
:p
X-Scale has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Would you like to know more?]
ZombieChicken has quit [Quit: Have a nice day]
<rqou>
ugh i need a better tool to visualize all of this data
<azonenberg>
rqou: that was th eproblem i ran into with bitstream RE in the past when i was focusing on netlists
<rqou>
i'm also currently focusing on netlists
<azonenberg>
Visualization of large netlists is a difficult problem and one i have not yet seen good tooling for
<azonenberg>
graphviz in particular is very poor at handling high-fanout nets
<rqou>
i mean, my favorite tool so far is "spreadsheets"
<azonenberg>
like supply, clocks, etc
<rqou>
which don't exactly scale either :P
<rqou>
it seems like i currently could really use some kind of "structured query language" for looking at the routing graph :P
<rqou>
azonenberg: quick thing i want a sanity check on
<rqou>
right now it appears that row wires can only be driven by "things in the same row"
<rqou>
so i think that a proper overestimate of "anything that might possibly ever enter a given mux" should be
<rqou>
*) every right-going wire originating from the left of this tile up to the current tile
<rqou>
*) every left-going wire originating from the right of this tile down to the current tile
<rqou>
*) every up-going wire originating from below up to this tile
<rqou>
*) every down-going wire originating from above this tile
<rqou>
does this seem like it includes a superset of valid connections?
<azonenberg>
My mental math says thats roughly half the routs in the whole chip
<azonenberg>
But yes
<rqou>
i mean, i can also just try _everything_
<rqou>
960^2 is manageable (for now)
<rqou>
this is intended to be an overestimate just to cut down 960^2 even smaller
<azonenberg>
yeah i get where you're going
<azonenberg>
and any optimization helps
<azonenberg>
But thats still a laaaarge set
<rqou>
960^2 ~= 2^20
<rqou>
not that large
<azonenberg>
depends
<azonenberg>
remember, O(1) says nothing about the magnitude of the constant ;)
<azonenberg>
How long does each test take?
<azonenberg>
How many routes can you eliminate per P&R?
<rqou>
oh each test takes forever
<rqou>
and 1
<rqou>
so let's see
<rqou>
each test takes like 1 second at least
<rqou>
so 960^2 = 256 hours
<azonenberg>
lol
<azonenberg>
at 1 sec per build?>
* azonenberg
is thinking vivado level synth times
<azonenberg>
where building "assign x = y" probably takes a minute or more
<rqou>
i run at least 20 threads
<rqou>
so ~15 hours?
<azonenberg>
Times however many seconds each build takes
<azonenberg>
Still, it's less than a lifetime and probably will even finish before the chip goes EOL
<rqou>
lol
<azonenberg>
important metrics :p
<rqou>
the largest chip is <8x bigger
<azonenberg>
So <64x run time? :p
<azonenberg>
with any luck though, by the time you get to th ebigger chips
<azonenberg>
you'll have a better idea of how the fabric works
<azonenberg>
And you wont have to do such dumb fuzzing
<azonenberg>
it'll be much more directed
<rqou>
i mean, R4 is clearly 4 tiles long
<rqou>
so i can obviously cut that down
<rqou>
oh wait a sec
<rqou>
i'm an idiot
<rqou>
you can kinda run multiple tests in parallel
<rqou>
oh wait
<rqou>
no you can't
<rqou>
er, maybe you can?
<rqou>
anyways
<rqou>
quartus routing constrants can contain "OR" terms
<rqou>
but only for each specific routing element
<rqou>
so you can't easily do "this complete path or that complete path"
<rqou>
but this might still be usable?
<rqou>
i might not bother for now
<rqou>
see what happens
bitd has joined ##openfpga
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has quit [Ping timeout: 248 seconds]
ondrej2 has joined ##openfpga
brizzo has quit [Ping timeout: 264 seconds]
brizzo has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 276 seconds]
afiskon has joined ##openfpga
rohitksingh_work has joined ##openfpga
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 260 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 276 seconds]
pie_ has joined ##openfpga
scrts has quit [Ping timeout: 256 seconds]
Hamilton has joined ##openfpga
Hamilton has quit [Remote host closed the connection]
scrts has joined ##openfpga
X-Scale has joined ##openfpga
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
Ultrasauce has quit [Ping timeout: 256 seconds]
Ultrasauce has joined ##openfpga
Miyu has joined ##openfpga
rohitksingh has joined ##openfpga
Bike has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
azonenberg_work has quit [Ping timeout: 245 seconds]
genii has joined ##openfpga
ZipCPU has joined ##openfpga
azonenberg_work has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
<azonenberg_work>
Sooo apparently rapidwright just disappeared
<azonenberg_work>
the github is an empty readme
<azonenberg_work>
wonder if somebody screwed up or XLNX is doing something funky
<daveshah>
azonenberg_work: luckily someone forked it
<balrog>
isn't RapidWright a fork of RapidSmith anyway?
<daveshah>
not exactly sure what the relationship is
<daveshah>
anyone want to create a PR to RapidWright restoring all the stuff :P
<daveshah>
RapidSmith looks to be XDL based, so ISE only
<azonenberg_work>
So here's a fun question
<azonenberg_work>
Suppose we wanted to create a "rapidwright community edition"
<azonenberg_work>
based on the existing state of the repo people have forked
<azonenberg_work>
And suppose we got data files for existing devices
<daveshah>
just need to find someone who got those data files
<daveshah>
the only problem would be the questionable copyright of the data files
<azonenberg_work>
How hard would it be to use prjxray to extend support to new not-yet-existing / not-yet-supported devices?
<daveshah>
easy, I think UltraScale support has already been considered even
<azonenberg_work>
Or clean-room recreate the data files from prjxray-db plus the source?
<azonenberg_work>
i.e. we know what the data is supposed to be, we just have to create it in a format that rapidwright can read
<azonenberg_work>
Not that i'm proposing such a course of action as a viable way forward
<daveshah>
looks doable, although there's a point you may as well just use xray
<azonenberg_work>
but its worth thinking about
<azonenberg_work>
exactly my thought
<azonenberg_work>
i dont want to deal with java
<azonenberg_work>
that was my biggest complaint with rapid
<azonenberg_work>
rapid*
<azonenberg_work>
Both of them were java
rohitksingh has joined ##openfpga
<daveshah>
our open "flow of the future" will be C++ based and support extensions either in C++ or rapid prototyping/scripting in Python, as a replacement for the Tcl interface of existing tools
<azonenberg_work>
Good
<azonenberg_work>
Because tcl is a disaster :p
<shapr>
I'm shocked to hear xilinx and open source in the same sentence.
<daveshah>
it didn't last long, don't worry
<shapr>
I thought maybe they'd realized they were a hardware company.
<balrog>
daveshah: are there any plans for build system work?
<balrog>
I'm asking because that's the elephant in the room that no one ever wants to touch, and for good reason :/
<daveshah>
balrog: currently it's mostly me on that. I can't really discuss anything (other than the sneak preview in Clifford's twitter) until the public release
<balrog>
ahh :|
<balrog>
CMake seems to have won for most software, but it's weird enough that people go out of their way to avoid it
<kc8apf>
as far as the low-level bits, new xc7 devices mostly add additional rows. Pretty easy to support them even without a released device.
<azonenberg_work>
balrog: yeah i want to find time to sit down and fix/finish splash
<azonenberg_work>
Maybe once the house is under control
<azonenberg_work>
In other news i just walked through the house and counted receptacles to see how many i needed
<azonenberg_work>
... wow
<azonenberg_work>
This explains why it took so long to wire the place lol
<azonenberg_work>
i have somewhere between 250 and 275 duplex receptacles in this place
<azonenberg_work>
Depending on whether you count spaces like the kitchen that aren't being remodeled yet
<kc8apf>
clearly you've gone above and beyond the 6' spacing rule
<azonenberg_work>
So first off, its a 12' spacing rule in the code
<azonenberg_work>
No point on the wall can be >6 from a receptacle
<azonenberg_work>
Which means 12' pitch
<kc8apf>
right. that's why 6' extension cords
<azonenberg_work>
In "general residential" areas like bedrooms
<sorear>
What’s the sneak preview? Just the nextpnr thing!
<azonenberg_work>
I did 6' spacing so no point >3' from a receptacle
<kc8apf>
been way too long since I remodeled a house
<sorear>
?
<azonenberg_work>
In "electronics heavy" areas like the living room TV corner, the office, and the lab
<azonenberg_work>
I put one every two studs, or roughly every 32"
<azonenberg_work>
Also, everywhere i put power, I put a 2-gang box with two duplex receptacles
<azonenberg_work>
or four total NEMA 5-20R's
<azonenberg_work>
Rather than the usual 1-gang box with a single duplex receptacle
<kc8apf>
I wish I had done that in my previous house
<azonenberg_work>
my wife thinks i am nuts for having so much power
<azonenberg_work>
i'm just waiting for when we move in
<azonenberg_work>
and she's wishing for more
<kc8apf>
worst is when you are hunting for an open outlet for a vacuum
<kc8apf>
I would put one box behind doors just so they wouldn't be occupied
<azonenberg_work>
Yeah i have some of that
<azonenberg_work>
But its too late to change much, the inspector is coming today for rough-in :p
<azonenberg_work>
I think i did everything right, i even made sure to use a torque screwdriver for all of the breaker and receptacle connections (only a handful of those so far, for the single temporary construction circuit)
<kc8apf>
I've had mixed results with inspectors. Some hated that I was doing the work myself and wanted to find any flaw. Others were thrilled I took the time to read the code and checked very little.
<azonenberg_work>
Yeah
<azonenberg_work>
I'm hoping when this guy sees i am doing full commercial-grade wiring with metal boxes and MC
<azonenberg_work>
that he realizes i'm taking it seriously and actually reading the code etc
<azonenberg_work>
I actually crunched box fill numbers, made sure to keep my wires >1.25" from the face of a stud and used plates when i couldn't, etc
<kc8apf>
One inspector in Campbell, CA saw all the data cabling and took it as a sign to be extra annoying
<azonenberg_work>
And put in a dedicated subpanel for the (future) hard wired UPS
<azonenberg_work>
well i have 300 feet of ENT in this place, plus probably 200 feet of cable tray? (not yet all hung, i'm temporarily fitting it before drywall but it wont go up for real until later)
<azonenberg_work>
So he'll have fun with the data there :p
<azonenberg_work>
The one thing i am a bit worried about is the bollards by the breaker panel
<azonenberg_work>
there is a water pipe coming right out of the floor under the panel
<azonenberg_work>
So i framed out a knee-height wall that stuck out a few inches on either side of it, to prevent anything from bumping into it and hitting the shutoff, shearing the pipe, etc
<azonenberg_work>
But it's going into the clear working zone under the panel
<azonenberg_work>
I'm a little concerned that the electrical inspector may tell me to rip out the wall while the plumbing inspector will tell me to put it back
<azonenberg_work>
:p
<kc8apf>
usually inspectors are generalists
<kc8apf>
they just rotate through first available
<azonenberg_work>
Not here
<azonenberg_work>
Electrical inspections are done by the state dept of labor and industrires
<kc8apf>
huh
<azonenberg_work>
all other construction stuff is done by the county (if outside city limits) or the city (if you are, like me)
<azonenberg_work>
A few very large places like seattle have their own electrical inspectors but almost everywhere else has state inspectors
<kc8apf>
I've had San Jose inspectors call their office to ask about trades they aren't as familiar in
<azonenberg_work>
and the building dept has a small pool of inspectors and i believe one is assigned to each permit
<azonenberg_work>
Since any time i called with questions i got the same guy after i gave the permit number
<kc8apf>
sounds much more sane that what I've experienced in the SF area
<azonenberg_work>
So presumably my plumbing, framing, insulation, sheetrock, etc will all be the same guy
<azonenberg_work>
But it wont be the one who inspects the wiring
<kc8apf>
this reminds me I need to find a new plumber to run a gas line. Previous plumber changed ownership and isn't nearly the same quality.
<azonenberg_work>
Well
<azonenberg_work>
Don't go with the guys who did my sump pump
<daveshah>
Claim to be "license incompatibilities"
<daveshah>
Anyway, it's gone. Don't want to ruffle any feathers and upset either work or uni
<mithro>
daveshah: Yeap - I'm pretty sure its because of their attempt to relicense it as non-gpl so they could link against their proprietary Xilinx stuff
<daveshah>
mithro: lol
<mithro>
daveshah: Do we have a python parser for pcf?
<daveshah>
mithro: there will be one in icebox_vlog
<daveshah>
but it's not many lines at all, at least if you just want pin constraints
<daveshah>
full pcf is more complicated if you want to do location constraints
<azonenberg_work>
daveshah: sooo
<azonenberg_work>
do you think rapidwright is dead?
<azonenberg_work>
Or are they just relicensing it
<daveshah>
it sounds like something will happen again but who knows
<daveshah>
suspect whatever it is will have more binary blobs and/or a shitty license
<mithro>
azonenberg_work: From what I could see it seemed that Xilinx was unhappy with the RapidWright having the ability to extract all the info from the checkpoint files
<mithro>
azonenberg_work: As the latest release they tried to remove all that and make it a proprietary java lib that RapidWright linked against...
<pie_>
does rqou have a mirror
<rqou>
sorry, no
<daveshah>
azonenberg_work: I've replied to their email asking what the long term plan with RapidWright is
<daveshah>
Tbh the DCP format doesn't look too complicated anyway - the first layer is a standard archive, I forget which, and then it is EDIF+xdef. the xdef format is proprietary but 90% ASCII with some binary control stuff. clean room RE should be doable anyway
<daveshah>
Open DCP tools could be interesting if people want to run stuff on EC2 F1 instances, which for good reason don't allow raw bitstreams
<rqou>
anyone want to poke at altera's equivalent?
<rqou>
azonenberg recommended that i avoid doing anything like that
<daveshah>
Certainly that sort of thing is established to be safe in the EU
<rqou>
sure
<daveshah>
No time personally, but it's not something I would avoid - but fortunately Lattice provided to/from text conversion tools for Diamond ncl files anyway
<rqou>
why hasn't anybody made me the "EU edition" of xc2par yet?
<rqou>
azonenberg: would it be legal if i just took a vacation in the EU and then went and created the "EU edition" of xc2par?
<jn__>
EU edition? o.O
<azonenberg_work>
rqou: lol
<azonenberg_work>
thats a very good question, and i dont actually know
<azonenberg_work>
if a us citizen does something in the eu that's locally legal but violates US law
<azonenberg_work>
i know there are some laws specifically regulating conduct of us citizens in foreign countries, but they're targeting things like bribing foreign officials and sex tourism
<rqou>
jn__: the EU edition (which doesn't actually exist yet) will support all the parts, not just the xc2c32a
<azonenberg_work>
in this case i think the concern would be if you continued to work on / use that code after coming back to the US
<daveshah>
but chances are the penalties for use would be less than those for publishing
<azonenberg_work>
I dont know if that would be a problem
<azonenberg_work>
You'd have to talk to a lawyer
<azonenberg_work>
daveshah: the question is if the code was pushed to github while he was outside the country
<azonenberg_work>
if the act of creating that code violated US law
<azonenberg_work>
can you be prosecuted?
<azonenberg_work>
Since it was outside their jurisdiction
<azonenberg_work>
and i dont know
<daveshah>
Is it different from going to e.g. a cannabis cafe in Amsterdam?
<azonenberg_work>
well...
<azonenberg_work>
If you returned to the US with cannabis still in your system you might be in violation of something
<azonenberg_work>
Which is closer to what is going on here
<daveshah>
I suppose so
<azonenberg_work>
i.e. the code is still out there
<azonenberg_work>
But the fun bit is, distributing the code would be legal
<daveshah>
Yes, for the sake of argument lets say it is left on a server in the EU only
<azonenberg_work>
Since its information, you aren't distributing xilinx copyrighted source
<azonenberg_work>
no you're missing the point
<azonenberg_work>
the code itself would (I think) not violate US law
<daveshah>
Yeap, it should be safe, so long as it doesn't count as a derivative work
<azonenberg_work>
its just a table of numbers that contain factual informatoin about the chip
<azonenberg_work>
Only the process by which those numbers are discovered is (potentially) illegal in the US
<azonenberg_work>
Decapping the chip and looking at vias, as I did with the 2c32a: undeniably legal
<azonenberg_work>
Fuzzing ISE: questionable
<azonenberg_work>
reading ISE data files: almost certainly illega
<daveshah>
This may be further complicated by the potential for it being civil rather than criminal
digshadow has quit [Quit: Leaving.]
<daveshah>
And the jurisdicition in the license (contract) being the US anyway
<daveshah>
AFAIK what keeps you safe in the EU is the fact you can't be extradited for civil matters
<azonenberg_work>
hmm, so if you use a xilinx product in the EU and violate some clause in the contract (as a EU citizen or US citizen)
<azonenberg_work>
then visit the US
<azonenberg_work>
can you be prosecuted?
<daveshah>
Obviously you couldn't have criminal action brought against you. But I think a civil case is possible
<azonenberg_work>
Hmm
<rqou>
maybe you can be MalwareTechBlogged
<daveshah>
I don't think it's so much being in the US changes things, as being in the US makes it enforceable
<azonenberg_work>
well thats the question though
<daveshah>
Even having assets in the US would be a problem, as they could be seized
<azonenberg_work>
Did the US court have jurisdiction if the original breach of contract occurred outside the US
<azonenberg_work>
and the clause of the contract was unenforceable under EU law?
<daveshah>
The contract would probably also have to be signed in the EU
<azonenberg_work>
Suppose its a clickwrap license on ISE
<azonenberg_work>
Is there a clause in there saying you agree to US court jurisdiction?
<azonenberg_work>
If so is such a clause enforceable under EU law?
<daveshah>
Clickwrap limitations may not apply in the EU to free software
<daveshah>
But if you bought ISE as a natural (not corporate) person in the EU you should be OK
<azonenberg_work>
Even if you later visited the US?
<daveshah>
happy to work on a proper schema if it will encourage its usage and not be too much work
<daveshah>
I was able to write a small python script to fix some attributes in literally 10 minutes with no hackery, which was very nice
<awygle>
a schema would make me happier
<awygle>
personally
<daveshah>
yeah, tbh the complicated part is the semantics rather than just what goes where, which a schema doesn't seem like a great way of describing. but I agree having one is useful if anyone wants to generate this stuff
<rqou>
the schema seems simple enough but some of the semantics are underspecified
<rqou>
e.g. can nets have no name? (xc2par says yes, idk about yosys)
<awygle>
i rode through the ZIA on a net with no name...
<rqou>
in general the "what if you did something wierd" behavior seems unspecified
<daveshah>
rqou: I allow it too, but Yosys doesn't AFAIK
<rqou>
xc2par has a policy of accepting basically anything
<kc8apf>
Re: Xilinx knowing about prjxray; one of the Xilinx programming interface designers follows me on Twitter and provides occasional background on odd parts of the design I mention on my blog.
<kc8apf>
He's fascinated to see his work documented
<daveshah>
one (documented) trap to beware of is that `port_directions` is not guaranteed to be included. including the aforementioned case of JSON directly coming from a BLIF
<daveshah>
kc8apf: interesting, it must be fun to be on the other side of that too
<daveshah>
of course, for ice40, 99% of the people involved will be long since dispersed
<daveshah>
can't imagine any are left at Lattice
<awygle>
yeah if i was a xilinx engineer i would be cheering for you folks
<daveshah>
rqou: there's no need if you know what the cells are anyway, as you would in a PAR tool
<daveshah>
But it's more of a problem for other tools
<eduardo__>
rqou: icestorm is a toy. Also Yosys is just a toy. We are all just a bunch of cracy nerds. I like it that way.
<eduardo__>
daveshah: Lattice knows about Trellis up to the CTO.
<daveshah>
eduardo__: oh, that's kind of awesome
<azonenberg_work>
eduardo__: and what does he think of it? can you say?
<eduardo__>
azonenberg_work: No I cant tell what he thinks now, but I was offered to have a meeting with to give him a demo. This meeting might take place end of Nov with some ECP5 HW in my hand.
<eduardo__>
currently Lattice does not have a real CEO, so they do care about other things.