Virtex-5 и DDR-? Опции

[jojo]

По поводу назначения выводов в MIG для Xilinx Virtex5 и SODIMM DDR2, плата ML555, ISE10.1:

Я не могу заказать в Wizard-e назначение выводов, как для платы ML555.

Почему у Wizard-а и у платы разное назначение выводов?
Для работы контроллера DDR2 достаточно, чтобы DQS[] просто попали в те же банки, что и их DQ[][]?
Для остальных управляющих выводов достаточно просто правильно указать их типы SSTL и т.д, а положение их может быть любым, которое допустит ISE?

Рекомендуемое Wizard-ом назначение дает частоту около 266 МГц. Когда я правлю UCF и вписываю выводы для платы ML555, частота падает до около 200 МГц.

Т.е. назначение для ML555 хуже, чем в новых версиях MIG?

[nachinayuschiy]

У меня вопрос: для проекта необходимо две независимые планки DDR2 SDRAM. То есть это понадобится два контроллера. Влезут ли они в Виртекс-4 или в Виртекс-5 ?

[nachinayuschiy]

Просто подскажите как вот эту часть ucf-файла передлать для двух контроллеров:

Код

###############################################################################
# Define multicycle paths - these paths may take longer because additional
# time allowed for logic to settle in calibration/initialization FSM
###############################################################################

# MIG 2.1: Eliminate Timegroup definitions for CLK0, and CLK90. Instead trace
#          multicycle paths from originating flip-flop to ANY destination
#          flip-flop (or in some cases, it can also be a BRAM)
# MUX Select for either rising/falling CLK0 for 2nd stage read capture
INST "*/u_phy_calib/gen_rd_data_sel*.u_ff_rd_data_sel" TNM = "TNM_RD_DATA_SEL";
TIMESPEC "TS_MC_RD_DATA_SEL" = FROM "TNM_RD_DATA_SEL" TO FFS
"TS_SYS_CLK" * 4;
# MUX select for read data - optional delay on data to account for byte skews
INST "*/u_usr_rd/gen_rden_sel_mux*.u_ff_rden_sel_mux" TNM = "TNM_RDEN_SEL_MUX";
TIMESPEC "TS_MC_RDEN_SEL_MUX" = FROM "TNM_RDEN_SEL_MUX" TO FFS
"TS_SYS_CLK" * 4;
# Calibration/Initialization complete status flag (for PHY logic only) - can
# be used to drive both flip-flops and BRAMs
INST "*/u_phy_init/u_ff_phy_init_data_sel" TNM = "TNM_PHY_INIT_DATA_SEL";
TIMESPEC "TS_MC_PHY_INIT_DATA_SEL_0" = FROM "TNM_PHY_INIT_DATA_SEL" TO FFS
"TS_SYS_CLK" * 4;
TIMESPEC "TS_MC_PHY_INIT_DATA_SEL_90" = FROM "TNM_PHY_INIT_DATA_SEL" TO RAMS
"TS_SYS_CLK" * 4;
# Select (address) bits for SRL32 shift registers used in stage3/stage4
# calibration
INST "*/u_phy_calib/gen_gate_dly*.u_ff_gate_dly" TNM = "TNM_GATE_DLY";
TIMESPEC "TS_MC_GATE_DLY" = FROM "TNM_GATE_DLY" TO FFS "TS_SYS_CLK" * 4;
INST "*/u_phy_calib/gen_rden_dly*.u_ff_rden_dly" TNM = "TNM_RDEN_DLY";
TIMESPEC "TS_MC_RDEN_DLY" = FROM "TNM_RDEN_DLY" TO FFS "TS_SYS_CLK" * 4;
INST "*/u_phy_calib/gen_cal_rden_dly*.u_ff_cal_rden_dly"
  TNM = "TNM_CAL_RDEN_DLY";
TIMESPEC "TS_MC_CAL_RDEN_DLY" = FROM "TNM_CAL_RDEN_DLY" TO FFS
  "TS_SYS_CLK" * 4;

###############################################################################
# DQS Read Post amble Glitch Squelch circuit related constraints
###############################################################################

###############################################################################
# LOC placement of DQS-squelch related IDDR and IDELAY elements
# Each circuit can be located at any of the following locations:
#  1. Unused "N"-side of DQS differential pair I/O
#  2. DM data mask (output only, input side is free for use)
#  3. Any output-only site
###############################################################################

