[BSACPLD 14]

Решил недавно попробовать вместо altsyncram использовать HDL описание DPRAM и столкнулся со следующей проблемой:

Если синтезировать в чистом Quartus, то всё нормально.

Если использовать Synplify, то вместо аппаратного rden получаю кучу внешних регистров адреса с мультиплексорами.

Вопрос: можно ли как-то объяснить Synplify'ю, что нужно использовать аппаратный rden, а не лепить его аналог на логике?

DPRAM_Q.rar

DPRAM_S.rar

[des00 25]

используйте макросы + два вида описания и не грейте попусту мозг ;)

[BSACPLD 14]

Так если только под Altera, то проблем нет. А если попытаться перейти на Xilinx, то возникают проблемы с использованием их примитивов или макросов - фактически поверх них нужно писать внешнюю обертку, т.к. один примитив даёт задействовать только один BRAM. Хотя, конечно, можно сделать комбинированный исходник: под Altera - altsyncram, под Xilinx - HDL и забить на лишнюю логику .

[des00 25]

Так если только под Altera, то проблем нет. А если попытаться перейти на Xilinx, то возникают проблемы с использованием их примитивов или макросов - фактически поверх них нужно писать внешнюю обертку, т.к. один примитив даёт задействовать только один BRAM. Хотя, конечно, можно сделать комбинированный исходник: под Altera - altsyncram, под Xilinx - HDL и забить на лишнюю логику .

и в чем проблема то ?

 

`ifdef __USE_ALTERA_MACRO__
`elsif  __USE_XILINX_MACRO__ 
`else 
`endif

 

???

[Bad0512 2]

Решил недавно попробовать вместо altsyncram использовать HDL описание DPRAM и столкнулся со следующей проблемой:

Если синтезировать в чистом Quartus, то всё нормально.

Если использовать Synplify, то вместо аппаратного rden получаю кучу внешних регистров адреса с мультиплексорами.

Вопрос: можно ли как-то объяснить Synplify'ю, что нужно использовать аппаратный rden, а не лепить его аналог на логике?

А объясните мне зачем вообще нужен аппаратный RDEN? Вам чем-то мешает чтение данных с "неправильных" адресов? Или вы таким способом пытаетесь снизить энергопотребеление?

Если вам нужно чтобы данные на выходной шине данных не менялись - для этого достаточно не менять адрес на чтение и всё.

[BSACPLD 14]

и в чем проблема то ?

 

`ifdef __USE_ALTERA_MACRO__
`elsif  __USE_XILINX_MACRO__ 
`else 
`endif

 

???

Да проблема не в том, как их задействовать, а в том, что Xilinx'овские макросы очень не удобные в использовании - геммороя с ними много :angry2:

Для Altera'ы я могу указать тип памяти AUTO и она будет синтезироваться в зависимости от объёма на тех или иных блоках автоматически (M4K, M144, ...).

Для Xilinx обязательно указывать тип памяти, причём для разных семейств будет свой примитив, со своим набором сигналов. В отличии от altsyncram, который один для всех семейств.

 

А объясните мне зачем вообще нужен аппаратный RDEN? Вам чем-то мешает чтение данных с "неправильных" адресов? Или вы таким способом пытаетесь снизить энергопотребеление?

Если вам нужно чтобы данные на выходной шине данных не менялись - для этого достаточно не менять адрес на чтение и всё.

Для того, чтобы корретным образом тормозить и запускать конвеер. Есть уже готовый рабочий модуль под Altera, который я хочу попробовать адаптировать по Xilinx без пределки основного кода.

[Bad0512 2]

Для того, чтобы корретным образом тормозить и запускать конвеер. Есть уже готовый рабочий модуль под Altera, который я хочу попробовать адаптировать по Xilinx без пределки основного кода.

Xilinx Block RAM не поддерживает отдельный enable на чтение. Только на все операции сразу. Почему? ИМХО потому что это - совершенно бессмысленный сигнал.

Если хотите честно победить проблему - тормозите логику формирования адреса чтения на моменты когда RDEN = 0. Результат будет тот же.

 

[BSACPLD 14]

После вставки в основной проект проблема решилась сама собой. "Лишние" регистры соптимизировались с остальной логикой проекта. Так что по ресурсам я практически ничего не потерял.