RE: [ethmac] TX MAC

[Novan Hartadi <novan@vlsi.itb.ac.id>]

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 -