ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
unixb0y has quit [Ping timeout: 252 seconds]
unixb0y has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
Bike has quit [Quit: Lost terminal]
Bob_Dole has joined ##openfpga
<Bob_Dole> I've been looking around for just what CPLDs are usable with a foss toolchain. So far greenpak4 is the only thing that looks viable, but I haven't found anything to really say much about how well or what models or if there's any missing features, excluding a line in the yosys manual that includes 3 parts for it.
<whitequark> Bob_Dole: there's a greenpak4 par manual
<whitequark> i have used it for a few small but real designs and it works very well
<whitequark> not perfect, but better than the weird schematic entry mode vendor tools use
<azonenberg_work> Bob_Dole: rqou has partial support for the xilinx coolrunner-2 parts as well
<azonenberg_work> the 32a is fully working
<azonenberg_work> the larger parts are blocked on legal issues - basically we know exactly how to support them
<azonenberg_work> but there is one bit of the routing fabric where support involves either illegally copying xilinx proprietary files, doing invasive silicon reverse engineering (what i did to support the 32a)
<azonenberg_work> or developing an as-yet-unknown black box technique to discover the same data from the silicon
<Bob_Dole> I saw the mention of being-in-the-eu is a workaround.. would passing off instructions to another party in the eu to make the bitstreams to send back for a person in the us to program be an option for that?
<sorear> afaik cpld vs fpga is almost entirely a marketing term in 2018
<azonenberg_work> Bob_Dole: tl;dr it may be legal to reverse engineer the data out of the xilinx toolchain in the EU
<azonenberg_work> whether it's legal for an american to use data learned from that process to write their own clean implementation is more questionable
<azonenberg_work> IANAL and don't want to take the risk of putting such code in my project
<azonenberg_work> Going with silicon RE was undeniably clean
azonenberg_work has quit [Read error: Connection reset by peer]
<Bob_Dole> and whitequark where's the greenpak4 manual? the main yosys one only having the SLG46140V, SLG46620V, and SLG46621V makes me uncertain about any other model such as the SLG46880
azonenberg_work has joined ##openfpga
<azonenberg_work> Back... Connection issues
<azonenberg_work> Re-posting in case it didn't go through
<azonenberg_work> (21:17:02) azonenberg_work: Bob_Dole: tl;dr it may be legal to reverse engineer the data out of the xilinx toolchain in the EU
<azonenberg_work> (21:17:24) azonenberg_work: whether it's legal for an american to use data learned from that process to write their own clean implementation is more questionable
<azonenberg_work> (21:17:50) azonenberg_work: Going with silicon RE was undeniably clean
<azonenberg_work> (21:17:31) azonenberg_work: IANAL and don't want to take the risk of putting such code in my project
<azonenberg_work> (21:20:43) azonenberg_work: Bob_Dole: in any case silego publishes greenpak docs so that's clean too
<azonenberg_work> (21:21:07) azonenberg_work: but i will accept PRs to support them
<azonenberg_work> (21:21:00) azonenberg_work: there are a handful of IP blocks that i don't yet support, and i have been way too busy to work on it
<azonenberg_work> (21:21:19) azonenberg_work: and the unsupported features are very clearly documented in the manual
<whitequark> azonenberg_work: can you link gp4par manual?
<rqou> azonenberg_work: i do have a proposed procedure for REing the interconnect without a SEM
<rqou> straight from hardware
<rqou> i've been trying to get diamondman to do it
<Bob_Dole> it had dropped everything after <azonenberg_work> Going with silicon RE was undeniably clean
<Bob_Dole> That's useful info
<azonenberg_work> Bob_Dole: yeah i was on a VPN for work that was (unintentionally) also vpn'ing my irc session due to a routing rule bug
<azonenberg_work> and that connection was flaky
<rqou> Bob_Dole: oh yeah, azonenberg_work is also really really good at docs so gp4par has a manual
<rqou> xc2par does not have a manual :P
<Bob_Dole> thank you. I'm not the actual dev of anything, I'm just.. manufacture-and-supply-chain, but am often (usually) tasked with finding documentation too.
<whitequark> that is a very important job.
<rqou> lol
<whitequark> i mean. supply chains win wars. regardless of what i think about wars that seems kinda important
<rqou> heh true enough
<azonenberg_work> rqou: i'm good at documenting things when i bother to doc them
<azonenberg_work> a lot of my tools i've been too busy coding on to write a manual
<azonenberg_work> i threw them on github because why not, but dont have the time to make it a fully publicly-usable project yet
azonenberg_work has quit [Ping timeout: 244 seconds]
azonenberg_work has joined ##openfpga
azonenberg_work has quit [Ping timeout: 268 seconds]
azonenberg_work has joined ##openfpga
rohitksingh has joined ##openfpga
parport0 has quit [Ping timeout: 268 seconds]
parport0 has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
s_frit has quit [Ping timeout: 272 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
<q3k> azonenberg_work: re twitter: are you labeling your cables per bundle?
<q3k> azonenberg_work: The Standard is generally to have a) uniquely identified dorp points, ie patch panels, and connectors therein b) label structural cables by the pp & port number they reach
<q3k> azonenberg_work: and then have the labels be "PP01/23 <----> PP02/12", on both ends of the cable, and every so often at an inspection point (the closer together the better, so that you can easily visually see where they all are without having to find the label for a particular cable)
<q3k> azonenberg_work: and yes, sleeved labels and not dangling labels, but you've already got that right
<q3k> azonenberg_work: and finally, have a spreadsheet or other inventory/dcm system to keep info about runs
<q3k> azonenberg_work: netbox is supposed to get structural cabling support at some point afair
<q3k> azonenberg_work: also you can nerd out even further on this https://en.wikipedia.org/wiki/Structured_cabling#Standards
s_frit has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
<TD-Linux> new theme of my digikey order
<cpresser> its not on all articels (Yet?)
<TD-Linux> it's "tariff pending" if they haven't had to order new stock yet
<q3k> TD-Linux: what are you trying to order, MLC capacitors? :P
<TD-Linux> glasgow has lots of values :O
<TD-Linux> er for resistors, not caps
<TD-Linux> total bom cost is $58
<TD-Linux> omg caps went out of stock between me creating the bom and adding to cart
rohitksingh has quit [Quit: Leaving.]
Bike has joined ##openfpga
<mithro> Well rapidwright is back
<mithro> I don't expect it to last long, still looks to have pretty serious licence issues
<daveshah> Oh neat
<daveshah> downloading the data I didn't get last time now
<daveshah> You're right about the license - a mix of GPL and closed source doesn't seem healthy at all
rohitksingh has joined ##openfpga
<q3k> huh
<mithro> RapidSmith which RapidWright is clearly a derivative work from was GPL too IIRC
<q3k> okay, this is pretty cool
<mithro> q3k: if it was licensed properly, it would be super cool I think
<daveshah> Yes, and the risk it may disappear at any minute makes it quite a difficult choice to base a project upon
<q3k> mithro: right
thomaav has quit [Ping timeout: 246 seconds]
tms_ has joined ##openfpga
<mithro> And the moment someone replaces the closed source stuff with open stuff, I bet you'll see issues
tms_ has left ##openfpga [##openfpga]
rohitksingh has quit [Quit: Leaving.]
azonenberg_work has quit [Read error: Connection reset by peer]
m_t has joined ##openfpga
azonenberg_work has joined ##openfpga
<azonenberg_work> q3k: so, my cable plant is a full star topology here
<azonenberg_work> So everything runs from the one switch rack to wall panels
<q3k> right, so label your PPs in the racks as PPxx/yy
<q3k> and your wall drops as DR/xx/yy
<q3k> * DRxx/yy
<q3k> or whatever you want :)
<azonenberg_work> So what I have right now is wall plates labeled Dxx
<azonenberg_work> (Individual cables in the bundle not labeled, though i probably should fix that on the next bundle)
<q3k> you absolutely should
<azonenberg_work> The other end is implied
<q3k> you should fix up the one you already laid, even
<azonenberg_work> yes i will
<q3k> and the implied end will also bite you in the arse
<q3k> been there done that the pain was not worth it
<azonenberg_work> Why? Every wall drop in the building will terminate at nominally one panel
<azonenberg_work> it may be more than 1U high
<q3k> because at some point you will accidentally tear a cable out
<q3k> and you won't remember where it was plugged in
<q3k> seriously, labels are cheap, use them
<q3k> s,plugged,patched,
<azonenberg_work> yeah i guess? my thought was that i'd just label each patch panel jack
<azonenberg_work> "D01/1, D01/2" etc
<q3k> or you will find a bunch of cables somewhere and you really won't like to have to look up the other side
<q3k> you can put that label on the PP itself
<q3k> ie where does it go to
<azonenberg_work> that was the idea
<q3k> but the cables imo should contain both ends
<azonenberg_work> Hmm, is that your preference or a standard?
<q3k> my preferences
<q3k> that i've also learned from a contractor that showed me The Light
<azonenberg_work> because my thought was that if you know everything goes from the one rack to $SOMEWHERE
<azonenberg_work> all you have to do is label $SOMEWHERE on the entire run
<q3k> (their l3/routing sucked, but they did the l2 structural cabling was fantastic)
<azonenberg_work> and that identifies the run uniquely and sufficiently
<q3k> azonenberg_work: you have one rack now
<q3k> azonenberg_work: you might get a second smaller telco rack later
<q3k> azonenberg_work: you might end up having to do a direct connection instead of a star
<azonenberg_work> i mean i do have endpoint racks for lab equipment
<azonenberg_work> but yeah cant hurt to fix that
<q3k> again, it's not like this wastes time or money to do - you're printing the labels alreayd, might as well do it properly
<azonenberg_work> What i'll probably do in this case is use printed "nice" labels for wrapping around bundles
<q3k> i don't see a sense in wrapping bundles with labels tbh
<q3k> managing them with velcro, sure
<q3k> but labeling a bundle? why?
<azonenberg_work> Then the cheap pre-printed cable wrap labels for single cables in a bundle
<azonenberg_work> All of my endpoints have four cables in them right now
<azonenberg_work> So the thought was, label "D01" on the bundle then 1/2/3/4 on the wires
<azonenberg_work> rather than having a sea of labels on wires you'd have a 2-level hierarchy of naming
<q3k> i really don't like this idea - if at any point you'll have to add/remove/change the cabling it'll be a pain to relabel the entire bundle
<q3k> i do see structural cabling as a sea, though. it's unstructured by design.
<q3k> as in, unhierarchized :)
<azonenberg_work> Hmm, i guess you do have a point if i damage one wire
<q3k> your hierarchy comes from their use, which might change
<q3k> cables don't care, cables go point from point A to point B
<azonenberg_work> But the way the runs are done (tray for home-run then into conduit)
<azonenberg_work> the bundle ID describes which conduit it goes to
<azonenberg_work> Which will not change
<azonenberg_work> What i do with the cable may change, where it goes won't
<q3k> your call
<q3k> i'm reserving the right to 'i told you so' though
<azonenberg_work> Lol
<azonenberg_work> As far as sleeved labels go
<azonenberg_work> how would you do that on a cat5e for a longer label?
<azonenberg_work> go the other direction?
<q3k> hm?
<azonenberg_work> i can barely fit one number around a wire if i wrap around the circumference
<q3k> oh
<q3k> get wider labels?
<azonenberg_work> are you thinking of having text read lengthwise?
<q3k> wait, what sort of labels are you using
<azonenberg_work> Label maker
<q3k> yeah that doesn't answer my question though
<azonenberg_work> I can make them as long as i want, height is fixed at about 12 mm
<azonenberg_work> variable font size with 1-2 rows
<q3k> they have a printed and a transparent part
<q3k> and you can select an arbitrary width
<q3k> any other kind of label will come off
<q3k> especially standard labels wrapped around :/
<q3k> even worse is having them stick away from the cable
<cpresser> i put clear heat-shrink tube around 'regular' labeles
<q3k> cpresser: right, but for that you have to be able to put on heat-shrink tubing
<q3k> cpresser: so you have to drag that from the end of the cable
<azonenberg_work> ooh shiny
<azonenberg_work> and yeah that wont work with preterminated fiber
<q3k> cpresser: and you also can't do that if you have fibre with already welded jacks / plugs
<azonenberg_work> all my multimode will have LCs on it from the factory
<q3k> not welded, what's the english word for doing that thing to fibre
<q3k> spiced.
<q3k> *spliced
<azonenberg_work> Also, gotta run - but good ideas and i will definitely be tweaking some things tonihgt
<q3k> (for some reason you call that 'welding fibre' in polish)
azonenberg_work has quit [Ping timeout: 252 seconds]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
emeb has joined ##openfpga
<gruetzkopf> no trouble doing it to lc-preterminated fiber
<gruetzkopf> e2000 too
<gruetzkopf> SC i can see, ESCON definitly not
rohitksingh has joined ##openfpga
m_t has quit [Read error: Connection reset by peer]
rohitksingh has quit [Quit: Leaving.]
<pie_> is there some way to get more than 10 results from firefox's % tab search?
<q3k> pie_: look in the source code? ^^
<pie_> :p >_>
<emeb> what could be simpler?
<pie_> ...my monitor keeps bringing up the osd menu
<pie_> the brightness/up button seems to be stuck or something
<pie_> worked perfectly fine yesterday and i didnt press anything >:I
<jn__> just patch the firmware :P
<pie_> can radio signals push buttons? :P
<pie_> TAL, i dont know how i'd check, if you mean the computer is doing something
<pie_> besides reboot x)
<pie_> (unrelated: lol sigh cringe of the day https://twitter.com/JordanUhl/status/1046085009319317504 )
Bike has quit [Ping timeout: 272 seconds]
<pie_> "Two bits per transistor: high-density ROM in Intel's 8087 floating point chip "
* pie_ takes a poke at MHRD
X-Scale has quit [Ping timeout: 252 seconds]
<fseidel> MHRD was kind of a letdown
<fseidel> it ended before you build any really interesting circuits
<fseidel> and the syntax was pretty strange
<pie_> oh yeah? :c
<pie_> my main annoyance so far is i dont remember how to optimize boolean logic and im too lazy to look it up
<pie_> the other is that you have to add the type of every item you instantiate intead of being able to instantiate more than one thing per type :p
* pie_ hasnt actually written real HDL yet
X-Scale has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
<fseidel> pie_: yeah, that last thing was my biggest gripe
<fseidel> but if you've never written in a real HDL, it's probably not a bad start
<fseidel> it'll make verilog feel that much better :-)
<pie_> apparently today is "lol sigh cringe" day
<awygle> "how to optimize boolean logic" - write it in verilog, feed it to yosys
<awygle> well, abc really
<pie_> yeah ill probably keep forgetting that every time until someone reminds me here
<pie_> for azonenberg when he's back, whitequark https://pbs.twimg.com/media/DkBc-lCX0AEQ1k1.jpg
<pie_> now its time for me to get off twitter
<whitequark> pie_: incredible
<cr1901_modern> whitequark: wasn't your apartment wired by someone who made a pact w/ the underworld?
<pie_> cr1901_modern, thats basically my main reason for sharing such things
<whitequark> cr1901_modern: well no
<whitequark> "terminally incompetent" si more like it
Bike has joined ##openfpga
oeuf is now known as egg|zzz|egg
egg|zzz|egg is now known as oeuf
ym has quit [Quit: Leaving]
oeuf is now known as xn--uf-dsa
xn--uf-dsa is now known as oeuf
azonenberg_work has joined ##openfpga
azonenberg_work has quit [Ping timeout: 268 seconds]