LOGIN   :::   RECOVER PASS   :::   GET ACCOUNT    
Browse
  • Projects
  • Code (CVS)
  • Forums
  • News
  • Articles
  • Polls
  •  
    OpenCores
  • FAQ
  • CVS HowTo
  • Mission
  • Media
  • Tools
  • Sponsors
  • Mirrors
  • Logos
  • Contact us
  •  
    Tools
  • Search
      
  • Download Cores (CVSGet)
  •  
    More
  • Wishbone
  • Perlilog
  • EDA tools
  • OpenTech CD
  •  
    Navigation: All forums > Cores > Message List > Message Post

    Message

    Reply | Reply all
    Date Prev | Date Next | Thread Prev | Thread Next Date Index | Thread Index

    From: sharib4444 at rediffmail.com<sharib4444@r...>
    Date: Mon Nov 8 15:54:35 CET 2004
    Subject: [oc] wide crc_32 doesn't need to be slow.
    Top

    hello,
    really itz a gud approach making calc. faster.
    But can anyone suggest me a short mehod to calculate 64 bit crc
    without creating any lookup tables funda?

    sharib4444@r...

    ----- Original Message -----
    From: "llbutcher" <llbutcher@v...>
    To: <cores@o...>
    Date: Wed, 3 Oct 2001 00:52:48 -0700
    Subject: [oc] wide crc_32 doesn't need to be slow.

    >
    >
    > Allan:
    >
    > I looked into making wider CRC's run faster.
    >
    > At first glance, it seems that the logic grows and grows. So
    > wider CRC's would seem to run slower due to logic depth.
    >
    > But I found that the dependence on the internal CRC state does
    > NOT grow more and more complicated.
    >
    > What this means is that you can do a calculation based on the
    > new data in, and combine it with a calculation based on the
    > internal state.
    >
    > The advantage of this is that you can pipeline the complicated
    > calculation based on input data. It can take more than 1 clock.
    >
    > I think that one should be able to make the CRC calculation for
    > any width wider than 32 bits take roughly the same time as
    > a 32-bit calculation, with a pipeline depth which grows with
    > the input width. Plus lots of extra pipeline flops.
    >
    > I included a 64-bit calculation in the crc_32.lib which
    > demonstrates this.
    > I would expect it and wider CRC's to run in about the time it takes
    > to cascade 5 XOR's into a flop.
    >
    > I found a paper on the web by a person from IBM which uses a
    > different tactic. It describes a way to calculate a much wider CRC
    > with simple terms, and then collapse it to the final crc_32 at the
    > end.
    >
    > As you say, it looks like a 64-bit CRC should be able to run at
    > 10 GBit/sec in an FPGA. I have no idea what IBM needs to do
    > checksums on which runs substantially faster. Curious.
    >
    > blue beaver
    >
    >
    > > You reach a point where making the bus wider doesn't make the
    > CRC
    > > faster, in terms of bits per second. The number of inputs to
    > each XOR
    > > grows with the bus width.
    > >
    > > I was doing some parallel PRBS experiments recently, and I
    > found in some
    > > cases that the 128 bit bus produced lower bit rates than a 64
    > bit
    > > design.
    >

     
    Copyright (c) 1999 OPENCORES.ORG. All rights reserved.