Pull to refresh

Comments 14

 сейчас шина у нас всегда подключена в одно место, никакой конкуренции нет. 

Не могли бы Вы как-то объяснить эту фразу?

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

Не могу понять что Вы называете конвейером.

Картинка с паровозиком отличная.

Само ядро весит примерно 700 LE, регистры ещё около 1000. Можно сделать, например, 4 копии ядра, но доступ к памяти предоставить через 2 шины, потому что всё равно сильно не нагрузят. Каким ядрам надо, те и обращаются, остальные ждут освобождения места при необходимости.

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

Наконец-то понял. Конвейер это Вы про будущий конвейерный вариант процессорного ядра. "Сделать до конвейера" это добавить расширение "М" в текущий вариант процессорного ядра.

Всё верно. Потом путаница начнётся, вроде смотришь симуляцию, данные правильные, а результат странный, потому что надо мысленно графики сдвигать в разные стороны. Именование переменных частично помогает с этим справиться.

доступ к памяти предоставить через 2 шины

То, что у Вас сейчас шина "подключена в одно место " не означает отсутствие конфликта. В Вашем тестовом окружении уже есть конфликт доступа к памяти между шиной команд и шиной данных.

На практике они между собой не пересекаются, а даже если бы пересеклись, это не привело бы к блокировке доступа. С текущей конфигурацией памяти без кэша даже fence.i не понадобится. Насчёт того что экономия шин на несколько ядер не даст большого эффекта, потому что шина инструкций нужна всегда - это идея, тут надо подумать.

Смешно, картинка (КДПВ) содержит надпись Risk V. Это намекает, что реализация отличается от RISC V или художественное обыгрывание рисков нового проекта?

Здесь скорее всего риск, спроектированный с помощью ИИ. :)

Да я под конец заметил, когда уже залил. Вот так по ночам статьи писать.

Починил. Думаю над логотипом проца.

Несколько лет назад на волне увлечения Плис сделал 8080. Делал с умом, как мне казалось, находил закономерности в кодах и навешивал общую логику. А в результате использовалось элементов в несколько раз больше чем в оригинальном проце. Как они это сделали? Не понимаю...

В железе можно делать хаки, которые запрещены в плис, например, подключить несколько транзисторов по схеме с открытым коллектором. В плис для этого придётся or лепить. Поскольку входов у ячейки 4-6 штук, для проверки на ноль 32-битного регистра эти входы надо цеплять каскадом.

Раньше экономили общее количество логических элементов, убивая сразу еще двух зайцев - снижается энергопотребление и увеличивается быстродействие за счет времени проектирования. Задача почти творческая, но ручная - находить в булевых таблицах логики общие группы и объединять элементы, меняя И-ИЛИ-НЕ. Кажется, называлось склеивание, или карты Карно. Сейчас это проще отдать компьютеру на оптимизацию, все равно такое количество элементов нереально охватить за отведенное время.

Карты Карно один из методов минимизации. Карты Карно, метод Куайна, теорема ДеМоргана для преобразования из И в ИЛИ и наоборот. Едва ли эти методы можно вообще применить для ручной оптимизации в том же квартусе, особенно с учетом того что квартус сам умеет минимизировать. Разве что если рисовать схему вместо верилога.

Быстродействие больше зависит от максимальной длины цепочки логических элементов.

Sign up to leave a comment.

Articles