fast adder and equal

Sep 28, 2004 11 Replies

Hello



I need information about creating a fast adder (n = n + 1) and a fast equal (a = b). (both 28 bit signals)



I'm going to create a fast binary counter in a FPGA Spartan II



Would it be faster to create several 4 bit LFSR and a converter to binary than a normal binary counter?



I need the binary output because it's a timestamp



I need to be able to reset the counter to zero when it reaches a certain number. (reset every second by a pulse per second signal or if the reference signal is missing when the counter is equal to the measured frequency of the clock)



The goal is to use a clock frequency on 100MHz + 25% margin.



Thanks Rune


You can use a 28 bit binary up counter and comparator or also recommended is a 28 bit downcounter which issues a carry when it has reached zero. In this case the reset signal loads a preset value. The timestamp is a subtraction then, assumedly in software.

Rene

Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.net

Rune Christensen wrote: : Hello

: I need information about creating a fast adder (n = n + 1) and a fast equal : (a = b). (both 28 bit signals)

: I'm going to create a fast binary counter in a FPGA Spartan II

: Would it be faster to create several 4 bit LFSR and a converter to binary : than a normal binary counter?

: I need the binary output because it's a timestamp

: I need to be able to reset the counter to zero when it reaches a certain : number. (reset every second by a pulse per second signal or if the reference : signal is missing when the counter is equal to the measured frequency of the : clock)

: The goal is to use a clock frequency on 100MHz + 25% margin.

It depends on the FPGA family and the toolchain you use and if "b" is a constant or a input.

For most families, you requirements should be easily fullfilled. As first test, write some HDL code, synthesize and place the design eventually giving constraints describing your requirements and look at the reports.

Bye

Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

I have already done that but my goal is 8 ns and a simple implementation gives

Slack: -1.380ns (requirement - (data path - clock path skew

  • uncertainty)) Source: cnt_0 (FF) Destination: cnt_3 (FF) Requirement: 8.000ns Data Path Delay: 9.373ns (Levels of Logic = 9) Clock Path Skew: -0.007ns Source Clock: clk_BUFGP rising at 0.000ns Destination Clock: clk_BUFGP rising at 8.000ns Clock Uncertainty: 0.000ns

