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.

(comp.dcom.lans.ethernet added)
Fred wrote:

> 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.

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

Otherwise, I recommend Rich Seifert's book:

http://search.barnesandnoble.com/Gigabit-Ethernet/Rich-Seifert/e/9780201185539

Yes, despite the name he discusses previous ethernet standards.

-- glen

On Oct 15, 1:47=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> (comp.dcom.lans.ethernet added)
>
> Fred wrote:
> > I have the IEEE standard 802.3 documents but find they're not the most
> > readable in the world. =A0I 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? =A0I am
> > aware of a very good site for 10Base-T not for for fast ethernet.
>
> comp.dcom.lans.ethernet is probably the place to ask.
>
> Otherwise, I recommend Rich Seifert's book:
>
> http://search.barnesandnoble.com/Gigabit-Ethernet/Rich-Seifert/e/9780...
>
> Yes, despite the name he discusses previous ethernet standards.
>
> -- glen

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

On 2008-10-17, Fred <fred__bloggs@lycos.com> wrote:
> scrambled, when and how.  They are also very fussy in only accepting
> data with a correct checksum!

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

On Thu, 16 Oct 2008 10:47:38 -0700 (PDT), Fred
<fred__bloggs@lycos.com> wrote:
>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.

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.
http://www.dspia.com

On Oct 17, 6:01=A0am, Muzaffer Kal <k...@dspia.com> wrote:
> On Thu, 16 Oct 2008 10:47:38 -0700 (PDT), Fred
>
> <fred__blo...@lycos.com> wrote:
> >Very much appreciate your response - will try in the alternative news
> >group. =A0Generally if it's been done in an FPGA it would have been done
> >by someone here and would have sourced someliterature, other than the
> >IEEE documents.
>
> 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.
>

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.

On 17 Oct, 05:56, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote:
> On 2008-10-17, Fred <fred__blo...@lycos.com> wrote:
>
> > scrambled, when and how. =A0They are also very fussy in only accepting
> > data with a correct checksum!
>
> 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

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 <ducks to avoid remarks>
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.

On Fri, 17 Oct 2008 00:52:22 -0700 (PDT), Fred
<fred__bloggs@lycos.com> wrote:

>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.
>
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.

>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.
>
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.

>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!

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.
http://www.dspia.com

Fred wrote:
> On 17 Oct, 05:56, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote:
>> On 2008-10-17, Fred <fred__blo...@lycos.com> wrote:
>>
>>> scrambled, when and how.  They are also very fussy in only accepting
>>> data with a correct checksum!
>> 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
> 
> 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 <ducks to avoid remarks>
> 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.

Hi Fred,

   Having worked at National in 10/100/1000BT PHY line, I would 
recommend you getting a PHY and avoid headaches. Even if you could get 
it to communicate, you'll run into issues when things change: even a new 
or longer/shorter cable will make your connection unreliable.

my .02c

Cheers,
-P@

On Oct 17, 4:33=A0pm, Muzaffer Kal <k...@dspia.com> wrote:
> On Fri, 17 Oct 2008 00:52:22 -0700 (PDT), Fred
>
> <fred__blo...@lycos.com> wrote:
> >The output MLT-3 is also
> >feasible. =A0For some reason the IEEE 802 docs don't mention MLT-3
> >either, I suspect it's in there under another description.
>
> 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.
>

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 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. =A0In essence it would be nice to have an
> >example stream to start with, even just in waveform. =A0The notes I read
> >so far is that different scrambling is used for idle and I need to
> >read up more about it.
>
> 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.
>

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 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. =A0They are also very fussy in only accepting
> >data with a correct checksum!
>
> 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.
>

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.