[Georg.A 0]

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

 

Пытаюсь создать проект на ПЛИС путем генерации VHDL кода из Simulink`а.

 

Для начала задался целью сделать квадратурный Direct Digital Syntezator разрядностью 2^13, основанный на 2х таблицах значений функции Lockup Table, синусной и косинусной, разрядность каждой 2^13 (8192 отсчета), интервал от 0 до 2пи.

В хелпе по Simulink HDL Coder есть пример реализации памяти ROM на основе таблицы (внутри подсистемы находится Lockup Table и одиночная задержка), взял его за основу.

 

Проект DDS состоит из аккумулятора фазы и двух ROM подсистем, внутри каждой таблица отсчетов и задержка . После генерации VHDL кода и синтеза в Xilinx ISE 13.4, синтез репорт сообщает о использовании некоторого количества процентов блоков FIFO/RAM, то есть таблицы легли туда.

Если подвешиваю в Simulink модели к выходу ROM`ов какую нибудь подсистему, например фильтр, или выход DDS перемножаю с чем либо еще, то есть расширяю свой проект, то после синтеза в Xilinx ISE, репорт сообщает о том, что проект занял только slices, IOBs, DSP48 и т.д. но FIFO/RAM никак не задействована.

 

Поскольку разрядность DDS приличная, то он сжирает почти всю логику, а чтобы задействовать FIFO/RAM приходится генерировать DDS отдельно от остального проекта.

 

Если кто-то сталкивался с подобной задачей и/или знает как ее решить, подскажите пожалуйста.

Изменено 4 декабря, 2012 пользователем Georg.A

[Tue 0]

наберите команду: open_system('hdlcoderrom'), в открывшейся модели жмите Info. Внимательно посмотрите пример, там есть хитрость в настройках в файле управление (control file)

function c = hdlcoderrom_control
% C = HDLCODERROM_CONTROL
% This is a sample control file for the Simulink HDL Coder hdlcoderrom
% demo. This file shows how you can suppress generation of reset logic for
% the unit delay block in a ROM, and ignore data checking for the first
% cycle of HDL simulation.

%   Copyright 2008 The MathWorks, Inc.
%   $Revision: 1.1.6.2 $  $Date: 2009/11/19 16:38:13 $ 

c = hdlnewcontrol(mfilename);

c.generateHDLFor('./ROM');

c.forEach('./ROM/Unit Delay',...
          'built-in/UnitDelay', {},...
          'default', {'ResetType', 'none'});

c.set('IgnoreDataChecking', 1);

А Вам какой-то особенный DDS надо реализовать ? Просто уже готовый блок NCO есть и с какой-то версии Матлаба он доступен для выхода на HDL (в R2011a уже есть)

[Georg.A 0]

Требуется обычный DDS, для перенесения сигнала на промежуточную и для колец ФАПЧ.

Попробовал библиотечный NCO, он получился достаточно компактным, занял 7% слайсов и 6% LUT в ПЛИС, но память RAM опять не задействована.

 

Если пользуюсь библиотечной LUT симулинка для DDS, то последний кладется в RAM и занимает 10%, при этом слайсы и луты ПЛИС по 0%. Но при добавлении в симулинковский проект еще каких-то модулей, после генерации кода, ISE при синтеза кладет опять все в слайсы и луты, включая DDS.

 

Хотелось задействовать для хранения таблиц именно RAM, поскольку проект достаточных размеров, займет много места и без DDS. Кроме того, планировал использовать в общей сложности 7 DDS. Если же не получиться класть в RAM, то придется использовать 1 или 2 DDS с мультиплексированием по времени, использовать симметричность функции для уменьшения размеров таблицы, что потребует дополнительных усилий при том, что RAM будет пустовать.

 

Пользуюсь версией 2011b, попробовал разобраться с настройками control file, но зайдя в хелп наткнулся на следующее:

 

As of release R2010b, the coder does not support the attachment of a control file to a new model. Instead, the coder now saves all non-default HDL-related model settings, block implementation selections and implementation parameter settings to the model itself. This eliminates the need to maintain a separate control file. Because the coder saves only the non-default parameter settings, the loading and saving of models is more efficient. The recommended practice is to discontinue use of control files and convert existing models. This simple process is described in the next section.

 

