MIG 7-series энергопотребление, Высокое энергопотребление ядра MIG Опции

[Inanity]

Здравствуте!

В устройстве применяется Artix-7 XC7A50TCSG325-2L. К ней подключены 2 микросхемы DDR3L (4Gb x8), запитаны от 1.5в (при возможных 1.35в). Соответственно предполагалось иметь 2 контроллера MIG для каждой памяти. Для тестов была пока запаяна только одна микросхема DDR3L. Инициализацию память проходит, memorytest тоже (тест прогонялся примерно 1 час).

Ситуации:
1. ПЛИС с включенным питанием без конфигурации потребляет ~0.7W (темп-ра кристалла ~45град)
2. ПЛИС с проектом microblaze (Helloworld в бесконечном цикле) ~0.9W (темп-ра кристалла ~52град)
3. ПЛИС с проектом microblaze + одна DDR3L (MemoryTest в бесконечном цикле) ~ 2.0W(!) (темп-ра кристалла ~82град!)
Сразу скажу, что даже в таких диких условиях память корректно работает. Однако, температура кристалла и энергопотребление никак не сопоставляется с тем, что
обещал XPE и тем, что было спрогнозировано компилятором:
>>Total On-chip Power 0.78W
>>Junction Temperature 28.7 град
Проверял напряжение всех линий питания под нагрузкой и без - всё в порядке.

Я нахожу ситуацию №3 неадекватной. Я не первый, кто столкнулся с этой проблемой, однако решения ей пока в сети не нашёл:
раз два три

Прикладываю конфиг MIGa для одной из DDR3L:

MIG Output Options:
Module Name : SoC_my_mig_7series_0_0
No of Controllers : 1
Selected Compatible Device(s) : xc7a35t-csg325

FPGA Options:
System Clock Type : No Buffer
Reference Clock Type : No Buffer
Debug Port : OFF
Internal Vref : enabled
IO Power Reduction : ON
XADC instantiation in MIG : Enabled

Extended FPGA Options:
DCI for DQ,DQS/DQS#,DM : enabled
Internal Termination (HR Banks) : 40 Ohms

/*******************************************************/
/* Controller 0 */
/*******************************************************/
Controller Options :
Memory : DDR3_SDRAM
Interface : AXI
Design Clock Frequency : 2500 ps ( 0.00 MHz)
Phy to Controller Clock Ratio : 4:1
Input Clock Period : 10000 ps
CLKFBOUT_MULT (PLL) : 8
DIVCLK_DIVIDE (PLL) : 1
VCC_AUX IO : 1.8V
Memory Type : Components
Memory Part : MT41K512M8XX-125
Equivalent Part(s) : MT41K512M8RH-125
Data Width : 8
ECC : Disabled
Data Mask : enabled
ORDERING : Normal

AXI Parameters :
Data Width : 64
Arbitration Scheme : RD_PRI_REG
Narrow Burst Support : 0
ID Width : 1

Memory Options:
Burst Length (MR0[1:0]) : 8 - Fixed
Read Burst Type (MR0[3]) : Sequential
CAS Latency (MR0[6:4]) : 6
Output Drive Strength (MR1[5,1]) : RZQ/6
Controller CS option : Enable
Rtt_NOM - ODT (MR1[9,6,2]) : RZQ/6
Rtt_WR - Dynamic ODT (MR2[10:9]) : Dynamic ODT off
Memory Address Mapping : BANK_ROW_COLUMN

Что пробовал сделать:
1. Первоначально думал, что проблема с памятью. Благо запаял для тестов только одну микр-му. Сконфигал ядро на работу с незапянной памятью и наблюдал такое же высокое потребление. (стало быть дело в MIG?)
2. Пробовал отключать терминирование DQ\DSQ на ПЛИС - не помогло. Кстати работать не перестало, память всё так же инициализируется и проходит memorytest.
3. Версия ПЛИС с индексом -2L позволяет гонять её при напряжении ядра 0.9v. Что соответственно и сделал (1.0v -> 0.9v). Это помогло на ~10% снизить энергопотребление, но проблему не решило.

Заметил следующую одну очень странную особенность: ПЛИС зашита конфигурацией, но кода microblaze нет (ничего не гоняется и по идее DDR3 неактивна, кроме, наверное refresh). После загрузки кода, и запуска проекта (memorytest), потребление НЕ изменяется!! Тогда вопрос, чем занят MIG всё то время, когда я к нему не обращаюсь? Насколько это нормальное поведение контроллера? И почему вообще это ядро так много потребляет?

