Фишка в том, что в коде очень легко найти что-то, что там есть
По-моему стоит начать искать условие, которое вызывает «A secter is revealed» на данном уровне. Хотя я согласен, что всё это диванные разговоры, без непосредственного изучения кода.
Интересно другое. Заинтересованный народ наверняка реверсил код игры. Соответственно, если секрет открывается, когда игрока толкнули, то где-то в коде должна быть проверка того, что движение через телепорт было инициировано не самим игроком, а некоторой сторонней силой. Если я не ошибась, то это должно быть отчетливо видно в коде. Почему этого не заметили те, кто патчил игру?
На самом деле вы всё верно говорите, и я с вами в общем плане согласен.
Вы же просто смешиваете разные уровни и задачи FPGA-дизайна, якобы для наглядности и упрощения процесса.
Почему я смешиваю уровни? Синтезатор игнорирует эти задержки. Возможно для вас будет аргументом то, что я хотел бы видеть диаграммы при симуляции так, как если бы к реальному железу был подключен реальный логический анализатор. Логический анализатор показал бы, что состояние на выходе триггера изменяется с задержкой, а не строго по активному фронту. И всё! Если мы не имеем ввиду gate level, то ни для какой другой задачи эта задержка не нужна. Ещё, наверное, стоит сказать, что правильнее эту задержку определять как «parameter», предоставляя пользователю право обнулять это значение.
Хорошо, давайте уберём в сторону gate level симуляцию, хотя это вполне себе аргумент, мы же не коня в вакууме описываем, а работаем в конечном итоге с реальной ПЛИС и её примитивами. Я не защищаю автора статьи с проблемами переприсвоения тактового сигнала. Но задержка при неблокирующем присваивании просто напросто упрощает понимание диаграмм. Факт в том, что по активному фронту на триггере образуются новые данные, но в реальности это не так, новые данные появляются позже. Это задержка может быть больше или меньше, но она строго больше нуля и меньше периода (желательно). Хорошо, когда эта задержка в реальности меньше периода с учётом всех накладных расходов (logic delay + routing delay), это означает, что мы уложились по таймингам.
Чтобы не повторяться с ответами, nerudo, old_bear, eugenk, предлагаю вам прочитать эту небольшую статью, она даёт исчерпывающий ответ на вопрос о целесообразности использования задержек при неблокирующем присваивании.
Если честно, немного удивлён результатами голосования. Лично я всегда использую задержки при неблокирующем присваивании.
Неблокирующее присваивание без задержки выполняется в симуляторе мгновенно, хотя в реальности это триггер и новое значение на его выходе формально образуется через время tCQ (clock to q delay). Без этой задержки события в симуляторе будут происходить на такт раньше, что может привести к неправильному пониманию работы схемы при симуляции. В то время как с задержкой мы видим то, что происходит в реальности. Собственно исходя из этих соображений можно привести массу примеров того, когда результаты симуляции отличаются от железа.
Так уж получилось, что на широких просторах интернета мне на глаза попадались исходники фирменных ядер Xilinx, Altera, Mictrotronix, SLS и т.д. Очень часто вижу задержки при неблокирующем присваивании. У Xilinx вообще все ядра симулируются с задержкой на триггерах в 100ps.
Точно, согласен. Вот в чём был подвох. Нам важен сам факт отражения, а не его направленность. Зеркало даёт направленное отражение, но отражает хуже (0,72–0,85), а например алебастр даёт диффузное отражение (0,92). Таким образом белая керамика с учётом её тугоплавкости лучший вариант. Спасибо!
Согласен, но чтобы изолировать горячий экран от остальной части зонда уже используется слой из углеродной пены с температурой плавления ~3527 °C. Пока не очень понятно, что мешало сделать отражатель с бОльшим КПД.
Чем обусловлен выбор белой керамики в качестве щита? Белый цвет — не идеальный отражатель, т.е. достаточно много энергии излучения будет поглощено, но зато керамика очень тугоплавкая ~3000 °C. Где-то тут должен быть баланс между тугоплавкостью отражателя и его КПД. Интересно, почему выбор пал на керамику?
Второй случай был, когда к нам пришел заказчик с довольно большим проектом, на котором было примерно два миллиона зарегистрированных пользователей. Мы начали работу, заказчик предоставил нам доступ к коду и базе. А в базе все пароли пользователей в незашифрованном виде.
Не то, чтобы я придираюсь к словам, но если речь идёт о паролях аккаунтов, то в базе должны быть достаточно трудоёмкие хэши паролей + соль. Если вы имели ввиду как раз это, то хэширование — не шифрование.
Почему закон Яровой нереализуемый?
Вы так решили? Я вот вижу, пакет спокойно реализуется.
Предположим, что вы можете прослушивать и записывать всё и вся. Современная криптография позволяет создавать защищённую связь поверх любого открытого канала. И какой толк от зашифрованных данных, которые вы записали?
Последний более-менее нормальный USB SS PHY от Texas Instruments TUSB1310A стал NRND (not recommended for new design) уже больше года назад. А других нет… только FT600 от FTDI, который просто тупой быстрый FIFO, который автору не подойдёт, поскольку в нем нет той гибкости, которая есть у GPIF FX3.
P.S. Я уже не говорю о том, что поднять USB SS link layer далеко не так просто. В этом плате FX3 становится наиболее дешевым и наименее трудоёмким способом попасть в мир USB3.0.
… пропускная способность PCIe gen 1 и gen 2 для x1 составляет 500 МБ/с
Почему вы пишите, что у gen1 и gen2 скорости одинаковые?
PCIe gen1 x1 — 2.5Gb/s (на физ.уровне), т.е. 250MB/s (после 8b/10b)
PCIe gen2 x1 — 5.0Gb/s (на физ.уровне), т.е. 500MB/s (после 8b/10b)
Вопрос в том, почему об этом не предупредил сам автомобиль? Вот, что плохо и стоит поправить. На всех дисплеях, изо всех динамиков должно кричать предупреждение о неисправности батареи. Фарами, гудком предупреждать окружающих. Можно, наверное, ещё двери разблокировать, короче говоря спасать пассажиров. Разумеется за это всё должна обеспечивать дублирующая небольшая батарея + логика управления.
Исходники этой матери в altium: www.kosagi.com/w/index.php?title=Novena_PVT_Design_Source
У microchip-а есть такие решения. Например PIC18F97J60 со встроенным MAC и 10-Base T PHY.
Почему я смешиваю уровни? Синтезатор игнорирует эти задержки. Возможно для вас будет аргументом то, что я хотел бы видеть диаграммы при симуляции так, как если бы к реальному железу был подключен реальный логический анализатор. Логический анализатор показал бы, что состояние на выходе триггера изменяется с задержкой, а не строго по активному фронту. И всё! Если мы не имеем ввиду gate level, то ни для какой другой задачи эта задержка не нужна. Ещё, наверное, стоит сказать, что правильнее эту задержку определять как «parameter», предоставляя пользователю право обнулять это значение.
Неблокирующее присваивание без задержки выполняется в симуляторе мгновенно, хотя в реальности это триггер и новое значение на его выходе формально образуется через время tCQ (clock to q delay). Без этой задержки события в симуляторе будут происходить на такт раньше, что может привести к неправильному пониманию работы схемы при симуляции. В то время как с задержкой мы видим то, что происходит в реальности. Собственно исходя из этих соображений можно привести массу примеров того, когда результаты симуляции отличаются от железа.
Так уж получилось, что на широких просторах интернета мне на глаза попадались исходники фирменных ядер Xilinx, Altera, Mictrotronix, SLS и т.д. Очень часто вижу задержки при неблокирующем присваивании. У Xilinx вообще все ядра симулируются с задержкой на триггерах в 100ps.
Не то, чтобы я придираюсь к словам, но если речь идёт о паролях аккаунтов, то в базе должны быть достаточно трудоёмкие хэши паролей + соль. Если вы имели ввиду как раз это, то хэширование — не шифрование.
Предположим, что вы можете прослушивать и записывать всё и вся. Современная криптография позволяет создавать защищённую связь поверх любого открытого канала. И какой толк от зашифрованных данных, которые вы записали?
P.S. Я уже не говорю о том, что поднять USB SS link layer далеко не так просто. В этом плате FX3 становится наиболее дешевым и наименее трудоёмким способом попасть в мир USB3.0.
Почему вы пишите, что у gen1 и gen2 скорости одинаковые?
PCIe gen1 x1 — 2.5Gb/s (на физ.уровне), т.е. 250MB/s (после 8b/10b)
PCIe gen2 x1 — 5.0Gb/s (на физ.уровне), т.е. 500MB/s (после 8b/10b)