RE: [ethmac] TX MAC

["NewsGroup" <nbase@nbase.com>]

12-Oct-00

   Hi,

1.
	in this case you have to correct your sch. as is show 4 if I'm not looking
in the wrong place.


2.
	The PAD can be any number for most protocol I'm aware of , the one
exception I'm aware of is id you need to encapsulate the ethernet with PPP
maybe other know about other exception, but apart from that the pad can be
any number from the simple reason that 0 is also a valid number so the
detrmination of where the pad start is not based on looking for 0.

3.
  oh for sure the CRC have 32 FF what I'm suggesting is that you will have
something like :

D[0] = (calc) ? <crc equation> (shift) ? Q[4] : Q[0] ;

this way instead of having the 32 bit locked and every time look on
different 4 you shift them and while this mean extra stage in the crc it
save stage in the large mux you have in the out and thus enabling working in
higher frequancy as this moudle can be used for many other designes except
Eth10/100 but again this is only suggestion.

4.

  Yes, even tho' I need to think a bit more on your ipg issue as it look to
me as you might "waste" some clock in certain condition.

5.
   no once you "see" collision you simple need to keep transmiting jam so
the other station/s will "see" it as well and there is no need to send sdf
or even continue with the preamble , simple move to jam and make sure you
obay the two rules:
a. min jam is 32BT
b. min length is 96BT

and this go with my wondering in respect to what I wrote in (4)

6.
   :-)

7.

I belive that in order to not "waste" clock but also make the design simple
you should have two type (maybe 3 ) of jam 32BT,96BT (and 64BT) and depend
on where the collision occur you use the appropriate jam, of course you can
use counter to reach 96BT and 32BT "rules" but this is up to you.

have a nice day

   Illan



-----Original Message-----
From: owner-ethmac@opencores.org [mailto:owner-ethmac@opencores.org]On
Behalf Of Novan Hartadi
Sent: Friday, October 06, 2000 10:10 PM
To: ethmac@opencores.org
Subject: RE: [ethmac] TX MAC



Hi all,

> 	Few comment in respect to
> http://www.opencores.org/cores/ethmac/blocks_1/txethmac/txmodules.shtml
>
> 1.
> the data the come in seem to be 4 bit and so is the data that go out , if
so
> why do you have a select for the data on the output mux ?

the data come in is 8 bit wide

> 2.
> the JAM and pad can be any value so why not simple leaving the mux on what
> ever value he was and thus saving ?

For JAM pattern I know that any value will be accepted.
But for pad, as far as I know (correct me if I'm wrong) the pattern is
'0000'.

> 3.
> the CRC you can also save as you read only 4 bit so simple shift the other
> bit "up" every clock and thus the mux can have only one state for the crc

I think, it depends on how CRC Generator will give CRC number to data
multiplexer.
In this case, I propose the CRC Generator will store the last valid result
of CRC number (32 bits) to its output after the last byte of data.

> 4.
> IFP you said that in FDX "this module will ignore any carrier signals" is
> this mean that the trasmite available will be always 1 ?
> I would think that you shoudl in FDX look on the tx_en.

I mean that the counter will run to get inter frame gap without watch
carrier signal. And the transmit available is a pulse signal that will be
activated every 96 bit times.

And in Full Duplex, as you suggested I will add tx_en to IFG Timer.
So, in Full Duplex the IFG Timer will count inter frame gap after tx_en
has been disappeared. Is it correct ?

> 5.
> why do you have the transmite preamable and trasmite sfd as input to the
> collision counter ?
> I would thing that trasmite preamble is enouth (or simple tx_en) for
knowing
> you are trasmiting and the trasmite 64 is enouth for determine wether it
is
> late collision or not.

Is it true that if collision is detected while preamble and sfd is being
transmitted then Tx MAC will continue transmit preamble or sfd before
sending JAM to the medium ?

So, I add transmit preamble and transmit sfd to the collision counter in
order to give announcemet.

> 6.
> Why do you have a coll_event_p in the random module ?
> it is more advisable that the random number keep runing with the collision
> counter of course used for masking as locking the random might cause in
two
> simlar machine getting into same backoff number and thus never been able
to
> get out of it.
> if you don't lock the ppm of the clock's will cause even in two identical
> machine to  have eventually different numbers.

Ehm ... I think you're right. I will remove coll_event_p from
RandomNumberGenerator. Then this module will keep runing to generate
random number.

> 7.
> The JAM timer you have is 64BT but if mean that you "waste" some clock as
if
> the packet was collide after it send 64 byte a 32BT of JAM is sufficient,
on
> the other hand if the packet was collide on the preamble you might need
more
> than 64BT, as you need minimum of 96BT.

What about the standards ? If it is still conform with the standards, I'll
agree with your suggested. So, how long should we define JAM timer for
every case ?

> 8.
> in the CRC as I mention above I belive it will give you better permormance
> if you only send out 4 bit.

I'll consider your advice, thanks.

> have a nice day
>
>    Illan

Have a nice weekend

- novan hartadi -