-- clock counter counter : process(clk, cnt, freq_meas) begin if (clk'event and clk = '1') then if (reset = '1') then cnt

equal

reference

the

If you don't like the idea of a down-counter where the carry out loads your count value... If you don't want to offset your counter by 2^n-MaxCount... If you want everything, consider pipelining. It uses the same number of resources as the "reset on equal" because the register packed with the equal signal would go unused: pipeline the terminal count.

By determining the terminal count by registering the comparison to the terminal count minus 1, you get the zero-offset and much greater than 100MHz timing.

Rune, Have you run the timing analyser to find out which path is failing? The '(Levels of Logic = 9)' implies that it's not the carry chain, which, for a

skew

For a timestamp, why can't you write out the value of the LFSR, and decode it later at data analysis time? The sequence is predictable.

28 bits is a lot, though. How about two smaller LFSR's, with relatively prime cycle lengths. A small lookup table would convert each to a binary count, and then you can easily figure out the actual count.

-- glen

"Symon" skrev i en meddelelse news: snipped-for-privacy@uni-berlin.de...

================================================================================ Timing constraint: TS_clk = PERIOD TIMEGRP "clk" 8 nS HIGH 50.000000 % ;

3436 items analyzed, 17 timing errors detected. (17 setup errors, 0 hold errors) Minimum period is 8.347ns.

-------------------------------------------------------------------------------- Slack: -0.347ns (requirement - (data path - clock path skew

  • uncertainty)) Source: cnt_0 (FF) Destination: cnt_19 (FF) Requirement: 8.000ns Data Path Delay: 8.337ns (Levels of Logic = 11) Clock Path Skew: -0.010ns Source Clock: clk_BUFGP rising at 0.000ns Destination Clock: clk_BUFGP rising at 8.000ns Clock Uncertainty: 0.000ns

Data Path: cnt_0 to cnt_19 Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- CLB_R23C3.S0.YQ Tcko 1.292 cnt cnt_0 CLB_R28C2.S0.F1 net (fanout=4) 1.800 cnt CLB_R28C2.S0.COUT Topcyf 1.486 _n0006 Madd__n0006_inst_lut2_01 Madd__n0006_inst_cy_0 Madd__n0006_inst_cy_1 CLB_R27C2.S0.CIN net (fanout=1) 0.000 Madd__n0006_inst_cy_1 CLB_R27C2.S0.COUT Tbyp 0.096 _n0006 Madd__n0006_inst_cy_2 Madd__n0006_inst_cy_3 CLB_R26C2.S0.CIN net (fanout=1) 0.000 Madd__n0006_inst_cy_3 CLB_R26C2.S0.COUT Tbyp 0.096 _n0006 Madd__n0006_inst_cy_4 Madd__n0006_inst_cy_5 CLB_R25C2.S0.CIN net (fanout=1) 0.000 Madd__n0006_inst_cy_5 CLB_R25C2.S0.COUT Tbyp 0.096 _n0006 Madd__n0006_inst_cy_6 Madd__n0006_inst_cy_7 CLB_R24C2.S0.CIN net (fanout=1) 0.000 Madd__n0006_inst_cy_7 CLB_R24C2.S0.COUT Tbyp 0.096 _n0006 Madd__n0006_inst_cy_8 Madd__n0006_inst_cy_9 CLB_R23C2.S0.CIN net (fanout=1) 0.000 Madd__n0006_inst_cy_9 CLB_R23C2.S0.COUT Tbyp 0.096 _n0006 Madd__n0006_inst_cy_10 Madd__n0006_inst_cy_11 CLB_R22C2.S0.CIN net (fanout=1) 0.000 Madd__n0006_inst_cy_11 CLB_R22C2.S0.COUT Tbyp 0.096 _n0006 Madd__n0006_inst_cy_12 Madd__n0006_inst_cy_13 CLB_R21C2.S0.CIN net (fanout=1) 0.000 Madd__n0006_inst_cy_13 CLB_R21C2.S0.COUT Tbyp 0.096 _n0006 Madd__n0006_inst_cy_14 Madd__n0006_inst_cy_15 CLB_R20C2.S0.CIN net (fanout=1) 0.000 Madd__n0006_inst_cy_15 CLB_R20C2.S0.COUT Tbyp 0.096 _n0006 Madd__n0006_inst_cy_16 Madd__n0006_inst_cy_17 CLB_R19C2.S0.CIN net (fanout=1) 0.000 Madd__n0006_inst_cy_17 CLB_R19C2.S0.Y Tciny 0.545 _n0006 Madd__n0006_inst_cy_18 Madd__n0006_inst_sum_19 CLB_R17C3.S0.F3 net (fanout=1) 1.094 _n0006 CLB_R17C3.S0.CLK Tick 1.352 cnt _n00021 cnt_19 -------------------------------------------------

--------------------------- Total 8.337ns (5.443ns logic,

2.894ns route) (65.3% logic, 34.7% route)

"Rune Christensen" skrev i en meddelelse news:4159c8c6$0$275$ snipped-for-privacy@dread12.news.tele.dk...

================================================================================

--------------------------------------------------------------------------------

---------------------------

I have reached my goal by rearrange the circuit.

Now I only need to test the new circuit to see if it works :-)

Thanks to all the answer.

Cheers Rune Christensen

-- frequency counter f_cnt : freqcounter_28bit port map ( rst => rst, clk => clk, pps => pps, freq_meas => freq_meas, running => running );

-- pulse per second -- pos edge detection p_pps_edge : process(rst, clk) begin if (rst = '1') then pps_edge_new

Rune, make everything (more) synchronous. e.g.

-- clock counter counter : process(clk, cnt, freq_meas) begin if (clk'event and clk = '1') then if (reset = '1') then cnt

And tidy up the sensitivity list ;-)

counter : process(clk) begin if rising_edge(clk) then ... ...

Not to menti> Rune,

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required