11 / 37 · Теория
Шифратор и приоритет: выбор одного из нескольких запросов
Различайте предположение one-hot обычного шифратора и сигналы valid и результата приоритетного шифратора.
Уроки доступны бесплатно. Запишитесь, чтобы сохранять прогресс.
Обратное преобразование тоже требует условий
ДешифраторДешифратор активирует выходную линию, соответствующую двоичному коду. При наличии enable неактивное разрешение может устанавливать все выходы в 0. Подробнее превращает адрес в линии выбора one-hotOne-hot — представление, в котором ровно один бит равен 1. Если допускаются также все нули, это отдельно называют one-hot-or-zero. Подробнее. Шифратор преобразует позицию активного входа в адрес. Но обычный one-hot-шифратор предполагает, что включён только один вход. Для нескольких единиц нужна дополнительная спецификация выбора позиции.
Для четырёх запросов зададим приоритет большего номера. При всех нулях valid=0, index=00. Определять отсутствие запроса только по index=00 нельзя: это также индекс r0.
| Вход r3r2r1r0 | valid | index |
|---|---|---|
| 1--- | 1 | 11 |
| 01-- | 1 | 10 |
| 001- | 1 | 01 |
| 0001 | 1 | 00 |
| 0000 | 0 | 00 |
Знак - означает одинаковый результат и для 0, и для 1. Он не разрешает подавать симуляционное X. Шаблоны сверху вниз определены как взаимно исключающие.
При 1011 index=11. При 0110 r2 приоритетнее r1, поэтому index=10.
Показать данные диаграммы
| Сигнал | Диаграмма | Значения шины |
|---|---|---|
| запросы | 234523 | 0000 → 0001 → 0011 → 0110 → 1011 → 1000 |
| valid | 01.... | |
| index | 2.345. | 00 → 01 → 10 → 11 |
RTL должен явно показывать приоритет
always_comb begin
valid = |request;
index = 2'b00;
if (request[3]) index = 2'd3;
else if (request[2]) index = 2'd2;
else if (request[1]) index = 2'd1;
endЕсли единица только в request[0], остаётся index=0 по умолчанию, valid=1. Значения по умолчанию для всех путей не дают комбинационной схеме приобрести память. Проверяя 16 входов, при valid=1 убедитесь: выбранный бит равен 1, а все биты выше него — 0.
Выбор и справедливость — разные задачи
Если r3 постоянно равен 1, r0 никогда не выбирается. Эта схема реализует только фиксированный приоритет. Для справедливого обслуживания нужен арбитраж с памятью предыдущего выбора, то есть последовательностная схема.
Практикум · наблюдайте запрос, адрес и grant вместе
r3r2r1r0=1011; valid=1; index=11; grant=1000. Приоритет выше у запросов с большим номером. При valid=0 index не указывает выбранный запрос.
В начальном запросе 1011 выбирается r3. Выключите r3: выбирается r1, index=01, grant=0010. Пока r1=1, включение и выключение r0 не должно менять выбор.
Сравните «Выключить все» с включённым только r0. В обоих случаях index=00, но valid и grant различаются. Если следующий блок читает лишь index, он может обработать несуществующий запрос.
Grant с единицей только у выбранного запроса получается повторным декодированием index и valid.
Проверяйте три инварианта: в grant не более одной единицы; на её позиции действительно есть запрос; все запросы с номером выше выбранного равны 0. Упражнение не потребляет запросы и не хранит предыдущий выбор. Ожидание младших запросов при постоянно включённом r3 — свойство фиксированного приоритета.
Попробуйте сами
Укажите index, valid и grant для запросов 0101 и 0001. Почему нельзя обрабатывать r0 при запросе 0000 лишь потому, что index=00?
Прочитать объяснение
Для 0101: index=10, valid=1, grant=0100. Для 0001: index=00, valid=1, grant=0001. При 0000 index=00 — лишь значение по умолчанию; valid=0 и grant=0000 означают отсутствие запроса.