Ethernet trigger an protocol decoding for MSO or Logic analyser

[mikeselectricstuff]

A while ago I did a video on triggering and decoding 100M ethernet packets (below).
I have no idea if this is a potentially useful product but seems like it might be so I've built  a couple of dozen boards and knocked a website together :
www.etherdecode.com

Any comments /feedback welcome.

https://youtu.be/SYnO9CsTEqQ

[Gribo]

Great product, one nitpick: On the 3rd row from the top, it should be 100BASE-TX, not 10Base100.
Can we get 1000BASE-T support? 

[maginnovision]

I like almost everything except the part where it could come with a case later on. Makes me feel pretty strongly that waiting is the right choice, but then maybe it never happens.   

[mikeselectricstuff]

I like almost everything except the part where it could come with a case later on. Makes me feel pretty strongly that waiting is the right choice, but then maybe it never happens.   

I need to limit how much time I put into this until I know it's a viable product. If it happens, the cased version will cost a bit more and may have additional functionality based on feedback from early users.
Or it may not happen at all.
Either you need it or you don't.....

[maginnovision]

I like almost everything except the part where it could come with a case later on. Makes me feel pretty strongly that waiting is the right choice, but then maybe it never happens.   

I need to limit how much time I put into this until I know it's a viable product. If it happens, the cased version will cost a bit more and may have additional functionality based on feedback from early users.
Or it may not happen at all.
Either you need it or you don't.....

That's just it. It would be a nice thing to have but I don't NEED it. My ethernet designs can be debugged in software since the packets are all manage in software already. It would however be nice to avoid having to write extra code and  adding delays that don't need to be there. I'll have to think about how nice it would be.

[Hydron]

Looks good, one of those tools that when you need it, you _really_ need it, and a sharp price to boot!
Did you end up using one of those small QFN Lattice FPGAs? Last I checked they'd finally gotten around to releasing some of the MachXO2 parts in the smaller packages that their family datasheet promised - they struck me as something that you'd probably be happy to have available for the type of designs you do.

[mikeselectricstuff]

Looks good, one of those tools that when you need it, you _really_ need it, and a sharp price to boot!
Did you end up using one of those small QFN Lattice FPGAs? Last I checked they'd finally gotten around to releasing some of the MachXO2 parts in the smaller packages that their family datasheet promised - they struck me as something that you'd probably be happy to have available for the type of designs you do.

Yes - AFAIK the XO2's have always had a couple of QFN32 options, at least as long as I've been using them. Could have used ICE40 but the learning curve and OTP onboard memory wouldn't have been worth saving a quid on the BOM

[mikeselectricstuff]

https://youtu.be/oC2ifYLQDP0

[Carrington]

I've already ordered one!
Thanks for sharing you work!

[mikeselectricstuff]

Only 3 left from the first batch
All gone now (20) . I'll be doing a batch  in a week or so - if they go at a reasonable rate, it will be redesigned into a small case at a slightly higher price.

[ajb]

Neat! 

Might be useful to offer a selectable 4-bit mode.  Obviously that means twice the data rate but would be useful when running two decoders on a <=16 channel analyzer.

It could also be useful to offer a few more mark options, for instance highlighting only specific fields to make it easier to do things like setup scope triggers on specific port numbers or something.  (You could also implement that sort of filtering in the decoder, but then you need some sort of UI to configure it and it's probably not worth that much effort.  If you're using a device like this you probably have other ways of isolating the traffic you want.)

[mikeselectricstuff]

Neat! 

Might be useful to offer a selectable 4-bit mode.  Obviously that means twice the data rate but would be useful when running two decoders on a <=16 channel analyzer.

It could also be useful to offer a few more mark options, for instance highlighting only specific fields to make it easier to do things like setup scope triggers on specific port numbers or something.  (You could also implement that sort of filtering in the decoder, but then you need some sort of UI to configure it and it's probably not worth that much effort.  If you're using a device like this you probably have other ways of isolating the traffic you want.)

There's plenty that could be done once there's a UI, but that adds a lot of complexity - the whole idea is to keep it simple and cheap. More so as I'm not yet sure how useful it is....

[Howardlong]

I’m wondering if it might have more value/market if it did bidirectional. I realise you can use two.

I happened to notice your tweet earlier today, so I got lucky. I’ll see how I get on with it, maybe it’s not a big deal in practice.

I’m assuming it’s transparent between ports and there’s no buffering, i.e., no packet latency?

[mikeselectricstuff]

I’m wondering if it might have more value/market if it did bidirectional. I realise you can use two.

I happened to notice your tweet earlier today, so I got lucky. I’ll see how I get on with it, maybe it’s not a big deal in practice.

