oval

Я в свое время тоже не нашел. Можно посмотреть у Synopsys'а, там есть кое что. Вообщем в результате подумали и сделали сами. Полностью согласен с scheme_ru.

Не понятно, что конкретно требуется? Нельзя ли поподробнее?

Была похожая проблема, причины выяснить не удалось, в общем-то особо и не заморачивался. В ISE5 все разводилось нормально, поэтому и решил не разбираться. Сложилось впечатление, что это ошибка Xilinx'а. Если посмотреть схему после синтеза, то указанный вход был задействован. Trim report был пуст!!! Удачи.

Не думаю, что подобная идея подойдет для данной конкретной задачи, ибо, как минимум, растянется цикл доступа к памяти. Что, если мы не имеем возможности разнести операции по последовательным тактам? Что, если этих операций 100? Чем повышается надежность работы схемы при таком подходе? Модуль, который после прихода управляющего сигнала выдает последовательные импульсы, это тот же автомат состояний. Идея понятна, но на мой взгляд, никакой надежности не добавит. P.S. Господа, при проектировании автоматов "не опускайтесь" до уровня импульсов, думайте "выше", на уровне действий, операций. Про управляющие сигналы, конечно, не забывайте.

SDRAM занимается сама собой только после подачи команды AUTO REFRESH, сколько тактов она занимается собой, зависит от рабочей частоты. То, через какое время SDRAM будет заниматься собой, зависит от того, когда подавать соответствующую команду. Условие обычно следующее, раз в 64ms необходимо произвести регенерацию всех строк SDRAM, т. е. за период 64ms необходимо выдать на SDRAM количество команд AUTO REFRESH, равное количеству строк SDRAM. Как они (эти команды) будут распределены внутри этого промежутка времени (подряд, через равные промежутки, пачками и т. п.), не важно.

Насколько известно человеку, который у меня занимается контроллерами памяти SDRAM, подавать команду до истечения времени Trfc нельзя, причем никакую, кроме NOP. Это будет нарушением протокола работы SDRAM. Как же отреагирует на такую ситуацию память, зависит от типа памяти, есть мнение, что проигнорирует.

