SM 0 28 января, 2015 Опубликовано 28 января, 2015 · Жалоба Каждому разработчику нагляднее/понятнее то описание/программа, которое максимально близко подходит под собственные "стандарты" написания кода/программы Это бесспорно, субъективный фактор тут имеет большое значение. Но есть и объективные, как например: чем больше информации влезет в поле зрения без перелистывания, тем нагляднее видно, как это работает Самым точным сообщением является сообщение минимальной длины. (следовательно, не минимальная длина порождает неточности, в том числе, и в восприятии). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Maverick_ 15 28 января, 2015 Опубликовано 28 января, 2015 · Жалоба Самым точным сообщением является сообщение минимальной длины. НУ, это уже стало аксиомой в мире программирования, что хорошим стилем программирования является написание программы/функции, которая помещается на один экран К этому необходимо стремиться по возможности... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Krys 2 28 января, 2015 Опубликовано 28 января, 2015 · Жалоба утверждаю что такой кусок кода 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 29 января, 2015 Опубликовано 29 января, 2015 · Жалоба Недавно читал книгу, так в ней сказано, что не стоит экономить на строках повышающих понимаемость кода, это влечет к потере $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 30 января, 2015 Опубликовано 30 января, 2015 · Жалоба Дак это обычное "не надо на спичках экономить". Аналогично в российских компаниях зачастую экономят на мощности компа у разработчика: то памяти крохи, то монитора 2 не покупают и т.п. Хотя эти разовые траты по сравнению с его годовой зарплатой - сущие копейки. Предприятие готово платить немалые деньги в качестве зарплаты разработчику, но неготово оплатить ему нормальный инструмент по цене существенно ниже этих немалых денег на зарплату. Так вот и сидим при хорошей зарплате и на говёном железе и про себя подумываем: может мне самому уже купить на свою хорошую зп недостающее и на этом работать? ))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SM 0 30 января, 2015 Опубликовано 30 января, 2015 · Жалоба это влечет к потере $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 11 февраля, 2015 Опубликовано 11 февраля, 2015 · Жалоба У меня еще вопрос как по перепаду выскочастотного клока зафиксировать перепад низкочастотного клока? Или то что при ВЧ импульсе n-1 НЧ сигнал был 0, а при ВЧ импульсе n НЧ сигнал стал 1. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 11 февраля, 2015 Опубликовано 11 февраля, 2015 · Жалоба 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 11 февраля, 2015 Опубликовано 11 февраля, 2015 · Жалоба У меня еще вопрос как по перепаду выскочастотного клока зафиксировать перепад низкочастотного клока? Или то что при ВЧ импульсе 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 11 февраля, 2015 Опубликовано 11 февраля, 2015 · Жалоба ну и можно упростить и еще упростить 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 6 августа, 2015 Опубликовано 6 августа, 2015 · Жалоба Здравствуйте. Подскажите, пожалуйста: синтезатор Xilinx даёт ошибку: System functions/tasks may not be used in a constant function Функция такая: function clog2ge1; input x; clog2ge1 = ($clog2(x) < 1) ? 1 : $clog2(x); endfunction Какими рациональными причинами можно объяснить такое ограничение? И как его обойти? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться