[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ethmac] RE: Status of Open Ethernet MAC Core / EventualContribution
Hi ,
can i have verilog code of MII management module and MAC control
module.Waiting for your replay.
Thanking you
yogesh
----- Original Message -----
From: 97024 Hendra Gunawan <hendrag01@s... >
To: ethmac@o...
Date: Mon, 30 Apr 2001 10:51:43 +0700 (JAVT)
Subject: RE: [ethmac] RE: Status of Open Ethernet MAC Core /
EventualContribution
>
>
>
>
> On Thu, 26 Apr 2001, Illan Glasner wrote:
>
> > 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)
> [/cgi-bin/post.cgi?cmd=new&to=igor%20dot%20mohor%20at%20uni-
mb%20dot%20si&msg=/ml-
archive/archives/ethmac/0104/msg00027.shtml]
> > 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
> [/cgi-bin/post.cgi?cmd=new&to=rhofmann%20at%20raygmbh%20dot%
20de&msg=/ml-archive/archives/ethmac/0104/msg00027.shtml]
> > > Sent: 24. april 2001 13:00
> > > To: igorm@o...
> > > 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
> > >
> > >
> >
>
--
To unsubscribe from ethmac mailing list please visit http://www.opencores.org/mailinglists.shtml