Jump to content

    

lexx

Свой
  • Content Count

    217
  • Joined

  • Last visited

Community Reputation

0 Обычный

About lexx

  • Rank
    Местный

Recent Profile Visitors

2280 profile views
  1. Попробуйте обновить 1 бит/байт в слове.
  2. С точки зрения памяти запись наиболее проблемное место. Посмотрите в описании сколько максимально (размер слова) читается/пишется за один запрос памяти, это будет ширина буфера, далее читайте вниз по памяти до заполнения квадрата и потом обратно в память. P.S. расположение картинки может быть как 1D, линейное, так и 2D. По сути также линейное, но размер по ширине ограничивается размером страйда.
  3. Открытая, производительная и без багов. Выберите любые 2. Хорошее никогда бесплатным не будет, это не софт. Из последнего только OpenRisc вылизан, но ему уже более 14-ти лет
  4. Есть разные варианты реализации, как тяжёлые и производительные, так и сверхлегкие, но медленные.
  5. Поправлю сам себя, только что попалось в статье. Вышеуказанная архитектура также возможна (я про интерфейс в внутрь иерархии), называется vertical interface topology, другой вариант - горизонтальная. Для этого нужно прописать дополнительный modport для нижнего уровня и так далее.
  6. Хочется видеть... Но довольно часто этот просто человек, который не понимает что и как он пишет и боится что другой влезет на его территорию и поменяет его код.
  7. Я бы рекомендовал выделить код вида fm_state == чем-то => wire read = fm_state == чем-то. И потом уже его использовать, либо же parameter READ=что-то и потом уже сравнивать fm_state == READ. А так бывает разное, весь код не переделать. Бывает на разное натыкаешься
  8. В SystemVerilog-e есть unique case, который к тому же является assertion. Synosys в своём мануале для синтеза специально акцентирует внимание на то, что использование подобных конструкций может привести к ошибке. RTL Modeling with SystemVerilog For Simulation and Synthesis http://www.sutherland-hdl.com/books_and_guides.html#RTL Book как раз подробно расписывает все возможные варианты, с результатами синтеза.
  9. Какая-то мешанина всего (я про книгу), но в принципе, это можно сказать про большинство книг по теме, хотя бы автор не индус. Как всегда накидали все и обо всем. P.S. всегда удивляет описание про parallel/full case, кто-то еще этим пользуется?
  10. Не согласен, модпорты как раз и есть часть интерфейса, ничего не запрещает клок собрать вместе с логикой, ошибок нет, кроме попыток продолжить использовать порты.
  11. Я не сильно большой знаток, но интерфейс это инкапсуляция уже существующих портов, а не сквозное декларирование и 2е - автор языка даже не упоминает об этой возможности, а он в своей книге по нескольку раз вдоль и поперёк проходит все всем возможным конструкциям.
  12. Да. Немного логики, обязательный FSM с приоритетами по портам. Может немного сложновато для студента, но вполне.
  13. В защиту хантера на позицию интерна: простое задание на FSM, прибыль с него не получить.
  14. Для работы обычно используем CVS, так уж давно сложилось и, в принципе, другого пока не нужно. Но на днях возникла ситуация и некоторые вопросы. Работа ведется над 2я проектами одновременно, кто-то делает в одной части, кто-то в другой части ядра. Планируется использования одинаково ядра с различным окружением. Разделение идёт через глобальный define, ну и немного отличающиеся filelist-ы. Хотелось бы иметь 2 различные ветки проекта с пересекающимся ядром внутри них, чтобы коммит ядра из одного приводил к изменению также и 2го. Возникает вопрос, как это можно организовать, если не CVS, то что? По возможности киньте линк на объяснения.