denisys

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

Можно так: user_net_config_info[0].use_dhcp = 0; // Запрет DHCP user_net_config_info[0].ipaddr = 0xac100002; // 172.16.0.2 user_net_config_info[0].netmask = 0xffffff00; // 255.255.255.0 Это я вставляю в самом начале главного потока до вызова system_init(). Необходимые структуры описаны в #include <lwip/cglobals.h>

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

Нет. Ввиду того, что при заданных условиях удовлетворительное качество получается применением простейшей функции, т.е. результирующее изображение получится не настолько хуже изображения полученного с фильтрацией, чтобы на этом заморачиваться. Все сказанное относится к моему проекту и моей субъективной оценке результата. EvgY судя по всему описал тот самый алгоритм, из примера альтеры.

Не всегда задав заведомо большую частоту можно получить в отчете максимальную частоту для проекта. У xilinx есть скрипт XPLORER, который позволяет в авто-режиме разложить проект несколько раз с различными параметрами и в результате получить наиболее оптимальное их сочетание для проекта. Ну и конечно, запас по частоте нужно иметь, например задав для проекта с микроблазом некоторую чатоту (практически максмальную для проекта) я не получил ошибок таймингов, запас времени для данной частоты по отчету составлял не более 10 пик (для одного из путей в ядре проца), но ядро микроблаза не завелось (остальная логика функционировала нормально), чуть снизив частоту проект запустился (частоту для проверки менял DCMом). Теперь я всегда задаю ограничения с не менее 5% запасом.

При интерполяции вначале между исходными отсчетами вставляют нулевые, а затем ФНЧ. При прореживании вначале ФНЧ, затем выбирают требуемые отсчеты. Все это относится к изменению частоты выборок в целое число раз. Для дробного коэффициента масштабирования в идеале пришлось бы делать вначале интерполяцию, ФНЧ, затем прореживание. В моем случае выполняется апроксимация всего выше сказанного более простой функцией, следовательно, ФНЧ не нужен. Не могу сказать на сколько результат далек от идеала, но для данного применения результат меня удовлетворил. В альтеровском примере, который я взял за отправную точку ФНЧ не было.

Когда-то и мне доводилось делать маштабирование. Изображение было черно-белым, требовалось как увеличивать так и уменьшать его. За основу был взят пример альтеровский (сейчас уже не вспомню номер). Понравилась простота реализации. Яркость результирующей точки равна сумме двух ближайших точек, умноженных на коэффициенты близости их к результирующей. Привожу свой VHDL исходник масштабирования по горизонтали. xscale.vhd

Я получал бинарник из эльфа MB с помощью elf2bin отсюда: h__p://sbibuilder.dc-france.com/download/?idsys=2&idcat=7

Если Post-P&R симуляция проводилась с учетом полученых при раскладке времянок, то стоит обратить внимание на следующее: 1. Правильно ли заданы ограничения для цепей; 2. Смог ли раскладчик выполнить заданные ограничения.

Вы используете библиотечный компонент RAMB4_S16, который описывает память так как это необходимо для моделирования, и этот компонент замечательно работает. Поэтому, следует обратить внимание именно на управляющие сигналы, которые Вы направляете на этот компонент. Кстати, как ведет себя Ваша схема при функциональном моделировании? Проблемы в post-translate симуляции могут быть следствием неверного (с точки зрения синтеза) кода...

Когда-то скачивал, выложил сдесь: http://nukeuploads.com/download/1173965191.../Xpong.zip.html

Содержимое памяти в моделсиме можно посмотреть с помощью окна Workspace и его закладки Memories выбрав соответствующий инстанс.

При работе с двунаправленной внешней шиной данных я явно определяю выходные буферы используя примитив IOBUF, позволяющий управлять двунаправленным пином: SRAMDataBus_i : for i in (C_DWIDTH-1) downto 0 generate SRAMDataBit_i : iobuf port map ( I => mem_Data_O(i), IO => mem_Data_pin(i), O => mem_Data_I(i), T => mem_Data_T(i) ); end generate; При этом внутри спартана имеются две шины данных входная и выходная и сигнал переключения буфера. При таком подходе у меня не возникало проблем с использованием внешней памяти на Spartan-3 starter Kit.

Вы безусловно правы, EDK позволяет в одном проекте создать несколько ядер проца и переферию к ним и назначить каждому ядру софт (при этом для синтеза каждого ядра затрачивается время), но поскольку вопрос звучал так: то и ответ я дал, как это сделать именно в ISE.

Рекомендую попробовать следующее: 1. Сгенерить проект EDK для 1 проца в режиме подмодуля. 2. Создать проект в ISE и добавить туда основной vhdl файл проца, который сгенерил EDK в каталоге HDL (не _stub и не _wrapper). Этот файл вызывает используемые коры проца, описанные как black_box. 3. Создать главном файле проекта инстансы для двух процев используя entity из файла пункта 2. Отсинтезить проект. Если все ок идем дальше. 4. В настройках раскладки указать путь к нетлистами для кор проца 5. Создать bmm файл, который должен содержать описание памяти для двух ядер (ядрам дать разные имена) и передать его в параметры ngbuild (-bm). 6. В настройках битгена назначить каждому имени ядра назначить свой elf-файл (-bd) После этого можно запускать раскладку (надеюсь, пройдет успешно :))