|
Message
From: 97024 Hendra Gunawan <hendrag01@s...>
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) [mailto:igor.mohor@u...]
> 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@r...]
> > 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
> >
> >
>
|
 |
Browse