INST "*/gen_dqs[0].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X1Y22";
INST "*/gen_dqs[0].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X1Y22";  
INST "*/gen_dqs[1].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X1Y20";
INST "*/gen_dqs[1].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X1Y20";
INST "*/gen_dqs[2].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X1Y18";
INST "*/gen_dqs[2].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X1Y18";
INST "*/gen_dqs[3].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X1Y16";
INST "*/gen_dqs[3].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X1Y16";
INST "*/gen_dqs[4].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X0Y182";
INST "*/gen_dqs[4].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X0Y182";
INST "*/gen_dqs[5].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X0Y180";
INST "*/gen_dqs[5].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X0Y180";
INST "*/gen_dqs[6].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X0Y178";
INST "*/gen_dqs[6].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X0Y178";
INST "*/gen_dqs[7].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X0Y176";
INST "*/gen_dqs[7].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X0Y176";
INST "*/gen_dqs[8].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X0Y142";
INST "*/gen_dqs[8].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X0Y142";
INST "*/gen_dqs[9].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X0Y140";
INST "*/gen_dqs[9].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X0Y140";
INST "*/gen_dqs[10].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X0Y138";
INST "*/gen_dqs[10].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X0Y138";
INST "*/gen_dqs[11].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X0Y136";
INST "*/gen_dqs[11].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X0Y136";
INST "*/gen_dqs[12].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X2Y102";
INST "*/gen_dqs[12].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X2Y102";
INST "*/gen_dqs[13].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X2Y100";
INST "*/gen_dqs[13].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X2Y100";
INST "*/gen_dqs[14].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X2Y98";
INST "*/gen_dqs[14].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X2Y98";
INST "*/gen_dqs[15].u_iob_dqs/u_iddr_dq_ce"  LOC = "ILOGIC_X2Y96";
INST "*/gen_dqs[15].u_iob_dqs/u_iodelay_dq_ce"  LOC = "IODELAY_X2Y96";

###############################################################################
# LOC and timing constraints for flop driving DQS CE enable signal
# from fabric logic. Even though the absolute delay on this path is
# calibrated out (when synchronizing this output to DQS), the delay
# should still be kept as low as possible to reduce post-calibration
# voltage/temp variations - these are roughly proportional to the
# absolute delay of the path
###############################################################################

INST "*/u_phy_calib/gen_gate[0].u_en_dqs_ff"  LOC = SLICE_X71Y11;
INST "*/u_phy_calib/gen_gate[1].u_en_dqs_ff"  LOC = SLICE_X71Y10;
INST "*/u_phy_calib/gen_gate[2].u_en_dqs_ff"  LOC = SLICE_X71Y9;
INST "*/u_phy_calib/gen_gate[3].u_en_dqs_ff"  LOC = SLICE_X71Y8;
INST "*/u_phy_calib/gen_gate[4].u_en_dqs_ff"  LOC = SLICE_X0Y91;
INST "*/u_phy_calib/gen_gate[5].u_en_dqs_ff"  LOC = SLICE_X0Y90;
INST "*/u_phy_calib/gen_gate[6].u_en_dqs_ff"  LOC = SLICE_X0Y89;
INST "*/u_phy_calib/gen_gate[7].u_en_dqs_ff"  LOC = SLICE_X0Y88;
INST "*/u_phy_calib/gen_gate[8].u_en_dqs_ff"  LOC = SLICE_X0Y71;
INST "*/u_phy_calib/gen_gate[9].u_en_dqs_ff"  LOC = SLICE_X0Y70;
INST "*/u_phy_calib/gen_gate[10].u_en_dqs_ff"  LOC = SLICE_X0Y69;
INST "*/u_phy_calib/gen_gate[11].u_en_dqs_ff"  LOC = SLICE_X0Y68;
INST "*/u_phy_calib/gen_gate[12].u_en_dqs_ff"  LOC = SLICE_X143Y51;
INST "*/u_phy_calib/gen_gate[13].u_en_dqs_ff"  LOC = SLICE_X143Y50;
INST "*/u_phy_calib/gen_gate[14].u_en_dqs_ff"  LOC = SLICE_X143Y49;
INST "*/u_phy_calib/gen_gate[15].u_en_dqs_ff"  LOC = SLICE_X143Y48;

# Control for DQS gate - from fabric flop. Prevent "runaway" delay -
# two parts to this path: (1) from fabric flop to IDELAY, (2) from
# IDELAY to asynchronous reset of IDDR that drives the DQ CE's
NET "*/u_phy_io/en_dqs*" MAXDELAY = 600 ps;
NET "*/u_phy_io/gen_dqs*.u_iob_dqs/en_dqs_sync" MAXDELAY = 800 ps;

###############################################################################
# "Half-cycle" path constraint from IDDR to CE pin for all DQ IDDR's
# for DQS Read Post amble Glitch Squelch circuit
###############################################################################

