Literature on 100Base-TX request

I have the IEEE standard 802.3 documents but find they're not the most readable in the world. I find they confuse issues by having many standards in one document.

Is there a more readable document around which is specifically related to 100Base-TX?

Does any one know of example waveforms I could include in a test bench, so I can check the scrambling and descrambling of data? I am aware of a very good site for 10Base-T not for for fast ethernet.

I'm trying to send an Ethernet packet direct from a FPGA though a suitable line driver.

Reply to
Fred
Loading thread data ...

comp.dcom.lans.ethernet is probably the place to ask.

Otherwise, I recommend Rich Seifert's book:

formatting link
Yes, despite the name he discusses previous ethernet standards.

-- glen

Reply to
glen herrmannsfeldt

Hi Glen,

Very much appreciate your response - will try in the alternative news group. Generally if it's been done in an FPGA it would have been done by someone here and would have sourced some literature, other than the IEEE documents.

I've ordered the book, it was quite cheap second hand from Amazon.

Many thanks again.

Fred

Reply to
Fred

I was trying to debug an ethernet interface five years ago or so. At that time I wasn't sure if I was sending the correct CRC or not. To make a long story short, I modified the Linux driver for my Ethernet card so that it ignored the bad CRC bit. In that way I managed to look at my packets even though I normally wouldn't.

Not that it helped though, my CRC was still bad and I still needed to figure out the correct way to send the CRC :) But perhaps this can be of some help to you while debugging your solution.

/Andreas

Reply to
Andreas Ehliar

The difference with 100b-tx is that there have been very few driver chips for it and on the receive side you need significant signal processing and the bit rate at 125 MHz is quite high so almost no one interfaces to it at that level. It's much easier to use a PHY chip which includes all of these and gives you parallel data at 25 MHz. Where did you even get the driver chip? National had one and I got some on Ebay quite a while ago for a prototype but I don't even think they're available anymore. I'd suggest you use a PHY with MII.

Regards, Muzaffer Kal

ASIC/FPGA Design Services DSPIA INC.

formatting link

Reply to
Muzaffer Kal

Even the slowest of FPGAs can be clocked in excess of 200MHz. Spartan

3E for example. Not much of the device needs to be clocked at this speed either. The scrambling is also possible and have done similar for another project some years ago. The output MLT-3 is also feasible. For some reason the IEEE 802 docs don't mention MLT-3 either, I suspect it's in there under another description.

I accept that the driver for the line and magnetics has to be snappy, but was trying to get away from buying a PHY when all the other things can be done in the FPGA. In essence it would be nice to have an example stream to start with, even just in waveform. The notes I read so far is that different scrambling is used for idle and I need to read up more about it.

I do know I have an obvious source of data, ie a real ethernet adaptor but it's not the same as a waveform down on paper, explaining what is scrambled, when and how. They are also very fussy in only accepting data with a correct checksum!

Many thanks for your thoughts.

Reply to
Fred

I have found some software Colasoft Packet Builder which nicely tells you what the checksum would be. I have already done this for 10Base-T and generate packets in the FPGA and drive a fast RS485 driver IC. However 100Base-TX is somewhat more complex, with it's scrambling and

4B/5B encoding.

I'm not familiar with Linux and use Windows We can only be expert in so many things at once!

I don't really want to throw in the towel and buy PHYs!

Many thanks for your reply.

Reply to
Fred

Yes, MLT-3 is described in TP-PMD not in 802.3. And MLT-3 output has some relatively strict slew control requirements so it would be difficult to generate a compliant signal if that's something important.

Not really. There is 4b/5b encoding to go from 4 bits at 25 MHz (ie

100mb/s) and then there is a scrambler at 125 MHz. This scrambler is a self-synchronizing one and there is no CRC associated with it. At 4bit stage if there is no packet data (ie if MAC is not sending anything) a 5 bit IDLE code is inserted in the bitstream continuously.

The checksum is only at the MAC packet level so it's still the same as that in the 10bt standard. After you assemble the packet correctly you send it down to be processed for 100b-tx signalling.

HTH. Muzaffer Kal

ASIC/FPGA Design Services DSPIA INC.

formatting link

Reply to
Muzaffer Kal

Thanks for the info, I'm surprised it's not included in the 802.3 specs.

To be honest, I don't feel limiting slew is going to be important, obtaining enough may be! We'll also be using off the shelf magnetics.

I've come across 4b/5b encoding elsewhere and don't feel it's going to be an issue, the legal codes, the Start and End of Stream Delimiter should be easy to code.

Not sure what you mean by self-synchronizing. This is something I need to look into further.

I though the 5 bit idle code was all 1's but that these were also scrambled?

I've already got a 10Base-T system up and running so feel this part ought to be lower risk!!

Many thanks for your thoughts.

Reply to
Fred

Yes, there is nothing interesting about the encoding in the transmitter.

Sorry about the confusion, I meant that the descrambler at the receiver is self-synchronizing. The scrambler at the transmitter is just a standard scrambler.

Yes the idle code is 5 bits of 1 which is inserted in between actual packet data encoded with 4b5b. Then the resulting 125 Mb/s bit stream is scrambled and mlt-3 encoded before being driven to the wire. Muzaffer Kal

ASIC/FPGA Design Services DSPIA INC.

formatting link

Reply to
Muzaffer Kal

I'm rapidly coming to the conclusion that the purchase of a PHY, given their cost, might be a smart move. Sad really because I would have liked to have coded the whole system in a FPGA. A VHDL test bench would have been ideal!!

Reply to
Fred

Believe me that's the right choice. Also if you have to receive in addition the transmitting, you have to deal with clock recovery and equalization (not to mention blw correction) at the receiver which are much more difficult problems than transmitting mlt3 signal. A 125 (or

250 depending on how you do things) ADC probably at 8 bits (if you have to do blw in digital) probably costs the same as a PHY so go with that and save yourself a world of trouble.

Muzaffer Kal

ASIC/FPGA Design Services DSPIA INC.

formatting link

Reply to
Muzaffer Kal

I see DigiKey have a Micrel part for les than =A31 in 100s. Given the trouble I'd have to go to I'm convinced!!

I doubt I'd need anything like an 8 bit device but as you say there's an awful lot of code which would need writing!

Reply to
Fred

Muzaffer Kal wrote: (snip)

Well, there is a certain symmetry between the two. A self-synchronizing descrambler requires the appropriate logic in the scrambler.

-- glen

Reply to
glen herrmannsfeldt

Fred wrote: (snip)

formatting link
As I understand it, it was borrowed from FDDI and so 802 just references the appropriate FDDI standard.

-- glen

Reply to
glen herrmannsfeldt

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.