MobyDick

Согласно CYCLONE Datasheet, "There is a current limit of 320 mA per 16 consecutive output pins... ... PCI, LVTTL, LVCMOS, and other supported I/O standards not shown in the table do not have standardized loading conditions. As such, the current allowed per pin in a series-loaded condition for these standards is considered negligible." (секция IV, DC Guidelines) В случае заметного превышения максимально допустимого выходного тока этим ограничением, думаю, уже нельзя пренебрегать. Возможно, перегрузка по току приводит к просадке напряжения в пределах банка ВНУТРИ матрицы, что не наблюдается на внешних выводах питания. И ещё: "If the input clocks have any low-frequency jitter (below the PLL bandwidth), the PLL attempts to track it, which increases the jitter seen at the PLL clock output. To minimize this effect, avoid placing noisy signals in the same VCCIO bank as those that power the PLL clock input buffer. This is only important if the PLL input clock is assigned to 3.3-V or 2.5-V LVTTL or LVCMOS I/O standards. With these I/O standards, VCCIO powers the input clock buffer. Therefore, any noise on this VCCIO supply can affect jitter performance. For all other I/O standards the input buffers are powered by VCCINT." (секция II, Board Layout - Jitter Considerations)

В нашем случае - EP2C(35/50)F672 - 28/14 пар выводов резервируются для совместимости с ..C70.. Проблема сквозных токов, например, существует только для выходных каскадов логики? Т.е. если входной сигнал в матрице далее не используется, проблем не будет? Отключаются ли в матрице физически входные цепи вывода, сконфигурированного как выход?

В том-то и проблема, что у Альтеры эти пины в матрицах меньшего объёма - обычные User I/O, и в случае, например, 1-ых Циклонов, Vccint = 1.5V =~1/2*Vccio.

Поделитесь, пожалуйста, опытом - кто как делает, пусть даже и без обоснования.

Можно ли во 2-ых Циклонах (и в других семействах) выводы, зарезервированные под Vccint для миграции, сажать непосредственно на Vccint? Не будет ли проблем с неопределённым логическим уровнем на входах матрицы? Мы раньше подключали их через перемычки...

Вопрос из разряда "У меня в подполе происходит стук. Объясните, почему?" :unsure: Возможна масса причин - как внутри матрицы, так и вне её. Прежде всего - "... триггеры и прочие автоматы ..." не работают в симуляторе или в железе?

При испытаниях устройства (мост Ethernet - n*64k) на основе контроллера IР175 столкнулись с проблемой. Предложенная заказчиком методика испытаний включает проверку прохождения пакетов длиной 32k (= рing -l 32000 x.x.x.x). На линейных испытаниях такие пакеты иногда проходят, иногда - нет. Попытки воспроизвести и локализовать проблему в лабораторных условиях показали, что при соединении 2-х компов с сетевыми картами, настроенными с одной стороны на 100М, а с другой - на 10М, через коммутатор (switch), максимальный размер нормально проходящего рing-пакета составляет от ~7kБ до ~30kБ в зависимости от сетевых карточек и моделей свитчей. Карточки - встроенные Marvеll Yukоn Gigаbit Ethеrnet и/или PCI-ные RТL8029, RТL8139; свитчи - LаnTеch Pаlm Switсh 500 (на базе IР175), COMPEX РS2208В, SМС-ЕZ6505Tx. В некоторых случаях (зависит от типа 100М карты) длинные пинги не проходят при 100М Full Duplеx, а в Hаlf Duplеx проходят, в других случаях - наоборот. "Вскрытие" показало, что свитч начинает отбрасывать кадры. В одном из случаев это выглядит так: проходят 6 кадров (фрагментов длинного пакета по 1514 байт), 7-й отбрасывается, затем начинает отбрасываться каждый третий кадр. Собственно, сами вопросы: 1) Неужели размер пакетного буфера свитчей слишком мал? Я считал, что он составляет в худшем случае не меньше сотни килобайт на порт. Может, кто знает объём буфера (в байтах и кадрах) для IР175 ? 2) В случае Full Duplеx анализатор протокола не обнаруживает "pаuse cоntrоl frаme", хотя в IР175 включен 802.3x Flоw Cоntrоl. Должны ли они быть видны в анализаторе или они обрабатываются сетевой картой и не передаются на верхний уровень?

Проблема с БайтБластером в Квартусе II 4.1 sp2. В цепочке 4 не-Альтеровских чипа + 2 Циклона. БайтБластер рабочий. На других платах (с одной матрицей) в Квартусе проблем нет. С этой JТАG-цепочкой в Квартусе не работают ни автодетект (Unable to scan.. Can't scan..), ни конфигурирование с принудительным заданием устройств (Can't access JТАG chain). В Макс*Плюсе*10.1 на той же машине с тем же шнурком нормально работает Detect_JТАG_chain_info (находит 6 устройств с правильной суммарной длиной регистра инструкций). Универсал*Скан*8 работает с этой платой на ура. Непонятный момент: Универсал*Скан и Макс*Плюс начинают работу с цепочкой с IR_Scan/Shift, а Квартус - с DR_Scan/Shift. *********************** Если кому интересно - другая плата с подобной цепочкой нормально заработала с Квартусом. В обоих случаях матрицы стоят последними в цепочке, а первыми - ТМS (на первой плате - 5402, на второй - 6414).