oval
-
Постов
260 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные oval
-
-
2. согласен полностью - с ростом автомата максимальная частота его на которой он работает уменьшается примерно так по биномеальному закону. я бы даже по-другому посоветовал : при количестве состояний автомата превышающей x-цать желательно переходить на автоматы с микропрограмным управлением - но это уже в сторону от начальной темы
Здесь стоит отметить, что максимальная частота работы автомата (его логики переходов) в большей степени зависит не от количества состояний, а от способа кодирования этих состояний и сложности переходов между состояниями. Как пример, можно рассмотреть автомат из сотни состояний, где граф переходов представляет собой переход только из соседнего состояния в соседнее, а кодирование состояний типа onehot. Состояний много, но сложность логики переходов минимальна, отсюда частота работы достаточно высока.
-
Для того, чтобы использовать SOMA модели памяти, необходимо установить соответствующй софт (Denali MMAV, сейчас вроде как входит в состав пакета PureSpec). Я работал последний раз с версией MMAV 3.100-0033 в связке с ModelSim. Документацию к ней могу кинуть на почту (укажите куда).
P.S. Давно интересуюсь более новой версией MMAV (PureSpec), но раздобыть пока не удалось. Может быть кто-нибудь может помочь в данном вопросе? Буду признателен.
-
Используем Code Coverage входящий в состав ModelSim. Помогает в основном при оценке качества тестов. При этом, конечно, не забываем про assertion's.
-
-
Интересно, можно ли все-таки задействовать обычный INBUF в качестве клокового? Вопрос исключительно нагрузочной способности и неравномерности времен распространения сигнала до селлов или принципиально нельзя?
Не раз приходилось задействовать INBUF в качестве клокового. То есть делать так можно. Придется только очень внимательно работать с временами (анализ времен, планирование расположения). Частоты получаются относительно низкими.
-
1. достаточно для неиспользуемых IO указать атрибут PULLUP / PULLDOWN / KEEPER (например, в том же UCF)
Помниться раньше ISE по умолчанию конфигурировал незадействованные IO как входы с PULLUP. Не знаю, как сейчас. То есть, если схемотехнически устраивает вход с PULLUP, то можно ничего не задавать.
имел в виду введение дополнительных регистров в комбинационную часть схемы (критичную к задержкам): как результат увеличение задержи (между поступлением вх.данных и их появлением на выходе) и частоты работы блокаВ данном случае "увеличение задержки" связано с понятием латентности (latency). То есть, применительно к данному случаю, в литературе используется понятие латентности.
-
2 vleo:
ваш пример можно сократить до:
cmd_decoder:cben<= CMD_RD when mem_rd='1' and mem_wr_reg='0' else CMD_WR when mem_rd='0' and mem_wr_reg='1' else (others=>'0');
!! всего 2 строчки. Можно и в 1 строчку написать.
и вариант №2:
case conv_integer(std_logic_vector'(mem_rd &mem_wr_reg)) is when 2 => when 1 => when others =>
case std_logic_vector'(mem_rd &mem_wr_reg) is when "10" => when "01" => when others =>
тоже должен работать.
Можно также использовать конструкцию with ... select ... , которая является аналогом конструкции case ... .
-
Было дело, поступали следующим образом (могу ошибаться в деталях, так как было это относительно давно):
- после компиляции программы имеем бинарный файл исполняемого кода в формате elf;
- создаем текстовый .bmm файл описания формата памяти, в которой должна размещаться программа;
Проект может быть создан с использованием любого подходящего средства синтеза.
- добавляем .elf файл и .bmm в проект ISE;
- после процессов размещения и разводки в ISE, имеем битовый файл с проинициализированной памятью.
В процессе разводки ISE на основе оригинального .bmm файла создается еще один, в который добавляется информация о конкретном размещении блоков памяти. В дальнейшем, используя модифицированный ISE .bmm файл, .elf файл и специальную утилиту ISE (помоему data2bram, точно уже не помню), можно без переразводки получать бинарные файлы битстрима с проинициализированной содержимым .elf файла памятью.
-
Никаких странностей здесь нет, это не feature и не bug. :) Все так и должно быть.
Для проверки необходимого вам условия, смотрите в сторону атрибутов сигнала ('event, 'last_event и т.п.).
-
Итак, что хочется:
1. Смотреть видео с DVD-плеера на компьютерном LCD мониторе (с разрешением 1280x1024).
Решение видится в виде преобразователя PAL -> VGA - делаем 2 видео страницы, в одну записываем данные со входа другую используем для вывода. После заполнения входной страницы делаем переключение между страницами. При записи в память сразу же делаем масштабирование.
Здесь есть свои ньюансы, не все так тривиально, как кажется. Через какой интерфейс будет поступать сигнал с DVD-плеера? Скорее всего потребуется декодер. Есть ли он на Вашей плате starter kit?
Сигнал можно брать в виде обычного RGB. Тут во всяком случае понадобится минимальный объём преобразований. Понадобится подключить к плате 3х канальный АЦП с соответствующим быстродействием.
Попробуйте. Но у декодеров не столь простое устройство. Есть еще масса функций по улучшению качества результата оцифровки и т.п.
Еще одна проблема (хотя и не очень существенная) - проблема согласования частоты кадров входного и выходного видео потоков. Не факт, что достаточно 2-х буферов (страниц).
Да. Теоретически может понадобиться небольшой (меньше размера кадра) буфер в который будет складываться входной поток после заполнения входного буфера и до тех пор пока не будет закончено чтение очередного кадра из выходного буфера. Хотя возможно самым простым решением было бы сделать циклический "фрейм" из 3х буферов.
На входе (выход DVD) идет поток полукадров (interlaced scan), выход - полный кадр (progressive scan). Каким образом будете преобразовывать? Способов есть несколько, соответственно разное качество результата... Чем проще, тем хуже результат.
Если выполнять по каждому входящему полу-кадру замену полу-кадра выходящего буфера то результат будет плохим?
Не думаю, что хорошим. Особенно на быстро движущихся контрастных сценах.
Формат сигнала на входе (уже с выхода декодера) обычно YCbCr, на выходе - RGB. Соответственно потребуется преобразование... Иногда встречаются декодеры, выполняющие это преобразование, но среди современных, не встречал, хотя особо этим вопросом не занимался, могу и не знать.
Эта проблема решается использованием RGB выхода.
Ну и наконец, масштабирование. Полноценное цифровое масштабирование, - далеко не тривиальная задача... Тем более с дробными коэффициентами.Масштабирование я рассматривал только с целым коэффициентом. Соответственно, не весь экран будет использоваться в этом случае.
То есть фактически простым размножением коэффициентов пикселей. Если так, то не думаю, что будет достигнут желаемый результат...
2. Преобрабовывать VGA -> VGA (с разрешения 1024x768/800x600 -> 1280x1024).
LCD мониторы обычно хорошо работают только на своём родном разрешении, во всех остальных случаях получается довольно большое мыло. Соответственно, пользоваться программами (играми), использующими разрешение меньше родного разрешения монитора бывает очень затруднительно.
Самым простым решением (кроме варианта покупки второго монитора или неиспользования программ, которые не могут "жить" в родном разрешении монитора) вижу обыкновенное преобразование VGA сигнала на ПЛИС, при этом исходное изображение выводить без какого-либо преобразования в центре экрана (а вокруг будет чёрная рамка).
Особенно сильно эта проблема может вставать при использовании широкоформатных мониторов (скажем, обычный Benq 20" с разрешением 1680x1050)
Здесь "обыкновенное преобразование VGA сигнала на ПЛИС" выливается в далеко не тривиальное! Несущая частота на входе и выходе разная, потребуется буфер хранения данных картинки, вообщем часть того, что в п.1. Увы...
Да, потребуется до 3х буферов способных запомнить весь экран, при этом задержка прохождения сигнала через схему будет не более 50ms (при частоте обновления 60Hz).
3. Сделать функцию Picture-In-Picture когда в небольшом окошке на компьютере можно, к примеру, смотреть телевизор.
Ну это уже из разряда "хочется когда-нибудь", поэтому рассматривать пока нет смысла.
Для п.1 и п.3 просто приобретаете плату TV приемника, а на сегодняшний день эти задачи полностью реализуют современные видео адаптеры :) Самое бюджетное решение, правда компьютер должен быть включен, соответственно и DVD-плеер оказывается ненужным...
Тюнер в компьютере есть. Хочется избавиться от компьютера в схеме воспроизведения.
А телевизора нет (просто не нужен и некуда особо ставить).
Не дешевое решение выбираете. Многие стремяться наоборот использовать компьютер... Но это уже индивидуально...
Собственно, теперь сами вопросы:
1. Что лучше читать на эту тему чтобы получить лучшее представление о структуре видео сигналов?
2. Хочу всё реализовать на базе starter kit с Xilinx XC3S500E-4FG320C Spartan-3E на борту. Насколько реально?
Не думаю, что реально без внешних модулей... Также для полноценного решения может не хватить ресурсов самой платы starter kit, в частности возможно самой ПЛИС. Здесь уже требуется более детальная оценка...
Пока обнаруживается только внешний АЦП. Я что-то ещё пропустил?
Не знаю, может и не упустили. А выходной интерфейс будет полностью в цифре или ЦАПы поставите?
3. Есть ли какие-то примеры реализующие подобные функции? Разбираться в существующем проекте и постепенно его дорабатывать под себя намного удобней, чем писать всё с нуля.
4. Что из оборудования потребуется для проверки результата? Как минимум требуется осциллограф.. Т.к. всё делается просто для себя, то желательно уложиться в минимальные деньги. Можете посоветовать наиболее оптимальное для данной задачи решение? Видел в интернете несколько компьютерных осциллографов, которые (вроде бы) должны подойти (по max частоте исследуемого сигнала) по цене $200-$300. Насколько это реально?
Ну и вообще был бы рад любым комментариям, которые могут помочь в решении возникших вопросов :)
P.S. ИМХО не стоит даже браться:1. скорее всего не хватит энтузиазма :) Хотя всякое бывает...
2. не тот проект для ПЛИС, да и вообще, с которого стоит начинать...
3. скорее всего потребуется изготовление платы под эти задачи, а это затраты...
4. задачи для коллективной реализации, на коленках я бы не взялся делать...
5. время реализации при отсутвие опыта много больше времени присутствия энтузиазма :) Тут тоже разные случаи бывают...
P.P.S.: прошу прощения, если расстроил... :)
Ну вопрос стоит браться или нет остаётся открытым. На первом этапе хочется окончательно понять во что выльется реализация такого решения (по п. 1 и 2), а потом уже можно будет определиться - стоит ли оно того или легче просто купить монитор с RGB входом и поддержкой P-i-P (благо такие сейчас уже есть и по цене насколько я помню в пределах ~$700) :))
По трудозатратам, купить дешевле однозначно. Но думать Вам...
-
Всем привет!
Никогда раньше не имел дело с ПЛИС, опыт работы с железом заканчивается несколькими пробами пера на Atmel'овской ATmega8.
Но тут передо мной встала довольно интересные (для меня) задачи и захотелось найти для неё решение, причём ПЛИС тут подходит больше всего.
Итак, что хочется:
1. Смотреть видео с DVD-плеера на компьютерном LCD мониторе (с разрешением 1280x1024).
Решение видится в виде преобразователя PAL -> VGA - делаем 2 видео страницы, в одну записываем данные со входа другую используем для вывода. После заполнения входной страницы делаем переключение между страницами. При записи в память сразу же делаем масштабирование.
Здесь есть свои ньюансы, не все так тривиально, как кажется. Через какой интерфейс будет поступать сигнал с DVD-плеера? Скорее всего потребуется декодер. Есть ли он на Вашей плате starter kit?
Еще одна проблема (хотя и не очень существенная) - проблема согласования частоты кадров входного и выходного видео потоков. Не факт, что достаточно 2-х буферов (страниц).
На входе (выход DVD) идет поток полукадров (interlaced scan), выход - полный кадр (progressive scan)
. Каким образом будете преобразовывать? Способов есть несколько, соответственно разное качество результата... Чем проще, тем хуже результат.
Формат сигнала на входе (уже с выхода декодера) обычно YCbCr, на выходе - RGB. Соответственно потребуется преобразование... Иногда встречаются декодеры, выполняющие это преобразование, но среди современных, не встречал, хотя особо этим вопросом не занимался, могу и не знать.
Ну и наконец, масштабирование. Полноценное цифровое масштабирование, - далеко не тривиальная задача... Тем более с дробными коэффициентами.
2. Преобрабовывать VGA -> VGA (с разрешения 1024x768/800x600 -> 1280x1024).LCD мониторы обычно хорошо работают только на своём родном разрешении, во всех остальных случаях получается довольно большое мыло. Соответственно, пользоваться программами (играми), использующими разрешение меньше родного разрешения монитора бывает очень затруднительно.
Самым простым решением (кроме варианта покупки второго монитора или неиспользования программ, которые не могут "жить" в родном разрешении монитора) вижу обыкновенное преобразование VGA сигнала на ПЛИС, при этом исходное изображение выводить без какого-либо преобразования в центре экрана (а вокруг будет чёрная рамка).
Особенно сильно эта проблема может вставать при использовании широкоформатных мониторов (скажем, обычный Benq 20" с разрешением 1680x1050)
Здесь "обыкновенное преобразование VGA сигнала на ПЛИС" выливается в далеко не тривиальное! Несущая частота на входе и выходе разная, потребуется буфер хранения данных картинки, вообщем часть того, что в п.1. Увы...
3. Сделать функцию Picture-In-Picture когда в небольшом окошке на компьютере можно, к примеру, смотреть телевизор.Ну это уже из разряда "хочется когда-нибудь", поэтому рассматривать пока нет смысла.
Для п.1 и п.3 просто приобретаете плату TV приемника, а на сегодняшний день эти задачи полностью реализуют современные видео адаптеры :) Самое бюджетное решение, правда компьютер должен быть включен, соответственно и DVD-плеер оказывается ненужным...
Собственно, теперь сами вопросы:1. Что лучше читать на эту тему чтобы получить лучшее представление о структуре видео сигналов?
2. Хочу всё реализовать на базе starter kit с Xilinx XC3S500E-4FG320C Spartan-3E на борту. Насколько реально?
Не думаю, что реально без внешних модулей... Также для полноценного решения может не хватить ресурсов самой платы starter kit, в частности возможно самой ПЛИС. Здесь уже требуется более детальная оценка...
3. Есть ли какие-то примеры реализующие подобные функции? Разбираться в существующем проекте и постепенно его дорабатывать под себя намного удобней, чем писать всё с нуля.4. Что из оборудования потребуется для проверки результата? Как минимум требуется осциллограф.. Т.к. всё делается просто для себя, то желательно уложиться в минимальные деньги. Можете посоветовать наиболее оптимальное для данной задачи решение? Видел в интернете несколько компьютерных осциллографов, которые (вроде бы) должны подойти (по max частоте исследуемого сигнала) по цене $200-$300. Насколько это реально?
Ну и вообще был бы рад любым комментариям, которые могут помочь в решении возникших вопросов :)
P.S. ИМХО не стоит даже браться:
1. скорее всего не хватит энтузиазма :) Хотя всякое бывает...
2. не тот проект для ПЛИС, да и вообще, с которого стоит начинать...
3. скорее всего потребуется изготовление платы под эти задачи, а это затраты...
4. задачи для коллективной реализации, на коленках я бы не взялся делать...
5. время реализации при отсутвие опыта много больше времени присутствия энтузиазма :) Тут тоже разные случаи бывают...
P.P.S.: прошу прощения, если расстроил... :)
-
Господа!
Обнаружены следующие ошибки синтеза для VHDL:
1. Xilinx ISE8.1SP3 XST Spartan 3E - неправильно синтезируется конструкция с использованием стандартной функции mod (mod 2^n);
2. Synplify 8.8 Virtex 4 - ошибка VIRTEX4 Mapper и SPARTAN3 Mapper (другие семейства не проверял) при компиляции RTL -> Gate. Проблема при использовании примитива типа FDRS (gate level), формируется некорректная схема включения (отсутствие обратной связи).
P.S. Может быть кому-то данная информация поможет :)
-
Поставьте и поиграйтесь mentor hdldesigner - если продеретесь через начальные трудности и сумеете освоить, а документации там навалом, то описанные проблемы исчезнут.
+1
и "поднять" контроль версий
-
to oval:
Отдельный клок имеется. Может знаете где почитать про работу с несколькими доменами (ссылки, книги...).
Попробуйте здесь на форуме поискать. Были ссылки, посмотрите здесь, основная информация правда на английском.
-
Товарищи, а если FPGA (ACEX) висит на PCI, то чем лучше тактировать
UART (использовать PCI клок или внешний завести) ?
Практика показывает, что в таком случае лучше использовать отдельный генератор.
Насчет нескольких тактовых доменов, ничего страшного там нет, просто нужно внимательно и правильно реализовывать переход между ними.
-
вопрос о ОСР попрежнему открытый
OpenCore Protocol. Поддерживается и развивается консорциумом, куда входят несколько довольно крупных компаний. Сайт: ocpip.org. Спецификацию можно получить, заполнив соответствующую форму. Правда, это только разрешение на "использование в исследовательских целях". Если же надо "коммерческое использование", необходимо заполнять... другую форму. :)
И кроме того етот вопрос отпадает когда надо что то добавлять в уже имеющююся SoCВ этом случае, топик бы и не создавался :)
Если требуется высокая производительность шины, то ИМХО следует смотреть в сторону AMBA AXI или OCP, концепция у них похожая. Из этой же серии есть еще IBM CoreConnect, но она ИМХО слишком навороченная, ее достаточно сложно реализовывать (поддерживать).Можно чуть подробнее? Wishbone отстаёт в производительности? А где можно результаты тестирования найти? CoreConnect, действительно, не для "простых смертных"... Очень уж заумная.
ahb|apbИМХО, стоит смотреть в сторону более новой AXI. APB, кстати, достаточно простая шина, но медленная.
Если требуется высокая производительность шины, то ИМХО следует смотреть в сторону AMBA AXI или OCP, концепция у них похожая. Из этой же серии есть еще IBM CoreConnect, но она ИМХО слишком навороченная, ее достаточно сложно реализовывать (поддерживать).Можно чуть подробнее? Wishbone отстаёт в производительности? А где можно результаты тестирования найти? CoreConnect, действительно, не для "простых смертных"... Очень уж заумная.
По Wishbone сейчас ничего не скажу, попросту уже не помню ее протокол. Результатов сравнительного тестирования производительности также не встречал. Думаю стоит просто проанализировать набор сигналов + протокол, кое-какие выводы уже можно будет сделать.
ahb|apbИМХО, стоит смотреть в сторону более новой AXI. APB, кстати, достаточно простая шина, но медленная.
Каждая из шин AXI, AHB, OPB ориентирована под свои задачи по критерию сложность реализации/производительность. Поэтому и выбор должен основываться, как я уже говорил ранее, на том, какие характеристики требуется обеспечить. Простой регистровый IP-блок не имеет особого смысла "сажать" на AXI, поскольку реализация интерфейса AXI может оказаться нетривиальной.
-
Все зависит и от того, что за IP-ядро и в какого рода системах предполагается его использование. От требований этого IP-ядра к шине с точки зрения производительности, возможностей, будет ли в составе IP-ядра только slave (target) этой шины или только master, или оба одновременно.
Если требуется высокая производительность шины, то ИМХО следует смотреть в сторону AMBA AXI или OCP, концепция у них похожая. Из этой же серии есть еще IBM CoreConnect, но она ИМХО слишком навороченная, ее достаточно сложно реализовывать (поддерживать).
Раньше мы строили системы на основе AMBA AHB, сейчас для регистровых устройств (только slave) используем ее же в варианте AHB Lite (только один master), для остальной высокопроизводительной части системы используем AMBA AXI.
-
Возможно Вам частично (VHDL, Verilog) поможет HDL Designer от Mentor Graphics. В нем есть возможность преобразования текста в структуру, правда получается не очень красиво, обычно требуется доработка "ручками". Также в нем есть средства документирования и экспорта полученных блок схем.
-
Довелось пообщаться с автором топика. Подход к задаче дилетантский, плюс также неадекватная реакция. Вот такие дела.
-
Константы съедят место в зависимости от того, как они будут использоваться в схеме. Триггеров, конечно, из них не будет, но по-моему 6700 бит констант лучше разместить в памяти...В таком случае ещё вопрос, имеет ли смысл реализовывать эти массивы через блочную память как ПЗУ или же можно оставить их константами, но при этом интересует синтезируются эти константы и сколько они съедят ресурсов ПЛИСины?
Константы съедят место в зависимости от того, как они будут использоваться в схеме.В таком случае ещё вопрос, имеет ли смысл реализовывать эти массивы через блочную память как ПЗУ или же можно оставить их константами, но при этом интересует синтезируются эти константы и сколько они съедят ресурсов ПЛИСины?Кроме того, объем аппаратуры будет зависеть и от непосредственно самих значений этого массива констант. Поэтому нужно пробовать, экспериментировать. :)
-
описание то я почитал :cranky: только толку от него немного....
итого создал bmm файл
ADDRESS_BLOCK ram_cntlr RAMB4 [0x00000000:0x00000FFF]
BUS_BLOCK
top/ram_cntlr/ram7 [63:56]; // LOC = R3C5;
top/ram_cntlr/ram6 [55:48]; // LOC = R3C6;
top/ram_cntlr/ram5 [47:40]; // LOC = R3C7;
top/ram_cntlr/ram4 [39:32]; // LOC = R3C8;
top/ram_cntlr/ram3 [31:24]; // LOC = R4C5;
top/ram_cntlr/ram2 [23:16]; // LOC = R4C6;
top/ram_cntlr/ram1 [15:8]; // LOC = R4C7;
top/ram_cntlr/ram0 [7:0]; // LOC = R4C8;
END_BUS_BLOCK;
END_ADDRESS_BLOCK;
а дальше что?
видимо нужно создать инстансы top/ram_cntlr/ram0.... в которых используется блочная память или собственно является блочной памятью - как? :cranky:
.bmm файл создается обычно уже на основе просинтезированного ( или даже откомпилированного и размещенного проекта ISE). Собственно там выясняются точные иерархические имена "инстансов" блоков памяти, и эти имена заносятся в .bmm файл. При этом совсем не обязательно указывать привязку расположения блоков, достаточно только имена. Утилита автоматически создаст .bmm файл с привязкой под конкретную расположение/разводку кристалла (файл *_bd.bmm).
.bmm файл не создается на основании непосредственно исходников проекта.
-
Добрый день!
Возник вопрос относительно памяти в ПЛИС.
Мне необходимо реализовать массивы констант объемом 6720 бит,
но если это делать такой конструкцией:
Type TPorcia is range 0 to 64;
Type TIP is array (1 to 64) Of TPorcia;
Constant IP : TIP := (58,50,42,34,26,18,10,2,
60,52,44,36,28,20,12,4,
62,54,46,38,30,22,14,6,
64,56,48,40,62,24,16,8,
57,49,41,33,25,17,9,1,
59,51,43,35,27,19,11,3,
61,53,45,37,29,21,13,5,
63,55,47,39,31,23,15,7);
то все это будет реализовано на триггерах и может не хватить ресурсов на такую модель Spartana 3 xc3s1500.
второй вариант я вижу в испоьзовании Block Memory, но тут встает вопрос как на этапе конфигурирования плиски часть памяти отвести под ПЗУ и залить в нее мои массивы?
Если реализовать массив констант (подчеркиваю, именно констант) так, как Вы описали выше, то никаких триггеров задействовано не будет, поскольку это константы.
Способов проинициализировать блочную память несколько: с помощью задания набора атрибутов INIT для соответствующего компонента-примитива; если использовать для создания модуля памяти Core Generator, то с помощью соответствующего .coe файла; также можно "залить" содержимое блочной памяти непосредственно в файл конфигурации ПЛИС (.bit файл), используя утилиту data2mem, входящую в состав ISE, правда входной формат данных в этом случае - бинарный файл (.elf и еще по-моему несколько вариантов).
-
Штыревая гребёнка с шагом 1,27 мм х 1,27 мм - ответная часть для программатора Actel.
Где взять за разумную цену и как называется Part Number?
Мы ставили из каталога DigiKey part number: ED83100-ND. При установке резали на несколько частей.
-
...........Какой асинхронный или синхронный, в принципе не важно, главное его грамотное формирование.
Использование синхронного потребует большего количества ячеек, асинхронный же будет занимать специально выделенные ресурсы.
ну почему сразу больше то? :) не на много больше
так разве нельзя сделать?
из внешнего асинхронного ресета делаем синхроный (задерживаем в неск-их FF)
и с выхода FF подаем на глобальный ресет - а он уже заводится на все FF в LE на асинхрон ресет
а и синхр ресет всё же лучше ибо -
Feeding Inputs and Resets to Your State Machine
Reset signals are traditionally asynchronous and are routed directly to the clear
inputs of state machine register elements. When the reset is asserted, all registers
(state and output bits) are cleared immediately. All well and good, but what
happens when the reset is deasserted? Consider a state machine that will transition
from the reset state to some other state directly after the reset is deasserted.
If the reset deasserts close to a clock edge, some of the state bits will
assume their new states, while others might not. The state machine ends up in
an undefined error state, and, yet again, you have egg on your face.
The solution? Synchronize that darned reset! That way, the reset will be
removed well before the clock edge, and all register elements will correctly transition
to their new states.
...........Какой асинхронный или синхронный, в принципе не важно, главное его грамотное формирование.
Использование синхронного потребует большего количества ячеек, асинхронный же будет занимать специально выделенные ресурсы.
ну почему сразу больше то? :) не на много больше
Если описать на HDL именно как синхронный (то есть внутри тактового условия, если так можно выразиться), то на входе триггера появиться мультиплексор. Для технологии Actel ProASIC получиться в два раза больше. :)
так разве нельзя сделать?из внешнего асинхронного ресета делаем синхроный (задерживаем в неск-их FF)
и с выхода FF подаем на глобальный ресет - а он уже заводится на все FF в LE на асинхрон ресет
Почему нельзя? Можно, как вариант. Есть еще варианты. :) Главное снимать синхронно. ;)
а и синхр ресет всё же лучше ибо -Feeding Inputs and Resets to Your State Machine
Reset signals are traditionally asynchronous and are routed directly to the clear
inputs of state machine register elements. When the reset is asserted, all registers
(state and output bits) are cleared immediately. All well and good, but what
happens when the reset is deasserted? Consider a state machine that will transition
from the reset state to some other state directly after the reset is deasserted.
If the reset deasserts close to a clock edge, some of the state bits will
assume their new states, while others might not. The state machine ends up in
an undefined error state, and, yet again, you have egg on your face.
The solution? Synchronize that darned reset! That way, the reset will be
removed well before the clock edge, and all register elements will correctly transition
to their new states.
Как раз то, о чем я упомянул выше. Есть тут ньюансы, временные ограничения, например, желательно задать. Вообщем, если все продумать и грамотно сделать, все будет ок! :)
Для ProASICPlus и для 3-го. Мне сброс для работы схемы не нужен, схема сама выйдет на нужный режим из любой начальной комбинации триггеров. И вот приходится подрисовывать этот ненужный для работы сброс, иначе симуляция становится невозможной, а это ухудшит результат трассировки чипа, что понизит возможности чипа по частоте и емкости.В этом случае просто определяйте начальное состояние сигналов (как я понимаю, речь идет об HDL). Можно еще в схеме для синтеза подать на сигнал сброса константу (неактивный уровень), синтезатор сам выкинет эту ненужную логику.
О QuestSim AFV
в Среды разработки - обсуждаем САПРы
Опубликовано · Пожаловаться
В России и странах СНГ официальным представителем компании Mentor Graphics является компания Megratec. На сайте есть контактная информация. Цены также можно узнать по почте.