Cyclone I & II memory fmax

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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?


Re: Cyclone I & II memory fmax

Hi Martin,

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


Re: Cyclone I & II memory fmax

Quoted text here. Click to load it

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).


Re: Cyclone I & II memory fmax
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.

Re: Cyclone I & II memory fmax
Hi Subroto,

Quoted text here. Click to load it

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


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;


process (wrclk)
    if rising_edge(wrclk) then
        if wren='1' then
            ram(to_integer(unsigned(wraddress))) <= data;
        end if;
    end if;
end process;

process (rdclk)
    if rising_edge(rdclk) then
        reg_dout <= ram(to_integer(unsigned(rdaddress)));
        dout <= reg_dout;
    end if;
end process;

end rtl;

Re: Cyclone I & II memory fmax
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?

Re: Cyclone I & II memory fmax
Quoted text here. Click to load it
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.


Site Timeline