Сразу скажу, что решить проблему активным охлаждением в моём случае невозможно. Единственно, что возможно - пассивное охлаждение, но рассчитывать на него не хочется.

Спасибо!

[Inanity]

TO des00:

--Да, была у меня мысль провести такой тест, как-нибудь на днях обязательно сделаю. Но дело в том, что данные для XPE взяты не с потолка, а после implementation вызвана команда report_power -xpe filename.xpe. И уже этот файл был загружен и проанализирован XPE.

-- Что касается потребления в статике - согласен, судя щиту оно скорее всего превышено. Но к сожалению точное значение тока на линии питания ядра вычислить сложно.

TO Dr.Alex:

--Спасибо за информацию! Запускали ли вы MIG?


--->Начинаю вспоминать, что в процессе сборки инженерного варианта был следующий казус. Питание VCCAUX подавалось с dc-dc регулятора через LC-фильтр. Дело в том, что после запайки и проверки всего питания я не заметил, что этот самый LC фильтр не был установлен. Таким образом после первого включения ПЛИС VCCAUX не был запитан.(Запитано было VCCINT, все VCCIO и два питания трансиверов) Могло ли это повредить ПЛИС? (нагрева, кстати, с отсутствующим питанием VCCAUX я не заметил тогда).
Мог ли так же перегрев ПЛИС при её запайке и запайке других компонентов привести к такому поведению?

Сообщение отредактировал Inanity - Jan 2 2015, 19:51

[Flood]

--->Начинаю вспоминать, что в процессе сборки инженерного варианта был следующий казус. Питание VCCAUX подавалось с dc-dc регулятора через LC-фильтр. Дело в том, что после запайки и проверки всего питания я не заметил, что этот самый LC фильтр не был установлен. Таким образом после первого включения ПЛИС VCCAUX не был запитан.(Запитано было VCCINT, все VCCIO и два питания трансиверов) Могло ли это повредить ПЛИС? (нагрева, кстати, с отсутствующим питанием VCCAUX я не заметил тогда).
Мог ли так же перегрев ПЛИС при её запайке и запайке других компонентов привести к такому поведению?

Отсутствие VCCAUX не должно быть страшно для 7-й серии, по крайней мере, если ни один IO банк не запитывается от 3,3В.

The voltage difference between VCCO and VCCAUX must not exceed 2.625V for longer than TVCCO2VCCAUX for each
power-on/off cycle to maintain device reliability levels.

По опыту еще ни разу не встречал повышенное потребление по ядру - обычно при проблемах с Vccint/Vccaux чип закорачивается на землю и все умирает.
Зато Xilinx'ы отлично умеют гореть по Vcco - при выгорании какой-либо ножки IO соответствующий банк начинает жрать приличный ток, при этом все, кроме подгоревшей ножки, работает. В пострадавшем банке, как правило, серьезно нарушается качество сигнала на оставшихся ножках (параллельные шины начинают глючить), но в целом банк продолжает шевелиться (если источник Vcco справляется с нагрузкой). Сгоревший банк можно вызвонить на выключенной плате по резко сниженному сопротивлению Vcco.
Однако этот эффект не динамический и не масштабируется в зависимости от конфигурации ПЛИС.

Насчет генератора на 1,8В - это явное нарушение, но оно не даст такого большого тока (на 0,7Вт потребления). Можно попробовать его снять или выключить (EN генератора на землю) для оценки потребления пустой плисины.

Если есть серьезные подозрения на саму ПЛИС - ее можно заменить, а снятую поставить во второй прототип.

Возможно, все-таки 0,7Вт потребляет не сама ПЛИС, а вся плата целиком? Температура кристалла ПЛИС вообще не имеет полезного значения для оценки потребления, т.к. сильно зависит от теплоотвода в виде печатной платы.

[Inanity]

Отсутствие VCCAUX не должно быть страшно для 7-й серии, по крайней мере, если ни один IO банк не запитывается от 3,3В.

Нет питания 3.3в на ПЛИС не заходит вообще. Банки питаются от 1.5в и 1.8в

Зато Xilinx'ы отлично умеют гореть по Vcco - при выгорании какой-либо ножки IO соответствующий банк начинает жрать приличный ток, при этом все, кроме подгоревшей ножки, работает. В пострадавшем банке, как правило, серьезно нарушается качество сигнала на оставшихся ножках (параллельные шины начинают глючить), но в целом банк продолжает шевелиться (если источник Vcco справляется с нагрузкой).