Для начала, как образуются защелки: допустим, мы хотим сформировать некоторый сигнал B, состояние которого изменяется в зависимости от сигнала A следующим образом, к примеру, пусть когда A высокий, то инвертируем B. Это описывается так: if A = 1 then B <= not B; end if; Дальше все просто: мы не указываем, какое значение присвоить B, если A не равен '1', то есть если A не равен '1', то состояние сигнала B изменять не требуется, и требуется сохранение его (B) текущего состояния, это и образует защелку. В вашем случае, при формировании выходных сигналов автомата состояний, чтобы избежать образования защелок, требуется назначать значение каждого выходного сигнала в каждой ветви условий, либо, как обычно делают, чтобы не забыть, при входе в процесс назначают каждому сигналу значение по умолчанию. Попробую продемонстрировать: if (CLR = '1') then MEM_CS <= '1'; MEM_RD <= '1'; MEM_WR <= '1'; inc_addr1 <= '0'; write_MEM <= '1'; MEM_A(14 downto 0) <= addr1 (14 downto 0); -- отсутствует в данной ветви data(7 downto 0) <= MEM_D(7 downto 0); -- отсутствует в данной ветви else case CurState is when sStartReadMem => write_MEM <= '0'; MEM_A(14 downto 0) <= addr1 (14 downto 0); MEM_CS <= '0'; MEM_RD <= '0'; MEM_WR <= '1'; -- отсутствует в данной ветви inc_addr1 <= '0'; -- отсутствует в данной ветви data(7 downto 0) <= MEM_D(7 downto 0); -- отсутствует в данной ветви when sEndReadMem => MEM_CS <= '1'; MEM_RD <= '1'; data(7 downto 0) <= MEM_D(7 downto 0); inc_addr1 <= '1'; write_MEM <= '0'; -- отсутствует в данной ветви MEM_A(14 downto 0) <= addr1 (14 downto 0); -- отсутствует в данной ветви MEM_WR <= '1'; -- отсутствует в данной ветви when sSaveData => write_MEM <= '0'; inc_addr1 <= '0'; ------- MEM_CS <= '1'; -- отсутствует в данной ветви MEM_RD <= '1'; -- отсутствует в данной ветви data(7 downto 0) <= MEM_D(7 downto 0); -- отсутствует в данной ветви MEM_A(14 downto 0) <= addr1 (14 downto 0); -- отсутствует в данной ветви MEM_WR <= '1'; -- отсутствует в данной ветви when sStartWriteMem => MEM_A(14 downto 0) <= addr2(14 downto 0); MEM_CS <= '0'; MEM_WR <= '0'; MEM_RD <= '1'; -- отсутствует в данной ветви data(7 downto 0) <= MEM_D(7 downto 0); -- отсутствует в данной ветви write_MEM <= '0'; -- отсутствует в данной ветви inc_addr1 <= '0'; -- отсутствует в данной ветви when sEndWriteMem => MEM_CS <= '1'; MEM_WR <= '1'; MEM_A(14 downto 0) <= addr2(14 downto 0); -- отсутствует в данной ветви MEM_RD <= '1'; -- отсутствует в данной ветви data(7 downto 0) <= MEM_D(7 downto 0); -- отсутствует в данной ветви write_MEM <= '0'; -- отсутствует в данной ветви inc_addr1 <= '0'; -- отсутствует в данной ветви end case; -- здесь тоже надо присваивать MEM_CS <= '1'; -- отсутствует в данной ветви MEM_WR <= '1'; -- отсутствует в данной ветви MEM_A(14 downto 0) <= addr2(14 downto 0); -- отсутствует в данной ветви MEM_RD <= '1'; -- отсутствует в данной ветви data(7 downto 0) <= MEM_D(7 downto 0); -- отсутствует в данной ветви write_MEM <= '0'; -- отсутствует в данной ветви inc_addr1 <= '0'; -- отсутствует в данной ветви end if; Это первый вариант, не самый удачный, надо сказать, обычно так не делают. Второй вариант: -- присваиваем всем сигналам значения по умолчанию и дальше ни разу не паримся, о том, что что-то забыли MEM_CS <= '1'; MEM_WR <= '1'; MEM_A(14 downto 0) <= addr2(14 downto 0); MEM_RD <= '1'; data(7 downto 0) <= MEM_D(7 downto 0); write_MEM <= '0'; inc_addr1 <= '0'; if (CLR = '1') then MEM_CS <= '1'; MEM_RD <= '1'; MEM_WR <= '1'; inc_addr1 <= '0'; write_MEM <= '1'; else case CurState is when sStartReadMem => write_MEM <= '0'; MEM_A(14 downto 0) <= addr1 (14 downto 0); MEM_CS <= '0'; MEM_RD <= '0'; when sEndReadMem => MEM_CS <= '1'; MEM_RD <= '1'; data(7 downto 0) <= MEM_D(7 downto 0); inc_addr1 <= '1'; when sSaveData => write_MEM <= '0'; inc_addr1 <= '0'; ------- when sStartWriteMem => MEM_A(14 downto 0) <= addr2(14 downto 0); MEM_CS <= '0'; MEM_WR <= '0'; when sEndWriteMem => MEM_CS <= '1'; MEM_WR <= '1'; end if; Второй, широко используемый вариант. Его и рекомендую. Относительно инкремента счетчика адреса: по тому фронту, по которому защелкиваете прочитанные из памяти данные, по нему же и инкрементируете адрес. Здесь ничего выдумывать не надо. Удачи! P.S. Не особо заморачивался, возможны опечатки

В APA150 для начала хочу разместить PCI Target 32/33 под имеющейся *.GSF файл с I/O constraints. Если можете помочь, то готов к взаимовыгодному :cheers: сотрудничеству. <{POST_SNAPBACK}> Без проблем могу помочь. Давайте netlist и файл ограничений.

У меня P4-2.8, 2G RAM, софт Actel Designer 6.0, кристалл APA450 на 87% загружен, с ограничением по размещению. Размещение + разводка занимает примерно 40 минут.

Господа, знающие! Подскажите, что лучше использовать для разработки ПО под Cygnal C8051, и очень желательно под Linux. Заранее спасибо

