2013-10-12 1 views
1

Я проектирую микроконтроллер в VHDL. Я нахожусь в точке, где я понимаю роль каждого компонента (ALU/Memory ...) и некоторые идеи о том, как их реализовать. Я в основном хочу реализовать архитектуру фон Неймана.Протокол шины для микроконтроллера в VHDL

Но вот что я не понимаю: как взаимодействуют компоненты? Я не знаю, как спроектировать мой автобус (автобусы?). Поэтому я ищу простую реализацию и протокол шины.

Мои нерешенные вопросы:

  • ли проще иметь один автобус за все или отделить разные данные?
  • Как каждый компонент знает, когда «слушать» и когда «писать»?

Акцент делается на простоте конструкции (и, следовательно, реализации). Меня не волнует скорость. Я хочу делать все с нуля (т. Е. Готового softcore).

Я не знаю, имеет ли это значение на данном этапе, но ему не нужно запускать «настоящий» скомпилированный код, имеет какую-либо совместимость с чем-либо существующим. Кроме того, в какой момент я начинаю думать о своих инструкциях «сборки»? Я думаю, что я загружу их непосредственно в память.

Благодарим за помощь.

EDIT: я в конечном итоге рисунок (много) вдохновение из Picoblaze, потому что:

  • просто понять
  • под BSD лицензией

В частности , Я начал с добавления нескольких инструкций к нему.

ответ

2

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

Z80 Memory and I/O

Чтобы ответить на ваш первый вопрос (один против нескольких автобусов), это чип использует единую шину для всего, и он имеет очень простой дизайн. Вероятно, вы могли бы использовать что-то подобное. Чтобы сделать терминологию понятной, одна системная шина может состоять из подпути (и они также называются шинами). На рисунке показана системная шина, состоящая из шины данных двунаправленного трафика (8 бит) и адресной шины (16 бит).

Чтобы ответить на второй вопрос (как знают компоненты, когда они активны), на изображении выше вы видите два разных сигнала, запрос памяти и запрос ввода-вывода. Одновременно будет активен только один, и когда запрос ввода-вывода активен, именно тогда к нему можно получить доступ к периферии.

Если у вас нет большого количества периферийных устройств, вам не нужно использовать все 16 адресных линий (некоторые Z80 имеют 8-разрядное пространство ввода/вывода). Каждое периферийное устройство будет доступно через некоторые адреса в этом пространстве. Например, в очень простой системе:

  • периферийное таймер может использовать адреса от 00h до 03h
  • УАПП может адреса от 08h до 0FH

В этом простом примере, вам нужно обеспечивают две цепи: один будет определять, когда адрес находится в диапазоне 00-03h, а другой будет делать то же самое для 08-0Fh. Если вы выполняете логику «и» между выходом каждого детектора и сигналом запроса ввода-вывода, тогда у вас будет два сигнала, указывающих, когда к каждому из периферийных устройств обращаются. Ваше периферийное оборудование должно в первую очередь прослушивать этот сигнал.

Наконец, в отношении вашего вопроса о инструкциях поток данных внутри вашего микропроцессора будет иметь несколько этапов. Обычно это называется процессорным datapath. Распространено разделить этапы на:

  1. FETCH: прочитайте инструкцию из памяти программы
  2. ДЕКОДИРОВАТЬ: проверить определенные биты в инструкции, и решить, какой тип обучения это
  3. ВЫПОЛНИТЬ: взять действия, предусмотренные инструкцией (например, АЛУ операции)
  4. ПАМЯТЬ: для некоторых инструкций, которые вы должны сделать данные чтения или записи
  5. WRITE НАЗАД: обновляют свои регистры процессора с новыми значениями, затронутых инструкцией

A Typical Microprocessor Datapath

Источник: https://www.cs.umd.edu/class/fall2001/cmsc411/projects/DLX/proj.html

Большая часть вашей работы иметь дело с отдельными инструкциями будет сделана в DECODE и EXECUTE этапов. Что касается контроля данных, вам понадобится конечный автомат, который контролирует последовательность операций через 5 этапов. Этот функциональный блок обычно называется блоком управления.Здесь у вас есть несколько вариантов:

  1. Ваш государственный автомат может идти по всем этапам последовательно, по одному за раз. Для выполнения команды потребуется несколько тактовых циклов.
  2. Как и в случае выбора выше, но комбинируя два или более этапа за один цикл, если вы хотите сделать вещи проще и быстрее.
  3. Трубопровод выполнения инструкций. Это может дать большой прирост скорости, но, возможно, лучше оставить его на потом, потому что все может стать довольно сложным.

Что касается реализации, я рекомендую держать функциональные блоки как отдельные объекты, и убедитесь, что вы пишете испытательный стенд для каждого блока. Ваша работа будет быстрее, если вы напишете эти тестовые стенды.

Что касается блоков, файл регистра довольно легко кодировать. Декодер инструкций также прост, если у вас есть четкое представление о макете инструкций и опкодах. И ALU также легко, если вы знаете, какие операции он должен выполнять.

Я бы начал с написания testbenches для декодера команд и файла регистра. Затем я бы написал сценарий, который запускает все тестовые узлы и автоматически проверяет их результаты. Только тогда я бы сосредоточился на реализации самих функциональных блоков.

+0

+1 Вы прибивали мои проблемы :) Я не совсем понимаю ваш ответ, но думал, но это определенный прогресс. Я вижу два автобуса на первой схеме, что я ошибаюсь? Кроме того, кто контролирует последовательное выполнение datapath (CPU?)? И как вы обеспечиваете правильный запуск (сброс?)? Кроме того, есть ли у вас какие-либо рекомендации относительно того, с чего начать сначала? – nha

+0

Отредактировал ответ, чтобы решить эти проблемы (@nha), и, надеюсь, сделать вещи немного яснее – rick

+0

Яснее :) Я могу опубликовать следующий вопрос о фактической реализации. – nha

0

В основном встроенные шины будут использовать параллельные шины для ввода и вывода адресов и данных. Обычно будет какой-то арбитр, который решает, какой компонент разрешен для записи на шину. Таким образом, существует общий подход:

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

Обычно ваша шина на шине использует концепцию «ведущий/ведомый», поэтому только мастера имеют действующий доступ к шине. Ведомые только ждут запросов от ведущего.

Я для одного, как дизайн AMBA AHB/APB, но это может быть немного превыше всего для вашего приложения. Вы можете взглянуть на это book, ища идеи о том, как реализовать свою шину.