Спасибо, буду иметь ввиду. Но в данном случае не вижу предпосылок для такого развития событий. Банк так или иначе работает и управляет памятью на скорости 800Mb\s, при чём проходит относительно продолжительный тест (тем более при высокой температуре). Сбоев или единичных ошибок пока не наблюдал.

Насчет генератора на 1,8В - это явное нарушение, но оно не даст такого большого тока (на 0,7Вт потребления). Можно попробовать его снять или выключить (EN генератора на землю) для оценки потребления пустой плисины.

Абсолютно с вами согласен в том, что это нарушение, к сожалению это мой промах, очень плотный дизайн, практически все пины заняты. Тем не менее поверил (EN генератора на землю) - проблема не в нём, потребляемый ток уменьшается на величину, равную потреблению самого генератора.

Возможно, все-таки 0,7Вт потребляет не сама ПЛИС, а вся плата целиком? Температура кристалла ПЛИС вообще не имеет полезного значения для оценки потребления, т.к. сильно зависит от теплоотвода в виде печатной платы.

Прошу прощения, боюсь, что я допустил ошибку и ввёл людей в заблуждение. Цифры потребления из первого сообщения приводились для всей платы. Просто хотел продемонстрировать потребление устройства на разных битстримах при прочих равных условиях, т.е. на одном и том же железе.

Если мы говорим только о ПЛИС, то 0.375W - это потребление пустой ПЛИС по всем линиям питания + потребление одной DDR3 в статике. Я понимаю, что это очень грубая оценка, но это то, что я смог получить, отключив на плате всё, что можно. Если потребление DDR3 MT41k512M8 (die rev E) оценить как 0.05W, то получаем ~0.3W для всех линий питания ПЛИС, что в принципе, учитывая некоторую погрешность в расчётах, соизмеримо с данными из даташита DS181. Стало быть потребление в статике в норме.


Если мои соображения ранее верны, то осталось ответить на 2 вопроса:

---Почему MIG (если сравнивать ситуации №1 и №3 из первого поста) добавляет 1.3W? Откуда такая прожорливость у этого ядра?
---Почему после загрузки кода microblaze (когда начинается сам memorytest и память активно пишется\читается) потребление НЕ изменяется? Чем занимается MIG в то время, когда я к нему не обращаюсь? Насколько это адекватное поведение контроллера?

Сообщение отредактировал Inanity - Jan 3 2015, 01:30

[Flood]

---Почему MIG (если сравнивать ситуации №1 и №3 из первого поста) добавляет 1.3W? Откуда такая прожорливость у этого ядра?
---Почему после загрузки кода microblaze (когда начинается сам memorytest и память активно пишется\читается) потребление НЕ изменяется? Чем занимается MIG в то время, когда я к нему не обращаюсь? Насколько это адекватное поведение контроллера?

Возможно, это нормальное потребление. Попробуйте также ввести данные проекта в XPE вручную для грубой оценки.

Насчет микроблейза - не сможет этот процессор хорошо нагрузить память. Для нагрузочного теста нужны постоянные длинные пересылки, обеспечить которые может только DMA.

Есть вариант собрать MIG без процессорной подсистемы - в простом, не embedded маршруте. Для чистоты эксперимента можно генерировать ядро без использования шины AXI. Там создается Example Design с тестовым генератором. Этот тестовый проект нужно собрать, загрузить в ПЛИС и посмотреть, сколько он будет жрать в софт-ресете и при нормальной работе. Заодно, нужно смотреть на выходы calib_complete и error (лучше делать это в ILA). Получится наиболее чистый тест ядра MIG. Если все клоки заведены согласно пожеланиям MIG'а - никакой ручной работы не потребуется.
Заодно можно будет повторить тест на 1,35В и оценить разницу.

Все незадействованные пины подключены, как описано в даташите. Перепайка - не проблема, однако хотелось бы её оставить на самый крайний случай. Идеи кончаются, что я ещё не попробовал?

Идей сгенерить можно еще миллион, был бы с них толк Например, подключение незадействованных пинов (например, половину к питанию, половину к земле, как советуют для железобетонных проектов) может сыграть неприятную шутку, если в топе проекта найдутся неиспользованные выходы. Маппер положит их куда-нибудь и, если брошенный выход с нулем попадет на подключенную к питанию ножку, неприятные эффекты будут обеспечены.