Re: FEC 1/3

Thanks Ravi for the comprehensive review.This is exactly what we should
focus on; I mean detailed review of the spec. sections one block by
another until we clarify all the issues required to start the phase of
the RTL coding. The conclusions should be used to update our documents
of spec. accordingly.
I will get back to you tomorrow about the important technical issues.

Let us Keep the good work always to get NOUR chip working!
Thanks ..
Best Regards,
        Mohamed A.SalemOn Sun, 2004-02-29 at 15:00, Ravi Ranjan Kumar
wrote:
> Hi Mohamed,
> I am sorry for the late response. I have started looking at all
> the block once again. I have these findings on CRC block. Please
> give them a consideration. I will review rest the blocks one
> after another and will send you the review comments for the
> same.
> Thanks and Regards
> -- Ravi
> 
> Review comments on CRC block.
> 1. Fig:3, Functionality of some signals are not clear, like
>          a. BitSample
>          b. InoutSelect
>          c. Pass
>          d. EnableBlock
>                I also find that there is no reset signal going
> for the block.
> 
>  
> 2. I propose that the muxing of the txData and rxData can be
> done at time integrtation (Which makes the whole process
> easier).
> 
> 3. I think there is no use of initValue, because for a system it
> will a constant value always. If we have the initValue, then the
> number gates for implementation will increase.
> 
> 4. The behaviour of the signal EOP is not really clear from this
> (I mean whether it's a pulse or a level signal), whcih will
> affect the implementation of the CRC-16 block.
> 
> 5. Let's also add some waveforms to the document, so that will
> make the implementer's life easy and there wont be any wrong
> assumption.
> 
> 6. The clock frequency of the systemclk is not specified (i
> guess it is 1 MHZ).
> 
> I have a proposal for the CRC-16 block, which is very much
> similar to the one in bitstream.pdf but simpler than that. I
> hope you will consider this.
> 
> Description of the crc-16 block:
>           This block implemets a CRC-16 CCITT . The LFSR gets
> initialize with all "0" before it starts calulating/checking the
> CRC-16 for any data stream.
> 
> Signal description
> ------------------
>  Input signals:
>      txRxClk      : 1 MHz clock.
>      sysReset_n   : Active low global reset signal
>      txRxDataIn   : A multiplexed (txData: at the time of 
>                     transmit and rxData: at time of reception) 
>                     data on which the block has to
>                     calculate/check CRC-16
>      init         : A pulse to initialize the LFSR of the CRC-16
>                     block ( This signal should be asserted for
>                     at least a clock period of txRxClk before
>                     start of each transaction).
>      drain        : This signal gets asserted in the transmit
>                     direction only, when the data is over and
>                     the calculated CRC-16 has to be appended,
>                     it should be high of 16 clocks of txRxClk in
>                     turn draining all the 16 bits of CRC-16 
>                     LFSR.
>      enableBlock  : It enables the LFSR to calculate/check the 
>                     CRC-16. (I am not sure whether it is 
>                     required or not, but it's better to have it.
>                     if it is not required it will be tied to 
>                     "1".)
> 
>  Output signals:
>       
>       txRxDataOut  : If the drain == "0"; it holds the value
>                      of txRxDataIn.
>                      If the drain == "1"; it holds CRC-16
>                      calculated value.
>        crcMatch    : Whenever the value of the LFSR is equal to
>                      "0", the crcMatch gets asserted. It is
>                      receive controller's duty to sample it at
>                      the end of the packet, to know whether 
>                      CRC-16 has passed or not.
> 
> 
> 
> ---- On 26 Feb 2004 09:07:33, Mohamed Salem
> ([email protected]) wrote:
> 
> > Ravi,
> > 
> > Thanks for the review of the specs.and the neat presentation
> that is
> > explantory for development.
> > Please, feed us with your point about FEC 1/3 Architecture as
> you noted
> > for me that it might be some review of its architecture posted
> in the HW
> > specs.
> > 
> > Thanks 
> > Best Regards,
> > 
> > 	Mohamed A.Salem
> > 
> > --------------------------
> > NOUR Mailing List
> > Handasa Arabia Organization
> > http://www.handasarabia.org
> > [email protected]
> > 
> > Message number 110
> > 
> > 
> > 
> 
> 
> ________________________________________________
> Get your own "800" number
> Voicemail, fax, email, and a lot more
> http://www.ureach.com/reg/tag
> 
> --------------------------
> NOUR Mailing List
> Handasa Arabia Organization
> http://www.handasarabia.org
> [email protected]
> 
> Message number 112
> 

--------------------------
NOUR Mailing List
Handasa Arabia Organization
http://www.handasarabia.org
[email protected]

Message number 113