Jump to content

    

FakeDevice

Свой
  • Content Count

    83
  • Joined

  • Last visited

Community Reputation

0 Обычный

About FakeDevice

  • Rank
    Частый гость
  • Birthday 08/31/1983

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Recent Profile Visitors

1642 profile views
  1. а где размещается новый массив? может, заканчивается именно та область памяти, а не область памяти под программу? размер кучи/стека не пробовали увеличивать? было что-то подобное с микроблейзом, увеличение размера кучи исправило ситуацию.
  2. опечатка, надо так: outn <= '1' when clock = '0' else '0';
  3. навскидку http://www.xstarter.com/rus/ UPD: странно, сайт сейчас не работает, раньше работал. но найти можно на других ресурсах
  4. Ещё вариант, попробовать зайти в папку установки p-cad'а и удалить все файлы *.manifest (предварительно забекапив, на всякий случай). Не забыть перезапустить P-cad
  5. В SystemC подобное делал с помощью функций типа observe_foreign_signal. Возможно, существует что-то аналогичное и для SV?
  6. (+/-) 1/16 = |1/8|, если быть точнее. надо исходить из размера пакетов, скорости обмена, девиации. тут каждый сам выбирает, что ему ближе. палка о двух концах: либо частота не подойдёт, либо точности не хватит.
  7. у меня тоже контролируется. года за 3-4 тоже сбоя не было ни разу.
  8. домена 2 -- это минус. частота 1x -- это плюс. ну и наглядность, простота реализации в xapp мне тоже понравилась. тут, видимо, исходя из реальных обстоятельств лучше принимать решение. Просто, повторюсь, у меня к тому моменту уже были задействованы dcm и с 2x, и с 3x. Лишнего уже не терял по потреблению и ресурсам. Вот и реализовал именно так не задумываясь. обеспечение точности разницы фаз, конечно, на совести трассировщика... Я никого не стремлюсь убедить/переубедить, но лично мне спокойнее, когда работаю на 1 домене. не будет она строго меандром, конечно, но ~40% внутри кристалла вполне достижимо ведь? помехоустойчивость... а что мы сможем тут сделать в разумных пределах кроме попыток защиты от метастабильности? не фильтровать же в самом деле на 16x сигнал? да и от помехи зависит. даже если фильтровать -- далеко не всегда спасёт. если нужна надёжность -- только дублирование. всего. засылок, устройств и т.д. и то не факт, что метеорит не упадёт.
  9. да там ничего особо хитрого, клок 2x, работа по обоим фронтам клока. вот и вся хитрость. получаем 4 семпла на бит. нарисовать это на бумаге и всё очевидно станет. можно и проще сделать, как посоветовал там тоже 4x, для относительно небольших скоростей вполне подходит вариант. но увеличение скорости требует увеличения точности смежных фаз клоков. плюс еще вместо одного домена используется 2. мелочь, но жаба душит. поэтому мой вариант с одним доменом 2x, но с DDR мне больше понравился. Тем более, что 2x уже и в других модулях используется. Ну и если требуется повышенная надёжность -- не забывайте про защиту от метастабильности.
  10. поток 128 МБит/с, тактовая на приёме 2x = 256 МГц, но! некоторые триггеры, которые ловят старт-бит, работают по другому фронту. в результате имеется один (если правильно помню) переход между некоторыми триггерами, где получается t=(1/256MHz) / 2, эквивалент ~ 512 МГц. Грубо говоря, oversampling получается 4. Но с учётом того, что на этом переходе только клоковый домен меняется, нету ни логики или еще чего-то, разводится норм. ну на свежих поколениях, как минимум.
  11. с x1 -- согласен. x2 -- уже вполне адекватными решениями можно добиться цели. так речь же не идёт о том, что можно сделать. понятное дело, многое. только какой ценой? исходя из контекста я понимаю, что речи о золотых во всех смыслах проводах не идёт. ну как минимум таких, чтобы удовлетворить ключевые требования к высокочастотным lvds линиям. всего-то надо передать 100 Мбит/с.
  12. отлично, вместо того, чтобы реализовать полноценный и отвечающий всем требованиям интерфейс на полсотни строк vhdl -- гораздо проще разработать целую систему с синхронизаторами, калибровщиками, кодировщиками канала, восстановителями тактовых частот и неведомо ещё чем.
  13. не вижу никаких проблем кроме той, что нужен клок в 2 раза выше того, на котором сформирована последовательность бит. если сделать всё грамотно, то как раз наоборот: меньше сигналов -- меньше проблем.
  14. если клок только у мастера, тогда да, проблема. если данные в обе стороны со своими клоками, управляющими сигналами и т.д. идут, то +/- одинаковые задержки будут, но в таком случае даже lvds наловит столько помех, что ему хватит (тем более, что проводами качественный lvds не сделать). а UART -- линия туда, линия обратно. обе "молчаливые". для отсеивания "вдруг чего словится" -- можно добавить контрольную сумму.