Я пытаюсь реализовать устройство SPI в Verilog. У меня много проблем с координацией ведущего и ведомого, поскольку иногда (с моим текущим внедрением) ведущее устройство SPI не отправляет достаточное количество тактовых импульсов ведомому устройству, чтобы оно могло завершить свою обработку.
Например, это может произойти, если ведомое устройство реализовано так, что его конечный автомат имеет больше состояний, и он перестает получать тактовые импульсы до завершения своего цикла.
Я мог бы изменить свою реализацию, чтобы эти два устройства были скоординированы с точки зрения тактовых импульсов, однако это означает, что главный разработчик должен знать реализацию. детали ведомого (и всех потенциальных ведомых). Мне это вообще не кажется правильным.
Определяет ли протокол SPI, сколько именно импульсов ведущий должен передать подчиненному при отправке, например, одного байта? Если нет, то как любое ведущее устройство SPI совместимо с любым ведомым? Можно ли отправить тонну импульсов (например, 64 импульса на 1 байт) подчиненному устройству на всякий случай?
Мастер SPI не несет ответственности за то, чтобы внутренний конечный автомат ведомого устройства получал «достаточное количество» тактовых импульсов. Все, за что отвечает мастер, — это один тактовый импульс на бит, передаваемый на ведомое устройство или от него — вот и все.
Если вашему подчиненному устройству требуется дополнительное тактирование, то вам решать, как управлять своей реализацией таким образом, чтобы это поддерживалось - возможно, вы указываете какое-то минимальное количество байтов, которые должны быть переданы (даже если некоторые из них являются "фиктивными" байтами), или, может быть, у вас есть для предоставления внешних часов подчиненному устройству в дополнение к часам SPI.
Подчиненный SPI с хорошим поведением должен сбросить свою конечную машину SPI, когда его вход выбора ведомого деактивирован, чтобы все, что мастер делает в одном раунде связи, не обязательно прерывало следующий раунд из-за того, что что-то находится в незавершенном состоянии.
Ответ на любой вопрос о протоколе SPI: протокола SPI не существует! Это простейший из возможных способов передачи последовательных данных, по сути просто сдвиговый регистр. Взгляните на типичный SPI-модуль в микроконтроллере, и вы увидите проблемы, связанные с отсутствием стандарта (например, какой край захватить).
Вам нужен метод, чтобы приемник SPI получал локальные часы и не полагался на источник SPI, предоставляющий часы, чтобы делать что-либо, кроме часов в последовательных данных. Вы можете использовать общие часы SPI для передачи данных, но использовать локальные часы для обслуживания конечного автомата.
SPI не является протоколом в том смысле, который вы имеете в виду.
Это всего лишь интерфейс для автоматической последовательной передачи битов, чаще всего кратных восьми, для передачи байтов между устройствами.
Конечно, это протокол в том смысле, что все стороны должны договориться о том, как отправлять данные, включая такие вещи, как фаза синхронизации, чтобы знать, на каком фронте загружаются данные и какова полярность холостого хода.
Кроме того, устройства должны использовать протокол битов или байтов, чтобы знать, что означают биты и байты.
По сути, если вашему приемнику SPI требуется определенное количество битов, то передатчик SPI должен передавать это количество битов, не больше и не меньше. Вам решать, что содержат эти биты и как работает ваш приемник SPI, если правильное количество битов не передается.
Реакция подчиненного устройства на передачу MOSI полностью зависит от вас, поскольку вы разрабатываете поведение подчиненного устройства.
Если передача является единственным временем (когда кадр активен), для ответа ведомого устройства оно либо должно настроить свое поведение, чтобы закончить во время кадра, либо оно должно реализовать и описать это поведение, чтобы мастер, использующий эту возможность, синхронизировался. Данные MOSI достаточно длинные (данные-заполнители), чтобы позволить ведомому устройству завершиться.
В этом суть.
Пример того, где я видел это, находится в части Microsemi SmartFusion 2 (MS2090):
На самом деле это не так уж странно или необычно. Microsemi M2S090 имеет аналогичное состояние при опросе файлов HW_STATUS
. MOSI отправляет 0xFF
, и во время тактирования команды данные MISO содержат ответ. В том же кадре во время тактирования команда MOSI не после 0xFF
тактирования подчиненному.
Сравните отличие с другими командами, где после синхронизации полезной нагрузки MOSI мастер сохраняет кадр активным, синхронизирует больше данных MOSI, чтобы ведомое устройство могло ответить на какое-то требование. Мастер — это то, что поддерживает активность фрейма, и, пока он активен, он поддерживает работу часов.
Это ваш дизайн и, следовательно, ваши требования.
Что я сделал для сравнения, так это запустил несколько плат Arduino M/S и оценил поведение. Я использовал этот сценарий, чтобы проверить ожидание реакции ведомого устройства на команду/данные MOSI.
РЕДАКТИРОВАТЬ: Если подумать, это не полностью зависит от вас. На самом деле существуют стандарты, вокруг которых строятся сторонние поставщики. Если вы полностью уверены, что ваш огороженный сад использования FPGA и SPI изолирован, делайте, что хотите. Но если какое-либо стороннее устройство предназначено для подключения и обмена данными с вашим мастером , необходимо позаботиться о поведении мастера во время передачи SPI. (Я имею в виду Mode, и есть статьи в Википедии и т. Д. Об этом, а также в вашем описании вашего кремния было бы еще лучше посмотреть).
Джей
Мартель
Джей
Сидящий ястреб
Майкл
илккачу