I’m assuming it’s transparent between ports and there’s no buffering, i.e., no packet latency?

Yes - just parallelises the PHY data - there might be some delay or FIFO in the PHY, but any delays should be fixed.

Bidirectional can be done with a port mirroring switch, though it's harder to tell which traffic is in which direction. And of course you can use two, so didn't think it was worth it to do a bidirectional version - I may offer a discount for two units in future..

[Zucca]

Nice one mikeselectricstuff, hoping you will make a lot of money and start to develop the next 1GB version soon...

http://www.etherdecode.com/future.htm

[ajb]

There's plenty that could be done once there's a UI, but that adds a lot of complexity - the whole idea is to keep it simple and cheap. More so as I'm not yet sure how useful it is....

Totally fair.  I would probably be tempted to just slap a USB MCU on there as cheap future proofing and worry about adding configurability later.  But you're fitting into a narrow niche with this product, so it certainly makes sense to keep it simple.

[Howardlong]

Bidirectional can be done with a port mirroring switch, though it's harder to tell which traffic is in which direction. And of course you can use two, so didn't think it was worth it to do a bidirectional version - I may offer a discount for two units in future..

Excellent point, I already have an old 100/10 hub switch that I keep for sniffing, should've figured that out for myself!

[tsman]

Can we get 1000BASE-T support? 

1000BASE-T looks far more complicated.

[mikeselectricstuff]

Can we get 1000BASE-T support? 

1000BASE-T looks far more complicated.

Using a port-mirroring switch is the easiest way

[Howardlong]

Can we get 1000BASE-T support? 

1000BASE-T looks far more complicated.

Using a port-mirroring switch is the easiest way

An old-school 100Mbps hub is even easier, no configuration at all, that's just the way they work, everything is broadcast.

More common than straight 100Mbps hubs are 10/100 hub switches, which have two collision domains, one for 100Mbps and the other for 10Mbps, with a single switch in between the domains. Sniffing at 100Mbps gives you all the 100Mbps traffic.

[mikeselectricstuff]

Can we get 1000BASE-T support? 

1000BASE-T looks far more complicated.

Using a port-mirroring switch is the easiest way

An old-school 100Mbps hub is even easier, no configuration at all, that's just the way they work, everything is broadcast.

Not for monitoring 1G ethernet

[Howardlong]

Can we get 1000BASE-T support? 

1000BASE-T looks far more complicated.

Using a port-mirroring switch is the easiest way

An old-school 100Mbps hub is even easier, no configuration at all, that's just the way they work, everything is broadcast.

Not for monitoring 1G ethernet

I must improve my reading skills.

[mikeselectricstuff]

Back in stock now.

[MarkL]

I bought a couple of etherdecode boards from Mike and thought I'd share how to use it with an Agilent 16700 series logic analyzer.  I have a 16702B with a 16752A acquisition card, but the following should apply to all the combinations of chassis/cards in the 16700 series.

The first thing to note is that the 16700 series already understands various network layers such as TCP, IP, and Ethernet, so it's just a matter of getting the etherdecode data into the analyzer.

The etherdecode board is set up with SW1=OFF and SW2=OFF, and the analyzer is used in state mode (not timing mode).

The etherdecode MARK output is used as a clock input for each data byte (rising edge), and the TRIGGER as a second clock to force a capture at the start and end of the packet (both edges).  So, in this configuration, the analyzer only uses one sample memory location per ethernet data byte, plus an additional two for packet start and end.

A "bus" needs to be defined for the analyzer's trigger and packet decode, and that is done through the "Find Packet" selection in the "Trigger Functions" tab.  This is where the etherdecode DATA, MARK, and TRIGGER outputs are tied together to define the boundaries and contents of a packet.

In the Listing window, the inverse assembler "INETWRKE" needs to be loaded in order to decode the captured packet headers.  Once loaded, the "Max length of packet" in Invasm-->Preferences needs to be adjusted to 1600 from its default of 600 (1500 doesn't quite do it).

The analyzer's full triggering and selective storing is available via pull-down menus for all layers from the Ethernet MAC address through TCP/UDP (beats counting byte offsets!), and there's a trigger out and arm in for other equipment to join in the fun.

I've included a pile of screen shots below to show the flavor of what's possible and the settings I used to get everything to work.  In the screen shots I called TRIGGER "InPacket", meaning we're inside a packet, and MARK "Clk", because, well, it's the data clock.

I didn't set up the second etherdecode board to capture the other direction, but there's plenty of inputs on the analyzer and it would just be a duplication of the settings.  It's easy to instantiate a second analyzer using the system's dual analyzer feature (in Pod Assignment).


Overall, another useful tool in the box.  Thanks, Mike!