Re: How to use easics crc generator?

Discussion in 'VHDL' started by Jan Decaluwe, Jun 24, 2003.

  1. Jan Decaluwe

    Jan Decaluwe Guest

    Mike Treseler wrote:
    >
    > Jan Decaluwe wrote:
    >
    > > The bad one is the following. A coding style using
    > > for loops and variables is forbidden by many "gurus".
    > > In fact, in Verilog, the language used for the most
    > > advanced ASIC designs, you shouldn't use them. If you
    > > take the Verilog "gurus" seriously, that is. Unfortunately,
    > > many people do, especially managing types. So if you
    > > just need to stay out of trouble, here's your solution.

    >
    > My advice applies only to VHDL and FPGAs.
    > I know very little about ASICs and Verilog.
    >
    > > The good one is the following. General synthesis tools
    > > don't necessarily perform well on specialized
    > > optimizations. For-loops are great as a description tool,
    > > but they may result in an inefficient "starting point"
    > > structure for synthesis.

    >
    > Try it and see. I found no substantial difference
    > using Easics vs leo or synplicity on parallel
    > 16 and 32 bit FCS checkers for an FPGA target.


    Try and see is definitely the good advice.
    My experience dates back several years, with Synopsys -
    other synthesis tools / versions may behave differently,
    especially if they would contain xor-specific optimizations,
    as they perfectly could.

    Also, for the record: a "stand-alone" experiment with
    only the CRC functions is not sufficient to judge well.
    The functions can and will be used in a context -
    I remember that the difference became especially significant
    within larger modules and for large bit
    widths (e.g. 32) and large poly's (e.g. Ethernet).

    However - if there's no significant difference, then
    there is definitely no reason to use a specialized solution.

    Regards, Jan

    --
    Jan Decaluwe - Resources bvba
    Losbergenlaan 16, B-3010 Leuven, Belgium
    mailto:
    http://jandecaluwe.com
     
    Jan Decaluwe, Jun 24, 2003
    #1
    1. Advertising

  2. Jan Decaluwe

    Jos Guest

    Jan Decaluwe wrote:
    >
    > Mike Treseler wrote:
    > >
    > > Jan Decaluwe wrote:
    > >
    > > > The bad one is the following. A coding style using
    > > > for loops and variables is forbidden by many "gurus".
    > > > In fact, in Verilog, the language used for the most
    > > > advanced ASIC designs, you shouldn't use them. If you
    > > > take the Verilog "gurus" seriously, that is. Unfortunately,
    > > > many people do, especially managing types. So if you
    > > > just need to stay out of trouble, here's your solution.

    > >
    > > My advice applies only to VHDL and FPGAs.
    > > I know very little about ASICs and Verilog.
    > >
    > > > The good one is the following. General synthesis tools
    > > > don't necessarily perform well on specialized
    > > > optimizations. For-loops are great as a description tool,
    > > > but they may result in an inefficient "starting point"
    > > > structure for synthesis.

    > >
    > > Try it and see. I found no substantial difference
    > > using Easics vs leo or synplicity on parallel
    > > 16 and 32 bit FCS checkers for an FPGA target.

    >
    > Try and see is definitely the good advice.
    > My experience dates back several years, with Synopsys -
    > other synthesis tools / versions may behave differently,
    > especially if they would contain xor-specific optimizations,
    > as they perfectly could.
    >
    > Also, for the record: a "stand-alone" experiment with
    > only the CRC functions is not sufficient to judge well.
    > The functions can and will be used in a context -


    Absolutely right. Synthesis tools tend to converge to an optimal
    solution when synthesized "stand-alone". When buried in a bunch of other
    logic the synthesizer doesn't find the optimal solution.

    My favourite in that respect is the recursive xor or adder tree versus
    the loop generated xor or adder.
    Same phenomenon , same result.

    Regards,

    Jos

    > I remember that the difference became especially significant
    > within larger modules and for large bit
    > widths (e.g. 32) and large poly's (e.g. Ethernet).
    >
    > However - if there's no significant difference, then
    > there is definitely no reason to use a specialized solution.
    >
    > Regards, Jan
    >
    > --
    > Jan Decaluwe - Resources bvba
    > Losbergenlaan 16, B-3010 Leuven, Belgium
    > mailto:
    > http://jandecaluwe.com
     
    Jos, Jun 24, 2003
    #2
    1. Advertising

  3. Jan Decaluwe

    John Moore Guest

    Sorry to be a bore, but I'm still having trouble getting the generator
    working in an ethernet transmitter.

    It works fine in a receiver if I preload the crc with (others <= '1'), and
    feed in the input bytes in bit reversed form, and look for an answer of
    x"c704dd7b" at the end of the frame.

    Presumably I should also preload with (others <= '1') for a transmitter as
    well? This doesn't give the right answer (which I know from other
    applications) after loading the last byte of the frame. Should I be doing
    anything else?

    Thanks for any further help
    John Moore
     
    John Moore, Jun 25, 2003
    #3
  4. John Moore wrote:
    > Sorry to be a bore, but I'm still having trouble getting the generator
    > working in an ethernet transmitter.
    >


    We only do monitors so I haven't actually done this,
    but in theory, the FCS you add to the end of the
    packet should be the payload remainder with each
    octet bit reversed, then the whole thing inverted.


    -- Mike Treseler
     
    Mike Treseler, Jun 25, 2003
    #4
  5. Jan Decaluwe

    John Moore Guest

    > We only do monitors so I haven't actually done this,
    > but in theory, the FCS you add to the end of the
    > packet should be the payload remainder with each
    > octet bit reversed, then the whole thing inverted.
    >

    Thank you Mike. After reversing the CRC bytes, reversing the bits in each
    byte, and inverting the bits (!) I have got the transmitter working as well.
    Having a parallel CRC calculation is much nicer than a serial bit by bit
    method. I can use a slower clock for a start.

    John Moore
     
    John Moore, Jun 26, 2003
    #5
  6. John Moore wrote:

    > Thank you Mike. After reversing the CRC bytes, reversing the bits in each
    > byte, and inverting the bits (!) I have got the transmitter working as well.
    > Having a parallel CRC calculation is much nicer than a serial bit by bit
    > method. I can use a slower clock for a start.


    You are welcome. Glad it works for you.
    Consider posting a snippet of the
    generator code to share with the group.

    -- Mike Treseler
     
    Mike Treseler, Jun 26, 2003
    #6
  7. John Moore wrote:

    > The generator code is attached. It's trivially simple.


    Good example, thanks.
    Getting code working and making it look simple isn't simple.

    > I hope this may help someone else.


    It has.

    -- Mike Treseler
     
    Mike Treseler, Jun 27, 2003
    #7
  8. Jan Decaluwe

    cain

    Joined:
    Aug 25, 2008
    Messages:
    1
    easics CRC implementation

    hello all - i'm a complete newbie in the CRC world and have done quite a bit of googling on the topic, and eventually landed at the easics web site. i got their module for the Ethernet CRC32 module up and running and i have a few questions regarding the results:

    1) i used a software algorithm with the same polynomial to generate the CRC for a data packet to send. i assumed that when generating the CRC that it initially had to be set to "FFFFFFFF", and on the receiving end, i must do the same thing before checking the data. this goes for inverting the result at the end as well (inverted by the transmitter = inverting by the receiver). this is sound, correct?
    2) the comments in the CRC32 function say that "the first serial data bit is D(7)" , meaning, for all bytes, they must be bit reversed. easy enough. but which byte needs to come first? say for a 64 bit word, do i need to feed bits 63 downto 57, bit reveresed, first? or the 7 downto 0, bit reveresed, first?

    I've tried both methods of feeding bytes into the algorithm, but I still can't get the CRCs to match. I tend to think that the SW generated CRC is correct in that it's been in use here for awhile, so I'm obviously missing something on the receiving end. i'm just not sure what. any tips would be greatly appreciated!
     
    cain, Aug 25, 2008
    #8
  9. Jan Decaluwe

    AK51

    Joined:
    Dec 29, 2008
    Messages:
    3
    Hi, I can get the correct CRC for the first byte, but that's it.
    If I feed the second byte, the CRC is wrong. Do I need to modify the return CRC value before I feed into the module? Right now, I have a direct feeding. Thx.
     
    AK51, Dec 29, 2008
    #9
  10. Jan Decaluwe

    revol212

    Joined:
    Apr 30, 2009
    Messages:
    1
    Hi, I can get the correct CRC for the first byte, but that's it.
    If I feed the second byte, the CRC is wrong. Do I need to modify the return CRC value before I feed into the module? Right now, I have a direct feeding. Thx.
    -------------------------------

    AK51,

    I ran into the same problem while trying to compare the output of the generator with the output of the Zilog MPSC chip. The answer can be found here under the Q&A for Synchronous Modes section h_t_t_p://www-clips.imag.fr/projet-systeme/Z85230/chapter7.pdf

    Basically the second byte consists of {first_byte[7:6],second_byte[5:0]} in verilog or first_byte (7 downto 6) & second_byte (5 downto 0) in VHDL.

    Hope that helps! It took me a few hours to find out.
     
    revol212, Apr 30, 2009
    #10
  11. Jan Decaluwe

    rellur

    Joined:
    Nov 26, 2010
    Messages:
    1
    Hi All,

    I have been facing problems with easics crc16 (USB) generator. I have used the module at their website in by RTL and i plan to build a serial type crc generator to verify it. As per by calculation for CRC16 (X16+X15+X2+1) if the first 8bit data is 24 then crc output for this should also be 24. but i dont see that happening in the RTL. can you please suggest ? Should the data be manipulated before sending it in for crc calculation ?
     
    rellur, Nov 26, 2010
    #11
  12. Jan Decaluwe

    OutputLogic

    Joined:
    May 20, 2009
    Messages:
    8
    OutputLogic.com CRC generator

    Hi,

    You can try using a different CRC generator tool on OutputLogic.com
    It has a user forum with several similar questions that have been already answered.

    Thanks
     
    OutputLogic, Nov 26, 2010
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Moore
    Replies:
    1
    Views:
    2,436
    Alan Coppola
    Jun 26, 2003
  2. Shukla, Sunil Kumar

    parallel CRC equation generator

    Shukla, Sunil Kumar, May 31, 2005, in forum: VHDL
    Replies:
    2
    Views:
    1,177
    Pete Fraser
    May 31, 2005
  3. Mamut

    crc-8 and crc-16 code...

    Mamut, Feb 21, 2007, in forum: C++
    Replies:
    5
    Views:
    4,116
    Victor Bazarov
    Feb 22, 2007
  4. `Zidane Tribal
    Replies:
    1
    Views:
    2,556
    Joe Smith
    Jul 28, 2007
  5. `Zidane Tribal
    Replies:
    3
    Views:
    269
    Sisyphus
    Jul 27, 2007
Loading...

Share This Page