Forums

Cyclone I & II memory fmax

Started by Martin Schoeberl August 3, 2006
Hi group,

using a 128x32 bit simple dual port memory with independent
read and write clock results in following fmax for both
clocks (dout is registered):

    Cyclone (I) 256 MHz, Cyclone II 210 MHz (restricted)

That's a little bit strange. Especially since the fmax for
the memories in the data sheet is the other way round:
Cyclone (I) 200 MHz and Cyclone II 250 MHz.

BTW: according to the errata sheet this configuration does not
need any restructuring from Quartus.

The numbers for simple dual port with a single clock are:

    Cyclone (I) 256 MHz, Cyclone II 235 MHz (restricted)

I'm using Quartus 6.0.
Will this change with a new Quartus version?

Martin


Hi Martin,

where do the memory data input / write strobe/ read strobe inputs
come from, pins or registers ?=20

Rgds
Andr=E9

>where do the memory data input / write strobe/ read strobe inputs >come from, pins or registers ?
For the test they come from pins. Therefore, the setup and hold times for the pins are very long, but this not the issue. The maximum frequency is determined by the memory blocks between the input registers (address, write data) and the memory or output register (read data). Martin
Hi Martin,

The 210MHz is correct for Cyclone II M4K in SDP (simple dual port) mode
with dual, non-PLL clocks.
The speed for Cyclone II M4K in SDP mode with a single, non-PLL clock
is 235Mhz.

- Subroto Datta
Altera Corp.

Hi Subroto,

> > The 210MHz is correct for Cyclone II M4K in SDP (simple dual port) mode > with dual, non-PLL clocks. > The speed for Cyclone II M4K in SDP mode with a single, non-PLL clock > is 235Mhz.
Ok, thanks for the hint/correction. One should not try to figure out performance numbers in the wrong context - no one will drive a system with 200+ MHz without using the PLL. With the PLL (and now Quartus 6.0sp1) the numbers are (independent of single or dual clock): Cyclone I: fmax = 256 MHz Cyclone II: fmax = 235 MHz Martin BTW: It's very nice that Quartus instantiates the simple dual port memory from plain VHDL - no vendor specific components ;-) For those who are interested here is the (very simple) VHDL code: library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity sdpram is generic (width : integer := 32; addr_width : integer := 7); port ( wrclk : in std_logic; data : in std_logic_vector(width-1 downto 0); wraddress : in std_logic_vector(addr_width-1 downto 0); wren : in std_logic; rdclk : in std_logic; rdaddress : in std_logic_vector(addr_width-1 downto 0); dout : out std_logic_vector(width-1 downto 0) ); end sdpram ; architecture rtl of sdpram is signal reg_dout : std_logic_vector(width-1 downto 0); subtype word is std_logic_vector(width-1 downto 0); constant nwords : integer := 2 ** addr_width; type ram_type is array(0 to nwords-1) of word; signal ram : ram_type; begin process (wrclk) begin if rising_edge(wrclk) then if wren='1' then ram(to_integer(unsigned(wraddress))) <= data; end if; end if; end process; process (rdclk) begin if rising_edge(rdclk) then reg_dout <= ram(to_integer(unsigned(rdaddress))); dout <= reg_dout; end if; end process; end rtl;
I still discover a difference between the fmax for Cyclone I and
Cyclone II.

Is this caused by the DP-RAM bug with Cyclone II devices -
let's say with the additional hardware produced by the work around?

>I still discover a difference between the fmax for Cyclone I and > Cyclone II. > > Is this caused by the DP-RAM bug with Cyclone II devices - > let's say with the additional hardware produced by the work around? >
AFAIK the example I'm using (same data width on both ports) does not need the additional hardware. With different port widths, which I used first, I got the additional MUX inserted by Quartus. However, in my application I can tolerate some latency, so I will MUX the data (and demux) it in an extra pipeline stage. Martin