Cyclone I & II memory fmax

Hi Martin,

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

Rgds Andr=E9

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,

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

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