[SM 0]

Каждому разработчику нагляднее/понятнее то описание/программа, которое максимально близко подходит под собственные "стандарты" написания кода/программы

Это бесспорно, субъективный фактор тут имеет большое значение. Но есть и объективные, как например:

 

чем больше информации влезет в поле зрения без перелистывания, тем нагляднее видно, как это работает

 

Самым точным сообщением является сообщение минимальной длины. (следовательно, не минимальная длина порождает неточности, в том числе, и в восприятии).

[Maverick_ 15]

Самым точным сообщением является сообщение минимальной длины.

НУ, это уже стало аксиомой в мире программирования, что хорошим стилем программирования является написание программы/функции, которая помещается на один экран

 

К этому необходимо стремиться по возможности...

[Krys 2]

утверждаю что такой кусок кода

wire SignalToModul1
wire SignalToModul2
wire SignalToModul3   
wire Module4OutputBus;
assign {SignalToModul1, SignalToModul2, SignalToModul3} = Module4OutputBus;
Module4 Mod_inst (.out(Module4OutputBus));

в сто раз нагляднее чем

Module4 Mod_inst (.out({sig1, new_sig, new_newSig_3}));

А вот я утверждаю обратное. В последнем случае всё очевидно из одной строчки. Для первого случая необходимо ещё дополнительно напрячь мозги и поднять глаза выше, разобравшись ещё с одной строчкой. А теперь представим себе, что портмаппинг длинный, и в экран не влазит - нужно пролистывать и искать, откуда же растут ноги. А так всё в одном месте. Не надо лишних сущностей.

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

 

 

 

Важно не число строк, а структура кода,

А вот с этим согласен. Поэтому я обычно не пишу портмаппинг в одну строчку - слишком сложно парсить глазами ))) Я бы записал у себя в коде так:

Module4 Mod_inst (
    .out({sig1, new_sig, new_newSig_3})
);

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

[egorman44 0]

Недавно читал книгу, так в ней сказано, что не стоит экономить на строках повышающих понимаемость кода, это влечет к потере $3.48 при заработной плате в $100.000 в год .

 

There is no economic reason to reduce the number of lines of code. Unless, of course, it also improves the maintainability. Saving one line of code, with an average of 50 characters per line, saves only 50 bytes on the storage medium. With 10Gb hard drives costing less than $300 today, this represents a savings of $28x10-9. The time saved in typing, assuming an extremely slow typing speed of one character per second and a loaded labor rate for an engineer at $100,000 a year, amounts to $0.69. However, if saving that line reduces the understandability of the code where it will require an additional 5 minutes to figure out its operation, the additional cost incurred amounts to $4.17. The total loss from reducing code by 1 line equals $3.48. And that is for a single line, and a single instance of maintenance.

 

 

[Krys 2]

Дак это обычное "не надо на спичках экономить". Аналогично в российских компаниях зачастую экономят на мощности компа у разработчика: то памяти крохи, то монитора 2 не покупают и т.п. Хотя эти разовые траты по сравнению с его годовой зарплатой - сущие копейки. Предприятие готово платить немалые деньги в качестве зарплаты разработчику, но неготово оплатить ему нормальный инструмент по цене существенно ниже этих немалых денег на зарплату. Так вот и сидим при хорошей зарплате и на говёном железе и про себя подумываем: может мне самому уже купить на свою хорошую зп недостающее и на этом работать? )))

[SM 0]

это влечет к потере $3.48 при заработной плате в $100.000 в год .

Если внимательно читать, то это на одну строку кода в одном модуле. Если помножить - будет неслабо. Однако, там очень серьезный "IF" есть! - "if saving that line reduces the understandability of the code " - а мы тут ведем речь про устранение всякого мусора, затрудняющего понимание, но никак, например, не уменьшение комментирования, где оно необходимо. При этом, оно оказывается спорным - кому-то оно затрудняет понимание, кому-то, наоборот, улучшает. Таким образом получается, что к этому if надо приписать еще и "else if that improves the understandability" - что коренным образом исправит эту статистику. При примерном равенстве тех и этих, получим экономию. А кого больше - неизвестно. А уж про экономию нервов, я вообще молчу. Это самое написание "мусора", вызванное некой необходимостью (не важно какой, языком HDL, как таковым, или требованием "дяди" о стиле), равно как и чтение с отсеиванием этого мусора, есть неслабый стресс.

[sidy 1]

У меня еще вопрос как по перепаду выскочастотного клока зафиксировать перепад низкочастотного клока? Или то что при ВЧ импульсе n-1 НЧ сигнал был 0, а при ВЧ импульсе n НЧ сигнал стал 1.

[Golikov 0]

reg l_clk_reg = 0;
always @(posedge h_clk)
begin
   l_clk_reg <= l_clk;
   if((l_clk == 1'b1)&&(l_clk_reg == 1'b0)) //вот оно!
       ....
end

 

ну и хорошим тоном будет l_clk пропустить еще через пару триггеров до этого

 

типа

 

reg l_clk_reg1 = 0;
reg l_clk_reg2 = 0;
reg l_clk_reg3 = 0;
always @(posedge h_clk)
begin
   l_clk_reg3 <=  l_clk_reg2;
   l_clk_reg2 <=  l_clk_reg1;
   l_clk_reg1 <=  l_clk;
   if((l_clk_reg3 == 1'b1)&&(l_clk_reg2 == 1'b0)) //вот оно!
       ....
end

 

ну и можно упростить

if(l_clk_reg3 & (~l_clk_reg2))

 

[egorman44 0]

У меня еще вопрос как по перепаду выскочастотного клока зафиксировать перепад низкочастотного клока? Или то что при ВЧ импульсе n-1 НЧ сигнал был 0, а при ВЧ импульсе n НЧ сигнал стал 1.

 

reg [2:0]    low_freq_pipe;

always @(posedge high_freq_clk) begin
       low_freq_pipe <= {low_freq_pipe[1:0],low_freq_clk};
end

wire low_freq_rise_edge =  !low_freq_pipe[2] & low_freq_pipe[1];
wire low_freq_fall_edge =   low_freq_pipe[2] &!low_freq_pipe[1];

[SM 0]

ну и можно упростить

и еще упростить

 

reg [2:0] rise_detect_sh_reg;

 

always @(posedge high_clk)

rise_detect_sh_reg <= {rise_detect_sh_reg[1:0], low_clk};

 

wire low_clk_rise = (rise_detect_sh_reg[2:1] == 2'b01);

 

-------

упс. меня обогнали :)

[Krys 2]

Здравствуйте. Подскажите, пожалуйста: синтезатор Xilinx даёт ошибку:

System functions/tasks may not be used in a constant function

Функция такая:

function clog2ge1;
input x;
    clog2ge1 = ($clog2(x) < 1) ? 1 : $clog2(x);
endfunction

Какими рациональными причинами можно объяснить такое ограничение? И как его обойти?