# Max delay from output of IDDR to CE input of DQ IDDRs = tRPST + some slack
#  where slack account for rise-time of DQS on board. For now assume slack =
#  0.400ns (based on initial SPICE simulations, assumes use of ODT), so
#  time = 0.4*Tcyc + 0.40ns = 1.6ns @333MHz
INST "*/gen_dqs[*].u_iob_dqs/u_iddr_dq_ce" TNM = "TNM_DQ_CE_IDDR";
INST "*/gen_dq[*].u_iob_dq/gen_stg2_*.u_iddr_dq" TNM = "TNM_DQS_FLOPS";
TIMESPEC "TS_DQ_CE" = FROM "TNM_DQ_CE_IDDR" TO "TNM_DQS_FLOPS" 1.6 ns;

################################################################################
INST "*/gen_dq[0].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y19;
INST "*/gen_dq[1].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y19;
INST "*/gen_dq[2].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y18;
INST "*/gen_dq[3].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y17;
INST "*/gen_dq[4].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y17;
INST "*/gen_dq[5].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y16;
INST "*/gen_dq[6].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y15;
INST "*/gen_dq[7].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y14;
INST "*/gen_dq[8].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y14;
INST "*/gen_dq[9].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y13;
INST "*/gen_dq[10].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y12;
INST "*/gen_dq[11].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y12;
INST "*/gen_dq[12].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y6;
INST "*/gen_dq[13].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y6;
INST "*/gen_dq[14].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y4;
INST "*/gen_dq[15].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X68Y4;
INST "*/gen_dq[16].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y99;
INST "*/gen_dq[17].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y99;
INST "*/gen_dq[18].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y98;
INST "*/gen_dq[19].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y97;
INST "*/gen_dq[20].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y97;
INST "*/gen_dq[21].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y96;
INST "*/gen_dq[22].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y95;
INST "*/gen_dq[23].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y94;
INST "*/gen_dq[24].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y94;
INST "*/gen_dq[25].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y93;
INST "*/gen_dq[26].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y92;
INST "*/gen_dq[27].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y92;
INST "*/gen_dq[28].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y86;
INST "*/gen_dq[29].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y86;
INST "*/gen_dq[30].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y84;
INST "*/gen_dq[31].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y84;
INST "*/gen_dq[32].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y79;
INST "*/gen_dq[33].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y79;
INST "*/gen_dq[34].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y78;
INST "*/gen_dq[35].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y77;
INST "*/gen_dq[36].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y77;
INST "*/gen_dq[37].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y76;
INST "*/gen_dq[38].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y75;
INST "*/gen_dq[39].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y74;
INST "*/gen_dq[40].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y74;
INST "*/gen_dq[41].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y73;
INST "*/gen_dq[42].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y72;
INST "*/gen_dq[43].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y72;
INST "*/gen_dq[44].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y66;
INST "*/gen_dq[45].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y66;
INST "*/gen_dq[46].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y64;
INST "*/gen_dq[47].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X0Y64;
INST "*/gen_dq[48].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y59;
INST "*/gen_dq[49].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y59;
INST "*/gen_dq[50].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y58;
INST "*/gen_dq[51].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y57;
INST "*/gen_dq[52].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y57;
INST "*/gen_dq[53].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y56;
INST "*/gen_dq[54].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y55;
INST "*/gen_dq[55].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y54;
INST "*/gen_dq[56].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y54;
INST "*/gen_dq[57].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y53;
INST "*/gen_dq[58].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y52;
INST "*/gen_dq[59].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y52;
INST "*/gen_dq[60].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y46;
INST "*/gen_dq[61].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y46;
INST "*/gen_dq[62].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y44;
INST "*/gen_dq[63].u_iob_dq/gen_stg2_*.u_ff_stg2a_rise"  RLOC_ORIGIN = X140Y44;

[SFx]

Просто подскажите как вот эту часть ucf-файла передлать

В реальности должно быть так:
1. INST "*/gen_dq*" RLOC_ORIGIN =* должны нахоодится в IOB вывода DQ[]

2. INST "*/u_phy_calib/gen_gate* LOC = SLICE_*;" должны иметь идентичное положение относительно друг-друга.

3. INST "*/" придется заменить на полный иерархический путь к первому и второму контроллеру.


А вообще лучще путем играния с порядком резеирвированных выводов опытным путем добится правильного расположения ножек у пинов. тулза сама правильно поставить тогда п.1 и п.2. и останится только п.3 и с большой вероятностью все заработает с превого раза.

я выводами для DDR контроллера я в свое время наелся. в принципе пару часов потыкаться в тулзе MIG2.0 и все получилось. пока других способов я не знаю. может быть кто знает поделется ?

[nachinayuschiy]

