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
fast adder and equal
Started by ●September 28, 2004
Reply by ●September 28, 20042004-09-28
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.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 by ●September 28, 20042004-09-28
Rune Christensen <rune.christensen@adslhome.dk> 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 ----------
Reply by ●September 28, 20042004-09-28
"Uwe Bonnes" <bon@elektron.ikp.physik.tu-darmstadt.de> skrev i en meddelelse news:cjbm19$n8j$1@lnx107.hrz.tu-darmstadt.de...> Rune Christensen <rune.christensen@adslhome.dk> 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 <= X"000_0000"; else cnt <= cnt + 1; end if; end if; -- local mode when reference is missing if (cnt = freq_meas and localmode = '1') then overflow <= '1'; else overflow <= '0'; end if; end process counter; reset <= ref_edge or overflow; The minimum slack I have had is aprox. -0.500 ns but no matter how I change the circuit I can not get the wanted 8 ns I'm using Xilinx Project Navigator and the FPGA is a SpartanII XC2S200-5pq208 Cheers Rune
Reply by ●September 28, 20042004-09-28
"Rune Christensen" <rune.christensen@adslhome.dk> wrote in message news:41594f1e$0$238$edfadb0f@dread12.news.tele.dk...> Hello > > I need information about creating a fast adder (n = n + 1) and a fastequal> (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 thereference> signal is missing when the counter is equal to the measured frequency ofthe> clock) > > The goal is to use a clock frequency on 100MHz + 25% margin. > > Thanks > RuneIf 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 by ●September 28, 20042004-09-28
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 28 bit counter, would be about 14 levels, 2 bits/level. I suggest you run the analyser and post your failing path. Cheers, Syms. "Rune Christensen" <rune.christensen@adslhome.dk> wrote in message news:41596bb8$0$257$edfadb0f@dread12.news.tele.dk...> > > I have already done that but my goal is 8 ns and a simple implementation > gives > > Slack: -1.380ns (requirement - (data path - clock pathskew> + 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 >
Reply by ●September 28, 20042004-09-28
Rune Christensen wrote:> 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 timestampFor 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 by ●September 28, 20042004-09-28
"Symon" <symon_brewer@hotmail.com> skrev i en meddelelse news:2rti2pF1e4a0qU1@uni-berlin.de...> 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 > 28 bit counter, would be about 14 levels, 2 bits/level. I suggest you run > the analyser and post your failing path. > Cheers, Syms. > "Rune Christensen" <rune.christensen@adslhome.dk> wrote in message > news:41596bb8$0$257$edfadb0f@dread12.news.tele.dk... >> >> >> 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 >> > >================================================================================ 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<1> cnt_0 CLB_R28C2.S0.F1 net (fanout=4) 1.800 cnt<0> CLB_R28C2.S0.COUT Topcyf 1.486 _n0006<1> 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<2> 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<4> 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<6> 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<8> 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<10> 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<12> 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<14> 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<16> 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<18> Madd__n0006_inst_cy_18 Madd__n0006_inst_sum_19 CLB_R17C3.S0.F3 net (fanout=1) 1.094 _n0006<19> CLB_R17C3.S0.CLK Tick 1.352 cnt<19> _n0002<19>1 cnt_19 ------------------------------------------------- --------------------------- Total 8.337ns (5.443ns logic, 2.894ns route) (65.3% logic, 34.7% route)
Reply by ●September 28, 20042004-09-28
"Rune Christensen" <rune.christensen@adslhome.dk> skrev i en meddelelse news:4159c8c6$0$275$edfadb0f@dread12.news.tele.dk...> "Symon" <symon_brewer@hotmail.com> skrev i en meddelelse > news:2rti2pF1e4a0qU1@uni-berlin.de... >> 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 >> 28 bit counter, would be about 14 levels, 2 bits/level. I suggest you run >> the analyser and post your failing path. >> Cheers, Syms. >> "Rune Christensen" <rune.christensen@adslhome.dk> wrote in message >> news:41596bb8$0$257$edfadb0f@dread12.news.tele.dk... >>> >>> >>> 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 >>> >> >> > > ================================================================================ > 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<1> > cnt_0 > CLB_R28C2.S0.F1 net (fanout=4) 1.800 cnt<0> > CLB_R28C2.S0.COUT Topcyf 1.486 _n0006<1> > > 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<2> > > 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<4> > > 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<6> > > 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<8> > > 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<10> > > 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<12> > > 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<14> > > 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<16> > > 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<18> > > Madd__n0006_inst_cy_18 > > Madd__n0006_inst_sum_19 > CLB_R17C3.S0.F3 net (fanout=1) 1.094 _n0006<19> > CLB_R17C3.S0.CLK Tick 1.352 cnt<19> > _n0002<19>1 > cnt_19 > ------------------------------------------------- --------------------------- > Total 8.337ns (5.443ns logic, > 2.894ns route) > (65.3% logic, 34.7% > route) > >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 <= '0'; pps_edge_old <= '0'; pps_edge <= '0'; elsif (clk'event and clk = '1') then pps_edge_new <= pps; pps_edge_old <= pps_edge_new; pps_edge <= not pps_edge_old and pps_edge_new and running; end if; end process p_pps_edge; -- running -- edge detection p_running_edge : process(rst, clk) begin if (rst = '1') then running_edge_new <= '0'; running_edge_old <= '0'; cnt_step <= X"000_0001"; elsif (clk'event and clk = '1') then running_edge_new <= running; running_edge_old <= running_edge_new; if ((running_edge_old and not running_edge_new) = '1') then cnt_step <= not freq_meas; else cnt_step <= X"000_0001"; end if; end if; end process p_running_edge; -- clock counter p_counter : process(clk) begin if (clk'event and clk = '1') then if (pps_edge = '1') then cnt <= X"000_0000"; else cnt <= (cnt + cnt_step) and not SXT(overflow & overflow, 28); end if; end if; end process p_counter; -- overflow detection -- reference mode - when pps is present -- local mode - when pps is missing -- output: -- overflow : std_logic; p_overflow : process(cnt, freq_meas, running) begin if ((cnt & running)= (freq_meas & '0')) then overflow <= '1'; else overflow <= '0'; end if; end process p_overflow; -- trigger -- pos edge detection p_trigger_edge : process(rst, clk) begin if (rst = '1') then trigger_edge_new <= '0'; trigger_edge_old <= '0'; elsif (clk'event and clk = '1') then trigger_edge_new <= trigger; trigger_edge_old <= trigger_edge_new; trigger_edge <= not trigger_edge_old and trigger_edge_new; end if; end process p_trigger_edge; -- timestamp register -- timestamp / freq_meas => fraction of second p_timestamp_reg : process(rst, clk) begin if (rst = '1') then timestamp <= X"000_0000"; elsif (clk'event and clk = '1') then if (trigger_edge = '1') then timestamp <= cnt; end if; end if; end process p_timestamp_reg; ================================================================================ Timing constraint: TS_clk = PERIOD TIMEGRP "clk" 8 nS HIGH 50.000000 % ; 3110 items analyzed, 1 timing error detected. (1 setup error, 0 hold errors) Minimum period is 8.026ns. -------------------------------------------------------------------------------- Slack: -0.026ns (requirement - (data path - clock path skew + uncertainty)) Source: cnt_2 (FF) Destination: cnt_2 (FF) Requirement: 8.000ns Data Path Delay: 8.026ns (Levels of Logic = 9) Clock Path Skew: 0.000ns Source Clock: clk_BUFGP rising at 0.000ns Destination Clock: clk_BUFGP rising at 8.000ns Clock Uncertainty: 0.000ns Data Path: cnt_2 to cnt_2 Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- CLB_R21C4.S1.YQ Tcko 1.292 cnt<3> cnt_2 CLB_R24C4.S0.G4 net (fanout=3) 1.304 cnt<2> CLB_R24C4.S0.COUT Topcyg 1.396 Mcompar__n0006_inst_cy_28 Mcompar__n0006_inst_lut4_15 Mcompar__n0006_inst_cy_28 CLB_R23C4.S0.CIN net (fanout=1) 0.000 Mcompar__n0006_inst_cy_28 CLB_R23C4.S0.COUT Tbyp 0.096 Mcompar__n0006_inst_cy_30 Mcompar__n0006_inst_cy_29 Mcompar__n0006_inst_cy_30 CLB_R22C4.S0.CIN net (fanout=1) 0.000 Mcompar__n0006_inst_cy_30 CLB_R22C4.S0.COUT Tbyp 0.096 Mcompar__n0006_inst_cy_32 Mcompar__n0006_inst_cy_31 Mcompar__n0006_inst_cy_32 CLB_R21C4.S0.CIN net (fanout=1) 0.000 Mcompar__n0006_inst_cy_32 CLB_R21C4.S0.COUT Tbyp 0.096 Mcompar__n0006_inst_cy_34 Mcompar__n0006_inst_cy_33 Mcompar__n0006_inst_cy_34 CLB_R20C4.S0.CIN net (fanout=1) 0.000 Mcompar__n0006_inst_cy_34 CLB_R20C4.S0.COUT Tbyp 0.096 Mcompar__n0006_inst_cy_36 Mcompar__n0006_inst_cy_35 Mcompar__n0006_inst_cy_36 CLB_R19C4.S0.CIN net (fanout=1) 0.000 Mcompar__n0006_inst_cy_36 CLB_R19C4.S0.COUT Tbyp 0.096 Mcompar__n0006_inst_cy_38 Mcompar__n0006_inst_cy_37 Mcompar__n0006_inst_cy_38 CLB_R18C4.S0.CIN net (fanout=1) 0.000 Mcompar__n0006_inst_cy_38 CLB_R18C4.S0.COUT Tbyp 0.096 Mcompar__n0006_inst_cy_40 Mcompar__n0006_inst_cy_39 Mcompar__n0006_inst_cy_40 CLB_R17C4.S0.CIN net (fanout=1) 0.000 Mcompar__n0006_inst_cy_40 CLB_R17C4.S0.XB Tcinxb 0.046 overflow Mcompar__n0006_inst_cy_41 CLB_R21C4.S1.G3 net (fanout=28) 2.060 overflow CLB_R21C4.S1.CLK Tick 1.352 cnt<3> _n0004<2>1 cnt_2 ------------------------------------------------- --------------------------- Total 8.026ns (4.662ns logic, 3.364ns route) (58.1% logic, 41.9% route) -------------------------------------------------------------------------------- 1 constraint not met. Data Sheet report: ----------------- All values displayed in nanoseconds (ns) Clock to Setup on destination clock clk ---------------+---------+---------+---------+---------+ | Src:Rise| Src:Fall| Src:Rise| Src:Fall| Source Clock |Dest:Rise|Dest:Rise|Dest:Fall|Dest:Fall| ---------------+---------+---------+---------+---------+ clk | 8.026| | | | ---------------+---------+---------+---------+---------+ Timing summary: --------------- Timing errors: 1 Score: 26 Constraints cover 3110 paths, 0 nets, and 575 connections Design statistics: Minimum period: 8.026ns (Maximum frequency: 124.595MHz)
Reply by ●September 28, 20042004-09-28
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 <= X"000_0000";
else
cnt <= cnt + 1;
end if;
-- local mode when reference is missing
if (cnt = freq_meas and localmode = '1') then
overflow <= '1';
else
overflow <= '0';
end if;
reset <= ref_edge or overflow;
end if;
end process counter;
Any better timing wise?
Cheers, Syms.
