Если поделитесь умными ссылочками или что более актуально опытом, буду очень признателен...
Заранее благодарен....
Александр
Полная версия этой страницы: Virtex-5 и DDR-?
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Господа... Использовал ли кто в связке с Vertex-5 динамическую память, что нить типа DDR-2. Какие результаты и как они вообще совместно существуют....?
Если поделитесь умными ссылочками или что более актуально опытом, буду очень признателен...
Заранее благодарен....
Александр
Если поделитесь умными ссылочками или что более актуально опытом, буду очень признателен...
Заранее благодарен....
Александр
Цитата(GAZE @ Apr 22 2008, 10:02) 
Если поделитесь умными ссылочками
Стартовая позиция -- раздел Application Notes на сайте Xilinx.
Цитата(GAZE @ Apr 22 2008, 11:02)
Господа... Использовал ли кто в связке с Vertex-5 динамическую память, что нить типа DDR-2. Какие результаты и как они вообще совместно существуют....?
Если поделитесь умными ссылочками или что более актуально опытом, буду очень признателен...
Заранее благодарен....
Александр
Если поделитесь умными ссылочками или что более актуально опытом, буду очень признателен...
Заранее благодарен....
Александр
Посмотрите еще MIG (Memory Interface Generator). У меня стоит ISE 9.2i IP Update 2, в нем две версии MIG 1.72 и MIG 2.0. Я пользовался последней версией. На ML506 SODIMMвская планка (DDR2) заработала без особых проблемм.
Мы сейчас делаем, с чем столкнулись - в XAPP858 сказано выровнять линии данных, чтобы скос в них (на плате) не превышал 50 ps. И это, я вам скажу, гемморой еще тот оказался: провода, выровненные по длинне до десятой дают 60 ps разброса (из-за аккордеонов, переходных, разных слоев и т.п.).
Еще заметили, что у разных производителей памяти выходное сопротивление линий данных различается до двух раз (от 15 до 27 ом), поэтому не со всеми микросхемами удастся совсем обойтись без торцевых/подтягивающих резисторов (когда идет запись в DDR2 - там ODT, а вот когда чтение - у некоторых овершуты жуткие, несмотря на Half Strength).
Еще заметили, что у разных производителей памяти выходное сопротивление линий данных различается до двух раз (от 15 до 27 ом), поэтому не со всеми микросхемами удастся совсем обойтись без торцевых/подтягивающих резисторов (когда идет запись в DDR2 - там ODT, а вот когда чтение - у некоторых овершуты жуткие, несмотря на Half Strength).
Цитата(per_aspera_ad_astra @ Apr 23 2008, 10:16)
Посмотрите еще MIG (Memory Interface Generator). У меня стоит ISE 9.2i IP Update 2, в нем две версии MIG 1.72 и MIG 2.0. Я пользовался последней версией. На ML506 SODIMMвская планка (DDR2) заработала без особых проблемм.
Я просто планиру поставить MT47H128M16HG-3. Это MICRON-овская банка в 2Гбита. Нужен большой буфер, под PCI-E(х8).
Как думаете, необходимость в подтягивании каких либо ног есть или в принципе ПЛИСовские выходные каскады должны справиться??? Просто с Vertex-5 еще не работали...
и второй вопрос... Нигде не нашел информации на ограничение длины линий при разводке!!! Логично, что оно должно быть и чем короче линия, тем лучше... Из приактики не подскажите к чему стремиться то хоть... Какие у вас примерно длины линий???
Цитата(GAZE @ Apr 25 2008, 11:45)
Я просто планиру поставить MT47H128M16HG-3. Это MICRON-овская банка в 2Гбита.
Как думаете, необходимость в подтягивании каких либо ног есть или в принципе ПЛИСовские выходные каскады должны справиться??? Просто с Vertex-5 еще не работали...
Как думаете, необходимость в подтягивании каких либо ног есть или в принципе ПЛИСовские выходные каскады должны справиться??? Просто с Vertex-5 еще не работали...
У меня по результатам моделирования как раз вышло, что у Микрона самые крутые фронты. Но до 3 сантиметров длины дорожки результаты были удовлетворительные (без резисторов в смысле).
Цитата(GAZE @ Apr 25 2008, 11:45)
и второй вопрос... Нигде не нашел информации на ограничение длины линий при разводке!!! Логично, что оно должно быть и чем короче линия, тем лучше... Из приактики не подскажите к чему стремиться то хоть... Какие у вас примерно длины линий???
Для Микрона, как я писал выше, 3 сантиметра где-то предел. Для Самсунга - сантиметров 5-6. Если же поставите все резисторы (торцевые и подтяжку на Vref) - то длина практически не будет ограничена, вплоть до того, что можно будет несколько микрух на одну шину посадить.
В любом случае без моделирования IMHO не обойтись. Причем мы предварительно посмотрели в LineSim, что выйдет, затем по результатам сделали разводку и окончательно уже подровняли по результатам BoardSim.
всем спасибо за советы...
будем, как говорится, творить....
будем, как говорится, творить....
Задам ка в этой теме вопросик...
Есть такая идея: сделать плату, на которой будет размещено 4 ГБ оперативки (ориентировочно DDR-2, промышленая). Память должна управляться ПЛИС. Требуется записывать поток данных в районе 200 МБ/сек в течение 10-20 сек. Что-то типа осциллографа с накоплением.
Пока что еще не вентилировал этот вопрос, но хотелось бы услышать мнение тех кто с подобным сталкивался.
Насколько вообще такая идея близка к реальности?
Все бы хорошо: и память коммерчески доступна, и на ПЛИС можно контроллер для нее замастерить.
Но вот объем... видимо будет много чипов...
Насколько велика трудоемкость разработки?
Насколько велика вероятность наделать косяков, которые паяльником не исправишь?
Речь идет пока о единичных экземплярах такой платы.
Есть такая идея: сделать плату, на которой будет размещено 4 ГБ оперативки (ориентировочно DDR-2, промышленая). Память должна управляться ПЛИС. Требуется записывать поток данных в районе 200 МБ/сек в течение 10-20 сек. Что-то типа осциллографа с накоплением.
Пока что еще не вентилировал этот вопрос, но хотелось бы услышать мнение тех кто с подобным сталкивался.
Насколько вообще такая идея близка к реальности?
Все бы хорошо: и память коммерчески доступна, и на ПЛИС можно контроллер для нее замастерить.
Но вот объем... видимо будет много чипов...
Насколько велика трудоемкость разработки?
Насколько велика вероятность наделать косяков, которые паяльником не исправишь?
Речь идет пока о единичных экземплярах такой платы.
Цитата(kst @ Apr 30 2008, 20:21)
Есть такая идея: сделать плату, на которой будет размещено 4 ГБ оперативки (ориентировочно DDR-2, промышленая).
...
Все бы хорошо: и память коммерчески доступна, и на ПЛИС можно контроллер для нее замастерить.
Но вот объем... видимо будет много чипов...
Насколько велика трудоемкость разработки?
Насколько велика вероятность наделать косяков, которые паяльником не исправишь?
...
Все бы хорошо: и память коммерчески доступна, и на ПЛИС можно контроллер для нее замастерить.
Но вот объем... видимо будет много чипов...
Насколько велика трудоемкость разработки?
Насколько велика вероятность наделать косяков, которые паяльником не исправишь?
4 гигабайта - это пара DIMM, как я понимаю. Трудоемкость невелика, если хорошо спланировать (сделать правильный stackup, не полениться все промоделировать etc.). Конечно 64 линии данных промоделировать не пять минут дела, но ничего страшного.
Звучит оптимистично, это здорово 
DIMMы использовать, конечно, хорошо... в плане объема памяти... однако плата будет использоваться в довольно жестких условиях. В частности в условиях тряски/вибрации.
Возникает вопрос о стойкости разъемов и вставленных в эти разъемы DIMMов к вибрации...
DIMMы использовать, конечно, хорошо... в плане объема памяти... однако плата будет использоваться в довольно жестких условиях. В частности в условиях тряски/вибрации.
Возникает вопрос о стойкости разъемов и вставленных в эти разъемы DIMMов к вибрации...
Цитата(kst @ May 4 2008, 12:45)
Возникает вопрос о стойкости разъемов и вставленных в эти разъемы DIMMов к вибрации...
В ноутбуках используют SODIMM, никто вроде не жалуется.
Здравствуйте.
Использовал разъёмы DIMM DDR2. Тряску и вибрацию прошли,
Меня интересует такой вопрос: Как сделать на Virtex4 Две DIMM планки для одного контроллера в ПЛИС (Какие настройки в MIG-е. Как соединять и разводить DIMM-ы). Что бы пропускную способность увеличить в два раза.
Использовал разъёмы DIMM DDR2. Тряску и вибрацию прошли,
Меня интересует такой вопрос: Как сделать на Virtex4 Две DIMM планки для одного контроллера в ПЛИС (Какие настройки в MIG-е. Как соединять и разводить DIMM-ы). Что бы пропускную способность увеличить в два раза.
Цитата(NahaL @ May 21 2008, 11:54)
Меня интересует такой вопрос: Как сделать на Virtex4 Две DIMM планки для одного контроллера в ПЛИС (Какие настройки в MIG-е. Как соединять и разводить DIMM-ы). Что бы пропускную способность увеличить в два раза.
Путем увеличения разрядности. На той странице MIG, где выбирается тип (Components/RDIMM) есть еще и разрядность (прокрутить вниз надо), если поставить 144 - будет две планки. Если 144 не доступно - значит, не поддерживается в заданной конфигурации (зависит от заданной частоты памяти, скорости и корпуса FPGA).
Цитата(DmitryR @ May 21 2008, 15:39)
Путем увеличения разрядности. На той странице MIG, где выбирается тип (Components/RDIMM) есть еще и разрядность (прокрутить вниз надо), если поставить 144 - будет две планки. Если 144 не доступно - значит, не поддерживается в заданной конфигурации (зависит от заданной частоты памяти, скорости и корпуса FPGA).
В таком случае не подскажите, а где бы можно посмотреть примеры, в которых показано соединение двух планок (длина линий, подвешивающие резисторы, конденсаторы и т.п.). В смысле разводку и электрическую схему.
Работаю с UDIMM DDR2.
Вообще-то, так как планки у вас будут включены параллельно (шина адреса и управления общая, а данные раздельно), то можно попытаться обойтись только теми торцевиками, что стоят на UDIMM, поставив планки максимально близко. Если не выйдет - надо повесить все линии на VCC/2 через резистор ЗА планками, то есть НЕ между FPGA и UDIMM. Особо стоит отметить, что в силу большого тока, который пойдет на VCC/2 получать его ни в коем случае нельзя делителем, а надо использовать источник (есть специальные DC/DC даже для терминации). А необходимость торцевых на стороне FPGA и нагрузочных DQS резисторов необходимо выяснять по результатм моделирования, это в основном будет зависеть от использования DCI. Пример разводки наверное можно найти в каком нибудь ките (в ML561 я не нашел), но это вам мало что даст - ведь точно повторить ее (вместе со стеком) вряд ли удастся, поэтому все равно выравнивать длину надо будет не по физической длине проводника, а по его задержке.
По поводу назначения выводов в MIG для Xilinx Virtex5 и SODIMM DDR2, плата ML555, ISE10.1:
Я не могу заказать в Wizard-e назначение выводов, как для платы ML555.
Почему у Wizard-а и у платы разное назначение выводов?
Для работы контроллера DDR2 достаточно, чтобы DQS[] просто попали в те же банки, что и их DQ[][]?
Для остальных управляющих выводов достаточно просто правильно указать их типы SSTL и т.д, а положение их может быть любым, которое допустит ISE?
Рекомендуемое Wizard-ом назначение дает частоту около 266 МГц. Когда я правлю UCF и вписываю выводы для платы ML555, частота падает до около 200 МГц.
Т.е. назначение для ML555 хуже, чем в новых версиях MIG?
Я не могу заказать в Wizard-e назначение выводов, как для платы ML555.
Почему у Wizard-а и у платы разное назначение выводов?
Для работы контроллера DDR2 достаточно, чтобы DQS[] просто попали в те же банки, что и их DQ[][]?
Для остальных управляющих выводов достаточно просто правильно указать их типы SSTL и т.д, а положение их может быть любым, которое допустит ISE?
Рекомендуемое Wizard-ом назначение дает частоту около 266 МГц. Когда я правлю UCF и вписываю выводы для платы ML555, частота падает до около 200 МГц.
Т.е. назначение для ML555 хуже, чем в новых версиях MIG?
У меня вопрос: для проекта необходимо две независимые планки DDR2 SDRAM. То есть это понадобится два контроллера. Влезут ли они в Виртекс-4 или в Виртекс-5 ?
Просто подскажите как вот эту часть 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;
# 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;
Цитата
Просто подскажите как вот эту часть 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 и все получилось. пока других способов я не знаю. может быть кто знает поделется ?
У меня вопрос сможет ли virtex-4 работать с 512MB DDR2 SDRAM UDIMM с двумя планками? Или лучше для этого пяты использовать?
Сможет, но пятый сможет это лучше.
А данный контроллер памяти использует Distributed RAM? Если да, то сколько? Просто мне помимо контроллеров памяти ещё необходимо будет создавать фифошки на основе Distributed RAM
Имею 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...
Возник вопрос с адресами, точней с колонками...Ответа в 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...
Все очень просто: счетчик адреса квадрослова отдельный, и он перескакивает. Посмотрите документацию на любой чип DDR2, как там организован burst. Если поставите длину пакета 8 - то чтение с адреса 1 будет еще веселее: 12305674. Это делается для того, чтобы строку кэша можно было прочитать с того слова, которое непосредственно необходимо, но в результате чтобы строка кэша была прочитана полностью, даже если ее заполнение началось с середины, что и требует перескока на младшие адреса.
2 DmitryR - то есть получается что это эдакая фича ддр2 чипа.... и что это за строка кеша в 64 бита и слово 16 битное ??
А кроме как играми с масками можно есчё как то записать по произвольному нужному адресу определённую длинну данных используя MIG ??
и что это за строка кеша в 64 бита и слово 16 битное ??А кроме как играми с масками можно есчё как то записать по произвольному нужному адресу определённую длинну данных используя MIG ??
Кроме как используя маску вы не сможете это сделать, даже не используя MIG, потому что у DDR2 минимальный burst - 4, и работает он так, как я написал выше. Это не прихоть MIG, так работает ОЗУ. Но вообще говоря мне непонятно, зачем писать начиная с нечетных адресов: обычно в DDR2 пишет либо процессор из кэша, либо DMA, и они делают это всегда выровненно. И даже в своем устройства думаю всегда можно достичь выровненных обращений к памяти, аккуратно его спроектировав.
2 DmitryR - на счёт кеша это понятно, а дма не всегда может выровненно по 4 писать, если это заранее не заложить..
В обсчем спасибо за разъяснения, а то я подозревал конечно, что это я где то недочитал, но в литературе на миг этого момента не нашёл... Видимо самый правильный ход будет переделать логику под выровненную по 4-ке.
И всё же меня мучает вопрос - почему хилые не заложили маскирование?? не ужели это трудно для них было ?? хотя видимо он останется без ответа...
В обсчем спасибо за разъяснения, а то я подозревал конечно, что это я где то недочитал, но в литературе на миг этого момента не нашёл... Видимо самый правильный ход будет переделать логику под выровненную по 4-ке.
И всё же меня мучает вопрос - почему хилые не заложили маскирование?? не ужели это трудно для них было ?? хотя видимо он останется без ответа...
Цитата(Kuzmi4 @ Aug 28 2009, 21:40)
И всё же меня мучает вопрос - почему хилые не заложили маскирование?? не ужели это трудно для них было ??
Ну вобщем да, это на общий случай довольно заморочно, а в 99% случаев никому не нужно.
Цитата(Kuzmi4 @ Aug 28 2009, 11:21)
2 DmitryR - то есть получается что это эдакая фича ддр2 чипа.... и что это за строка кеша в 64 бита и слово 16 битное ??
А кроме как играми с масками можно есчё как то записать по произвольному нужному адресу определённую длинну данных используя MIG ??
и что это за строка кеша в 64 бита и слово 16 битное ??А кроме как играми с масками можно есчё как то записать по произвольному нужному адресу определённую длинну данных используя MIG ??
немного добавлю вообще это фича всей динамической памяти. об этом в даташите на память всегда подробно расписано %) в вот реализация нечетных масок на ддр возможная но достаточно геморойная, да и не нужна она в большинстве случаев, т.к. обычно, с точки зрения системы, память видится как 2*DDR_DATA_W. А вот четные маски не помешали бы
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.