User Tag List

Показано с 1 по 10 из 803

Тема: Реверс-инжиниринг Z80

Древовидный режим

Предыдущее сообщение Предыдущее сообщение   Следующее сообщение Следующее сообщение
  1. #11

    Регистрация
    08.05.2007
    Адрес
    Dnepropetrovsk
    Сообщений
    1,089
    Спасибо Благодарностей отдано 
    281
    Спасибо Благодарностей получено 
    70
    Поблагодарили
    49 сообщений
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от Titus Посмотреть сообщение
    Мне еще пока не понятно главное - как при произвольной CLK, но не превышающей определенную частоту, сделать, чтобы часть триггеров работала по спаду, часть по фронту?
    Могу точно пояснить по Spartan-6.
    Там в каждом блоке SLICE (в котором имеется 4-8 триггеров, 4 6-входовых комбинационных LUT6 и кое-что еще) можно конфигурировать полярность сигнала CLK на триггеры.

    Поэтому можно взять тактовый сигнал, описать на языке (VHDL/Verilog) инвертор для него, и подавать прямой или инверсный CLK на тактовый вход всех триггеров. Та часть из них, на которую подается прямой CLK, будет срабатывать по его нарастанию, а другая часть (с инверсным CLK) - по спаду. При синтезе схемы этот инвертор не займет никаких ресурсов кристалла. Ни буферов тактовой частоты (BUFG), ни комбинационной логики (LUT), ничего. И даже задержки сигнала от инверсии не будет.

    Как на Spartan-7 или Artix-7 - не знаю. У Xilinx была тенденция уменьшения гибкости логических ресурсов от поколения к поколению, чтобы упаковать их больше на один кристалл. Например, в Spartan-3 были триггеры с входами R и S, а в Spartan-6 - только один из двух (R или S). Также у Spartan-6 были асинхронные R- или S-входы у триггеров, а у Artix-7 - только синхронные (по фронту тактовой частоты). На самом деле эти ограничения даже полезные, они повышают культуру разработки и ни в коей мере не ограничивают свободу разработчика, если только он немного по-другому решит задачу, которую ранее решал асинхронными входами. В общем, по Artix-7 или Spartan-7 надо смотреть по докам, есть ли там тоже возможность инверсии тактового входа триггеров. В Spartan-6 точно есть.

    Я не рекомендую подавать внешний тактовый сигнал с неизвестной скважностью на схему, часть триггеров которой срабатывает по нарастанию, а другая часть - по спаду. Почему?

    Потому, что скважность тактового сигнала неизвестна. А размещение/разводка схемы требуют конкретных чисел. Например: что частота сигнала не более стольки-то МГц, и скважность не менее x % и не более y%. Тогда оптимизатор, исходя из наихудших условий (экстремально короткие тактовые импульсы и т.д.), раскидает и разведет схему по ресурсам ПЛИС, гарантируя ее работоспособность.

    Но широкие допуски на входной тактовый сигнал приведут к тому, что максимальная тактовая частота, при которой синтез проекта пройзойдет успешно, окажется весьма низкой. В самом деле, а вдруг пользователь подаст на тактовый вход сигнал самой неприятной для схемы скважности? Очень короткие положительные или отрицательные импульсы на тактовом входе приведут к трудностям при генерации работоспособной конфигурации ПЛИС.

    Что я предлагаю взамен? Гарантировать скважность 50% для тактовой частоты. Это можно сделать при условии, что входной тактовый сигнал периодический (без выпадений импульсов и т.п.). Подать входной тактовый сигнал на ФАПЧ, умножить его в n раз, и наслаждаться. На практике, у меня в железе на Spartan-6 работал 32-битный Softcore-процессор на частоте 80МГц, а некоторые модули схемы (напр. Gigabit MAC) - на 125МГц. Еще были приемники данных, работавшие на битовой частоте 960МГц и байтовой - 120МГц. Более современные поколения ПЛИС могут дать и более высокие рабочие частоты.

    Если внешней схеме требуется задержать работу процессора - то это следует делать не путем манипуляций с тактовой частотой, а другим способом. Сделать какой-нибудь сигнал типа WAIT, возможно - с более высоким приоритетом, который безусловно заставляет процессор в любом состоянии пропустить тактовый импульс.

    По языкам программирования (Verilog или VHDL) - наверное, это спор о вкусах. Когда учился, я пробовал освоить их оба, легче зашел VHDL, на нем и работал далее. Как профессиональный программист на Си, скажу, что "сходство" Verilog и C - кажущееся. Это совершенно разные языки, для совершенно разных задач, и способ мышления для них различается коренным образом. Между VHDL и Verilog больше сходств, чем между Verilog и C.

    Оба языка, повторюсь, задумывались для описания симуляции. Самые главные их концепции:
    1) описание узла схемы состоит из "параллельных" и "последовательных" инструкций.
    2) Параллельные инструкции выполняются (в абстрактной среде исполнения) все параллельно, непрерывно и одновременно. Как правило, они описывают комбинационные схемы.
    3) Последовательные инструкции исполняются как в обычном языке программирования, одна за другой. Они объединяются в "процессы" (Process в VHDL, Always-блоки в Verilog). Основная идея: "процесс" запускается по какому-либо событию (как правило - фронту тактовой частоты) и всякий раз мгновенно (в абстрактной среде исполнения) исполняется до конца. Отсюда конструкции VHDL типа: proc1: process(CLK) begin if CLK='1' and CLK'Event then ......... end if; end process;. В Verilog используется конструкция always @posedge(CLK). Хотя языки VHDL/Verilog допускают запуск "процесса" по изменению произвольных сигналов или их комбинаций, для синтезируемых схем следует запускать процессы только по фронту CLK. Ведь "процессы" синтезируются инструментами разработки в триггеры и комбинационную логику на их входах. Тело "процесса" может содержать разные команды, в том числе циклы, сложные конструкции if/else. Но опять же, для синтезируемых в приемлемых размерах схем следует ограничиться записью в какие-либо сигналы (это будут выходы триггеров) некоторой логической функции от каких-то других сигналов. "Процессов" в узле схемы может быть произвольное количество. По одному и тому же событию может запускаться много разных процессов, и все они (в абстрактной среде исполнения) исполняются одновременно и мгновенно.
    Последний раз редактировалось Barmaley_m; 30.08.2024 в 23:14.

    Этот пользователь поблагодарил Barmaley_m за это полезное сообщение:

    Titus(30.08.2024)

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 2 (пользователей: 0 , гостей: 2)

Похожие темы

  1. Ответов: 1739
    Последнее: 09.01.2025, 10:55
  2. Ответов: 32
    Последнее: 18.12.2024, 18:19
  3. Реверс-инжиниринг игры Boovie
    от Oleg N. Cher в разделе Программирование
    Ответов: 41
    Последнее: 09.01.2022, 23:07
  4. Реверс МК-92
    от Случайность в разделе Программируемые калькуляторы
    Ответов: 55
    Последнее: 24.04.2021, 23:47
  5. Реверс инжиниринг печатной платы
    от Filin в разделе Несортированное железо
    Ответов: 36
    Последнее: 11.03.2018, 22:46

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •