Как я могу написать большой модуль VHDL и сохранить его читабельным?

Возможно, вам просто нужно использовать редактор, лучше подходящий для чтения больших файлов VHDL. Я регулярно работаю с 3000+ строковыми файлами VHDL, где большая часть пространства занимает логику одного процесса, и у меня нет проблем с их чтением благодаря редактору, поддерживающему свертывание кода.

Я использую Notepad++, но я уверен, что есть и другие редакторы, поддерживающие свертывание синтаксиса VHDL. Когда я открываю файл, я нажимаю alt+0, чтобы свернуть каждую возможную точку синтаксиса, а затем расширить по мере необходимости до той части, над которой я работаю. Вы также можете использовать скрытие строк, чтобы свернуть произвольные части вашего файла, хотя с этим немного сложнее работать.

Если у вас есть большие группы связанных параллельных операторов, вы можете легко сгруппировать их в точку свертывания с помощью name : if true generate, что также позволяет вам объявлять промежуточные сигналы за пределами вашей основной архитектуры (операторы block работают, но не поддерживаются всеми инструментами). ). Чтобы принудительно свернуть точку внутри процесса, я использую if true then.

Если вы проектируете процессор, реализующий различные операции в гигантском операторе case, то на самом деле вы описываете ряд параллельных функциональных блоков, питающих выходной мультиплексор. У вас может быть выход, который управляется, в зависимости от режима операции, выводом либо умножения, сложения, вычитания, некоторой логической операции, сдвига и т. д.

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

AddSub : entity work.AdderSubtractor
port map (
  clk => clk,
  enable => decoded_instruction.addsub_enable,
  a => a,
  b => b,
  mode => decoded_instruction.addsub_mode, -- This might be an enumerated type
  output => addsub_output
);

Были бы другие сигналы _output, и в конце у вас было бы что-то вроде

OutputMux : process (all)
begin
  case decoded_instruction.output_mux_select is
    when ADD_SUB => output <= addsub_output;
    when MULT => output <= mult_output;
    when LOGIC => output <= logic_output;
  end case;
end process;

Одним из преимуществ этого способа является то, что вы можете найти эффективным несколько функций, реализованных в блоке DSP в FPGA; вы можете легко создать функциональный блок для сложения, вычитания, умножения, написанный для целевого блока DSP на вашем устройстве. Выход этого будет просто еще одним входом для вашего «выходного» мультиплексора. По моему опыту, вы должны быть в состоянии эффективно реализовать многие из ваших функций обработки, используя один блок DSP (или один объект, который описывает несколько каскадных блоков DSP, в зависимости от ширины пути данных).

Лично я предпочитаю такой подход, заключающийся в том, чтобы сделать дизайн очень модульным. В недавнем многоядерном проекте DSP у меня есть только пара файлов, содержащих около 500 строк, а в большинстве из них 200 или меньше. Это означает, что когда я возвращаюсь к части дизайна, она обычно умещается на одной странице, и ее можно легко подобрать и понять за очень короткий промежуток времени. Я также обнаружил, что при реализации тяжелой конвейерной обработки для повышения производительности проекта слишком много операций в одном процессе или объекте может на порядок усложнить эту работу.

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

Как говорится, на ваш вопрос трудно ответить. О каком количестве линий идет речь?

Тем не менее, вы можете найти хорошие практики кода VHDL: - следует избегать псевдонимов (не все инструменты даже поддерживают тогда, AFAIK) - дайте сигналам/переменным четкое имя - постарайтесь сгруппировать функциональность - постарайтесь не изменять сигнал/переменную в двух местах, разделенных на 500 строк обычно есть способ - если это действительно необходимо, вы можете рассмотреть возможность использования общих переменных, представленных в VHDL93. (это, однако, не решит вашу проблему с несколькими драйверами) - не забывайте о наличии записей для группировки сигналов

О том, чтобы сделать ваши «промежуточные сигналы видимыми», вы могли бы написать

junk_proc: process(clk, rst) is
variable a,b,c: of_some_types;
begin
if rst then
//do reset stuff
elsif rising_edge(clk)
b:=func1(a);
c:=func2(b);
end if;
end process;

переменные a, b и c (в данном случае простые провода), очевидно, могут быть визуализированы в любом инструменте моделирования.

Однако если вы пишете b=func1(func2(func3(func4(a))))), не забывайте, что вы описываете, что все это происходит за один такт. Учитывая ваше описание, держу пари, вы столкнетесь с проблемами, но, возможно, это хороший способ обучения.