<electronic_eel>
azonenberg: about your DS125DF111 board: what kind of clocking options do you plan for it? a 25 Mhz osc on board or also an external input for refclock?
<electronic_eel>
the external clock input could be used as external trigger for the output signal or similar
<electronic_eel>
or to observe how jitter on the input clock affects the output eye
<bvernoux>
A good option will be to add a differential Input
<bvernoux>
to check a signal as the DS125DF111 can do eye diagram
<bvernoux>
which is a very good feature
<electronic_eel>
hmm, i think azonenberg mostly wants to use this board to show how to measure the output with a scope and do the eye there
<bvernoux>
Yes I understand it is why I ask for an option with unpopulated SMA for the Input
<bvernoux>
It is clearly a big deal to check any SerDes with such a cheap board and have a 64x64pixels eye diagram up to 12Gbps
<tnt>
+1
<bvernoux>
If andrew does not want to add this option anyway we could add it ourself as I suspect the design will be opensource
bvernoux has quit [Quit: Leaving]
Bird|otherbox has quit [Remote host closed the connection]
Bird|otherbox has joined #scopehal
electronic_eel_ has joined #scopehal
azonenberg1 has joined #scopehal
electronic_eel has quit [Ping timeout: 250 seconds]
azonenberg has quit [Ping timeout: 250 seconds]
azonenberg1 is now known as azonenberg
<azonenberg>
My plan is to have single ended on board osc for clock and no inputs
<azonenberg>
feel free to modify the design if you want that capability
<azonenberg>
but this board is intended to be used free standing with no inputs or PC connection
<azonenberg>
it's just a signal generator
<azonenberg>
e.g. i'm not using the other channel on the chip at all (it's two channels intended for bidir redriving between a backplane and SFP+)
<azonenberg>
ah hmm so it does look like it's got all 4 directly into the one chip
<azonenberg>
And they sanded off the markings? lol
<monochroma>
gotta protect their investment from the likes of /YOU/ ! ;)
<azonenberg>
lol
<azonenberg>
i mean if i really wanted to RE it, i'm sure i could
<azonenberg>
i have acid :p
<azonenberg>
@louis ok so looking through your refactoring, a few quick comments
<azonenberg>
TRIG:LEV applies to all trigger types, not just edge
<azonenberg>
so SetEdgeTriggerLevel() should be renamed to SetTriggerLevel()
<azonenberg>
also you misspelled "acquisition"
<azonenberg>
also, we should change the signature of GetChannelID() to indicate digital or analog as well as a numeric ID
<azonenberg>
say, make it return a bool indicating validity
<azonenberg>
and take references for channel number and type
<azonenberg>
otherwise, good work
<tnt>
Mmm, too bad, the pinout matched pretty well with DS125RT410 even the caps for the charhe pumps on the 4 corners.
<tnt>
Although looking closer at the picture, I'm starting to wonder if all the resistors aren't part of built in passive probe for each lane, going to some other circuitry.
<electronic_eel>
maybe there are undocumented registers with new modes of operation in the DS125RT410 they got info on
<azonenberg>
it's also possible it's a close relative of a chip
<azonenberg>
of that chip*
<azonenberg>
but not that exact one
<tnt>
Sure, but from the very principle of operation of the eye monitor, it couldn't ever make a full eye diagram / outside view. And I haven't seen any chips having that function.
<azonenberg>
yeah
<azonenberg>
using such a chip for prbs generation followed by a diy sampling scope sounds very plausible though
<tnt>
yup that'd also explain all those resistors
<tnt>
unfortunately no high res pics of the pcb or of the backside :/
<azonenberg>
yeah somebody needs to tear one down properly
<d1b2>
<louis> Just so that we can tell if digital (or analog) specific commands should be allowed on said channel?
<miek>
the test reports they generate make me a little suspicious - the only hard numbers they give are for horizontal/vertical eye opening and they only ever show an internal mask. surely if you can really measure the full eye, you'd report a bit more and show the masking of the outside?
<d1b2>
<louis> I've pushed appropriate changes for those items
<d1b2>
<louis> The editor feature I wish Sublime has was SpellcheckInsdieCamelCase
<d1b2>
<louis> ...i could probably do that as an addon, actually
<d1b2>
<gatecat> Infinite project syndrome but I have one of the Microsoft Arria 10 PCBs with a DS250F810 retimer on the QSFP28
<d1b2>
<gatecat> no idea how I'd figure out how the I2C pins go but could be an interesting thing...
<tnt>
gatecat: I usually make a bitstream that outputs the ball number as UART on each IO ...
<d1b2>
<louis> @azonenberg is it your intent that everything that takes a chIndex should also take an isDigital (i.e. so you may have analog ch 0 and digital ch 0) or is it your intent that the chIndexes be non-overlapping and GetChannelID just reports it's digital-ness as a convinence? The latter seems much more convinent to me.
<d1b2>
<louis> I think the cleanest approach would be to declare that the chIndex as used in scpi-server-tools and as used as hwname in RemoteBridgeOsc must uniquely identify the channel (i.e., be the same as the OscChannel's index.) Then if there is some banking kinda thing in the hw API that's up to the implementer to abstract away.
<azonenberg>
louis: so, clientside in libscopehal
<azonenberg>
channel IDs are non-overlapping and consecutive
<azonenberg>
by convention the first N channels are analog
<azonenberg>
then after that you have external trigger inputs (which are channels that never have a waveform associated with them, but are otherwise usable as channels)
<azonenberg>
and digital channels
<azonenberg>
server side in the bridges, it makes sense to use a similar convention. that said. i believe the existing implementation of the bridges uses an overlapping namepsace
<azonenberg>
so e.g. D0 would parse as channel 0, isDigital=true
<azonenberg>
But this may not be the best approach for long term
<d1b2>
<louis> I think least confusing would be to make the channel indices match in libscopehal and in the bridge, and then the person writing the bridge would have to do some internal mapping to hardware names, and expose a IsDigital(size_t); IsExternalTrigger(size_t) that the parsing/validation code uses
<azonenberg>
well that generated more spam than i expected :p but the main repos are now under the glscopeclient org
<d1b2>
<louis> (My thinking mostly being that that will make the indices line up which will be helpful for debugging, and might make it easier if we decide to change to be network-transparent at the Oscilloscope layer)
<azonenberg>
Network transparency at the Oscilloscope layer is probably going to happen long term
<azonenberg>
but we likely will not *replace* what we have here with that
<azonenberg>
because, for example, transparency at the Oscilloscope layer will require moving the native waveform format over the wire
<azonenberg>
which is likely bulkier than what the bridges will use before converting to a Waveform