Chisel3: Как получить файлы verilog, cpp и vcd одновременно

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

После работы с учебными пособиями по Chisel я лучше понял, как все работает в chisel . В обучающих программах все организовано таким образом, чтобы упростить работу для начинающих (я полагаю, что это цель обучающих программ!).

Теперь я хочу перейти к следующей части, где я хотел бы разработать свои собственные небольшие проекты и немного больше погрузиться в то, как работает chisel (создание verilog, cpp, vcd), скажем, из простого файла Mux4.scala в chisel. (Я беру правильную версию кода модуля Mux4 и тестера из здесь) . Я просто добавил следующие строки в конец Mux4.scala

object Mux4Driver extends App {
  chisel3.Driver.execute(args, () => new Mux4(32))
} 

чтобы получить код Verilog напрямую.

Я поместил файл scala в src/main/scala/, а тестер в src/test/scala/.

Вот где у меня проблемы. Как указал jkoenig, я могу запустить свой код, используя команду sbt "run-main Mux4Driver" в корневом каталоге. При этом я получаю три файла _7 _, _ 8_, Mux4.anno.

  1. Но как я могу получить различные файлы (снимок экрана ниже), которые я получил с помощью

    TESTER_BACKENDS=verilator ./run-examples.sh GCD

когда я реализую свой собственный модуль (я понимаю, что могу передать файл verilog через верилятор, чтобы получить файлы cpp, но есть ли какой-нибудь изящный способ получить все файлы сразу, как в учебниках [Должен быть способ, но я просто не мог разобраться])  введите описание изображения здесь

(Я использую шаблон chisel для своего проекта).

  1. Я понимаю, что после написания модулей кажется, что для успешного запуска вашего кода и создания необходимых файлов требуется знание sbt. Я хотел бы понять, как я могу использовать sbt для организации своих проектов, как в учебных пособиях по chisel, и запускать их с помощью одной команды (например, ./run-examples.sh mymodule).

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

Изменить:

При тестировании команд, упомянутых в ответе ниже, я получил следующие ошибки:

введите описание изображения здесь

И когда я попробую --help, мои варианты отличаются от тех, что вы предложили. При сопоставлении моего --help вывода с выводом здесь Я обнаружил, что в моем выводе нет параметров тестера.

введите описание изображения здесь

Это проблема с версией Chisel (использующей Chisel3) или sbt, которую я использую?


person Abhishek Tyagi    schedule 19.09.2017    source источник


Ответы (1)


Это исправлено в связи с изменениями вопроса.

chisel-template repo является разумным примером того, как организовать дальнейшую разработку. Но, исходя из вашего вопроса, я бы порекомендовал вам использовать один из двух разных методов вызова модульных тестов.

class GCDTester extends ChiselFlatSpec {
  "GCD" should "calculate proper greatest common denominator" in {
    iotesters.Driver.execute(Array(), () => new GCD) {
      c => new GCDUnitTester(c)
    } should be (true)
  }
}

or

object GCDMain extends App {
  iotesters.Driver.execute(args, () => new GCD) {
    c => new GCDUnitTester(c)
  }
}

Одно важное отличие от кода в вашем вопросе заключается в том, что указанный выше драйвер - chisel3.iotesters.Driver, а не chisel3.Driver. Вы можете использовать аргументы командной строки с любым из них, например: Добавьте --help к таким аргументам, как

iotesters.Driver.execute(Array("--help"), () => new GCD) {

и запустите свой тест или запустите main из второго примера:

sbt 'runMain examples.GCDMain --help'

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

  -tbn, --backend-name <firrtl|verilator|vcs>
                           backend to use with tester, default is firrtl

и возможно

  -fiwv, --fint-write-vcd  writes vcd execution log, filename will be base on top

Вы можете добавить любой из этих аргументов точно так же, как вы добавили --help. Итак, чтобы запустить верилятор

iotesters.Driver.execute(Array("--backend-name", "verilator"), () => new GCD) {

и запустите свой тест или запустите main из второго примера:

sbt 'runMain examples.GCDMain --backend-name verilator'

Chisel.Driver поддерживает только подмножество опций iotesters.Driver и не включает верилятор.

Чтобы получить все нужные файлы, необходимо запустить имитацию схемы, для чего потребуется какое-то тестовое оборудование. iotesters.Driver.execute вызовет вашу тестовую программу, которая создаст интересующие вас файлы (при запуске с --backend-name verilator). Chisel.Driver.execute только разрабатывает схему, но не запускает симуляцию.

Примечание. Хотя параметр --fint-write-vcd предназначен только для получения выходного файла VCD при использовании интерпретатора, я полагаю, что по умолчанию используется выход vcd серверной части верилятора.

person Chick Markley    schedule 19.09.2017
comment
оооо, я видел эти параметры командной строки раньше, но не мог связать их здесь. Я их опробую. Любые комментарии о том, как организовать проекты, такие как chisel-tutorials (используя что-то вроде run-example.sh), или не ясно, о чем я спрашиваю (я тоже так считаю)? - person Abhishek Tyagi; 19.09.2017
comment
Я не думаю, что есть однозначный ответ. По большей части одиночные модульные тесты обычно запускаются с помощью тестовой системы. И по мере того, как вы начинаете составлять модули в более сложные схемы, большинство людей начинает создавать сценарии, которые управляют своим конкретным потоком. Это во многом зависит от целевой среды. - person Chick Markley; 20.09.2017
comment
Я отредактировал вопрос после выполнения вышеуказанных команд (не смог включить вывод в комментарии. Приносим извинения, если это не способ сделать это). Пожалуйста, посмотрите - person Abhishek Tyagi; 20.09.2017