Перейти к содержанию
    

gerbity

Участник
  • Постов

    19
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о gerbity

  • Звание
    Участник
    Участник
  • День рождения 19.04.1984

Информация

  • Город
    Array

Посетители профиля

764 просмотра профиля
  1. Спасибо за наводку. Установил режим Single Uncompressed Image with Memory Initialization, ошибка пропала
  2. Столкнулся с такой же проблемой невозможности проинициализировать ROM на камне 10M08SAU169C8G в квартусе 17.1 Prime Standart Edition. Не подскажите где можно посмотреть в каких версиях MAX10 эта возможность не работает?
  3. У вас с такой схемой (если ее так реализовывать как нарисовано) вообще всякий ужас с гличами может твориться. Я, конечно, давно не работал с FPGA (больше занимаюсь разработкой под ASIC) и привык строго относиться к сигналам клоков и ресетов, может и появились какие-нибудь хитрые триггеры или адгоритмы трассировки, которые помогают избавиться от гличей, но частота у вас с триггера Шмитта может идти любая, и заранее рассчитать задержки, чтобы избавиться от гличей, тут невозможно. Я бы на вашем месте, если это возможно, завел одну глобальную быструю частоту, и все через неё бы пустил. Ту частоту, с триггера Шмитта также бы пересенхранизировал на внутреннюю частоту, тогда бы и гличей не было бы. То же касается и ресетов. В схеме должен быть только один асинхронный ресет, который в самом начале ставит все триггеры в 0 (или в 1). Всё остальное - это должны быть всякие синхронные SET-ы (в 0 или в 1 смотря что нужно). При таком раскладе, естественно сигнал с делителя не надо заводить на сброс, а на синхронный SET в 0. Когда все будет синхронно, то все проблемы сами пропадут, потому как Quartus (или чем вы там пользуетесь) сам рассчитает нужные задержки между сигналами для соблюдения setup/hold и установит правильные констрейны (да они и не нужны будут на такой синхронной схеме). Сейчас у вас с скорее всего где-то идет нарушение setup/hold (что совсем не невероятно при такой реализации), что в свою очередь приводит к тому что триггер с равной вероятностью может защелкнуть как предыдущее так и последующее значение (или вообще что-то что третье, короче X будет на его выходе) и эти иксы могут все данные в счетчике херить.
  4. 1.1 Латч - это асинхронный элемент, а триггер синхронный. Следовательно триггер должен чем-то тактироваться. И как же его тактировать тем же самым клоком, который к нему на вход подается? фигня получится какая-то. Это вот если пересинхронизировать более медленный клок другим - более быстрым, то да. Там уже триггеры нужны. Даже два, чтобы метастабильности не было. 1.2 Вообще да, любые операции с клоком нужно делать синхронными с этим клоком сигналами. Иначе не оберетесь гличей. Вот например статейка про безгличивый клоковый мультиплексор. Там сигнал select для мукса предварительно синхронизируется по обоим клокам. 1.3 Не совсем понятно как тактовый вход относится к обычной ( не триггерной) логике. А вообще гличи (иголки или наоборот провалы) на клоке опасны для триггеров из-за того, что схема начинает непредсказуемо себя вести. Метастабильность только один из вариантов. Она появится, если этот глич нарушит сетапы или холды на одном триггере, и тогда эта метастабильность может распространиться по всей схеме. А если так получится, что не нарушит, то это наверное в какой-то степени еще хуже. Потому что это приведет к ложному (не рассчитанному) срабатыванию триггера. Пропустится например какое-нибудь значение счетчика, где-нибудь в дешефраторе команд процессора и он пропустит одну команду. И найти такой баг иногда довольно сложно.
  5. То что с начала все было нормально, а потом полезли глюки, говорит скорее о том, что просто где-то непропай. Возьмите и прогрейте все паяльником (если не BGA конечно).
  6. Ну это уже зависит от логики работы устройства. Может быть и нет смысла сбрасывать счетчик, если он все равно заморожен в отсутствии клока? А при такой схеме счетчик сбросится автоматически, как только появится клок. Если логика работы противоречит такому поведению, то можно поступить как советовали выше - пересинхронизировать внешний клок на внутреннюю частоту (также через 2 триггера), и работать полностью в одном частотном домене. Тут проблем вообще не будет, но это нормально будет работать, только если внутренний клок хотя бы в несколько раз выше внешнего.
  7. Простите, два конечно же. При передачи любых сигналов (в том числе и ресетов) из одного частотного домена в другой необходимо их дважды пересинхронизировать. Это обязательно. Вот выкладываю картинку, как это сделать. На выходе у вас получится сигнал сброса, который будет синхронизован с вашим внешним клоком. Платой за подобное использование будет задержка в два такта внешнего клока, которая может влиять на логику работы, но если это критично, то ее можно скомпенсировать. Например сбрасывать ваш счетчик не в ноль а в +2, например. Выложу ка я пару интересных книжечек, как правильно делать всякого такого рода вещи. CummingsSNUG2001SJ_AsyncClk.pdf CummingsSNUG2002SJ_Resets.pdf
  8. Есть хороший сайт, opencores.org с кучей готовых блоков. Вот на нем есть интересующий вас блок: http://opencores.org/websvn,filedetails?re...IFO%2Ffifo.vhdl Посмотрите, может быть подойдет вам.
  9. Вообще говоря клоки и ресеты - это как говорится святая корова, и без серьезной необходимости (ну очень серьезной) лучше их лишний раз не модифицировать и не подмешивать. Так что в этом случае поставите уж один асинхронный триггер и не мучайте клок, а то проблем не оберетесь.
  10. Линейный регулятор при понижении напряжении просто переводит неиспользуемую мощность в тепло, а девайс у вас на батарейках. Соответственно имульсный стабилизатор поможет немного съэкономить энергию батареи.
  11. если бы микросхемы разных вендоров вели бы себя "неизвестно как" то кто бы их тогда покупал? Например микросхемы DDR у всех производителей имеют однотипный футпринт как раз для того чтобы можно было практически безболезненно менять одну на другую. Согласен, что будут некоторые отличия, на мой взгляд 10% в худшем случае. В первом приближении этого будет достаточно ,чтобы посмотреть как ведет себя ПП, если она не будет работать с микросхемой одного вендора, то и с другими тоже не будет работать. Моделирование ПП покажет плохие места в топологии, которые и будут ухудшать поведение интерфейса.
  12. На данный момент полная занятость пока не рассматривается
  13. нечто подобное как раз и было на нашем SoC, также площадь съедают резисторные сборки для терминации, которую можно не делать в древовидной структуре
  14. Ищу подработку. Трассировка печатных плат по готовой схеме в Altium Designer. Моделирование вашего проекта PCB на Signal Integrity и Power Integrity. Мосвка, Email:[email protected]
  15. Тоже работал с этим тулом. Если проложите цепь агрессор подальше, то ее коэффициент связности естестаенно уменьшится, но ее место займет другай цепь-агрессор, с чуть меньшим коэффициентом связности. Просто нужно стараться соблюдать простые правила при разводке DDR. Определенное расстояние между линиями, определенное длинну, на которой приемлемо вести проводники параллельно, и т.д. Короче говоря нужно не просто уменьшить коэффициент связности какого-то конкретного сигнала, а стараться как можно сильнее уменьшить все коэффициенты связности. Хотя, конечно, экстремальных значений у отдельных сигналов также стоит избегать. Если кому-нибудь еще интересна работоспособность DDR3 при T-топологии (она же древовидная), могу внести свои 5 копеек. Недавно было разработано несколько подобных плат. Использовалось 4 чипа (два ставились один над другим). Терминации не было. Частота что-то около 450МГц. Моделирование в Cadance System SI показывало работоспособность при 500МГц, в реальности платы работали на частоте что-то около 470МГц (дальше не позволял разгонять процессор). Так что данное решение вполне жизнеспособное, если не требуется более высоких частот. Также плюсом является, что древовидная топология занимает меньше места на ПП. Делался один проект, в котором один DDR-порт процессора разводился как Fly-By, а второй - древовидной. Так вот второй вариант занимает примерно на 15% меньше места.
×
×
  • Создать...