RE: [ethmac] RE: Status of Open Ethernet MAC Core / Eventual Contribution

["Illan Glasner" <iglasner@zumanetworks.com>]

26-Apr-01

   Igor Hi,

	As for test bench, one of the good thing in Ethernet is that
while it have it's own chalange it is not as complicated as
Intel-Pentium etc meaning a simple random test bench will give a good
coverage.

basicly the test bench can be as followed :

a random packet generator which will inculde all the field that can be
randon as random while field that need to be specify will be define and
I will explain :
let's take the vlan as example than if a packet is vlan type it should
have the 8100 in the right position and this can't be random BUT the
vlan itself can be random.
so the packet generator can have certain variable as random and base on
them we constart the packet for example:

vlan_pkt=$random(seed);
fc_pkt=$random(seed);

or if we need range than :
length = ({$random(seed)}%1600+64);

but sometime we might have limitation for example packet can be 64 byte
WITH vlan and this mean that if your MAC is the type that know how to
strip the vlan it need to append padding as otherwise the packet will be
only 60 byte and in such case if your MAC for example support vlan strip
BUT don't support the add of the pad you need the packet to be at least
68 byte so you will also have something like :

if (vlan_pkt) length = ($random(seed)}%1600+68)

or you can also check if the packet is less than 68

if (vlan_pkt && (length<68)) length = length+4 ;

or any other way.

and all the rest of the data should be pure $random(seed). and of course
the seed should be change every test. 

I myself have a line saying

seed = `SEED where I have a file call seed_num that have one line in it
which is `define SEED 12345678 and this file I include in the test bench
and every time I run the test using sed I replace the SEED number with a
different number which can be for example the time.

and so you will have all the other parameter who ever you need as random
meaning for example the IPG. also if you lan to support gambo packet the
length need to be up to 4K or if you plan to support back to back packet
the IPG need to go as long as 1 clock.

as for preamble/sfd since the spec define that we need to support even 1
single byte we need to random the number of nibble from 16 (full
preambale and sfd) to 2 (only sfd).

we can use the same file to generate packet to be used to send packet
from the MAc outside (to the phy) or from the outside (phy) to the MAC
and so if all is randomize we shall have the colliwion in all kind of
places which is good.

and if we want to verify excessive collition and backoff we need to add
the capability for the packet trasmite from the phy and fom the MAC to
random small number as otherwise we shall never get excessive collition
this mean that it will be a good idea maybe to add a input signal that
is used for testing while in real it will be hocked to GND and when it
is one the backoff algoritem only random number between let say 0-3.
also any other big counter we can have this input to reduce simulation
time for example if we want to check flow control we really don't want
to wait FFFFx512BT for Xoff so once we see the 512BT clouter work
properly this signal can checnge this counter to count only from 0-1
this way we can run the simulation 512 times faster.

and than come to clock if your FIFO suppose to support certain PPM than
you need to have your enviroment to have random in each test also the
clock PPM and it can be + or - so sometime the tx_clk is a biut faster
thean the rx_clk and sometime the other way arrond for this you will
most likely need to have this moudle with timescale of 1ps instead of
the regular 1ns/1ns or 1ns/100ps.

Now to verifying, a good approach is to have the wave ONLY used for
debug not for verify as we can't really check thousands of packet using
waves, so one way is that every time you send a packet you send to the
log file something like :
$display("%0t XX %m PTX YYY pktnum(%d) vlan(%d) fc(%d) ...",%time,....);
and similary once the packet is recived AND pass crc check in the recive
behave module , we print similar thing only with PRX instead of PTX and
than using script we can diff and see that all packet was send.
if we have few mac we need to had also the mac number and if we have few
target we need to add the target but for single MAC the above I belive
will be sufficient.

XX is for the person name letter for example in my case it is IG igor I
belive is IM and so on this way it easy easy to grep in case of several
people that work togther each one for his own info.

YYY should be either nothing or the word BAD and this is because one of
the parameter we should random is wether the trasmite send packet with
bad CRC or anything else that should be reject and this way when we do
the diff to test that all the packet arrive we don't look for packet
that have the word BAD in the PTX or vice versa if such packet did go
out it mean our filter in the MAC don't work properly.

small additon it incase you allow the MAC to modify some of the packet
as than the PRX will not be like PTX and this mean that your sending
module need to expect what the MAC should send and will print also let
say PEX and the diff will be between the PRX and PEX while the PTX now
will only be for monitoring what we send.

But in real nothing work 100% in the first phase and so it would be good
if there are also few monitor files that have a switch let say mon_on so
once we clean the code we can turn off the switch and save time and this
monitor file will tell us as the packet move through the MAC for example
we can print the data of each packet when sending than we print the data
when it go to the FIFO when it go out fo the FIFO and so on. now if
something went wrong we compare the data and see where did the problem
start BEFORE we start lunching the waves as waves are slow work and this
monitoring will enable us if we do it carfully to know exactly where the
problme is meaning at what time and which module and only than we shall
run the waves for this time and find the bug or the source for it and
track it backward.

