[Koluchiy 0]

Здравствуйте, уважаемые гуру.

 

Пытаюсь я тут решить следующую задачу.

Есть проект для Xilinx Spartan-3. Он состоит из системы Microblaze и кучи модулей, написанных на Верилоге.

К ПЛИСу снаружи подключен SDRAM.

До недавнего времени этот SDRAM подключался к системе Microblaze при помощи контроллера opb_sdram (досталось по наследству).

Сейчас перешел на MPMC версии 5.04a.

Оно вполне себе работает, если синтезировать проект при помощи XST (да, среда - ISE 11.5).

Но если синтезировать при помощи Synplify 2009.06, происходит следующая бяка:

синтез проходит успешно, но при попытке Translate появляются ошибки:

 

ERROR:NgdBuild:947 - bidirect pad net 'SDRAM_Controller_SDRAM_DQ_pin_c[0]' is
   driving non-input buffer(s):
     pin I on block SDRAM_Controller_SDRAM_DQ_pin_obuf[0] with type OBUF
(для каждой линии данных)
И еще 
ERROR:NgdBuild:467 - output pad net 'SDRAM_Controller_SDRAM_Clk_pin_c' has an
   illegal buffer
ERROR:NgdBuild:467 - output pad net 'SDRAM_Controller_SDRAM_DM_pin_c[0]' has an
   illegal buffer
ERROR:NgdBuild:467 - output pad net 'SDRAM_Controller_SDRAM_DM_pin_c[1]' has an
   illegal buffer

К остальным сигналам (пока) не придирается.

 

Если посмотреть Technology schematic, можно увидеть, что Synplify почему-то сделал двунаправленную шину SDRAM_Controller_SDRAM_DQ однонаправленным выходом. Хотя, явно прописано inout.

 

Подскажите, куда читать и чего смотреть...

[Kuzmi4 0]

С недавнего, касательно NgdBuild:467

AR#32847

 

А так, логи в студию :laughing:

[Koluchiy 0]

Да-да, про XST там хорошо написано...

Где бы аналогично прочитать про Симплифай.

Какие конкретно логи - в студию?

Изменено 22 ноября, 2010 пользователем Koluchiy

[Kuzmi4 0]

Там один вменяемый лог для человеков - *.srr, в нём можно поиском прошвырнуться касательно интересующих моментов.

Или же через гуй :laughing: будет он же, но удобней

[Koluchiy 0]

Ну смотрите...

Предупреждаю сразу - 4 тыщи строк :).

E1X32XRT_srr.txt

[Kuzmi4 0]

Навскидку вот

@W: CG360 :"D:\files\Xilinx\E1X32_DataStream7L5_X11_32ch\projnav\Sources\E1X32XRT.v":575:13:575:43|No assignment to wire SDRAM_Controller_SDRAM_DQ_O_pin

А с иллегал буферами побороться можно конечно руками или самому повырезать их из кода

[Koluchiy 0]

@W: CG360 :"D:\files\Xilinx\E1X32_DataStream7L5_X11_32ch\projnav\Sources\E1X32XRT.v":575:13:575:43|No assignment to wire SDRAM_Controller_SDRAM_DQ_O_pin

 

Это рудимент, никуда не подключенные wire.

 

А с иллегал буферами побороться можно конечно руками или самому повырезать их из кода

 

Как они вообще появляются, как с ними бороться руками и как, из какого кода вырезать?

[Kuzmi4 0]

2 Koluchiy

по первому - ну тогда в данной ситуации думаю вам самому быстре будет найти почему оно так не по джентельменски обходится с SDRAM_DQ пинами.

По второму - в сгенерированном коде который вам выдало детище индусов присутствуют I/OBUF, с которыми и нужно "разобраться"..

 

Сам всегда брал МИГ и дописывал нужный интерфейс - и потому был избавлен от таких траблов.. Раньше встречал темы по поводу дозатачивания MPMC руками потому и выбрал MIG+руки :laughing: Поищите по форуму если не найдётся людей кто руками дотачивал MPMC..

[Koluchiy 0]

OBUF вставляет непосредственно Synplify...

Это тоже детище индусов?

[Kuzmi4 0]

По ссылке приведённой выше

...MPMC IP Core which already contains buffers in the HDL source code...

[Koluchiy 0]

Оно буферы содержит, но код, где они есть, юзеру недоступен.

Synplify не понимает того, что буферы уже есть, и ставит еще сверху OBUF'ы.

 

Вопрос в том, как отучить его это делать.

[andrew_b 14]

Глобально запретить можно через disable_io_insertion.

[Koluchiy 0]

Тогда он вообще не будет их вставлять, в том числе там, где это надо (когда-то пробовал - ничего хорошего не получилось).

 

В общем, сейчас проблему решил через строчку /*synthesis syn_black_box black_box_pad_pin=...*/, вставляемую в файл system.v .

Всё бы хорошо, но этот файл перезаписывается при каждой перекомпиляции системы Microblaze, и ее надо вставлять заново.

 

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

Ничего хорошего не получилось - Synplify считает этот промежуточный модуль как black box, и системы там не видит.

 

/*synthesis syn_black_box black_box_pad_pin=...*/ "работает" там, где модуль создается.

В моём понимании, надо сделать то же самое, но там, где модуль (система Microblaze) подключается.

Вот только вот как это сделать?

Изменено 23 ноября, 2010 пользователем Koluchiy

[andrew_b 14]

В общем, сейчас проблему решил через строчку /*synthesis syn_black_box black_box_pad_pin=...*/, вставляемую в файл system.v .

Всё бы хорошо, но этот файл перезаписывается при каждой перекомпиляции системы Microblaze, и ее надо вставлять заново.

А в файле констрейнов самого Synplify?