fast adder and equal

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

Reply to
Rune Christensen
Loading thread data ...

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
Reply to
Rene Tschaggelar

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
 Click to see the full signature
Reply to
Uwe Bonnes

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

Reply to
Rune Christensen

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.

Reply to
John_H

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

Reply to
Symon

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

Reply to
glen herrmannsfeldt

"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)
Reply to
Rune Christensen

"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

Reply to
Rune Christensen

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

Reply to
Symon

And tidy up the sensitivity list ;-)

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

Not to menti> Rune,

Reply to
Tim

Reply to
Symon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.