У меня есть только образ диска от нее с обучающими материалами :( . Если нет проблем со сканером (а главное, с желанием сканировать ;) ), переведи ее в электронный вид для всех пользователей форума, и Родина тебя не забудет :disco: . <{POST_SNAPBACK}> Ок! Сканер уже нашел, но книга ~700 страниц, так что быстро не обещаю. P.S.: и со временем сейчас запарки

Я начинал с "VHDL Cookbook" Peter J. Ashenden. Она существует в электронном виде. Сейчас пользуюсь "The Designer's Guide to VHDL" того же автора, но ее в электронном виде не встречал. Ничего лучшего в свое время не нашел, не знаю как сейчас. Русскоязычной литературой никогда не пользовался, так как в свое время нечего хорошего просто не было, да и сейчас думаю нет. Даже устоявшейся русскоязычной терминологии нет. Вообщем, мое личное мнение, лучше сразу осваивать буржускую терминологию и не забивать голову хламом. P.S.: Кстати, с буржуями тоже проще общаться будет.

Кроме этого, реально надо еще знать чего хотим-то. Например, если имеем асинхронный сброс от источника питания, т. е. достаточной длительности и низкой частоты, то исключаем цепь сброса из временного анализа схемы, получаем более быстродействующую схему, чем в случае использования синхронного сброса. При этом не забываем обеспечить снятие сигнала сброса СИНХРОННО тактовому сигналу (иначе, особенно при относительно высоких рабочих частотах схемы, схема может неправильно запуститься). Если сигнал сброса это внутренний сигнал некоторой схемы, и он влияет на логику работы, а не просто приводит схему в исходное состояние, то предпочтительнее использовать синхронный сброс. В моем понимании сброс - это сигнал приведения схемы в исходное состояние (достаточной длительности и относительно низкой частоты), все остальное - сигналы управления. Не забываем, что сигнал синхронного сброса должен быть именно СИНХРОННЫМ по отношению к тактовому. P.S.: Реально, железка с асинхронным сбросом должна заработать на большей частоте, чем с синхронным.

Если при анализе временных параметров для асинхронного варианта сброса, в анализе участвует сам сигнал асинхронного сброса, то меньшая тактовая частота работы схемы может получаться и по технологическим причинам (временные параметры технологии). Часто при использовании асинхронного сброса его исключают при анализе временных параметров схемы (например, объявляют как falsepath в настройках анализатора времен). Надо внимательно смотреть, чего требуется получить. Код для асинхронного и синхронного типа сбросов написан правильно, добавлять нечего.

Тааак... А в VHDL такое есть? А то я тут решил потихоньку кроме AHDL что-то освоить и как раз вчера начал один мелкий проект на верилоге делать... А у меня в AHDL этих ASSERT-ов довольно много (половина, правда, с severity info, но зато остальные - error) <{POST_SNAPBACK}> В VHDL для этих целей используется конструкция assert, как я понимаю, аналогичная assert AHDL.

Насколько я знаю никак, только каждую в отдельности. Специальных средств синтаксиса языка нет. Многие редакторы умеют добавлять "--" к каждой строке выделенного кода, коментируя его.

У меня был проект на Xilinx Virtex-II с 9-ю тактовыми доменами, из них четыре синхронных, остальные асинхронные. Сброс был как внешний (источники питания + кнопка), так и внутренний (программный регистр, выходы lock блоков DLL). Использовалось три блока DLL. Делал управление энергопотреблением путем снятия тактовых сигналов или переключения на более низкую частоту с помощью элементов BUFGMUX. Во всем проекте использовал асинхронный сброс. Сбросом каждого блока SoC управлял контроллер сброса, который формировал для каждого блока свой сигнал сброса и в нужной последовательности. Снятие каждого локального сигнала сброса происходило синхронно к соответствующему тактовому домену (это важно!). Также важна последовательность снятия локальных сигналов сброса для тех блоков, где есть переходы между тактовыми доменами. Чтобы при анализе времен не было путаницы, объявляю все сигналы сброса как falsepath, при этом эти пути не рассматриваются при анализе времен. Вообщем, все прекрасно работало + некоторая экономия ресурсов. Вывод: все зависит от задачи, оба типа схемы сброса имеют право на жизнь. PS: на Xilinx были материалы на тему организации сброса, смотрите

