[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ethmac] RE: Status of Open Ethernet MAC Core / EventualContribution
Hi.
There are several ways how to get the files, described here:
http://www.opencores.org/cvs.shtml/)
One of the ways is to go to:
http://www.opencores.org/cvsweb.shtml/ethernet/rtl/verilog/
and download files one by one.
Regards,
Igor
> -----Original Message-----
> From: owner-ethmac@opencores.org [mailto:owner-ethmac@opencores.org]On
> Behalf Of yogesh_bp@yahoo.com
> Sent: 12. marec 2002 6:13
> To: ethmac@opencores.org
> Subject: 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
>
--
To unsubscribe from ethmac mailing list please visit http://www.opencores.org/mailinglists.shtml