То есть, как я понял, в моей версии уже не поддерживаются control file`ы.

 

Из рекомендаций хелпа, следует что в этом контрол файле надо, чтобы параметр 'ResetType' в блоке задержки стоял на 'none' и установить 1 в property 'IgnoreDataChecking'.

 

Follow these modeling guidelines when building a ROM from Simulink:

-For an n-bit address, specify all 2^n entries of the Lookup Table data. Otherwise, your synthesis tool may not map the generated code to RAM, and the code may not match your Simulink model.

-Place the Lookup Table and Unit Delay blocks in the same model hierarchy. In addition, use the default implementation hdldefaults.LookupHDLEmission for the Lookup Table block, so that the generated code from the two blocks are also in the same HDL hierarchy.

-Support of RAM reset logic varies among FPGA devices and synthesis tools. For best synthesis result, suppress the generation of reset logic for the Unit Delay block by setting the 'ResetType' property to 'none' in the control file. Also set the 'IgnoreDataChecking' property to 1 to ignore the initial simulation mismatch caused by suppressing the reset logic.

 

Параметр 'ResetType' в блоке задержки у меня поставлен на 'none' через контектсное меню блока в пункте HDL Code Generation/HDL Block Properties. А вот что делать с 'IgnoreDataChecking' не знаю, поскольку не поддерживаются контрол файлы в 2011b.

 

Остальным требованиям мой DDS вроде отвечает (таблица и задержка в одной иерархии, число строк в таблице 2^13, адресация ведется сигналом ufix(13,0)).

Как уже говорил, проблема в том что отдельно от остальных блоков DDS кладется в RAM, а если включать его в проект то все ложится в слайсы и луты...

Возможно тут что-то с иерархией блоков, хотя пробовал по разному с одинаковым результатом:

 

Генерирую из subsystem1 внутри которой 2 sybsistem`ы (subsystem1/(accum и ROM)), в одной акумулятор фазы в другой LUT и задержка, все хорошо ложится в RAM.

 

Кладу subsystem1`у в другую пустую subsystem2 (subsystem2/subsystem1/(accum и ROM)), генерирую из subsystem2 все ложится в RAM.

Но как только добавляю что-то еще все ложится в слайсы и луты, в обоих случаях.

 

[Tue 0]

То есть, как я понял, в моей версии уже не поддерживаются control file`ы.

...

Параметр 'ResetType' в блоке задержки у меня поставлен на 'none' через контектсное меню блока в пункте HDL Code Generation/HDL Block Properties. А вот что делать с 'IgnoreDataChecking' не знаю, поскольку не поддерживаются контрол файлы в 2011b.

 

Это они пугают, что не поддерживается, видимо в будущем действительно от них откажутся. Для того, чтобы сгенерить HDL-код модели с control file я например делаю так:

makehdl('NameOfYourModel','HDLControlFiles',{'ctrl_file.m'})

 

(подробнее - см. параметры для команды makehdl)

ctrl_file.m - control file для вашей модели

NameOfYourModel - название вашей модели. Можете потренироваться на hdlcoderrom

 

Как уже говорил, проблема в том что отдельно от остальных блоков DDS кладется в RAM, а если включать его в проект то все ложится в слайсы и луты...

Возможно тут что-то с иерархией блоков, хотя пробовал по разному с одинаковым результатом:

 

Генерирую из subsystem1 внутри которой 2 sybsistem`ы (subsystem1/(accum и ROM)), в одной акумулятор фазы в другой LUT и задержка, все хорошо ложится в RAM.

 

Кладу subsystem1`у в другую пустую subsystem2 (subsystem2/subsystem1/(accum и ROM)), генерирую из subsystem2 все ложится в RAM.

Но как только добавляю что-то еще все ложится в слайсы и луты, в обоих случаях.

Скорее всего, что-то делаете не так или в САПР Xilinx какую-то галку надо поставить. Я работаю на Альтере, положите сюда модель, попробую.

[litv 0]

как мучаются люди без System Generator

[Georg.A 0]

Большое спасибо Tue, попробую изменить этот control file.

Архив с моделью и репортом о использовании ресурсов ПЛИС приложил.

 

Что касается System Generator, там есть библиотечный DDS, но у него избыточная функциональность в контексте нашего использования. Поэтому люди делают свой DDS используя библиотечный блок памяти RAM.

Я по аналогии сейчас решил попробовать использовать для DDS блоки simple dual port RAM загрузив в них таблицы. Вроде бы они занимают еще меньше места чем LUT таблицы загружаемые в RAM и библиотечный NCO.

ROM.rar

[litv 0]

Избыточная функциональность :1111493779: . Конечно мешает. Зато сразу можно выбрать Block или distrubuted RAM или auto,число задержек, оптимизация по скорости или площади и ................................................................................

........

[Tue 0]

Возможно тут что-то с иерархией блоков, хотя пробовал по разному с одинаковым результатом:

 

