Обновить
116
0

Пользователь

Отправить сообщение
Проблема-то не только в задержках. Проблема еще в том, что асинхронная схема подразумевает использование комбинационных сигналов для упраления другими частями схемы. Это подразумевает, что разработчик обязан обеспечить отсутствие паразитных импульсов на выходе таких комбинационных схем (простейший пример: нарисуйте схему двухвходового мультиплексора на элементах И-ИЛИ-НЕ с ненулевыми задержками элементов, и вы увидите, что когда оба его входа данных равны единице, то при переключении с одного на второй на выходе на некоторое время установится ноль). Но только в ПЛИСах комбинационная логика реализуется на LUT-ах, а в даташитах написано, что отсутствие паразитных импульсов на выходе LUT-ов не гарантируется.
Асинхронность оправдана только там, где физически без нее не обойтись — перевод сигнала между двумя асинхронными тактовыми сигналами. Во всех остальных случаях это равносильно ужину при свечах на бочке с порохом. У нас индусы умудрились зарелизить асинхронный контроллер. В результате одна микросхема заработала, а вторая нет. После чего я их заставил передать все на кондовую синхронную логику. Ну желающие рискнуть оптимисты всегда найдутся, но я бы не рекомендовал. Если не хватает скорости тактового сигнала — значит синхронизацию нужно делать более быстрым тактовым сигналом.
А чего тут сравнивать? Примерно 95% коммерческих разработчиков IP (начиная с ARM) используют Verilog. А они, смею вас уверить, не враги сами себе.
Картинки мы не трогали. А обозначения полезно знать разные, лично я предпочитаю IEC 60617-12 (элемент ИЛИ изображается гораздо логичнее, чем по ГОСТу): ru.wikipedia.org/wiki/Логический_вентиль
Считается, что основной контингент будет читать с планшетов. Я тоже был поначалу не в восторге, но потом привык. На большом мониторе лучше отображать сразу две страницы бок о бок.
А вы откройте и сразу увидите! А если вы уже открыли, то подсказка — верстка у английской и русской версии совершенно разные.
Кстати, в оригинале электронная книга стоит $50, так что можно серьезно сэкономить.
Книга действительно хорошая. Надеюсь, теперь у меня будет меньше проблем с наймом сотрудников!
Я собеседовал несколько (>10) кандидатов на junior-позиции (hardware) в наших офисах в Калифорнии и Китае — все они были вчерашними студентами американских и китайских университетов. Не могу сказать, что уровень их знаний хоть сколько-нибудь заметно отличался от уровня хорошего пятикурсника кафедры вычислительной техники хорошего российского института.

В одном только Питере таких студентов должны выпускаться сотни в год. Только хороших среди них — раз два и обчелся. Все, кто поумнее, перепрофилируются на программистов, потому что знают, что нормальной работы по специальности не найти. А потом, когда приходит иностранная компания и хочет нанять людей — не из кого выбирать. После этого такая компания, привыкшая, что это она выбирает кандидатов, а не бегает за ними, уговаривая пособеседоваться, больше в России никого на hardware не нанимает, а вместо этого открывает с нуля новый дизайн-центр в Китае и нанимает 30 местных выпускников. Ибо там есть выбор, а у нас нет (disclaimer: все совпадения с реальными компаниями случайны).
Ну просто я знаю, что наша контора продает свои собственные библиотеки для TSMC. То есть если я пойду прямо к TMSC и скажу, что хочу в их шаттл — они дадут либы бесплатно? Или нужно сначала кровью подписаться, что куплю контейнер пластин?

Интересно, как фаблесс модель работает в реальной жизни.
Интересно: на сайте ЦР написано, что вы им дали нетлист, а топологию они сделали сами под один из техпроцессов, который они поддерживают. Т.е. у них, видимо, куплены библиотеки стандартных ячеек под несколько техпроцессов (TSMC, Silterra, TowerJazz, Микрон). Библиотека (да и memory compiler) ведь нужна для синтеза — они вам ее дали, перепродали, или вы сами с фабрикой договаривались? На каком этапе разработки был выбран техпроцесс? Заранее, под какие-то рамки производительности, или сначала написали RTL, а потом выбирали, где произвести? (т.е. выбирали техпроцесс под частоту, или частоту под техпроцесс?)
Правда, такой «универсальный» вариант, скорее всего, не будет работать для DFT-шного scan-теста (но это актуально только для ASIC-ов).

Поэтому самый универсальный вариант такой:

input clk;
input bad_reset;
input dft_mode;
output good_reset;

reg [1:0] rst_sync_r;

always @(posedge clk, posedge bad_reset)
    if (bad_reset) rst_sync_r <= 2'b11;
    else rst_sync_r <= {rst_sync_r[0], 1'b0};

assign good_reset = (dft_mode) ? bad_reset : rst_sync_r[1];
Для метастабильного состояния нужен тактовый сигнал, а там его нету
Что-то никакого промышленного применения не наблюдается. ARM-ядро (AMULET) было сделано, если мне не изменяет память, где-то в 1995 году, т.е. 20 лет назад.

Есть хорошая книга про асинхронные схемы, правда стоит $245 на Амазоне: www.amazon.com/Principles-Asynchronous-Circuit-Design-Perspective/dp/0792376137/ref=sr_1_1?ie=UTF8&s=books&qid=1247408117&sr=8-1

А вот ее совершенно бесплатная (легальная!) версия, чуть-чуть урезанная: eecourses.technion.ac.il/048878/book.pdf — не благодарите :)

Самое интересное, что это одна из немногих областей, где был заметный в мировом масштабе вклад отечественных ученых (Варшавский и компания из ЛЭТИ).
В статье неявно сказана одна очень важная вещь, которую надо бы особо выделить: критически важно триггеры синхронизатора располагать как можно ближе друг к другу, это прямым образом влияет на время наработки на отказ, причем разница может быть на десятки порядков: www.aspenlogic.com/images/alj001.pdf
Синхронный сброс требует тактового сигнала, но иногда бывает нужно сбросить все триггеры до того, как тактовый сигнал появится (например, в контроллере JTAG, если он тактируется сигналом TCK, а не внешним тактовым сигналом).

Именно поэтому самый универсальный вариант — асинхронная установка сигнала сброса и синхронное снятие, то есть сбрасываем сразу, как только пришел сигнал сброса, а выводим из ресета только после синхронизации, чтобы быть уверенными, что все триггеры выйдут из ресета одновременно (на одном такте).
Это да, только он будет в три раза больше по размеру, жрать электроэнергию как крокодил, его CoreMark будет раза в три-четыре меньше, чем у конкурентов, а раз в сто тысяч выполненных команд в нем будут возникать непонятные баги, которые никто никогда не отладит.
Спасибо — то, что надо
«машины состояний» (state machines) — это то, что в общепринятой русскоязычной терминологии называется конечными автоматами

Информация

В рейтинге
Не участвует
Откуда
Porto, Португалия
Зарегистрирован
Активность