futarisIRCcloud has quit [Quit: Connection closed for inactivity]
mumptai_ has joined ##openfpga
mumptai has quit [Ping timeout: 246 seconds]
futarisIRCcloud has joined ##openfpga
Bike has quit [Quit: Lost terminal]
pie___ has joined ##openfpga
pie__ has quit [Ping timeout: 246 seconds]
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga
Hamilton has joined ##openfpga
Flea86 has quit [Quit: Goodbye and thanks for all the dirty sand ;-)]
Bob_Dole has joined ##openfpga
emeb has quit [Quit: Leaving.]
emeb_mac has quit [Ping timeout: 244 seconds]
Hamilton2 has joined ##openfpga
Hamilton2 has quit [Client Quit]
Hamilton has quit [Ping timeout: 272 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 272 seconds]
zem has quit [Ping timeout: 245 seconds]
zem has joined ##openfpga
<whitequark>
bubble_buster: read the USB PD spec, then you wouldn't want to
rohitksingh has joined ##openfpga
<s_frit>
bubble_buster: just curious: why would you want to require someone to use a break-out cable to connect other interfaces (DP, USB-A) when you could have those connectors on the board?
futarisIRCcloud has joined ##openfpga
<whitequark>
because nerds who have no idea how USB type-C works think it's "elegant"
<whitequark>
in the same way as unix is "elegant", and wrong for the same reasons
<whitequark>
brace yourself, that's the next ten years of discourse now. no going back
<sxpert>
usb* is horrible, period
<sxpert>
and thunderbolt, aka PCIE, is a security nightmare
<whitequark>
nah
<whitequark>
thunderbolt is actually better than usb, security-wise
<whitequark>
thunderbolt has challenge-response authentication built in, so you can prevent devices from ever being connected to the internal bus
<whitequark>
usb though? any old shit you plug in, in pretty much every OS on market, will instantly load a poorly audited binary in kernel mode and feed it some untrusted input
<whitequark>
and there's no way to prevent that short of filling the port with wax
<whitequark>
thunderbolt is also not pcie but encapsulation of pcie among other things and you should know that before starting talking about it
<whitequark>
e.g. displayport over thunderbolt is almost impossible to fuck up. most of the nasty parts are in usb pd, communicating the dp mux settings via pd vdms, which isn't strictly speaking thunderbolt itself
rohitksingh has quit [Ping timeout: 250 seconds]
<hl>
so basically the question now is how badly USB-IF can fuck up Thunderbolt with USB4
Asu has joined ##openfpga
<whitequark>
someone (here?) speculated that it'd be an USB encapsulation in Thunderbolt
<whitequark>
which... yeah, does raise the question of how authentication will work
<hl>
that was my speculation yeah
<hl>
I'm guessing they will define an encapsulation of the application-layer USB protocol over thunderbolt's MPLS network
<hl>
so that the USB programming model exposed to user-level developers isn't changed
<whitequark>
what if they just stuff an XHCI into every USB4 device?
<hl>
NO
<whitequark>
ahahahahaha
<hl>
they cannot possibly be that dumb
<whitequark>
have you -seen- USB?
<hl>
whitequark: yeah I'm just trying to tell myself that
<hl>
all we can do is pray
<whitequark>
look, the existing silicon that can do thunderbolt is all intel
<whitequark>
and it can all do xhci already
<whitequark>
and you might want to daisy chain tbt devices to usb4 devices
<hl>
because, like every other fucking "industry" standard, it's developed by closed doors and then just dumped on a website (if you're lucky, if you're unlucky they demand you join them)
<whitequark>
that means they'd just slightly repurpose existing controllers, maybe a firmware change even
<whitequark>
you can download most of them in my library. i steal them
<hl>
oh I know, I'm good at finding them
<tnt>
Meh I don't find usb 2.0 ls/fs/hs all that bad. Don't know enough about the newer ones to say anything. Sure there is no auth mechanism but (1) at the time it was first developped, nobody did that (2) the fault is more on the drivers being buggy than a fail of the bus protocol itself.
<hl>
but the other problem is, you get no input on the development of these standards. it's the diametrical opposite of e.g. the IETF
<whitequark>
tnt: (usb ls/fs/hs) it's trash on so many levels
<whitequark>
for example, who the fuck considered bit stuffing acceptable?
<whitequark>
what moron made it dc-coupled?
<hl>
i'm wondering what the world would look like if ACCESS.bus had won
<tnt>
whitequark: it's pretty common technique. At least before 8b/10b , maybe fallen out of favor now, but if you eval it against what was the "standard" when it came out ...
<whitequark>
that's not an excuse
<whitequark>
"it's common" just means you're as incompetent as everyone around
<whitequark>
as for the fault of drivers being buggy
<whitequark>
note, i did not complain that USB is particularly bad here
<whitequark>
i said that Thunderbolt is -better- than USB in this regard
<whitequark>
(they're both trash for a variety of other reasons)
<hl>
so I'm curious, do you know what the headers for Thunderbolt packets/frames look like?
<whitequark>
nope
<whitequark>
i know almost nothing about the actual TBT physical and link layers
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<whitequark>
if i wanted to RE it, i would have probably started with TBT2
<whitequark>
or even TBT
<whitequark>
TBT1*
<whitequark>
they likely have kept some of the framing (or all!) intact
<hl>
would be hilarious if it actually were MPLS
<whitequark>
i really don't think it's just MPLS
<hl>
yeah, seems unlikely
<whitequark>
knowing just the PHY frequency would probably let me lock onto it, but TBT3 is certainly scrambled
<whitequark>
with some polynomial we don't know
<hl>
do you have test equipment fast enough to deal with it?
<whitequark>
no, and even though i live in a major city, it is apparently hard enough for even a corporation dedicated to developing high speed interconnect to rent it
<hl>
eesh
<whitequark>
it might be possible to rely on OSINT
<whitequark>
it's definitely heavily patented
<whitequark>
A.b is hilarious
<whitequark>
A.b is "what if we just use I2C" but I2C doesn't work
<whitequark>
it especially doesn't work if you let people plug 3rd party devices into the only internal I2C bus
<whitequark>
this mentions 10.3 and 20.6 G line rates
<whitequark>
aha: For designers used to working with high-speed serial buses, much of what’s in Thunderbolt will look familiar. Thunderbolt signaling is a dual NRZ (64/66b encoded) at 10.3125 Gbps (same as SFP+) with two differential Tx pairs and two differential Rx pairs.
rohitksingh has joined ##openfpga
futarisIRCcloud has joined ##openfpga
<hl>
so it's basically just like an SFP+ interface to an active cable? figures
<whitequark>
looks like
<whitequark>
i mean not exactly
<whitequark>
i think cables used to be all active, not anymore
<hl>
yeah
<catplant>
lol we just thought about how
<catplant>
optical thunderbolt cables are like
<hl>
but I mean SFP+ DAC cables are often just passive twinax, so it's two switches talking SFP+ to one another direct
<catplant>
inverse dirrect-connect
<hl>
so the TB PHY might be a lot more normal than we were thinking
<whitequark>
yes
<hl>
can 7-series GTXes handle 10.3125Gbps?
<daveshah>
pretty sure it can
<daveshah>
I remember my Genesys2 with a k7 doing that
<hl>
"Fig. 4 is a block diagram of an example alternate mode packet header."
<whitequark>
huh
<hl>
"The packet header 400 includes a protocol-defined field (PDF) 402, a HopID field 404, a length field 406, and a Header Error Control/Check (HEC) field 408. In some examples, the PDF 402 may be 4 bits in size, the HopID field 404 may be 12 bits in size, the length field 406 may be 8 bits in size, and the HEC field may be 8 bits in size."
<hl>
"In some examples, an ordered set can be indicated in the PDF 402 field using the value 0001b. The ordered set value can be used to pass Training Sequence 1 (TS1), Training Sequence 2 (TS2), Start Data Stream (SDS) Ordered Set (OS) information."
<hl>
wtf?
<hl>
please tell me they didn't adapt USB to thunderbolt by explicitly modelling the USB PHY initialization state machine as commands ...
<hl>
>The protocol defined field (PDF) 1602 may be used to maintain synchronization between two adapters by replacing certain functionality of the PCIe physical layer, indicating how the receiver may parse the received byte stream, etc. The Hop ID field 1604 may be carried in the header of all packets associated with a path and may be a locally unique identifier for the path. The Length field 1606 field may be
<hl>
binary encoded with a value equal to the number of bytes in the transport layer packet payload. The HEC field 1608 may be configured to protect the packet header. In various embodiments, the HEC field 1608 may include some number of bits (e.g., 8 bits) and may be used to correct single-bit errors in the transport layer packet header.
<hl>
>In various embodiments, the PDF 1602 may be used for byte streams generated and received by the PCIe link training and status state machine (LTSSM). The LTSSM ordered sets may be modified in one or more various ways. For example, when a PCIe link is established over a multi-protocol interconnect, as indicated by the transition from 0b to 1b of a Physical LinkUp signal generated by the LTSSM, the first
<hl>
PCIe byte stream data provided to the protocol transport layer for transmission may be required to indicate “ParserReset.” in subsequent transmissions, every time a multi-protocol interconnect packet start also corresponds to the start of a TLP or DLLP, ParserReset” may be required to be indicated. In various embodiments, “ParserReset” may be required to be indicated before all Data Link Layer
<whitequark>
to route out the GMII clock you have to drop to 4/4
<tnt>
whitequark: is it only gigabit ? I mean ... wtf do you need such a weird package for 1G ethernet.
<gruetzkopf>
4/4 is fine on jlcpcb 4l
<whitequark>
yes, GbE
<whitequark>
gruetzkopf: no, you see, their reference footprint is mostly 5/5
<hl>
any reason you're going with that PHY?
<whitequark>
except for that one signal which they have to drop to 4/4 for
<whitequark>
hl: no comment
<gruetzkopf>
ouch
<bubble_buster>
what does 4/4 and 5/5 mean?
<gruetzkopf>
it's pcb track width / pcb track gap in 1/1000 inch
<bubble_buster>
I see, thanks
<azonenberg>
whitequark: multi row QFN
<azonenberg>
that looks like a weird asymmetric LGA
<whitequark>
azonenberg: exactly
<azonenberg>
is that an intel package?
<whitequark>
microsemi
<whitequark>
it's a gbe phy
<whitequark>
why the fuck
<whitequark>
would anyone go through this effort
<whitequark>
is beyond me
<hl>
ahh, I've heard things about microsemi
<azonenberg>
1G? pcie or something weird? or just rgmii
<azonenberg>
whitequark: can you mention the exact part?
<azonenberg>
the only microsemi gbe phy i've looked at is the VSC8211 which comes in a nice 117-ball LBGA
<azonenberg>
(9x13)
<whitequark>
VSC8501
<azonenberg>
i had been eyeing it for adapting spartan-6 to a 1000base-X backplane
<azonenberg>
But now that i've moved to 7 series i will probably never use it
<whitequark>
gmii/rgmii
<whitequark>
absolutely bog standard phy
<whitequark>
in an absolutely insane package
<hl>
they make SAS controllers... apparently, one of their SAS controllers has a firmware bug which means the activity LEDs don't work. a downstream vendor has been pressing them for a fix for this for like a year at this point, which they still haven't delivered
<azonenberg>
whitequark: on that note, the vsc8211 datasheet is now registered user only on the microsemi website
<azonenberg>
but digikey has a mirror of it :P
<hl>
also the readme for that SAS controller apparently claims the SAS controller doesn't support optical drives, or tape drives. how do you even manage to break that, or have the guts to call that a SAS controller
<whitequark>
azonenberg: the digikey package field for this says
<whitequark>
"135-QFN (12x12)"
<azonenberg>
also wait the lands are not even all the same size
<azonenberg>
wtaffffff
<whitequark>
they are not
<azonenberg>
when i first saw your image i was thinking they were test points on top of a fcBGA
<azonenberg>
Which would have somewhat made sense
<whitequark>
and the dots at the four corners are larger
<azonenberg>
(those are mechanical only i assume?)
<whitequark>
azonenberg: someone over at twitter suggested that it spells "fuck you" in morse
<azonenberg>
lool
<hl>
also that vendor has apparently found microsemi absolutely horrible to interact with.
<azonenberg>
which division? microsemi is a pile of companies they acquired
<hl>
tldr; microsemi is one of countless competitors for title of no. 1 "bunch of mindless jerks who'll be the first up against the wall when the revolution comes"
<azonenberg>
Vitesse is on my blacklist due to being impossible to get parts/samples from
<azonenberg>
or datasheets
<hl>
azonenberg: this would be their SAS division (ex-PMC-Sierra)
<azonenberg>
ah have not dealt with them so cant comment
<esden>
I was just about to say that some developer at Microsemi is signalling "help me out of here" in morse... but I guess others had similar thought :D
<esden>
or "send help"
<sxpert>
"help, management is runing amock just like at commodore"
lutsabound has quit [Quit: Connection closed for inactivity]