Генерирую из subsystem1 внутри которой 2 sybsistem`ы (subsystem1/(accum и ROM)), в одной акумулятор фазы в другой LUT и задержка, все хорошо ложится в RAM.

 

Кладу subsystem1`у в другую пустую subsystem2 (subsystem2/subsystem1/(accum и ROM)), генерирую из subsystem2 все ложится в RAM.

Но как только добавляю что-то еще все ложится в слайсы и луты, в обоих случаях.

 

Как-то сумбурно и непонятно. Из Вашей модели ROM_DDS если генерить код для блока ROM_DDS/DDS1, то код делается и кладется в ROM (задействуются блоки памяти, у меня Альтера). В блоке ROM_DDS/Subsystem у Вас там много всего, мне не дает генерировать код блок Lowpass Filter, так что попробовать не могу. Т.к. Вы поместили блок DDS2 в Subsystem, то также в контрольном файле, примерное содержимое которого я писал выше, нужно в строке "c.forEach('./ROM/Unit Delay',..." указать правильно путь, например так: "c.forEach('ROM_DDS/Subsystem/DDS2/ROM/Unit Delay',...", ну и для ROM_DDS/Subsystem/DDS2/ROM1/Unit Delay тоже

[Georg.A 0]

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

Tue, я попробовал сделать как Вы советовали makehdl('NameOfYourModel','HDLControlFiles',{'ctrl_file.m'})

результат в матлабе был такой пишет что не может открыть контрол файл.

 

Успешные результаты по генерации все же есть, счетчик и DDS успешно заработали, пришлось правда что-то подворачивать руками. По этому поводу хотел спросить у Вас, Tue, по опыту сделанных с помощью генератора работ:

Генерация кода производилась сразу из всей модели проекта или возникала необходимость...

1. некоторые части модели генерировать отдельно и связывать вручную

2. некоторые части модели переписывать вручную

3. и первое и второе

[Tue 0]

ммм... не понял вопроса. "Некоторые части модели генерировать отдельно и связывать вручную" - не понимаю в чем смысл? Обычно, когда d проекте ПЛИС есть модели, которые должны тактироваться разными частотами - то эти модули я соединяю вручную (например в схематике Квартуса, который можно потом перевести в hdl автоматом). Это потому что Симулинк умеет генерировать hdl для блоков с одной единственной частотой (один вход clk). Забота о разных тактовых доменах - это задача разработчика.

"некоторые части модели переписывать вручную" - а это зачем ?

 

Да, по поводу контрол-файла. Модель, для которой Вы генерируете код и контрол-файл находятся в одной директории и Матлаб находится в ней ?

[Georg.A 0]

""Некоторые части модели генерировать отдельно и связывать вручную" - не понимаю в чем смысл? "

Например, когда получается различный результат (как в моем случае, когда задействуются разные ресурсы ПЛИС) при генерации из всей модели и при генерации из отдельных частей.

 

А так не знаю, потому и спросил:)

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

 

"некоторые части модели переписывать вручную" - а это зачем ?

Для того, чтобы получить законченный проект на ПЛИС. Я и спрашиваю,"Генерация кода производилась сразу из всей модели проекта или возникала необходимость", то есть бывали ли такие случаи что всю модель не удавалось сразу перевести в VHDL, или же, с помощью кодера удалось успешно реализовать все проекты без необходимости:

1. некоторые части модели генерировать отдельно и связывать вручную

2. некоторые части модели переписывать вручную

 

 

Модель и матлаб находятся в одной директории, залез в свойства модели там написано:

 

 

http://electronix.ru/forum/style_images/1/.../attach_add.png

 

[Tue 0]

Различный результат получаться не должен. Если хотите в этом убедиться, отмоделируйте Вашу модель, а параллельно подключите блок HDL Cosimulation, например через ModelSim, в котором будет крутиться HDL-код сгенерированный по Вашей модели. Результаты моделирования должны быть идентичны (если все сделано правильно - еще не встречал разногласий в в результатах модели и HDL-кода)

то есть бывали ли такие случаи что всю модель не удавалось сразу перевести в VHDL, или же, с помощью кодера удалось успешно реализовать все проекты без необходимости:

1. некоторые части модели генерировать отдельно и связывать вручную

2. некоторые части модели переписывать вручную

такого не было и не должно быть. Если хотите создать для модели HDL-код, то она не должна содержать блоки, не поддерживаемые HDL Coder'ом. Если такие есть, то их надо вытаскивать за модель. Честно говоря, не приходит в голову причина, по которой "всю модель не удавалось сразу перевести в VHDL"

hdlcoderrom - это модель из демок. При обращении к ней MATLAB лезет в другую директорию. Если хотите с ней повозиться сохраните ее в своей папке с другим именем