Я думаю, что ваш босс подразумевает под «программной логикой», что ваш стиль кодирования требует, чтобы дизайнер думал последовательно. Другими словами, когда я читаю ваш блок always, я сначала должен подумать обо всех значениях, инициализируемых до их значений по умолчанию, а затем я должен оценить логику регистра. В действительности логика будет синтезироваться в эквиваленте default случая. Это вызывает несоответствие между логикой, которая представляет RTL, и логикой того, как я оцениваю ваше выражение в уме. Если вы знаете, что делаете, то это будет нормально большую часть времени . Но вы работаете в компании, поэтому ваш код должен учитывать других инженеров, работающих над проектом. Каждая отдельная команда в процессе проектирования будет рассматривать одну и ту же логику через потенциально разные объективы (например, физическая команда разработчиков не занимается Verilog, а синтезирует RTL). Если мы напишем наш Verilog, чтобы отразить окончательный RTL (т. Е. «Аппаратная логика»), то каждый анализирует логику подобным образом. Если я смотрю на выход в цепи и знаю все значения входов на заданном временном шаге, то я могу визуально проследить выход через схему и определить его значение, не обращая внимания на другую логику. Ваш код Verilog должен быть написан таким же образом.
Подводя итог, ваши операторы инициализации являются не чем иным, как другим случаем в мультиплексоре выбора в RTL. Итак, вы должны написать это так. Используйте регистр default и явно назначайте каждый выход блока в каждом случае. Это обычно считается лучшей практикой. Возможно, это не самый умный или изящный способ написания Verilog, но он является наиболее читабельным и приводит к гораздо меньшему количеству ошибок (а в промышленности люди больше озабочены проверкой проекта, чтобы снизить затраты, чем умением Verilog).
Кроме того, как вырастил @ dave_59, если вы используете директиву full_case Synopsis, то она создаст для вас драйверы вывода по умолчанию, где для выходов установлено значение "все равно". Это не тот результат, которого хочет кто-либо, и он будет отмечен командой проверки. Чтобы это исправить, вам нужно убедиться, что каждому выходу назначается, добавив их во все случаи, как упомянул ваш начальник. Если вы все равно вынуждены это сделать, то full_case является избыточным, потому что вы явно сделали заявление case полным. Что касается более старых инструментов синтеза, я не считаю, что это является большой проблемой для этого конкретного предмета, но это соображение, которое всегда дается в промышленности. Проблема может возникнуть в том случае, если ваша компания настроила нижестоящие инструменты для принудительного использования старых конструкций в целях сокращения затрат на проверку.
Доверьтесь опыту вашего менеджера по этому вопросу. На стиль кодирования в промышленности в значительной степени влияет сотрудничество с другими инженерами, затраты и наследство, а не технические детали. Вот где опыт вашего менеджера будет ценным.