Block RAM unusually long setup time ?
in [FPGA]
|
From: Sharath Raju on 28 May 2010 09:31 Hello, We are working on a project which involves using BLOCK RAMs. Since we were new to Block RAMs, I (my colleague actually) instantiated a BLOCK RAM in VHDL using Xilinx's Block RAM IP core. The question is regarding timing: The datasheet for the target Spartan 3ADSP XC3SD1800-4 device specifies the best case (setup + hold) time to be less than 1 ns, and the maximum frequency of operation to be 280 MHz. Worst case figures are not specified. However, we checked the static timing report and found the setup times for the data, address and control signals to be approximately 4 ns. Why is there such a substantial difference ?
From: Sharath Raju on 28 May 2010 09:47 I am afraid I forgot to include the code in the previous email: DBR : Core512 port map ( -- Ram A ena => ENA, enb => ENA, wea => WE, web => WE, ssra => SSR, ssrb => SSR, clka => CLOCK, clkb => CLOCK, addra => addr_1, addrb => addr_2, douta => DOUT(71 downto 36), doutb => DOUT(35 downto 0), dina => DIN(71 downto 36), dinb => DIN(35 downto 0) ); -- Address Declaration addr_1 <= '0' & ADDR(7 downto 0); addr_2 <= '1' & ADDR(7 downto 0); The code isn't much. Essentially, I am trying to pretend to have a 256 locations X 72 bits deep memory, whereas the BLOCK RAM is physically a 512 locations X 36 bits wide. On May 28, 6:31 pm, Sharath Raju <brshar...(a)gmail.com> wrote: > Hello, > > We are working on a project which involves using BLOCK RAMs. Since we > were new to Block RAMs, I (my colleague actually) instantiated a BLOCK > RAM in VHDL using Xilinx's Block RAM IP core. > > The question is regarding timing: > > The datasheet for the target Spartan 3ADSP XC3SD1800-4 device > specifies the best case (setup + hold) time to be less than 1 ns, and > the maximum frequency of operation to be 280 MHz. Worst case figures > are not specified. > > However, we checked the static timing report and found the setup > times for the data, address and control signals to be approximately 4 > ns. > > Why is there such a substantial difference ?
From: Gabor on 28 May 2010 10:05 On May 28, 9:47 am, Sharath Raju <brshar...(a)gmail.com> wrote: > I am afraid I forgot to include the code in the previous email: > > DBR : Core512 port map ( > -- Ram A > ena => ENA, > enb => ENA, > wea => WE, > web => WE, > ssra => SSR, > ssrb => SSR, > clka => CLOCK, > clkb => CLOCK, > addra => addr_1, > addrb => addr_2, > douta => DOUT(71 downto 36), > doutb => DOUT(35 downto 0), > dina => DIN(71 downto 36), > dinb => DIN(35 downto 0) > ); > > -- Address Declaration > addr_1 <= '0' & ADDR(7 downto 0); > addr_2 <= '1' & ADDR(7 downto 0); > > The code isn't much. Essentially, I am trying to pretend to have a 256 > locations X 72 bits deep memory, whereas the BLOCK RAM is physically a > 512 locations X 36 bits wide. > > On May 28, 6:31 pm, Sharath Raju <brshar...(a)gmail.com> wrote: > > > Hello, > > > We are working on a project which involves using BLOCK RAMs. Since we > > were new to Block RAMs, I (my colleague actually) instantiated a BLOCK > > RAM in VHDL using Xilinx's Block RAM IP core. > > > The question is regarding timing: > > > The datasheet for the target Spartan 3ADSP XC3SD1800-4 device > > specifies the best case (setup + hold) time to be less than 1 ns, and > > the maximum frequency of operation to be 280 MHz. Worst case figures > > are not specified. > > > However, we checked the static timing report and found the setup > > times for the data, address and control signals to be approximately 4 > > ns. > > > Why is there such a substantial difference ? > > The static timing report includes clock to output delays of the driver as well as routing delays in addition to the actual Tsu of the RAM itself. This should be broken into individual parts and well described in the timing report. Generally speaking, you should always assume that routing delays will constitute a significant portion of your timing budget for any path. According to Xilinx, the tools target 60% / 40% as a goal for logic delay / routing delay. HTH, Gabor
From: Sharath Raju on 28 May 2010 16:16 On May 28, 7:05 pm, Gabor <ga...(a)alacron.com> wrote: > On May 28, 9:47 am, Sharath Raju <brshar...(a)gmail.com> wrote: > > > > > I am afraid I forgot to include the code in the previous email: > > > DBR : Core512 port map ( > > -- Ram A > > ena => ENA, > > enb => ENA, > > wea => WE, > > web => WE, > > ssra => SSR, > > ssrb => SSR, > > clka => CLOCK, > > clkb => CLOCK, > > addra => addr_1, > > addrb => addr_2, > > douta => DOUT(71 downto 36), > > doutb => DOUT(35 downto 0), > > dina => DIN(71 downto 36), > > dinb => DIN(35 downto 0) > > ); > > > -- Address Declaration > > addr_1 <= '0' & ADDR(7 downto 0); > > addr_2 <= '1' & ADDR(7 downto 0); > > > The code isn't much. Essentially, I am trying to pretend to have a 256 > > locations X 72 bits deep memory, whereas the BLOCK RAM is physically a > > 512 locations X 36 bits wide. > > > On May 28, 6:31 pm, Sharath Raju <brshar...(a)gmail.com> wrote: > > > > Hello, > > > > We are working on a project which involves using BLOCK RAMs. Since we > > > were new to Block RAMs, I (my colleague actually) instantiated a BLOCK > > > RAM in VHDL using Xilinx's Block RAM IP core. > > > > The question is regarding timing: > > > > The datasheet for the target Spartan 3ADSP XC3SD1800-4 device > > > specifies the best case (setup + hold) time to be less than 1 ns, and > > > the maximum frequency of operation to be 280 MHz. Worst case figures > > > are not specified. > > > > However, we checked the static timing report and found the setup > > > times for the data, address and control signals to be approximately 4 > > > ns. > > > > Why is there such a substantial difference ? > > The static timing report includes clock to output delays > of the driver as well as routing delays in addition to > the actual Tsu of the RAM itself. This should be broken > into individual parts and well described in the timing > report. Generally speaking, you should always assume > that routing delays will constitute a significant > portion of your timing budget for any path. According > to Xilinx, the tools target 60% / 40% as a goal for > logic delay / routing delay. > > HTH, > Gabor Thanks gabor .. shall check the static timing report in more detail for the routing and clock to out delays.
From: Sharath Raju on 1 Jun 2010 03:06 On May 29, 1:16 am, Sharath Raju <brshar...(a)gmail.com> wrote: > On May 28, 7:05 pm, Gabor <ga...(a)alacron.com> wrote: > > > > > On May 28, 9:47 am, Sharath Raju <brshar...(a)gmail.com> wrote: > > > > I am afraid I forgot to include the code in the previous email: > > > > DBR : Core512 port map ( > > > -- Ram A > > > ena => ENA, > > > enb => ENA, > > > wea => WE, > > > web => WE, > > > ssra => SSR, > > > ssrb => SSR, > > > clka => CLOCK, > > > clkb => CLOCK, > > > addra => addr_1, > > > addrb => addr_2, > > > douta => DOUT(71 downto 36), > > > doutb => DOUT(35 downto 0), > > > dina => DIN(71 downto 36), > > > dinb => DIN(35 downto 0) > > > ); > > > > -- Address Declaration > > > addr_1 <= '0' & ADDR(7 downto 0); > > > addr_2 <= '1' & ADDR(7 downto 0); > > > > The code isn't much. Essentially, I am trying to pretend to have a 256 > > > locations X 72 bits deep memory, whereas the BLOCK RAM is physically a > > > 512 locations X 36 bits wide. > > > > On May 28, 6:31 pm, Sharath Raju <brshar...(a)gmail.com> wrote: > > > > > Hello, > > > > > We are working on a project which involves using BLOCK RAMs. Since we > > > > were new to Block RAMs, I (my colleague actually) instantiated a BLOCK > > > > RAM in VHDL using Xilinx's Block RAM IP core. > > > > > The question is regarding timing: > > > > > The datasheet for the target Spartan 3ADSP XC3SD1800-4 device > > > > specifies the best case (setup + hold) time to be less than 1 ns, and > > > > the maximum frequency of operation to be 280 MHz. Worst case figures > > > > are not specified. > > > > > However, we checked the static timing report and found the setup > > > > times for the data, address and control signals to be approximately 4 > > > > ns. > > > > > Why is there such a substantial difference ? > > > The static timing report includes clock to output delays > > of the driver as well as routing delays in addition to > > the actual Tsu of the RAM itself. This should be broken > > into individual parts and well described in the timing > > report. Generally speaking, you should always assume > > that routing delays will constitute a significant > > portion of your timing budget for any path. According > > to Xilinx, the tools target 60% / 40% as a goal for > > logic delay / routing delay. > > > HTH, > > Gabor > > Thanks gabor .. shall check the static timing report in more detail > for the routing and clock to out delays. I checked the timing report..It explicitly mentions the setup time to be about 4ns. Here is a section of the report: Data Sheet report: ----------------- All values displayed in nanoseconds (ns) Setup/Hold to clock CLOCK ------------+------------+------------+------------------+--------+ | Setup to | Hold to | | Clock | Source | clk (edge) | clk (edge) |Internal Clock(s) | Phase | ------------+------------+------------+------------------+--------+ ADDR<0> | 0.792(R)| 0.598(R)|CLOCK_BUFGP | 0.000| ADDR<1> | 1.335(R)| 0.164(R)|CLOCK_BUFGP | 0.000| ADDR<2> | 0.574(R)| 0.773(R)|CLOCK_BUFGP | 0.000| ADDR<3> | 1.590(R)| -0.040(R)|CLOCK_BUFGP | 0.000| ADDR<4> | 0.729(R)| 0.648(R)|CLOCK_BUFGP | 0.000| ADDR<5> | 2.400(R)| -0.688(R)|CLOCK_BUFGP | 0.000| ADDR<6> | 2.837(R)| -1.037(R)|CLOCK_BUFGP | 0.000| ADDR<7> | 3.441(R)| -1.521(R)|CLOCK_BUFGP | 0.000| The complete report can be accessed here: http://sites.google.com/site/brsharath/DBR.twr?attredirects=0&d=1 and here is the source: http://sites.google.com/site/brsharath/512x36.vhd?attredirects=0&d=1
|
Next
|
Last
Pages: 1 2 Prev: Xilinx' partition flow in ISE12.1 Next: Programming Digilent Nexys 2 from Linux |