azonenberg_hk has quit [Ping timeout: 260 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
azonenberg_hk has joined ##openfpga
<rqou>
whee, housemates set off the smoke detector in the apartment
<azonenberg_hk>
rqou: Lol
<azonenberg_hk>
There was one dorm back at RPI that was infamous for fire alarms
<rqou>
not an electrical fire though :P
<azonenberg_hk>
it was a private apt complex the school bought and renovated into student apartments
<azonenberg_hk>
With full kitchens and everything
<rqou>
housemates were baking bread and the light coating of flour burned
<azonenberg_hk>
If you put ultra-sensitive smoke detectors in a dorm full of 19-year-olds
<azonenberg_hk>
Who have never lived alone or cooked for themselves before
<rqou>
then end up with their batteries removed?
<rqou>
:P
<azonenberg_hk>
the results are... predictable
<azonenberg_hk>
No, they were hard wired
lain has joined ##openfpga
<azonenberg_hk>
and behind tamper enclosures
<rqou>
oh wow
<azonenberg_hk>
They had a running tally of how many times the building got evac'd in a semester
<azonenberg_hk>
it was often well over 30
<qu1j0t3>
:/
<rqou>
digshadow digshadow-s: I want to add some stuff to the p8x32a page on siliconpr0n and azonenberg_hk said to bug you for an account
<rqou>
azonenberg_hk: i'm surprised nobody duct-taped over the holes for the smoke detector
<rqou>
i remember hearing a story at one point where some students here at UCB were soldering in the dorms
<rqou>
they were blowing the smoke out the window
<rqou>
they didn't set off any fire alarms
<rqou>
instead one of the RAs was walking by, noticed a funny smell, and then asked them what the heck they were smoking :P
<azonenberg_hk>
lol
<azonenberg_hk>
"Rosin... want a hit?:
<azonenberg_hk>
"
<pie_>
azonenberg_hk, so about once every three days statistically?
<qu1j0t3>
pie_: this isn't on the exam you fool!
<azonenberg_hk>
pie_: something like that, lol
<pie_>
qu1j0t3, shit lol
<azonenberg_hk>
maybe even more than that
<pie_>
azonenberg_hk, well the well over 30 would imply that
<whitequark>
i've recently built a very simple fume extractor
<azonenberg_hk>
Yeah
<rqou>
my high school had huge problems with people prank-pulling the fire alarm
<whitequark>
just bought the cheapest fan in a home improvement shop and added some ducting
<rqou>
the record was three prank pulls in one day
<whitequark>
it is *absolutely astounding* how much of an improvement that is
<azonenberg_hk>
whitequark: Yeah i did basically that for my old fume hood
<azonenberg_hk>
it wasnt perfect but way better than nothing
<whitequark>
for soldering, hot air rework, especially grinding with a dremel
<whitequark>
all the nasty dust just disappears into ducting
<azonenberg_hk>
Yeah i need to set up a local exhaust at my soldering bench
<whitequark>
haven't tried HNO3 yet but expect that to also provide great relief
<azonenberg_hk>
i have a silly carbon filter with a tiny fan
<azonenberg_hk>
But it isnt much use
<whitequark>
the ducting and the fan will corrode
<azonenberg_hk>
i need something with some decent RPMs
<whitequark>
but at $15 per the entire thing
<azonenberg_hk>
actually
<whitequark>
I don't care
<rqou>
rumors claimed that the high school administration got so tired of prank pulls that they started adding a uv dye to the fire alarm pull
<azonenberg_hk>
i had a galvanized metal duct fan
<azonenberg_hk>
years of decapping never caused visible corrosion
<azonenberg_hk>
only problem i had was mold growing in the ducts from all the water vapor condensing in there
<whitequark>
the one I have is aluminium that is *I think* covered with polyester film
<whitequark>
it doesn't seem like bare Al
<whitequark>
rqou: that is definitely a thing
<whitequark>
what about gloves tho
<whitequark>
I never understood how it's supposed to work
<whitequark>
just deter really stupid pranksters?
<rqou>
i guess?
<pie_>
whitequark, is thre somehting you could paint on it?
<rqou>
it got so bad that they actually missed an actual fire
<whitequark>
pie_: on what?
<whitequark>
rqou: lol
<azonenberg_hk>
whitequark: i think the idea is more to catch the guy after the fact
<azonenberg_hk>
jsut go down a list of students with a uv lamp
<azonenberg_hk>
see whose hands are glowing
<whitequark>
azonenberg_hk: yeah I mean
<whitequark>
gloves
<whitequark>
gloves man
<rqou>
one day the motor in a fume hood shorted out and started billowing smoke out the fume hood
<rqou>
somehow the smoke detector and fire alarm pull didn't work
<pie_>
whitequark, the metal stuff so it doesnt corrode
<whitequark>
rqou: good thing that happened in a fume hood
<whitequark>
oh wait
<pie_>
but re:15$ i guess its not worth it
<whitequark>
pie_: exactly
<rqou>
this was in one of the "permanent portable" extra classrooms
<rqou>
so the teacher sent a student to pull the fire alarm pull in the main building
<whitequark>
the ducting costs nothing, the fan costs most of it
<rqou>
the student who did so didn't stick around the fire alarm pull
<rqou>
in the meantime the teacher forgot to call the internal emergency phone number
<rqou>
so the administration/fire department look at the pulled fire alarm pull and see nothing
<rqou>
assume it is a prank
<rqou>
and send the fire department away
<whitequark>
what about calling the admin
<qu1j0t3>
x_o
<whitequark>
oh
<whitequark>
forgot
<whitequark>
sigh
<azonenberg_hk>
rqou: lool
<rqou>
the teacher at this point realizes that she forgot to call the internal emergency number
<rqou>
she does so
<rqou>
administration tries to trigger the fire alarm again
<rqou>
somehow can't trigger it (due the the previous reset?)
<azonenberg_hk>
lol
<rqou>
makes an announcement to evacuate over the normal PA
<rqou>
and calls the fire department back
<rqou>
i assume the fire inspector gave them a huge fine afterwards
<whitequark>
wtf
<whitequark>
why does TCP/IP have reassembly BOTH at the TCP layer AND on the IP layer
<qu1j0t3>
that was depressing
<azonenberg_hk>
whitequark: This is one of the reasons i consider IP fragmentation deprecated
<azonenberg_hk>
and don't use it
<whitequark>
azonenberg_hk: can I just do that
<whitequark>
do things work?
<azonenberg_hk>
whitequark: So, with IPv6
<azonenberg_hk>
frag is done by endpoints and not routers
<whitequark>
if my stack just blanket replies "fuck off" to packets that are fragmented from the net
<whitequark>
and to the as?
<azonenberg_hk>
So if the endpoint doesnt frag you're good
<whitequark>
apps*
<azonenberg_hk>
With IPv4, frag is done by intermediate routers
<whitequark>
right I know that
<azonenberg_hk>
In both cases, it's typically done in response to either an ICMP pakcet-too-large message or a router hitting a package >MTU
<whitequark>
but nothing beyond it
<azonenberg_hk>
So as long as you never send packets bigger than the MTU
<azonenberg_hk>
you never need IP-layer frag
<azonenberg_hk>
if i dont already, i probably will soon block frags at my firewall
<azonenberg_hk>
Most apps set the ipv4 DF bit anyway
<azonenberg_hk>
its almost never used
<whitequark>
ok so with TCP I understand what happens if I accidentally exceed MTU somewhere in the path
<whitequark>
what about UDP?
<azonenberg_hk>
i've never tried sending a >1500 byte UDP packet, it does not do reassembly so my guess is the datagram gets dropped if you specify dont-fragment in the headers
<azonenberg_hk>
In any case
<azonenberg_hk>
if you have an IPv4 packet with DF set
<azonenberg_hk>
and its bigger than the MTU
<azonenberg_hk>
the router drops it
<azonenberg_hk>
and i think replies with an ICMP message
<azonenberg_hk>
None of the embedded stacks i've worked with have ever supported frag for v4 or v6
<azonenberg_hk>
and silently dropped anything marked as a frag
<azonenberg_hk>
And i've never had problems
<azonenberg_hk>
its not technically RFC compliant i think, but it never was an issue
<whitequark>
ok
<whitequark>
good to know
<rqou>
i've accidentally used ip-level frag before
<rqou>
most things seem to work ok
<whitequark>
"Applications relying upon IPv6 fragmentation to overcome a path MTU limitation must explicitly fragment the datagram at the point of origin; however, they should not attempt to send fragmented datagrams with a total size larger than 1500 bytes unless they know in advance that the remote host is capable of reassembly."
<whitequark>
hrm
<whitequark>
also why are there so many goddamn checksums
<whitequark>
ethernet checksum
<whitequark>
ip checksum
<whitequark>
tc checksum
<azonenberg_hk>
whitequark: lol
<azonenberg_hk>
well first off
<azonenberg_hk>
the IP checksum is headers only, not packet content
<azonenberg_hk>
and TCP can run over link layers other than 802.3
<azonenberg_hk>
There's no requirement that the link layer have a CRC
<whitequark>
fair enough
<azonenberg_hk>
UDP also has an optional checksum
<azonenberg_hk>
in ipv4 (mandated in v6)
<azonenberg_hk>
If you want absolute lowest latency in packet processing, udp over ipv4 over 802.3 is the way to go
<azonenberg_hk>
the IP headers can be pre-baked and have a static checksum
<rqou>
heh, my father had a great story about these checksums
<azonenberg_hk>
UDP checksum can be left blank
<lain>
UDP stands for U Drop Packets
<azonenberg_hk>
Then you can send the packet out on the wire and compute the checksum live
<azonenberg_hk>
then append the ethernet CRC at the end
<rqou>
the network equipment company he used to work for made all sorts of products that tunneled ethernet over <whatever you like>
<azonenberg_hk>
I REALLY wish that the designers of tcp/ip put the packet checksum at the end of the segment
<lain>
ethernet over mashed potatoes
<azonenberg_hk>
So you could send the frame and hash as you go, then send the crc
<rqou>
there was a case where some engineer noticed that one of the outer checksums was always a constant value
<rqou>
he assumed that the code was broken
<rqou>
but it wasn't
<azonenberg_hk>
as it stands you have to compute and buffer the entire packet and THEN calculate the checksum and send
<rqou>
two of the layers had crc checksums using the same polynomial
<whitequark>
...lol
<whitequark>
amazing
<azonenberg_hk>
Lol
<whitequark>
"Receiving hosts must make a best-effort attempt to reassemble fragmented IP datagrams that, after reassembly, contain up to 1500 bytes."
<whitequark>
about IPv6
<whitequark>
it says "best-effort"
<whitequark>
does that include "my best effort is not enough to care"
<whitequark>
is that compliant?
<pie_>
everything is best effort honstly
<whitequark>
for IPv4 you supposedly have to reassemble up to 576 bytes
<whitequark>
but thats irrelevant because no way in hell there is an MTU that low anywhere in today's internet
<azonenberg_hk>
Yeah
<rqou>
yeah there is, broken comcast dhcp :P
<azonenberg_hk>
i consider 1492 a reasonable MTU
<whitequark>
right
<azonenberg_hk>
That's enough for 1500 minus PPPoE headers for ADSL
<whitequark>
there's 6lowpan and other weird stuff
<whitequark>
but I think they don't fragment either
<azonenberg_hk>
Yeah
<lain>
firewalls can also be fucky about reassembly
<azonenberg_hk>
whitequark: In my projects i freely ignore features like that that nobody uses
<azonenberg_hk>
Same reason i currently do not support any ethernet speeds but gig/full :p
<whitequark>
azonenberg_hk: I want to make an "ahem" best-effort to follow the standards
<azonenberg_hk>
I plan to support 10/100 eventually, but have never been bothered to code up the CRC calculation for the different data width
<azonenberg_hk>
half duplex i consider deprecated
<rqou>
10/half?
<azonenberg_hk>
and do not intend to ever support
<whitequark>
right now it seems like I can *nearly* get to full compliance
<whitequark>
because fragmentation has so few actual requirements
<whitequark>
and given that I consider IPv4 deprecated anyway
<whitequark>
this is becoming less relevant
<azonenberg_hk>
yes, same here
<rqou>
when i was interning at broadcom i was told that some crazy customers used broadcom switches in 10/half mode
<whitequark>
I think NIST still has IPv4 so I can't drop that at all
<rqou>
they regularly caused sdk bugs :P
<azonenberg_hk>
in the next few months i plan to move my LAN to IPv6 single stack
<azonenberg_hk>
and only keep v4 on subnets that have legacy hardware with no v6 support, or subnets that talk to the internet
<azonenberg_hk>
(since there's so many v4-only endpoints out there)
<rqou>
apparently most of these products were of the form of "funnel 24/48 ancient devices into one fat pipe"
<azonenberg_hk>
rqou: on that note i wish usb 3.0 had TTs in hubs like 2.0 does
<rqou>
idk what a TT is
<rqou>
never looked at how hubs work
<azonenberg_hk>
Transaction Translator
<azonenberg_hk>
USB 2.0 allows you to connect many low/full speed devices to a high-speed hub and share the 480 Mbps of upstream bandwidth
<azonenberg_hk>
like, you can have a mouse and keyboard each at 12 Mbps but they don't share the same 12 Mbps of bandwidth
<azonenberg_hk>
they share 480 upstream from the hub
<rqou>
how does 3.0 do it?
<azonenberg_hk>
3.0 is essentially a fully separate protocol alongside 2.0
<rqou>
i thought 3.0 could get 5480 mbps?
<azonenberg_hk>
The cables have two sets of wires
<rqou>
as in they're totally separate
<azonenberg_hk>
So a super-speed device uses the 5 Gbps link
<azonenberg_hk>
But if you plug a high-speed device in, it uses the 480 Mbps link
<rqou>
ah i see
<azonenberg_hk>
And if you hav emultiple high-speed devices in a usb 3 hub
<azonenberg_hk>
they share the 480 Mbps upstream b/w
<rqou>
so does a 3.0 device work without the high-speed wires?
<azonenberg_hk>
so you cannot have, say, ten 480 Mbps webcams on one usb 3.0 hub sharing 5 Gbps upstream bandwidth
<rqou>
oh
<rqou>
yeah that kinda sucks
<azonenberg_hk>
Which seems like a common enouhg use case it'd be supportd
<azonenberg_hk>
But its not
<azonenberg_hk>
they will work, but at 480 Mbps aggregate b/w
<azonenberg_hk>
and i believe that you can make a functional, if not spec-compliant, super-speed-only device without the high-speed wires
<azonenberg_hk>
but i dont know usb at that level
<azonenberg_hk>
i'm a lot more familiar with TCP/IP and 802.3
<rqou>
i believe it should be possible too, but i also haven't looked in detail
<azonenberg_hk>
like, i've implemented most of 10baseT in verilog on a greenpak :p
<rqou>
how much do you know about usb3 physical signaling btw?
<azonenberg_hk>
I've done 1000baseX autonegotiation on an artix
<azonenberg_hk>
other than that its high speed differential, and the link layer is effectively PCie
<azonenberg_hk>
not much
<rqou>
are the 7-series transceivers compatible with usb3?
<azonenberg_hk>
I believe so but have not tested
<rqou>
why do people keep putting the silly ti PIPE phy on boards?
<azonenberg_hk>
marshallh was able to do usb3 on an equivalent altera part's transceivers
<cr1901>
the link layer of USB3 is effectively PCIe?
<rqou>
including the weird low frequency signaling thing?
<azonenberg_hk>
rqou: maybe for 2.0 support? 2.0 PHY needs some special stuff i think
<rqou>
yeah sure
<azonenberg_hk>
also, there is some signaling on the vbus line for usb-c
<azonenberg_hk>
that is probably not doable in fpga
<rqou>
but you should be able to use the gigabit transceivers with a ULPI 2.0 phy
<azonenberg_hk>
Correct
<azonenberg_hk>
and just not get the low-speed channel for usb-c
<rqou>
and that uses much fewer wires
<azonenberg_hk>
Or use an asic for that
<azonenberg_hk>
Yes
<azonenberg_hk>
i dont know why that isnt done
<azonenberg_hk>
i just know that it's PIPE
<azonenberg_hk>
and PCIe is PIPE
<azonenberg_hk>
And fpgas can do PCIe
<rqou>
also, iirc the ti PIPE phy has a separate ulpi link for the 2.0 part
<azonenberg_hk>
interesting
<azonenberg_hk>
whitequark: i also need to get back to my ethernet switch project one day lol
<azonenberg_hk>
So many things on my plate
<rqou>
also, the ti PIPE phy has various register values labeled as "reserved" where in the PIPE spec they correspond to sata/pcie modes
<rqou>
if someone wants to poke that at some point :P
<azonenberg_hk>
lol
<cr1901>
What is PIPE?
<rqou>
PHY Interface for PCI Express
<rqou>
(and SATA, and USB3)
<azonenberg_hk>
also wait, sata is pipe too?
<azonenberg_hk>
interesting
<azonenberg_hk>
I did not know that
<azonenberg_hk>
i looked at the sata link layer a while ago and i recalled it being different
<rqou>
here's the datasheet for the ti part i'm talking about
<cr1901>
I don't even know what consitutes the link layer tbh. "Is it the logical repr of ones and zeros"? I know UARTs implement link-layer
<azonenberg_hk>
whitequark: lol
<azonenberg_hk>
cr1901: i'd consider that to be a physical layer honestly
<azonenberg_hk>
translating voltages into bytes
<azonenberg_hk>
Link layer would be something like HDLC
<whitequark>
azonenberg_hk: I think the only two options that are useful/used at all is MTUP/MTUR
<rqou>
whitequark: it's a cisco protocol, what did you expect? :P :P
<rqou>
what about the NOP option?
<rqou>
will you support that?
<whitequark>
rqou: sure, I will do nothing
<cr1901>
I'm having trouble visualizing how USB and PCIe can be link-layer compatible then. Clearly, sending a PCIe payload down a USB line isn't going to work :P.
<rqou>
no, they're only (somewhat) physical layer compatible
<whitequark>
all of the Jon_Postel ones are deprecated, all of RC1108 ones are deprecated
<whitequark>
so uhhhhh
<cr1901>
(08:35:36 PM) azonenberg_hk: other than that its high speed differential, and the link layer is effectively PCie
<whitequark>
yeah that just leaves quick-start and pmtu discovery
<whitequark>
none of which are very important
<whitequark>
and can be freely ignored
<azonenberg_hk>
nice
<cr1901>
I should prob learn how Ethernet works, but FPGA Ethernet projects are so tired that I'm not motivated to do one.
<whitequark>
"Unfortunately, the Datagram Too Big message, as currently specified, does not report the MTU of the hop for which the rejected datagram was too big, so the source host cannot tell exactly how much to reduce its assumed PMTU.
<whitequark>
oh my god who designed this
<whitequark>
"
<azonenberg_hk>
loool
<azonenberg_hk>
cr1901: build a switch
<azonenberg_hk>
i havent seen any of those yet
<azonenberg_hk>
Also, even if it's not new and cool
<cr1901>
azonenberg_hk: Sure, want to send me a number of PHY breakout boards :)?
<azonenberg_hk>
its extremely educational
<azonenberg_hk>
you'll learn networking way better
<rqou>
cr1901: pull an azonenberg_hk and do optical-only :P
<cr1901>
Since FPGA's shouldn't try to drive the transformers directly?
<azonenberg_hk>
in all seriousness
<azonenberg_hk>
you can drive a SFP with a GTP and 3.3V power supply
<azonenberg_hk>
and optional I2C for discovery
<cr1901>
SFP? (ETOOMANYACRONYMS)
<azonenberg_hk>
small form-factor pluggable
<rqou>
<troll>you definitely need I2C</troll>
<azonenberg_hk>
it's basically a socketed laser and photodiode
<rqou>
how else will you blacklist finisar generic optics?
<whitequark>
lol
<azonenberg_hk>
rqou: half my collection is those
<azonenberg_hk>
:P
<cr1901>
is that what rqou meant by optical?
<azonenberg_hk>
cr1901: So that you can build a generic NIC/switch
<azonenberg_hk>
and interface to different kinds of fiber optics without respinning the board
<azonenberg_hk>
you just remove one module and put in another
<azonenberg_hk>
most fiber switches just come with empty sockets and you supply the correct optic for the wavelength you want to use
<rqou>
it's actually pretty ridiculous how cheap finisar generic optics are vs real cisco/hp ones
<rqou>
i found seller somewhere that had a pricing scheme like this
<azonenberg_hk>
The two most common are ~800 nm lasers over multimode fiber, good out to a few hundred meters
<azonenberg_hk>
and ~1500 nm over single-mode, good out to kilometers
<azonenberg_hk>
or more with repeaters
<cr1901>
I don't have any fiber optic cables... just twisted pair CAT5 stuff
<cr1901>
(08:51:56 PM) rqou: cr1901: pull an azonenberg_hk and do optical-only :P <--- what did you mean?
<azonenberg_hk>
I can get cheap surplus 1g sfps for $20 per 25
<azonenberg_hk>
cr1901: as in no copper PHYs/RJ45s
<azonenberg_hk>
fiber exclusively
<rqou>
oh i was looking at a dual 1g/10g optic
<rqou>
iirc it was $20 for a generic
<azonenberg_hk>
rqou: Yeah 10g is significantly more
<whitequark>
azonenberg_hk: how low can I run an 1g sfp
<azonenberg_hk>
whitequark: speed wise?
<whitequark>
100? 10? 1? 100k?
<azonenberg_hk>
Thats a good question, they're not specified any lower
<whitequark>
uart over sfp?
<azonenberg_hk>
they are AC coupled
<azonenberg_hk>
and the cap is on-module
<azonenberg_hk>
So that will be your limiting factor
<azonenberg_hk>
i'd say probably 10-100M is likely the limit
<azonenberg_hk>
1M maaaybe
<rqou>
i thought the optics AGC also behaves like ac coupling?
<azonenberg_hk>
rqou: on the rx side, possibly?
<azonenberg_hk>
i havent looked into it
<azonenberg_hk>
i know i was able to run 4G fibre channel optics at 1Gbps no problem
<azonenberg_hk>
no observable increase in BER
<rqou>
why do dual-mode 1g/10g optics have a "speed" pin?
<cr1901>
"and the cap is on-module" Meaning you can't change out the cap to reduce the high pass effect, huh :/
<azonenberg_hk>
probably LPFs at 1G mode
<azonenberg_hk>
to reduce noise
<azonenberg_hk>
cr1901: correct
<azonenberg_hk>
They're not meant for low pseed
<azonenberg_hk>
also
<azonenberg_hk>
can somebody help parse this for me?
<azonenberg_hk>
Buffer bandwidth: Set the maximum frequency that can pass through the input buffer on ‘Buffered PIN6’. Selecting frequencies 5kHz, 20kHz or 50kHz makes current consumption increase significantly. Use ONLY with VDD greater than 2.7V.
<azonenberg_hk>
While the Buffer Bandwidth parameter is applied to all ACMPs, the effect is only applied on input ‘Buffered PIN6’. • 1kHz, 5kHz, 20kHz and 50kHz: The current consumption increases significantly at higher bandwidths.
<azonenberg_hk>
so the parameter is applied everywhere but the effect is only applied to the buffered pin6? how does this work?
<azonenberg_hk>
my interpretation is that you're band-limiting the buffer itself, and unbuffered inputs are unaffected
<cr1901>
My interpretation is that only PN6 has the current increase
<whitequark>
my interpretation is that all ACMPs have configuration bits for that
<azonenberg_hk>
No
<whitequark>
ok
<azonenberg_hk>
there is one set of config bits
<azonenberg_hk>
i have to figure out the semantics of it
<azonenberg_hk>
SLG4662x 837:836
<azonenberg_hk>
I think this should be an attribute of GP_ABUF
<azonenberg_hk>
and only applies to the output of the ABUF
<azonenberg_hk>
Also, i think we are going to want to start doing DRC checks in gp4prog
<azonenberg_hk>
since certain options are not available when Vdd <= 2.7V
<azonenberg_hk>
we should complain if you do --emulate --voltage 2.5 or something
<cr1901>
Oh right. I should prob get a GP programmer for Christmas. And a skillet.
<cr1901>
To cook- err, reflow some breakout boards
lain has quit [Quit: WeeChat 1.6]
azonenberg_hk has quit [Ping timeout: 260 seconds]
azonenberg_hk has joined ##openfpga
<rqou>
azonenberg_hk: do you know what is special about dual speed 1g/10g sfps such that they aren't guaranteed to work in 1g-only equipment?
<azonenberg_hk>
No
lain has joined ##openfpga
<azonenberg_hk>
My guess is, the bandwidth-limit pin might not be pulled the right way
<azonenberg_hk>
and you might end up having high speed noise not being filtered out
<azonenberg_hk>
But i dont see this being a serious problem when 1g sfp's are so much cheaper
<azonenberg_hk>
when they're <$1 a pop it makes no sense to not buy a truckload of them
<rqou>
sure
<rqou>
although i basically don't have anything that is 1g optical
<azonenberg_hk>
I have a bunch of cisco 2970G's
<azonenberg_hk>
and i plan to make a 1g-only switch soonish
<cr1901>
azonenberg_hk: I take it you're not a firm believer in Just-In-Time inventory :P
<azonenberg_hk>
1g optical-only*
<rqou>
btw am i correct in reading that direct attach is only defined for 10g?
<azonenberg_hk>
Because 1g sfps are cheaper than 1g PHYs
<azonenberg_hk>
less pcb design work too
<azonenberg_hk>
so i plan to make some of my future projects optical-only
<azonenberg_hk>
as long as you have a switch to interface to, that is
<azonenberg_hk>
So i need to build a custom 1U switch
<azonenberg_hk>
Probably 12 1g optics, one 10g optic, and 12-24 1g copper interfaces
<rqou>
heh, my switch (still not set up after months :P ) is copper only for 1g
<azonenberg_hk>
my 2970Gs are 24 tri-speed copper plus four 1g-only sfp
<azonenberg_hk>
but EOL'd
<azonenberg_hk>
i want to replace them with something that doesn't have EOL software in the forwarding path
<azonenberg_hk>
for security reasons
<azonenberg_hk>
and might as well use that as an excuse to beta my switch core in a semi-production network
<azonenberg_hk>
cr1901: Lol, no
<azonenberg_hk>
i live on an island in earthquake country :P
<azonenberg_hk>
that kinda changes your mindset a bit :P
<cr1901>
I am space constrained. JIT is essentially the only way.
<rqou>
i still need to poke at the firmware of my switch
<azonenberg_hk>
also, i pipeline my projects
<azonenberg_hk>
to cut costs and use slow lead time on everything
<rqou>
a quanta lb4m
<rqou>
old (EOL ?) broacom chipset
<azonenberg_hk>
whitequark: btw i think that may be my next project
<rqou>
48-port 1gbaseT and 2-port 10g sfp+
<azonenberg_hk>
if pcbhdl works out well on the ethernet-jtag etc device
<azonenberg_hk>
i think my next project will be an xc7a200t-1ffg1156 based switch
<rqou>
azonenberg_hk: btw does optical not have auto negotiation?
<whitequark>
ack
<azonenberg_hk>
implement that in pcbhdl
<azonenberg_hk>
rqou: 1g optical has minimal autoneg but it doesnt really do much
<azonenberg_hk>
it seems kinda there because nobody thought to remove it :P
<rqou>
it can't detect 10g/1g?
<azonenberg_hk>
10g does not have any
<rqou>
ah ok
<azonenberg_hk>
Correct
<azonenberg_hk>
They are different line codes so not really possible
<azonenberg_hk>
the autoneg is done after the 8b10b syncs
<azonenberg_hk>
but 10g is not 8b10b
<azonenberg_hk>
i mean i guess you could hack it
<azonenberg_hk>
try to link up with one
<rqou>
a while back i was screwing around connecting my x520 to my housemate's meraki switch which has 2 1g optical ports
<azonenberg_hk>
if no link, wait a pseudorandom time and try again
<azonenberg_hk>
with the opposite speed
<rqou>
x520 is a dual rate card
<rqou>
but somehow i needed to use ethtool to change the eeprom
<azonenberg_hk>
lol
<rqou>
the normal "set rate" command didn't work
<rqou>
fortunately intel actually documents how the eeprom works
<rqou>
while screwing around i discovered that the meraki switch accepts direct attach cables on 1g
<rqou>
not sure if it's technically supposed to or not
<azonenberg_hk>
I mean physically there is no reason not to
<azonenberg_hk>
its just two GTPs coupled with a crossover and some coupling caps
<rqou>
the spec doesn't say it should :P
<azonenberg_hk>
doesnt care about the b/w
<azonenberg_hk>
i think it's more, there was not a need at 1g
<azonenberg_hk>
because 1g baseT was commodity already
<azonenberg_hk>
10g baseT is not, even now
<rqou>
also, i thought that meraki would have a module whitelist
<azonenberg_hk>
its kind of a niche because most 10g is optical
<rqou>
i'm assuming that even if it did have a whitelist all DA cables got whitelisted on the 10g products and this exception got carried over
<azonenberg_hk>
also, any idea how hard it would be to implement a 10g PCIe NIC from scratch?
<azonenberg_hk>
i feel like it could be a fun educational project to learn more about pcie
<rqou>
i thought being efficient is hard?
<azonenberg_hk>
and linux kernel drivers
<azonenberg_hk>
but it could also be a massive nightmare to do right
<azonenberg_hk>
It would also be awesome to have a custom NIC talking to a custom switch
<azonenberg_hk>
lol
<rqou>
awesome until you have a heisenbug :P
<azonenberg_hk>
Lol
<azonenberg_hk>
hey, i am not opposed to jtagging my NIC to debug it :p
<azonenberg_hk>
because i want a lot of optical ports
<azonenberg_hk>
let me see...
* azonenberg_hk
thinks
<azonenberg_hk>
what pcie do i have available on an artix...
<azonenberg_hk>
artix7 can go up to pcie 2.0 x8
<azonenberg_hk>
Which is 4 GB/s or 32 Gbps throughput
<azonenberg_hk>
that's easily enough to support two 10g lanes
<azonenberg_hk>
although it could not run both at full speed in both directions
<azonenberg_hk>
or no wait
<azonenberg_hk>
thats 32 Gbps each way
<azonenberg_hk>
so that's plenty for 2x 10g each way
<azonenberg_hk>
I'd even have enough b/w left over to put a few copper interfaces down or something
<azonenberg_hk>
but a custom switch is higher priority right now as i need the switch IP core for other applications and this would let me test it
<rqou>
btw is the TLk10031 the correct type of part to connect an Artix <10g transceiver to a SFP+?
<azonenberg_hk>
TLK10232 is what I was planning to use
<azonenberg_hk>
that's dual xaui to dual SFP+
<azonenberg_hk>
i don't know if there is a single channel part
<azonenberg_hk>
no
<azonenberg_hk>
that is not what you want, it's one channel in
<azonenberg_hk>
for artix to sfp+ you want 4x 3.125 Gbps 8b10b (XAUI) to 1x 10.3125 Gbps 64b66b
<azonenberg_hk>
or wait
<azonenberg_hk>
the datasheet was confusing
<azonenberg_hk>
the tlk10031 can do xaui
<azonenberg_hk>
so yes, it should work
<azonenberg_hk>
But the tlk10232 is half the price
<rqou>
but it also has some -KR backplane stuff?
<azonenberg_hk>
well, cheaper anyhow
<azonenberg_hk>
and gives you a second channel if yo need it
<azonenberg_hk>
the 10031 has 40g serdes
<azonenberg_hk>
which is too fast and thus expensive
<rqou>
wait no it doesn't?
<azonenberg_hk>
" The TLK10232 supports operation with SFP and SFP+ optical modules, as well as 10GBASE-KR compatible backplane systems."
<azonenberg_hk>
oh yeah i misread the title
<azonenberg_hk>
w/e
<azonenberg_hk>
the 232 will work and is $5 cheaper
<azonenberg_hk>
use it, even if yo udont need the second channel
<rqou>
digikey has both for $26 so effectively half
<rqou>
are they the same die?
<azonenberg_hk>
Dont know
<azonenberg_hk>
And i got samples for free lol
<rqou>
yeah i can probably pretend to be a student and request samples
<azonenberg_hk>
I was close friends in college
<azonenberg_hk>
with a TI FAE ;)
<azonenberg_hk>
So i can get samples of just about anything i want
<azonenberg_hk>
i asked for two or three of them
<rqou>
or maybe not since i don't know what type of student would be sampling a tlk10232 :P
<azonenberg_hk>
he gave me 15
<azonenberg_hk>
you have a berkely email right?
<azonenberg_hk>
use it
<rqou>
yeah i did that to buy a jetson x1 with the discount
<rqou>
since nobody's going to buy that at full price :P
<azonenberg_hk>
whitequark: oh, one other thing i really want in pcb hdl
<azonenberg_hk>
Strong typing
<azonenberg_hk>
and the ability to represent a bus as a type
<azonenberg_hk>
So i can have an I2CBus object and pass that around without explicitly messing with sda/scl, and it complains if i try to hook it to a SPIBus
<azonenberg_hk>
Bonus points if there's i2c address support somehow
<azonenberg_hk>
So i can have a DRC fail if i have two devices with the same address on one bus
<azonenberg_hk>
(you'd need to support strap pins somehow)
<azonenberg_hk>
Maybe also allow buses to have other attributes like "point to point"
<azonenberg_hk>
for example, it's an error to connect a RGMII bus to more than one device
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<azonenberg_hk>
So you know what i find interesting?
<azonenberg_hk>
greenpak has a regulator-disable feature
<azonenberg_hk>
that lets you turn off the internal LDO and use the external Vdd as Vcore
<azonenberg_hk>
this can only be done when Vdd is 1.8V, which makes sense for a 180nm device (1.8 is the usual core voltage for 180nm parts)
<azonenberg_hk>
but, if they are using an LDO and always running the device core at 1.8V
<azonenberg_hk>
Why does timing of internal IP get better when Vdd goes up?
<azonenberg_hk>
That seems to imply something along the timing path is running on Vdd, not Vcore
<azonenberg_hk>
Would be very interesting to look at the power domains on the die and figure out how this is implemented
firebird_ has joined ##openfpga
firebird_ is now known as cosmobird
cosmobird has quit [Ping timeout: 268 seconds]
doomlord has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
doomlord has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
cosmobird has joined ##openfpga
<rqou>
azonenberg_hk: does the timing of the actual ip change or only of the i/o cells?
X-Scale has quit [Read error: Connection reset by peer]
cosmobird has quit [Ping timeout: 246 seconds]
cosmobird has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<azonenberg_hk>
rqou: That's a very good question
<azonenberg_hk>
But based on the way the datasheet is written
<azonenberg_hk>
it seems the propagation delay of the actual ip changes
<rqou>
wut
<rqou>
that is indeed weird
<azonenberg_hk>
Which suggests that vcore varies with vdd
<azonenberg_hk>
But then what is the ldo for?
<azonenberg_hk>
it's confusing
<rqou>
sense amps?
<azonenberg_hk>
example: Tpd for LUT2 output falling is 15.32 ns at Vdd=1.8V
<azonenberg_hk>
5.92 at 3.3
<azonenberg_hk>
and 4.18 at 5.0
<azonenberg_hk>
I know there's a charge pump somewhere
<azonenberg_hk>
the analog hard IP requires the charge pump turned on when vdd is <2.7V
<rqou>
wtf
<rqou>
that feels so hacky
<azonenberg_hk>
So presumably the analog components have a minimum voltage of 2.7V
<azonenberg_hk>
they run off vdd when vdd > 2.7
<azonenberg_hk>
and when lower, the charge pump boosts to 2.7
<azonenberg_hk>
It sounds like a perfectly logical thing to do if you want a wide operating range
<azonenberg_hk>
and low power
<rqou>
silego's parts just feel a lot more "grab bag"-y than i expected
<azonenberg_hk>
My understanding is that silego started out as a fabless asic company making PMICs etc for laptop etc vendors
<azonenberg_hk>
They realized 99% of their products were slight reconfigurations of the same basic IP
<azonenberg_hk>
and they could cut mask costs by making a single reprogrammable base part and OTPing it to do what it needed to do
<azonenberg_hk>
Then they realized as long as they were making a PLD, might as well sell blank ones too
<azonenberg_hk>
I dont think they intended to be an FPGA company from the start
cr1901 has quit [Ping timeout: 245 seconds]
digshadow has quit [Quit: Leaving.]
talsit has left ##openfpga [##openfpga]
digshadow has joined ##openfpga
cr1901 has joined ##openfpga
<azonenberg_hk>
Ok, NVM retry for slg46140 implemented (they seem to have removed it from the 4662x documentation, i may implement it anyway for lulz but keep it at 1 since that's the only supported value)
<azonenberg_hk>
I'm running out of features to implement
<azonenberg_hk>
which is a good thing :p
* azonenberg_hk
goes down bitstream for slg4662x to see what is missing
<azonenberg_hk>
slave SPI... yep i knew about that one
<rqou>
(offtopic, from @eevblog) "free energy" company steorn finally liquidated after _16 years_
<rqou>
how were they still around at all?
<azonenberg_hk>
"CNT test enable" - that sounds like an interesting mode lol
<azonenberg_hk>
But i don't plan to implement it
<azonenberg_hk>
Then we have a bunch of modes for the counters, alternate clock sources, etc not currently implemented
<azonenberg_hk>
DCMP/PWM blocks, that's another known missing feature
<azonenberg_hk>
More slave SPI stuff
<azonenberg_hk>
some ADC config, we already know the ADC isn't supported yet
<azonenberg_hk>
Vref blocks driven by DACs
<azonenberg_hk>
That should be easy enough to add
<azonenberg_hk>
Vref blocks driven by external signals, that will take a bit more work due to the extra signal routing
<azonenberg_hk>
More ADC config, we already knew that needed to get implemented
<azonenberg_hk>
The DAC blocks
<azonenberg_hk>
aaand... that's it :)
<azonenberg_hk>
oh and then in the counter stuff we have some kind of chip-wide wake/sleep that i dont fully understand yet
<azonenberg_hk>
The list is shrinking :)
<rqou>
huh apparently steorn came alive in 2015 and came up with a completely new "free energy" claim that was totally different from their 2006 one
<azonenberg_hk>
aaand Vref driven by DAC was 99% there, implemented... need to test still
<rqou>
i'm really curious how they managed to delude themselves
<rqou>
or how they managed to run a decade-long scam
<rqou>
either way is quite impressive :P
<azonenberg_hk>
Lol
<azonenberg_hk>
huh this is interesting
<azonenberg_hk>
Getting NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED in chrome trying to visit amazon
<azonenberg_hk>
Through my VPN
<rqou>
i still don't understand how CT is supposed to solve any problems
<azonenberg_hk>
The idea is that you don't trust a cert that isn't in the public log
<azonenberg_hk>
And if the cert is in the log, the owner of the site is able to detect somebody issued a cert to their domain that isn't theirs
<rqou>
so? suppose you detect one
<rqou>
what are you going to do about it?
<rqou>
complain on twitter?
<azonenberg_hk>
I dont have access to my twitter here
<rqou>
no, as in
<rqou>
if a website owner detects a bad cert
<azonenberg_hk>
oh
<azonenberg_hk>
presumably you talk to the CA and prove you're the real owner of the site
<azonenberg_hk>
then they revoke the cert
<rqou>
or the CA replies in russian/chinese/vietnamese and tells you to f*ck off? :P
<azonenberg_hk>
lol
<azonenberg_hk>
if that happens presumably the CA gets blacklisted in the next browser release
<azonenberg_hk>
wosign anyone?
<rqou>
yeah, idk how well that works
<azonenberg_hk>
personally on a high-security platform i explicitly remove all but like the top 5 CAs
<rqou>
supposedly many people in china use chromium forks that may or may not decide to distrust wosign
<azonenberg_hk>
Because i don't want Turktrust Soemthing-or-other signing any of my certs
<azonenberg_hk>
also, interestingly enough the site loads fine in firefox and gives no errors
<rqou>
iirc when this was brought up the mozilla security guys just gave a very "problematic" answer that basically said "we hope they don't do that"
<azonenberg_hk>
the cert chains up to a valid verisign root
<rqou>
where "that" means "remain a CA for the china market only and keep themselves trusted in only chinese browser forks"
<azonenberg_hk>
Lol
<azonenberg_hk>
personally i think the whole CA system is broken
<azonenberg_hk>
i just dont have a better alternative to suggest :p
<rqou>
trust on first use?
<azonenberg_hk>
That... isn't a great option
<azonenberg_hk>
Especially when major websites run zillions of certs for various servers
<rqou>
they bodged on http public key pinning
<azonenberg_hk>
how so?
<rqou>
although apparently half of the point of HPKP is to footgun yourself :P
<azonenberg_hk>
Lol
<rqou>
just like half of the point of http strict transport security is to create supercookies
<rqou>
or 99% of the point of the battery status api is to fingerprint users
<rqou>
:P
cosmobird has quit [Ping timeout: 250 seconds]
talsit has joined ##openfpga
cosmobird has joined ##openfpga
_whitelogger has joined ##openfpga
<whitequark>
azonenberg_hk: interesting
<azonenberg_hk>
whitequark: re what?
<whitequark>
azonenberg_hk: LDO observations
<azonenberg_hk>
ah
<azonenberg_hk>
yeah, i have no idea how that can work
<azonenberg_hk>
there is an ldo and its a 1.8V core process
<azonenberg_hk>
just like e.g. stm32
<azonenberg_hk>
or pic32
<azonenberg_hk>
but somehow the timing is voltage dependent
<rqou>
huh i actually never noticed that stm32 timing is _not_ dependent on supply voltage :P
<rqou>
avr is
<rqou>
most avrs can't officially hit their top speed unless they're at 5v
<azonenberg_hk>
yeah but most avrs are 3.3/5V
<azonenberg_hk>
on 350nm
<azonenberg_hk>
right?
<azonenberg_hk>
at least everyone i decapped was
<rqou>
yeah i think so
<rqou>
most have a top speed of 20mhz at 5v
<rqou>
although they do overclock quite a bit apparently
<rqou>
hilariously enough sb0's avr clone (navre) is faster than any real avr :P
<whitequark>
lol
<azonenberg_hk>
lol
<azonenberg_hk>
well my antikernel's first mips cpu
<azonenberg_hk>
started out as a faster pic32 replacement
<azonenberg_hk>
on a spartan6 i managed to get both lower current consumption and higher clock speed than a real pic32
<rqou>
wtf
<rqou>
how does microchip do that bad a job?
<azonenberg_hk>
yeah i know
<azonenberg_hk>
i measured I(vccint) + I(vccaux) + I(vcco)
<azonenberg_hk>
at 80 MHz
<azonenberg_hk>
total power in watts was less
<azonenberg_hk>
Part of it was the non-disableable LDO
<azonenberg_hk>
pic32 needed 2.5 or 3.3V to run an 1.8V core
<azonenberg_hk>
via LDO
<azonenberg_hk>
the FPGA ran at 1.2V
<azonenberg_hk>
directly
<azonenberg_hk>
if you could run the pic's core directly through a SMPS, i suspect the tables would turn
<azonenberg_hk>
in fact, the pic32mx300 series *did* have an ldo bypass mode
<azonenberg_hk>
but not the 600 series
<rqou>
wut?
<rqou>
although stm32 tends to only have ldo bypass on the bga/csp parts
<rqou>
i assume because of inductance reasons
<whitequark>
"As soon as I tried to send the firmware, the breakpoints were going off left and right. In the function 0x401000, one of the arguments that was passed to it was "I am a key, wawawa". So thank you STMicroelectronics for making it very obvious what the key is and what function uses it."
<rqou>
somewhere i actually pulled the firmware from TI's swd dongle for the stellaris parts
<azonenberg_hk>
whitequark: lool
<azonenberg_hk>
wait
<azonenberg_hk>
"I am a key" was the actual key string?
<whitequark>
"I am a key, wawawa"
<rqou>
anyways, i pulled the stellaris swd dongle in a more hilarious way
<whitequark>
yes.
<rqou>
the stellaris launchpad uses a second stellaris mcu to do the swd debug
<rqou>
and i had two of them
<rqou>
so you connect one to the other, and ...
<rqou>
:P
<whitequark>
I think you can do that with stlinks too?
<whitequark>
I wanted to do it at least
<whitequark>
waaay back when I just started on them
<rqou>
anyways, the sega triforce also has a really great (DES) key that was successfully bruteforced
<rvense>
(apparently for a few months you couldn't get the stellaris chips, but you could get the dev boards for cheap and there was two on there you could desolder)
<rqou>
00 22 44 66 88 aa cc ee
<rqou>
best des key
<rqou>
bruteforcing this was especially fast, i wonder why? :P
<rqou>
whichever one broke the password into two pieces of 7 bytes
<whitequark>
original lm.
<whitequark>
it also changed it to uppercase.
<whitequark>
so, yes, I think original lm was actually worse
<whitequark>
oh
<whitequark>
oh wait.
<whitequark>
is THIS why it changed the password to uppercas?
<rqou>
yeah, i actually had to run cain and abel on one of my old windows password databases because i forgot the password
<rqou>
it turned out that it got the answer very quickly because the password was "password" :P
<whitequark>
I captured a domain admin auth transaction with ettercap in my HS and then extracted all the passwords from DC and ran them through rainbow tables
<whitequark>
that was fun
<rqou>
my HS didn't even require you to do that
<whitequark>
it turns out to be really easy to confuse switches with ettercap
<rqou>
the login was your student ID and the password was your last name
<whitequark>
what.
<whitequark>
is this why infosec people drink so much.
<azonenberg_hk>
lawl
<azonenberg_hk>
whitequark: yes
<rqou>
during my senior year the HS installed wifi throughout the school
<rqou>
it didn't use the same single sign on
<rqou>
the username was still the student ID and the password was password
<rqou>
:P
<azonenberg_hk>
i've seen things i can't unsee
<rqou>
nobody knew how to change the password either
<rqou>
because the sign-on wasn't hooked up :P
<rqou>
this was installed after the school administration banned teachers installing shitty wifi APs and not setting passwords
<azonenberg_hk>
lol
<rqou>
apparently the admins decided to do some traffic management and tried to get some baseline traffic numbers
<rqou>
and noticed that traffic dropped a negligible amount over spring break :P
<rqou>
whitequark: this is how US K-12 education works. isn't it brilliant? :P
<rqou>
schools here are barely capable of bikeshedding over whether they should buy new computers
<rqou>
when i was about to graduate HS the principal finally got embarrassed enough to upgrade all the computers that ran win95
<whitequark>
omg
<rqou>
because budget bikeshedding
<rqou>
for half of the time i was in high school the school paid $$$$$ for some novell server product thingy
<rqou>
but it was just being used as a glorified NAS
<rqou>
there weren't even quotas enabled
<rqou>
apparently some admin finally woke up and realized that instead of paying $$$$$ they could pay only $$ for a normal windows server
<rqou>
also, the "classic" or stereotypical hack you're supposed to do after hacking your high school is to edit the grades, right?
<rqou>
that couldn't even be done at my high school because the grading system wasn't centralized
<whitequark>
... no?
<whitequark>
all of our grades were on paper
<whitequark>
I actually don't think *anything* interesting could be done
<rqou>
oh that's even more unhackable/old-fashioned
<whitequark>
I suppose uhhhh bureaucracy something ms word documents from the principal?
<whitequark>
but I had so little interest in that back then
<rqou>
i pissed off the admin by spamming google searches with wget and a batch file
<rqou>
flooding their MITM monitoring software logs
<azonenberg_hk>
lol
<rqou>
not that the log dropped any entries
<rqou>
but the human looking at the log could no longer see useful information
<rqou>
oh yeah cmd.exe was disabled on the school computers but batch files would still run
<rqou>
also, there's no 802.1x on any ports so you can just unplug one and plug in a laptop
<rqou>
one of my friends actually had an even better story
<rqou>
he was taking the schools "IT/networking" class because he was bored
<rqou>
at one point somebody brought in an infected usb stick
<rqou>
it had a really crappily written fake AV worm on it
<rqou>
my friend wrote a new worm in VB6 that uninstalled the malicious worm
<rqou>
the "good worm" was jokingly called virus.vbs
<rqou>
at some point apparently some infection sources end up in the principal's office
<rqou>
and the principal asks "what is this file virus.vbs?"
<whitequark>
wow, this is some impressive level of idiocy
<whitequark>
so this captive portal has a https certificate...
<whitequark>
... that has the "certificate transparency required" bit set
<rqou>
i didn't even know there was such a bit
<rqou>
i don't understand why anyone would request such a bit either
<rqou>
any rouge cert would just not set it
<rqou>
(same with ocsp stapling required which basically seems to be "please cause random breakage when nginx reloads")
<whitequark>
I have no idea
<whitequark>
I dind't know there was such a bit either
<whitequark>
chromium just told me net::ERR_CERTIFICATE_TRANSPARENCY_REQUIERD
<rqou>
it's honestly getting to the point of "chrome infosec team echo chamber"
<rqou>
some guy was doing that before but let the domain expire
<rqou>
i want to actually continue the idea
<rqou>
unlike a certain entity that will not be named, the ieee oui system actually has a local/global bit
<rqou>
so you don't need any octet sequence squatting schemes
<whitequark>
well
<whitequark>
I don't think you can sell devices with local oui bit set
<whitequark>
conversely if you do it locally does it matter if you squat?
<whitequark>
(sell/distribute/etc)
<rqou>
how can that be enforced?
<rqou>
that certain entity does it via trademark
<rqou>
which is probably the best that ieee could try and do
<rqou>
but if you don't use their trademarks you can probably do whatever you want
<rqou>
(complying with all relevant laws of course)
<rqou>
whitequark: you're in HK, you should have already seen all the ethernet dongles with addresses of 00:00:00:00:00:00 or aa:aa:aa:aa:aa:aa or similar :P
<rqou>
i know i have some somewhere
doomlord has joined ##openfpga
<azonenberg_hk>
rqou: lol
<azonenberg_hk>
i decapped one somebody in another chan sent me
<azonenberg_hk>
a supereal chipset that had an empty footprint for a mac eeprom
<azonenberg_hk>
not populated
<azonenberg_hk>
because that 20 cents is so expensive
<azonenberg_hk>
And there's no law preventing you from selling them, but its considered bad practice
<azonenberg_hk>
For most of my prototype FPGA stuff i do 02:[device DNA low 40 bits]
<azonenberg_hk>
if i was going to distribute a product i'd buy a mac address eeprom from microchip
<azonenberg_hk>
they sell 24C's that have a pre-programmed mac burned into the low 6 bytes
<azonenberg_hk>
for almost no increase in cost vs the bare eeprom
<rqou>
except for if your design didn't need a 24c to start :P
<azonenberg_hk>
well
<azonenberg_hk>
if you got a mac address some other way
<azonenberg_hk>
you'd have to store it somehow
<azonenberg_hk>
Anyway, compared to the cost of an FPGA or something
<rqou>
i haven't gotten around to doing this yet, but i would probably store it in either "the supervisor uC" eeprom or on a microsd
<azonenberg_hk>
its not something i care about saving
<rqou>
but overall ieee has been much nicer than that organization that will not be named :P
<rqou>
e.g. there is no ban on reselling suballocations
<azonenberg_hk>
Lol
<azonenberg_hk>
And you wonder why 802.3 is my preferred interface for all of my projects
<azonenberg_hk>
as opposed to everyone's favorite 3-letter bus?
<rqou>
but the 3-letter bus has smaller connectors :P
<whitequark>
azonenberg_hk: re mcp eeprom: nice
<whitequark>
rqou: so
<whitequark>
there's like, nothing preventing you from running ethernet over usb3 connectors
<whitequark>
you have enough pairs
<whitequark>
not in usb2 but in usb3 you do
<rqou>
impedance?
<whitequark>
pfffff
<whitequark>
who cares
<rqou>
it's actually not the same apparently
<rqou>
100 ohm vs 90 ohm
<whitequark>
yeah sure but smaller connectors
<whitequark>
there's no way this "empedance" thing actually affects anything right
scrts has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
talsit has left ##openfpga [##openfpga]
doomlord has joined ##openfpga
<cr1901_modern>
"(7:44:41 AM) azonenberg_hk: And you wonder why 802.3 is my preferred interface for all of my projects" I would not personally want to implement a wiPHY
<qu1j0t3>
pie_: You are a bad person. Also: get back to your studies, slacker
<pie_>
:( kk
<qu1j0t3>
is that the link you intended though?
<pie_>
no its not
<rvense>
it didn't make much sense
<qu1j0t3>
well that certainly clears up a mystery
<lain>
confusion level: slightly less than 5 minutes ago
<pie_>
cant find the right link anymore though heh
<pie_>
something something UK bill requires companies to give gov opportunity to bacdoor products
<lain>
if the headlines are to be believed, the UK/EU are trying really hard to one-up the NSA lately
<pie_>
from snowden twitter
<pie_>
lain, honestly we can probably agree that its just going public :P
<pie_>
no civil war yet so they see they can just do whatever they want :P
<lain>
I'm just picturing some back-and-forth like "oh yeah, well *we* put spy devices in everyone's TOOTHBRUSH! beat /that/!"
<qu1j0t3>
lain: It's not just headlines. It's law.
<qu1j0t3>
lain: Bad law in Canada too.
<lain>
there is no escape, even america's hat is no longer safe
<qu1j0t3>
correct
<qu1j0t3>
however, i'm still free to make a coffee
<qu1j0t3>
not all is lost
* lain
nods
<qu1j0t3>
however i'll stick to analogue stovetop. No doubt always-connected Keurigs with microphones are just months away.
<qu1j0t3>
“Wow it's so cool that it starts brewing on voice command and ships all audio in the house to some cloud server 24/7.”
<pie_>
clod server
<pie_>
the technology haters were right all along
<lain>
like the samsung smart tv that comes with a warning to have discrete conversations in another room, because it's always processing voice data to a third party service
<qu1j0t3>
lain: +1 a great example. Also Amazon stuff. Nobody read 1984?!
<lain>
at least with like an amazon echo, you know what you're getting into
<qu1j0t3>
Not sure. I think a lot of people don't think it through, and/or have an unwarranted level of trust.
<pie_>
a lot of people probably wouldnt care...
<qu1j0t3>
that too
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]