У меня используется оба варианта обратной связи (feedback без bufg и с bufg). Все зависит от того, требуется ли выравнивание фазы входного и выходного тактового сигнала. Один блок DLL я использую просто для синтеза частоты, bufg не используется. По поводу этого ISE пишет: WARNING:LIT - CLKFB pin of DCM symbol "i_SDCM" is driven by pin CLK2X of DCM symbol "i_SDCM". Proper phase relationship to the original clock cannot be guaranteed if the driver is not an IBUF or BUFGMUX. Timing analysis results may not be valid. Т. е. просто не гарантируется соотношение фаз. Все работает нормально, если не требуется обеспечить синхронность выходных тактовых сигналов DLL по отношению к входному.

Насколько я понимаю, за размещение триггеров в блоках ввода/вывода отвечает Map (если не брать во внимание, что некоторые средства синтеза еще на этапе синтеза позволяют использовать технологические примитивы IFD и т. д.), т. к. именно на этом этапе определяется четкое соответствие схемы и технологических примитивов (см. map report). Галочка находится в параметрах процесса Map. PS: здесь речь шла о Xilinx, до ISE 7.1 было так

То, что разные биты шины переключаются в разные моменты времени это нормальное явление и ничего странного здесь нет. Главное, чтобы для каждого бита шины выполнялось условие по временам предустановки/удержания по отношению к сигналу синхронизации. Двунаправленная шина на VHDL 64 разряда: Порты: D : inout std_logic_vector(63 downto 0); DI : in std_logic_vector(63 downto 0); DO : out std_logic_vector(63 downto 0); E : in std_logic; Код архитектуры: DI <= D; D <= DO when E = '1' else (others => 'Z'); Здесь буфер открывается сигналом E = '1'. Удачи

Это означает, что представление компонента or4 не найдено. Смотрите на подключаемые библиотеки, т. е. на объявления use ..... Компонент должен быть "виден" внутри архитектуры. Если используются конфигурации, проверяйте их. Возможно дело в этом.

Не знаю точно про ядро MicroBlaze, но подавляющее большинство процессорных ядер инициируют транзакции блочного обращения только для обмена данными с кэшем. У Вас же кэш выключен, таким образом, пересылка данных осуществляется обычными одиночными циклами. Вообще, с точки зрения программирования довольно сложно продумать связь исполняемого кода с возникающими транзакциями на процессорной шине (шине памяти) в части работы в кэшируемых областях адресов. Параметр BURST_SUPPORT видимо лишь указывает на потенциальную возможность аппаратной поддержки контроллером памяти блочных обращений.

Пример посмотреть не смог, т. к. он, насколько я понял, создан в ActiveHDL, а я им не пользуюсь. Проект ориентирован на ПЛИС Altera, соответственно, насколько я понимаю, LPM_COUNTER, LPM_DFF - это технологические макросы Alter'ы, счетчик и D-триггер соответственно. MUX - мультиплексор. Про LPM_xx смотрите у Alter'ы. Возможно, в ActiveHDL тоже есть что-нибудь. Удачи

Спасибо, а ссылочку на толковую книжку, желательно на английском, не подскажите?

Для N устройств, подключенных к двунаправленной шине, существует N драйверов этой шины. При правильной работе в один момент времени, шиной управляет не более одного. Это надо обеспечить. Важный момент, по умолчанию в начальный момент времени все драйверы инициализируются значением 'U' (для VHDL), поэтому необходимо каждый драйвер шины перевести в 'Z'. Если этого не сделать, возникает 'X'. Часто бывает так: подключаем к двунаправленному сигналу какой-то порт блока, но в самом блоке этим сигналом никогда не управляем (не присваиваем значение), в результате при моделировании драйвер сигнала создается и инициализируется значением 'U', как следствие получаем на шине 'X'. Нужно задать либо начальное значение порта, либо непосредственно присвоить сигналу значение 'Z'. На VHDL для сигнала std_logic: D <= 'Z'; для std_logic_vector: D <= (others => 'Z'); Возможно, дело в этом.