У меня вопрос сможет ли virtex-4 работать с 512MB DDR2 SDRAM UDIMM с двумя планками? Или лучше для этого пяты использовать?

[DmitryR]

Сможет, но пятый сможет это лучше.

[nachinayuschiy]

А данный контроллер памяти использует Distributed RAM? Если да, то сколько? Просто мне помимо контроллеров памяти ещё необходимо будет создавать фифошки на основе Distributed RAM

[Kuzmi4]

Имею Virtex5 и DDR2, использую MIG v3.1 (ISE v11.2) контроллер для общения с памятью.

Возник вопрос с адресами, точней с колонками...Ответа в xapp-ах и ug-ах странному поведению не нашёл .. Вот решил спросить у пользовавших уже.
Burts len == 4, bust type == sequеntial, времянку строю согласно figure 3-10/figure 3-13 докУмента ug86.pdf - юзер гид на миг который.
Пытаюсь писать согласно figure 3-10 - ставлю адреса 00,04,08,0С - в в модельсиме вижу изменение колонок 0,1,2,3,4,5,6,7 и так далее... Тут всё нормально.
Если же ставлю адреса записи 01,05,09,0D - получаю изменение колонок в 1,2,3,0,5,6,7,4,9.... Чтение по этим адресам (согласно figure 3-13 ) вызывает такую же последовательность изменения колонок.... Смотрю на адреса между памятью и контроллером - там то же что я засовывал в фифошку миговскую - 01,05,09,0D .
Проверял на последовательности адресов начинающуюся с 3 - тоже белиберда какая то с адресами колонок - 3,0,1,2,7,4,5...
Для последовательности адресов начинающихся с 2 - 2,3,0,1,6,7,4...
Какую то логику трудно тут понять....

Этот вопрос кстати не у меня первого возник - только и там ответа нет.. глухо..
Не подскажет ли кто со знающих - с чего бы это такое ?? Ведь в должна была быть обычная инкрементирующая последовательность колонок типа 0/1,2,3,4...

[DmitryR]

Все очень просто: счетчик адреса квадрослова отдельный, и он перескакивает. Посмотрите документацию на любой чип DDR2, как там организован burst. Если поставите длину пакета 8 - то чтение с адреса 1 будет еще веселее: 12305674. Это делается для того, чтобы строку кэша можно было прочитать с того слова, которое непосредственно необходимо, но в результате чтобы строка кэша была прочитана полностью, даже если ее заполнение началось с середины, что и требует перескока на младшие адреса.

[Kuzmi4]

2 DmitryR - то есть получается что это эдакая фича ддр2 чипа.... и что это за строка кеша в 64 бита и слово 16 битное ??
А кроме как играми с масками можно есчё как то записать по произвольному нужному адресу определённую длинну данных используя MIG ??

[DmitryR]

Кроме как используя маску вы не сможете это сделать, даже не используя MIG, потому что у DDR2 минимальный burst - 4, и работает он так, как я написал выше. Это не прихоть MIG, так работает ОЗУ. Но вообще говоря мне непонятно, зачем писать начиная с нечетных адресов: обычно в DDR2 пишет либо процессор из кэша, либо DMA, и они делают это всегда выровненно. И даже в своем устройства думаю всегда можно достичь выровненных обращений к памяти, аккуратно его спроектировав.

[Kuzmi4]

2 DmitryR - на счёт кеша это понятно, а дма не всегда может выровненно по 4 писать, если это заранее не заложить..
В обсчем спасибо за разъяснения, а то я подозревал конечно, что это я где то недочитал, но в литературе на миг этого момента не нашёл... Видимо самый правильный ход будет переделать логику под выровненную по 4-ке.

И всё же меня мучает вопрос - почему хилые не заложили маскирование?? не ужели это трудно для них было ?? хотя видимо он останется без ответа...

[DmitryR]

И всё же меня мучает вопрос - почему хилые не заложили маскирование?? не ужели это трудно для них было ??

Ну вобщем да, это на общий случай довольно заморочно, а в 99% случаев никому не нужно.

[des00]

2 DmitryR - то есть получается что это эдакая фича ддр2 чипа.... и что это за строка кеша в 64 бита и слово 16 битное ??
А кроме как играми с масками можно есчё как то записать по произвольному нужному адресу определённую длинну данных используя MIG ??

немного добавлю вообще это фича всей динамической памяти. об этом в даташите на память всегда подробно расписано %) в вот реализация нечетных масок на ддр возможная но достаточно геморойная, да и не нужна она в большинстве случаев, т.к. обычно, с точки зрения системы, память видится как 2*DDR_DATA_W. А вот четные маски не помешали бы