Хорошее руководство для начинающих со скриншотами. Думаю, что многим будет полезно. Спасибо!
Но у меня возникло два вопроса.
1) Можно ли в ПЛИС использовать автоматы Милли с комбинационными выходами?
2) Можно ли подавать на логику переключения состояний сигнал insert, если он не синхронизирован?
Такие нередко можно увидеть на платах с 8-ю и более слоями. Интересней становится, когда нужно контролировать импеданс у внутренних сигнальных слоёв. У сигнальных слоёв внутри такого «бутерброда» из-за двух полигонов импеданс будет ниже в сравнении с внешним слоем. Поэтому либо надо менять толщину дорожек и расстояние между ними, если это диф. пара, либо делать «бутерброд» толще (разносить полигоны дальше от сигнальных слоёв).
Спасибо! Я пока только начал изучать мир проектирования ASIC. У меня сложилось впечатление, что без DFT совсем никак, потому что надо проверить чипы на пластине и отсеять брак.
Я тоже так думал, но недавно узнал, что можно с помощью фокусированного ионного луча (Focused Ion Beam (FIB)) делать простые доработки: перерезать связь, добавить новую. Дорого, конечно. Но зато можно опробовать некоторые изменения до перезапуска разработки. Сродни перерезанным дорожкам и перемычкам на печатной плате при первом запуске.
Подскажите пожалуйста, есть ли разница между Programmable Logic Device, Complex Programmable Logic Device и Field Programmable Logic Device?
3)
При этом отсутствует избыточность процессора, появляется малое потребление при той же скорости и функциональности
В то же время, FPGA кушает много тока. Одно статическое потребление некоторых FPGA уже поражает. Для ряда приложений, того же Интернета Вещей, микроконтроллер будет намного более выигрышным вариантом по потреблению.
4)
Отладив таким образом вычисления можно заказать ASIC, то есть заказную микросхему, выполняющую те же функции, но дешевле
Не совсем так. Проект, написанный для ПЛИС, можно попытаться перенести в ASIC. Только если в исходном проекте использовались примитивы FPGA (например, блочная память), то эти куски проекта придётся нещадно править. Никто не гарантирует, что под выбранный техпроцесс есть эквивалентные макроэлементы. Далее при синтезе логики под ASIC нужно будет добавлять сканирующую логику (Design for Test), ведь фабрика должна будет проверить готовый чип. Логика должна быть DFT friendly. В проектах для FPGA об этом даже думать не надо. Затем, в FPGA нет такой части, как back-end: не надо думать о целостности сигналов внутри кристалла, SPICE моделировании I/O. Добавление back-end, более объемная верификация требует больше человеко-часов. Уже только это скажется на стоимости разработки. Если приплюсовать сюда стоимость лицензий на инструменты, то получим намного менее привлекательную сумму.
ASIC будет дешевле только за счёт тиража, я бы сказал.
Да, есть такой интересный документ по преобразованию проектов ПЛИС под ASIC: www.onsemi.com/pub/Collateral/HBD872-D.PDF
Там довольно неплохо описаны все этапы.
5)
гиганты разработки FPGA начали создавать специальное ПО, позволяющее интерактивно переносить части вычислений из программы на C/C++ в FPGA и контролировать быстродействие (HLS, High-Level Synthesis)
HLS всё равно описывает аппаратуру, поэтому нужен определенный стиль кода и описания функций. Нельзя взять любой C++ код, положить его в HLS синтезатор и получить на выходе рабочую логику.
Под «тихим» подразумевал то, что, по моим текущим представлениям, стабильность потенциала на «GND» должна быть выше. На полигоне питания, плюсе, могут быть пульсации от импульсного источника. При скачке тока на нагрузке источник питания отрабатывает не сразу, и напряжение на выходе источника тоже прыгает.
Но сейчас я вспомнил о том, что есть такая штука как ground bounce, да и пульсации по «GND» тоже могут бежать.
С питанием действительно нужен намного больший набор ёмкостей и рабочих напряжений, чем может предложить C0G/NP0/МП0, да.
А не подскажете, на какие именно типы конденсаторов Вы поменяли керамику в схеме? У керамики, всё же, обычно высокий допустимый ripple current, и малое эквивалентное сопротивление. Хотя те же танталы сейчас стали обладать значительно меньшим эквивалентным сопротивлением, я иногда теряюсь в выборе замены.
Про +2,5 вольта на LVDS не совсем так. Это требование не стандарта, а производителя конкретной микросхемы. К примеру, в Cyclone 10 GX формировать LVDS могут только банки с питанием +1,8 вольта. В более ранних Cyclone — только банки с питанием +2,5 вольта.
PartNumber далее, чем BLM, не вспомню уже, увы. Могу ещё отметить, что это была бусина для линий питания.
Живого источника не было, а модели я не нашёл. Так что проверить режимы на практике я, не мог.
Да, конечно, в datasheet на импульсник рекомендовали конкретные значения индуктивности. И, кажется, по графику бусины значения индуктивности попадали в требования. По крайней мере, что-то такое вспоминается сейчас. Сопротивление по постоянке и величина максимального тока для бусины тоже были указаны. И эти величины вполне вписывались в то, что требовалось для источника. В том смысле, что ток импульсника был меньше, чем максимально допустимый ток бусины. Индуктивность бусины на частоте работы источника попадала в рекомендации. Отсюда и появились мои сомнения в том, что я могу чего-то не знать. Но если бы схему разрабатывал я, то в импульсник ставил бы индуктор точно. Бусины я использую только как фильтры.
и поэтому иногда требуется установка конденсаторов рядом с переходными отверстиями для замыкания путей возвратного тока по кратчайшему пути
То ли E. Bogatin, то ли кто-то еще, отмечал, что лучше всего вести сигналы вблизи одного опорного слоя. Т.е., например, если LVDS пара шла с опорой на «GND», то при переходе на другой слой пара по-прежнему должна опираться на «GND». При этом обычно вблизи перехода рекомендуют ставить сшивающие переходные («GND»-«GND»), дабы сократить путь возврата. Вот если после смены слоя опору для сигнала сохранить ну никак нелья (например, ближайший опорный слой — питание), тогда уже стоит ставить конденсаторы. Конденсаторы дадут более короткий путь для возвратного тока.
Вопрос о бусинах возник потому, что один раз я возился со схемой, которая досталась мне в наследство. Схема долго лежала в ящике и в производство не ушла. Но вдруг её стали рассматривать снова. И я обнаружил, что на схеме в контурах импульсников разработчик поставил ферритовые бусины. Сейчас сложно сказать, почему он выбрал такой вариант. Либо он хотел сократить перечень элементов, так как такие бусины уже стояли в цепях питания ФАПЧ для ПЛИС. Либо же это была классическая ошибка «копировать-вставить». На схеме, к слову, все ферритовые бусины были изображены как катушки.
Меня очень смутило то, что в импульсники поставили бусины. Однако другой коллега возразил тем, что на частоте работы импульсника бусина может вести себя как индуктор. Мол, если она ведёт себя как индуктор, то какие из этого проблемы. Тем не менее, мне показалось странным, что в иностранных схемах ферритовые бусины всегда изображают специальным символом, который не совпадает с символом индуктора. Плюс разница в параметрах и характеристиках, которые указывают в документации. В то же время, других обоснований у меня на то время не было. Импульсники работали примерно на 1-3 МГц, а там бусина действительно ведёт себя как индуктивность.
Помогла замена конденсаторов в аналоговой части на некерамические с аналогичными параметрами
Я ведь правильно помню, что керамика типа C0G/NP0/МП0 не имеет пьезоэффекта? Если номиналы и размеры позволяют, то можно рассматривать керамику такого типа к применению.
Количество конденсаторов у каждой микросхемы должно быть не менее количества ножек питания данной микросхемы…
В большинстве случаев вы не ошибетесь, если выберете емкость 0,1 мкФ…
В общем, лучше всегда уточнять номиналы требуемых конденсаторов в документации на конкретную микросхему
Очень любопытная ситуация возникает, если обратиться в документацию к современным ПЛИС. Возьмём для примера Cyclone 10 LP. www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/dp/cyclone-10/pcg-01021.pdf
Pin Connection Guidelines говорит: «The power plane should then be decoupled using the appropriate number of capacitors. To assist in decoupling analysis, Power Distribution Network (PDN) Design Tool serves as an excellent decoupling analysis tool».
«Достаточное количество конденсаторов». Как же определить, какое количество будет достаточным? Один из вариантов от Altera/Intel — это инструмент PDN Tool. Этот инструмент опирается на идею о том, что импеданс цепей питания должен иметь определенную величину в определенном диапазоне частот. Величина будет зависеть от динамического тока, от структуры платы, от импеданса источника и некоторых других параметров.
Для примера посмотрим на схему отладочной платы уже Cyclone 10 GX. www.intel.com/content/dam/altera-www/global/en_US/support/boards-kits/cyclone10/c10gx-dev-kits-board-a1-release.pdf
Смотрим страницы 13 и 14. Количество ножек питания ядра VCC — 55. Количество конденсаторов в цепи питания — 68.
Какие выводы из этого следуют:
— иногда приходится смотреть на целевой импеданс цепей питания;
— количество конденсаторов зависит от требуемого профиля импеданса;
— емкости 0,1 мкФ может быть недостаточно, более того, близкие номиналы могут взаимодействовать друг с другом (http://www.sigcon.com/Pubs/news/1_17.htm).
2)
После определения типа применяемого конденсатора (керамика, тантал, пленка, электролит и др.), необходимо обеспечить запас по напряжению хотя бы в 25-30%
Необходимо соединить цепи A_GND и D_GND между собой (иначе возвратным токам негде будет протекать). Как это правильно сделать? Существуют разные мнения на этот счет
Действительно, мнений много. Важно помнить, что разрывы в полигонах ведут к токовым петлям. Токовые петли становятся антеннами и ведут к увеличению помех. Плюс сигналы, которые из-за ошибок конструктора пересекают разрывы, получают скачок импеданса — растут потери на отражение. Поэтому я пришёл к выводу, что аналоговую часть от цифровой по возможности стоит разделять за счёт размещения на плате. Если же внутри одной микросхемы есть и аналог, и цифра, тогда стоит думать о разделении. Только это разделение должно быть локальным. См. с. 40-41 здесь: www.intel.ru/content/dam/www/programmable/us/en/pdfs/literature/ds/em2120_13149.pdf
Также важно помнить, что ток течёт по пути наименьшего сопротивления. На определенных частотах току становится всё равно, «GND» на этом куске металла или, например, «+3,3V». Поэтому ток может идти через конденсаторы цепей питания, ибо именно они соединяют «GND» и «+3,3V» (любую другую цепь). Значит, если на схеме один и тот же источник питает аналоговую и цифровую часть (минус разделили после выхода источника, через бусину, например), помехи из плюса питания цифровой части могут забежать на минус аналоговой. Отсюда разделять надо не только «GND», но и «PWR».
4)
индуктивности серии BLM от Murata
Вопрос, который уже давно меня волнует: можно ли ферритовую бусину называть индуктивностью? Да, это сердечник с одной (или двумя?) обмоткой. Но почему тогда в документации на ферритовые бусины не указывают индуктивность? У катушек индуктивности всегда пишут про индуктивность на определенной частоте, про ток насыщения, про сопротивление по постоянному току. У ферритовых бусин прежде всего сопротивление по постоянному току и частота, где бусина становится резистором. Индуктивность там присутствует только на графике импеданса. К чему это я: можно ли ставить ферритовую бусину в контур импульсного DC-DC, например? Хорошо ли дроссель будет изолировать две цепи питания?
У всех сигналов на внешних слоях появляется reference plane, благодаря которому можно разводить линии с заданным импедансом. Например, LVDS. И да, полигон питания тоже может быть опорным слоём, хотя он менее "тихий", чем GND.
При определённой толщине препрега или ядра из двух полигонов можно получить конденсатор, который будет отдавать свою энергию на высокой частоте — полезно для быстрых схем.
Сплошной полигон — это неразорванный путь для обратных токов. Петли токов — антенны. Нет разрывов — нет петель — меньше помех.
Вторая статья затрагивает тему переходных процессов и показывает, почему только керамика на входе питания — это плохо.
www.analog.com/media/en/technical-documentation/application-notes/an88f.pdf
Когда я начинал разрабатывать схемы, данные статьи весьма помогли мне разобраться с выбором конденсаторов. Язык там весьма доступный, без перегрузки формулами.
Под максимумом я подразумевал число кредитов, которое доступно передатчику в принципе. То есть, то число, что получается сразу же после инициализации, когда CREDITS_CONSUMED = 0, а CREDIT_LIMIT — это то, что выделила приемная сторона, CREDITS_ALLOCATED.
Допустим, после инициализации линка имеем CREDIT_LIMIT = 0x3DE кредитов для данных. CREDITS_CONSUMED = 0. Теперь отправляем 1 пакет в 256 байт и останавливаемся. Имеем CREDITS_CONSUMED = 256/16 = 16 или 0x10. Когда приемная сторона возвращает кредиты, CREDIT_LIMIT становится равен 0x3EE. CREDIT_LIMIT — CREDITS_CONSUMED = 0x3EE — 0x10 = 0x3DE. И больше, чем 0x3DE приемник не выделит.
А теперь представим, что на стороне ядра PCIe счетчик CREDIT_LIMIT вдруг рассинхронизировался, число доступных кредитов (CREDIT_LIMIT — CREDITS_CONSUMED) стало 0xFFE. Приемник же имеет (CREDITS_ALLOCATED — CREDITS_RECEIVED) = 0x3DE. Передатчик ядра ждёт, пока CREDIT_LIMIT не увеличится. Приемник же не увеличивает CREDIT_LIMIT, потому что больше, чем 0x3DE кредитов данных он выделить не может.
По крайней мере, в моём представлении ситуация из раздела «Debugging» оказывается именно такой.
Термин «Hard IP» также используется применительно к IP-блокам для FPGA. В этом случае подразумевается, что код блока был оптимизирован для использования в конкретной модели FPGA и синтезирован для размещения в ней.
По моему текущему опыту, под Hard IP в ПЛИС стоит понимать блоки, которые не только оптимизировали под конкретную ПЛИС, но и развели внутри самого кристалла. Иначе говоря, Hard IP в этом случае — это такой же неотъемлемый элемент ПЛИС, как LUT или триггер. Примеры: скоростные приемопередатчики (transceivers), контроллеры памяти, блоки канального уровня PCIe. Да собственно те же PLL. Конечно, вокруг таких ядер может подниматься дополнительная прослойка в виде "мягкой" логики. Но основная часть сделана в железе, дабы уложиться в требования по задержкам. PAM приемопередатчики на 58 Гбит/с на LUT с триггерами вряд ли можно сделать.
На форуме Xilinx есть обсуждение этого стиля, возможно одна из причин историческая — раньше синтезаторы не всегда хорошо оптимизировали такой код, а также имели проблемы с типом record.
Спасибо, что нашли то обсуждение. Я как раз недавно пытался отыскать его снова, но не смог. Пользователь с ником 'mwaechter', он же 'Mathias Wächter', — это и есть тот человек, благодаря которому я узнал про этот стиль. К слову, Mathias оставил немало полезных комментариев по теме контроллеров аппаратных ядер PCIe в ПЛИС как на форумах Xilinx, так и на форумах Altera.
Действительно, у Jiri Gaisler мог быть более продвинутый синтезатор, у которого не было проблем с record. С другой стороны, тот же Mathias пишет, что они начали применять этот стиль с 2004 года. Прошло уже 16 лет. Впрочем, здесь я сравниваю разработчика ASIC и разработчика FPGA. У них могут быть совершенно разные инструменты синтеза.
Глянул также исходники от самого Jiri, где используется этот стиль. Для случаев с большими конечными автоматами и большим количеством переменных он кажется уже не таким и приятным, я бы даже сказал, громоздким, следить за изменением одной переменной по состояниям сложно. Возможно, это дело предпочтений и привычки.
Мне кажется, что некоторую роль играет то, как структурирован сам код. Я пробовал писать проект в подобном стиле и в целом доволен результатами. Проблемы были только во внешних интерфейсах. Нужно тщательно продумать, как группировать внешние сигналы в record, иначе получается неразбериха и туча портов. Но писать код было, на мой взгляд, намного легче. Если что-то изменялось прямо во время разработки, я легко мог внести изменения; тратил меньше действий на добавить/удалить сигнал, делал меньше ошибок, не получал случайных защёлок.
Насколько я понял документацию на ядро, проблема в двух местах.
Первое — это счетчики потребленных кредитов (CREDITS_CONSUMED) и счетчики пределов/лимитов (CREDITS_LIMIT). В документации на ядро явно сказано, что счетчик лимитов в ядре может не соответствовать действительности («Sufficient credits may be unavailable if the link partner increments credits more than expected»).
Если мы обратимся к спецификации PCIe, то увидим, что доступные кредиты считаются как «лимит – (потребленные кредиты + кредиты для текущего пакета)». Пакет отправится только тогда, когда разница между лимитом и потреблением будет равна 2^[Field Size] / 2.
Полагаю, что в случае, который описан в “Debugging”, разница между лимитом и потреблением окажется отрицательной. В этой ситуации, так как счетчики беззнаковые, в реальности получаем, что разница превышает 2^[Field Size] / 2. Например, если для данных текущее значение счетчиков лимита — это 0x3D, а число потребленных кредитов — 0x3F, тогда число доступных кредитов — это FFE. Для кредитов данных 2^[Field Size] / 2 — это 7FF/2 = 3FF. Т.е. получается, что канальный уровень не может отправить пакет и должен ждать, пока счетчик лимитов вырастет.
А теперь предположим, что для приемной стороны текущие лимиты достигли максимума. Будет ли она отправлять передатчику (в нашем случае, ядру) пакет DLLP с новыми пределами? Как я понимаю, в этом случае приемник ничего отправлять не будет, так как для него лимиты уже на максимуме. Для ядра при этом лимиты оказываются меньше, чем нужно. Выходит, что имеем затор до тех пор, пока не обнулим счетчики ядра. Так как счетчики кредитов работают от времени инициализации линка, то единственный способ обнулить их — повторять инициализацию.
Второе — это буфер пакетов, куда попадает всё, что мы подаем на пользовательский интерфейс ядра Avalon-ST. Может оказаться, что “tx_st_ready” связан лишь с флагом “almost_full” буфера ядра. Допустим, мы хотим закинуть в ядро пакет в 128 байт. Счетчики кредитов говорят, что для 128 байт кредитов недостаточно, и при этом произошла рассинхронизация лимитов. Флаг “tx_st_ready” находится в “1”, потому что место в буфере ядра еще есть. Мы вливаем в ядро пакет, и на этом всё останавливается. Ядро ждет кредитов, которые не увеличатся, так как счетчики врут. Флаг “tx_st_ready” висит в “0”, потому что места в буфере больше нет.
Пакет в описанном случае действительно никуда не посылается, канальный уровень следует правилу. Проблема именно в том, как работает конкретная реализация ядра PCIe.
Хорошее руководство для начинающих со скриншотами. Думаю, что многим будет полезно. Спасибо!
Но у меня возникло два вопроса.
1) Можно ли в ПЛИС использовать автоматы Милли с комбинационными выходами?
2) Можно ли подавать на логику переключения состояний сигнал insert, если он не синхронизирован?
Пробовали ли Вы HLS? Если да, то каково впечатление?
Спасибо! Я пока только начал изучать мир проектирования ASIC. У меня сложилось впечатление, что без DFT совсем никак, потому что надо проверить чипы на пластине и отсеять брак.
Я тоже так думал, но недавно узнал, что можно с помощью фокусированного ионного луча (Focused Ion Beam (FIB)) делать простые доработки: перерезать связь, добавить новую. Дорого, конечно. Но зато можно опробовать некоторые изменения до перезапуска разработки. Сродни перерезанным дорожкам и перемычкам на печатной плате при первом запуске.
Интересно, что есть FPGA, которые не поддерживают горячего включения. Т.е. пока каскады I/O не запитаются, на входы ничего нельзя подавать, иначе от тока на I/O FPGA может повредиться.
См. пример здесь, искать по «Do Not Drive I/O Pins During Power Sequencing»:
www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-10/c10gx-51003.pdf
2)
Подскажите пожалуйста, есть ли разница между Programmable Logic Device, Complex Programmable Logic Device и Field Programmable Logic Device?
3)
В то же время, FPGA кушает много тока. Одно статическое потребление некоторых FPGA уже поражает. Для ряда приложений, того же Интернета Вещей, микроконтроллер будет намного более выигрышным вариантом по потреблению.
4)
Не совсем так. Проект, написанный для ПЛИС, можно попытаться перенести в ASIC. Только если в исходном проекте использовались примитивы FPGA (например, блочная память), то эти куски проекта придётся нещадно править. Никто не гарантирует, что под выбранный техпроцесс есть эквивалентные макроэлементы. Далее при синтезе логики под ASIC нужно будет добавлять сканирующую логику (Design for Test), ведь фабрика должна будет проверить готовый чип. Логика должна быть DFT friendly. В проектах для FPGA об этом даже думать не надо. Затем, в FPGA нет такой части, как back-end: не надо думать о целостности сигналов внутри кристалла, SPICE моделировании I/O. Добавление back-end, более объемная верификация требует больше человеко-часов. Уже только это скажется на стоимости разработки. Если приплюсовать сюда стоимость лицензий на инструменты, то получим намного менее привлекательную сумму.
ASIC будет дешевле только за счёт тиража, я бы сказал.
Да, есть такой интересный документ по преобразованию проектов ПЛИС под ASIC:
www.onsemi.com/pub/Collateral/HBD872-D.PDF
Там довольно неплохо описаны все этапы.
5)
HLS всё равно описывает аппаратуру, поэтому нужен определенный стиль кода и описания функций. Нельзя взять любой C++ код, положить его в HLS синтезатор и получить на выходе рабочую логику.
Но сейчас я вспомнил о том, что есть такая штука как ground bounce, да и пульсации по «GND» тоже могут бежать.
А не подскажете, на какие именно типы конденсаторов Вы поменяли керамику в схеме? У керамики, всё же, обычно высокий допустимый ripple current, и малое эквивалентное сопротивление. Хотя те же танталы сейчас стали обладать значительно меньшим эквивалентным сопротивлением, я иногда теряюсь в выборе замены.
Про +2,5 вольта на LVDS не совсем так. Это требование не стандарта, а производителя конкретной микросхемы. К примеру, в Cyclone 10 GX формировать LVDS могут только банки с питанием +1,8 вольта. В более ранних Cyclone — только банки с питанием +2,5 вольта.
PartNumber далее, чем BLM, не вспомню уже, увы. Могу ещё отметить, что это была бусина для линий питания.
Живого источника не было, а модели я не нашёл. Так что проверить режимы на практике я, не мог.
Да, конечно, в datasheet на импульсник рекомендовали конкретные значения индуктивности. И, кажется, по графику бусины значения индуктивности попадали в требования. По крайней мере, что-то такое вспоминается сейчас. Сопротивление по постоянке и величина максимального тока для бусины тоже были указаны. И эти величины вполне вписывались в то, что требовалось для источника. В том смысле, что ток импульсника был меньше, чем максимально допустимый ток бусины. Индуктивность бусины на частоте работы источника попадала в рекомендации. Отсюда и появились мои сомнения в том, что я могу чего-то не знать. Но если бы схему разрабатывал я, то в импульсник ставил бы индуктор точно. Бусины я использую только как фильтры.
То ли E. Bogatin, то ли кто-то еще, отмечал, что лучше всего вести сигналы вблизи одного опорного слоя. Т.е., например, если LVDS пара шла с опорой на «GND», то при переходе на другой слой пара по-прежнему должна опираться на «GND». При этом обычно вблизи перехода рекомендуют ставить сшивающие переходные («GND»-«GND»), дабы сократить путь возврата. Вот если после смены слоя опору для сигнала сохранить ну никак нелья (например, ближайший опорный слой — питание), тогда уже стоит ставить конденсаторы. Конденсаторы дадут более короткий путь для возвратного тока.
Вопрос о бусинах возник потому, что один раз я возился со схемой, которая досталась мне в наследство. Схема долго лежала в ящике и в производство не ушла. Но вдруг её стали рассматривать снова. И я обнаружил, что на схеме в контурах импульсников разработчик поставил ферритовые бусины. Сейчас сложно сказать, почему он выбрал такой вариант. Либо он хотел сократить перечень элементов, так как такие бусины уже стояли в цепях питания ФАПЧ для ПЛИС. Либо же это была классическая ошибка «копировать-вставить». На схеме, к слову, все ферритовые бусины были изображены как катушки.
Меня очень смутило то, что в импульсники поставили бусины. Однако другой коллега возразил тем, что на частоте работы импульсника бусина может вести себя как индуктор. Мол, если она ведёт себя как индуктор, то какие из этого проблемы. Тем не менее, мне показалось странным, что в иностранных схемах ферритовые бусины всегда изображают специальным символом, который не совпадает с символом индуктора. Плюс разница в параметрах и характеристиках, которые указывают в документации. В то же время, других обоснований у меня на то время не было. Импульсники работали примерно на 1-3 МГц, а там бусина действительно ведёт себя как индуктивность.
Я ведь правильно помню, что керамика типа C0G/NP0/МП0 не имеет пьезоэффекта? Если номиналы и размеры позволяют, то можно рассматривать керамику такого типа к применению.
У меня есть несколько примечаний и один вопрос.
1)
Очень любопытная ситуация возникает, если обратиться в документацию к современным ПЛИС. Возьмём для примера Cyclone 10 LP.
www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/dp/cyclone-10/pcg-01021.pdf
Pin Connection Guidelines говорит: «The power plane should then be decoupled using the appropriate number of capacitors. To assist in decoupling analysis, Power Distribution Network (PDN) Design Tool serves as an excellent decoupling analysis tool».
«Достаточное количество конденсаторов». Как же определить, какое количество будет достаточным? Один из вариантов от Altera/Intel — это инструмент PDN Tool. Этот инструмент опирается на идею о том, что импеданс цепей питания должен иметь определенную величину в определенном диапазоне частот. Величина будет зависеть от динамического тока, от структуры платы, от импеданса источника и некоторых других параметров.
Для примера посмотрим на схему отладочной платы уже Cyclone 10 GX.
www.intel.com/content/dam/altera-www/global/en_US/support/boards-kits/cyclone10/c10gx-dev-kits-board-a1-release.pdf
Смотрим страницы 13 и 14. Количество ножек питания ядра VCC — 55. Количество конденсаторов в цепи питания — 68.
Какие выводы из этого следуют:
— иногда приходится смотреть на целевой импеданс цепей питания;
— количество конденсаторов зависит от требуемого профиля импеданса;
— емкости 0,1 мкФ может быть недостаточно, более того, близкие номиналы могут взаимодействовать друг с другом (http://www.sigcon.com/Pubs/news/1_17.htm).
2)
При выборе запаса по напряжению стоит опираться на графики от производителя. Вот пара статей для керамических конденсаторов о том, как меняется ёмкость, и о чём не нужно забывать при выборе напряжения:
Первая статья
www.maximintegrated.com/en/design/technical-documents/tutorials/5/5527.html
рассказывает о том, почему конденсатор в схеме может потерять ёмкость. Один из важных выводов, который совпадает с пунктом про документацию, — это внимательно изучать графики на сайте производителя. Пример от Murata:
www.murata.com/en-SG/products/productdetail?partno=GRM188R61C475KE11%23
Вторая статья затрагивает тему переходных процессов и показывает, почему только керамика на входе питания — это плохо.
www.analog.com/media/en/technical-documentation/application-notes/an88f.pdf
3)
Действительно, мнений много. Важно помнить, что разрывы в полигонах ведут к токовым петлям. Токовые петли становятся антеннами и ведут к увеличению помех. Плюс сигналы, которые из-за ошибок конструктора пересекают разрывы, получают скачок импеданса — растут потери на отражение. Поэтому я пришёл к выводу, что аналоговую часть от цифровой по возможности стоит разделять за счёт размещения на плате. Если же внутри одной микросхемы есть и аналог, и цифра, тогда стоит думать о разделении. Только это разделение должно быть локальным. См. с. 40-41 здесь:
www.intel.ru/content/dam/www/programmable/us/en/pdfs/literature/ds/em2120_13149.pdf
Также важно помнить, что ток течёт по пути наименьшего сопротивления. На определенных частотах току становится всё равно, «GND» на этом куске металла или, например, «+3,3V». Поэтому ток может идти через конденсаторы цепей питания, ибо именно они соединяют «GND» и «+3,3V» (любую другую цепь). Значит, если на схеме один и тот же источник питает аналоговую и цифровую часть (минус разделили после выхода источника, через бусину, например), помехи из плюса питания цифровой части могут забежать на минус аналоговой. Отсюда разделять надо не только «GND», но и «PWR».
4)
Вопрос, который уже давно меня волнует: можно ли ферритовую бусину называть индуктивностью? Да, это сердечник с одной (или двумя?) обмоткой. Но почему тогда в документации на ферритовые бусины не указывают индуктивность? У катушек индуктивности всегда пишут про индуктивность на определенной частоте, про ток насыщения, про сопротивление по постоянному току. У ферритовых бусин прежде всего сопротивление по постоянному току и частота, где бусина становится резистором. Индуктивность там присутствует только на графике импеданса. К чему это я: можно ли ставить ферритовую бусину в контур импульсного DC-DC, например? Хорошо ли дроссель будет изолировать две цепи питания?
"Аналоговые девки" — это пять. Первый раз такой вариант вижу. Спасибо, повеселили.
На тему интересного поведения конденсаторов есть две статьи.
Первая статья
https://www.maximintegrated.com/en/design/technical-documents/tutorials/5/5527.html
рассказывает о том, почему конденсатор в схеме может потерять ёмкость. Один из важных выводов, который совпадает с пунктом про документацию, — это внимательно изучать графики на сайте производителя. Пример от Murata:
https://www.murata.com/en-SG/products/productdetail?partno=GRM188R61C475KE11%23
Вторая статья затрагивает тему переходных процессов и показывает, почему только керамика на входе питания — это плохо.
www.analog.com/media/en/technical-documentation/application-notes/an88f.pdf
Когда я начинал разрабатывать схемы, данные статьи весьма помогли мне разобраться с выбором конденсаторов. Язык там весьма доступный, без перегрузки формулами.
Допустим, после инициализации линка имеем CREDIT_LIMIT = 0x3DE кредитов для данных. CREDITS_CONSUMED = 0. Теперь отправляем 1 пакет в 256 байт и останавливаемся. Имеем CREDITS_CONSUMED = 256/16 = 16 или 0x10. Когда приемная сторона возвращает кредиты, CREDIT_LIMIT становится равен 0x3EE. CREDIT_LIMIT — CREDITS_CONSUMED = 0x3EE — 0x10 = 0x3DE. И больше, чем 0x3DE приемник не выделит.
А теперь представим, что на стороне ядра PCIe счетчик CREDIT_LIMIT вдруг рассинхронизировался, число доступных кредитов (CREDIT_LIMIT — CREDITS_CONSUMED) стало 0xFFE. Приемник же имеет (CREDITS_ALLOCATED — CREDITS_RECEIVED) = 0x3DE. Передатчик ядра ждёт, пока CREDIT_LIMIT не увеличится. Приемник же не увеличивает CREDIT_LIMIT, потому что больше, чем 0x3DE кредитов данных он выделить не может.
По крайней мере, в моём представлении ситуация из раздела «Debugging» оказывается именно такой.
По моему текущему опыту, под Hard IP в ПЛИС стоит понимать блоки, которые не только оптимизировали под конкретную ПЛИС, но и развели внутри самого кристалла. Иначе говоря, Hard IP в этом случае — это такой же неотъемлемый элемент ПЛИС, как LUT или триггер. Примеры: скоростные приемопередатчики (transceivers), контроллеры памяти, блоки канального уровня PCIe. Да собственно те же PLL. Конечно, вокруг таких ядер может подниматься дополнительная прослойка в виде "мягкой" логики. Но основная часть сделана в железе, дабы уложиться в требования по задержкам. PAM приемопередатчики на 58 Гбит/с на LUT с триггерами вряд ли можно сделать.
Спасибо, что нашли то обсуждение. Я как раз недавно пытался отыскать его снова, но не смог. Пользователь с ником 'mwaechter', он же 'Mathias Wächter', — это и есть тот человек, благодаря которому я узнал про этот стиль. К слову, Mathias оставил немало полезных комментариев по теме контроллеров аппаратных ядер PCIe в ПЛИС как на форумах Xilinx, так и на форумах Altera.
Действительно, у Jiri Gaisler мог быть более продвинутый синтезатор, у которого не было проблем с record. С другой стороны, тот же Mathias пишет, что они начали применять этот стиль с 2004 года. Прошло уже 16 лет. Впрочем, здесь я сравниваю разработчика ASIC и разработчика FPGA. У них могут быть совершенно разные инструменты синтеза.
Мне кажется, что некоторую роль играет то, как структурирован сам код. Я пробовал писать проект в подобном стиле и в целом доволен результатами. Проблемы были только во внешних интерфейсах. Нужно тщательно продумать, как группировать внешние сигналы в record, иначе получается неразбериха и туча портов. Но писать код было, на мой взгляд, намного легче. Если что-то изменялось прямо во время разработки, я легко мог внести изменения; тратил меньше действий на добавить/удалить сигнал, делал меньше ошибок, не получал случайных защёлок.
Первое — это счетчики потребленных кредитов (CREDITS_CONSUMED) и счетчики пределов/лимитов (CREDITS_LIMIT). В документации на ядро явно сказано, что счетчик лимитов в ядре может не соответствовать действительности («Sufficient credits may be unavailable if the link partner increments credits more than expected»).
Если мы обратимся к спецификации PCIe, то увидим, что доступные кредиты считаются как «лимит – (потребленные кредиты + кредиты для текущего пакета)». Пакет отправится только тогда, когда разница между лимитом и потреблением будет равна 2^[Field Size] / 2.
Полагаю, что в случае, который описан в “Debugging”, разница между лимитом и потреблением окажется отрицательной. В этой ситуации, так как счетчики беззнаковые, в реальности получаем, что разница превышает 2^[Field Size] / 2. Например, если для данных текущее значение счетчиков лимита — это 0x3D, а число потребленных кредитов — 0x3F, тогда число доступных кредитов — это FFE. Для кредитов данных 2^[Field Size] / 2 — это 7FF/2 = 3FF. Т.е. получается, что канальный уровень не может отправить пакет и должен ждать, пока счетчик лимитов вырастет.
А теперь предположим, что для приемной стороны текущие лимиты достигли максимума. Будет ли она отправлять передатчику (в нашем случае, ядру) пакет DLLP с новыми пределами? Как я понимаю, в этом случае приемник ничего отправлять не будет, так как для него лимиты уже на максимуме. Для ядра при этом лимиты оказываются меньше, чем нужно. Выходит, что имеем затор до тех пор, пока не обнулим счетчики ядра. Так как счетчики кредитов работают от времени инициализации линка, то единственный способ обнулить их — повторять инициализацию.
Второе — это буфер пакетов, куда попадает всё, что мы подаем на пользовательский интерфейс ядра Avalon-ST. Может оказаться, что “tx_st_ready” связан лишь с флагом “almost_full” буфера ядра. Допустим, мы хотим закинуть в ядро пакет в 128 байт. Счетчики кредитов говорят, что для 128 байт кредитов недостаточно, и при этом произошла рассинхронизация лимитов. Флаг “tx_st_ready” находится в “1”, потому что место в буфере ядра еще есть. Мы вливаем в ядро пакет, и на этом всё останавливается. Ядро ждет кредитов, которые не увеличатся, так как счетчики врут. Флаг “tx_st_ready” висит в “0”, потому что места в буфере больше нет.
Пакет в описанном случае действительно никуда не посылается, канальный уровень следует правилу. Проблема именно в том, как работает конкретная реализация ядра PCIe.