small advise that is not easy but it is up to you, once you finish debug
any certain module RE-CODE it as what happen many times you first desing
something clean that start patching it and before you know the code look
not only "ugly" but also it is no more efficient and you might loosing
clocks etc so once you figure all the bugs and problem re-code it clean.

Did I missed anyhing ? if so go ahead and ask and I will do my best to
answer.

two additional comment:

1. 
Since you target FPGA you might also want to tell to which FPGA you
target and more than simple saying either Altera or Xilinx and wether it
will be this size or another it is importent to decide on the family
type as the 10K /20K/20KE or amybe even 20KC and similar
Spartan/Virtex/VirtexE or even Virtex2 have each own it capabilities and
while the frequancy you want to work can be quite low as 25M if you are
not carefull you will have timing issue even with this.

so you might want to add guidlines/requirment like any module sample the
data in the in ans send it after FF wand so on. some lines might have
exception but otherwise you might find you have the code working and
simulation look good but you can't meet the timing.

and this go back to the family as while your code might run on the let
say Virtex2 if you only plan to put in in sprtan you will need stronger
demand let say for example no more than 3 LUT or any other requirment.

and of course no need to forget the speed dash as 1 in altera or 8 in
xilinx are great but they do cost primium and 3/6 might be cheap but
need tighter desing, just something you need to think.

another small example is memorey and I mean "real" memoreis as you might
choose a family that have memorey and so to save FF you can use the FIFO
and statistic counter in memorey but memorey access if have big depth
need addr of several bits and this again is a point need to be design
carefully in FPGA especialy if you look ofr cheap one.
 
2.
as for 8 weeks well ... good luck :-)

have a nice day

   Illan


-----Original Message-----
From: Igor Mohor (uni-mb) [mailto:igor.mohor@uni-mb.si]
Sent: Thursday, April 26, 2001 1:06 AM
To: Raymund Hofmann
Cc: Ethmac@Opencores. Org
Subject: [ethmac] RE: Status of Open Ethernet MAC Core / Eventual
Contribution


Hi, Raymund.

Sorry for the late reply, I was out of town. It would be great if you
could help us building the eth MAC. You can start by reading my comments
below :)

> -----Original Message-----
> From: Raymund Hofmann [mailto:rhofmann@raygmbh.de]
> Sent: 24. april 2001 13:00
> To: igorm@opencores.org
> Subject: Status of Open Ethernet MAC Core / Eventual Contribution
>
>
> Hi,
>
> I have quickly viewed all Information about the Ethernet Core on
> opencores.org.
> As i see it, some verilog modules are finished, but most of it
> still has to
> be done.
> Also some concepts do not seem to be finished.
> As i understood the MAC is supposed to read descriptors via DMA over
the
> Wishbone interface, but i could not understand how with the existing
> definition of the Wishbone Interface in the doc it should apply a
> address to
> read the Descriptor's (and read/write data blocks).

The DMA and the buffer descriptor logic both changed. Don't worry about
that. I'll update the ethernet MAC core spec. within few days. And the
update also includes the host interface with the descriptors and DMA.


> As i would like to have a minimalistic Ethernet MAC for a embedded
system
> FPGA, i could also contribute something to this Project.
> Unfortunately my Experience related to Ehternet is very limited.
> I designed a few FPGA's and a 200K Stdcell Asic (Video related)
> with Verilog
> (Synopsys / Verilog XL).
> What do you think will be the Proceeding of the Ethernet Project ?
> Could i contribute some useful work, despite my lack of Ethernet
> experience
> ?

Sure. We are all here to learn :)

The current status is:
- Rx module is finished by Mahmud. I just try it a bit but I didn't
really
test it. I don't know if he's improving the core or that is the final
version. We need his answer about that. Somebody also needs to spent
more
time on testing the core.

- Tx module is finished by Novan. He unfortunatelly left the team
because if
his work and some other reasons. Thanks, Novan.
This core also needs to be tested.

- MAC Control module. Nothing has been done so far.

- MII Management module: I finished it and test it. I also posted the
test
bench program on the net. So far I'm satisfied with it. For double check
somebody should spend some time in testing it.

- Host interface with the buffer descriptors and DMA: Nothing done, yet.
I
would like to do it, since I'm good contact with the RISC and DMA
developers.

- Ethernet specification update is in progress. I'll finish that in
short
time. I already promised that but I was working on some other things,
too.

It would be great to know what kind of tools you guys use. You can also
send
me a direct reply. Some tools is possible to get as a opencores
developer.
Check the webpage.

Illan Glasner seems to have a lot of experiance with the eth mac. It
would
be really great if he could help with advices. I would be specifically
happy
on guidelines on how to test the cores (detailed guidlines would be
prefered).

I know that all of us are busy with doing something and nobody can push
anybody else but in order to finish things in some finite period of time
I
would like all of you to allowe me to ask you about the status time to
time.
If that is acceptable with everybody, that is great, if not, give me
your
ideas.

Our goal is to have a working version in FPGA in 8 weeks from now.



Regards,
	Igor


>
> best regards
> Raymund Hofmann
>
> RAY Electronic-Design GmbH
> Lagerstrasse 49
> 64807 Dieburg, Germany
> Tel ++49 6071-986000
> Fax ++49 6071-9860098
>
>