one_eight_seven

Именно. Вопрос в том, зачем им выдают диплом инженеров?

Ну если у вас связь с реальностью неразрывна в момент, когда вы пишете следующие взаимоисключающие параграфы: То пожалуйста, считайте как вам больше нравится. Тем более, что требования ГОСТ 2.316-2008 настолько легко и быстро выполнимы (да и при этом не несут никакого вреда), что сам смысл спора с нормоконтроллером, а тем более с коллегами на форуме, исчезающе мал.

Vim, правда, я не знаю, что значит «прикрутить на ALT+F4», и не могу сказать, подойдёт ли по этому критерию

Ну, в нём явно написано. Что он относится и к схемам тоже. А есть какие-то проблемы? Я просто все чертежи выполнял в одном стиле - ТТ писал над основной надписью, между текстом и основной надписью не вставлял никакую графику, поэтому, не представляю, что может быть не так у вас с вашим нормоконтролем в этом плане.

Зачем вы мучаетесь сами и мучаете других подобным стилем кодирования? Разве не проще что-то вроде: always @(posedge clk or negedge async_rst_n) begin : sequential_code if (!async_rst_n) state <= { WIDTH {1'b0}}; else state <= nextstate; end always @* begin : comb_block nextstate = state; // store current state for loopbacks case (state) STATE0 : begin if (go_state_1) nextstate = STATE1; else if (go_state_2) nextstate = STATE2; ... end ... endcase end

Хоть я и не тот ваш собеседник, но пример привести могу: http://npofizika.ru/production/adc_dac/adc Конкретнее: Скорость выборки: 32 kS, Скорость выборки: 20 kS. Как-то это не сочетается со словами "Физика" (в названии компании) и "наука", упоминаемое вами. Согласитесь, что не хватает производной по времени. Вроде всем понятно, о чём речь, но отношение к вашей продукции уже испорчено, и отношение вашей компании к результатам вашего труда и к пользователям - налицо.

Попробовал iverilog 10 на fedora 25. Запустилось и заработало сразу без плясок с бубном, также очень понравилось сочетание Vim+Syntastic+Verilator. Хотя в syntastic есть проверка синтаксиса для iverilog, но она без плясок с бубном не работает, а при имеющемся Verilator мне и не нужна. Пока всё, что было написано, скомпилировалось без проблем. Что касается сравнения с другими симуляторами, то тут могу сравнивать только с Synopsys VCS. Конечно, iverilog уступает по всем статьям, кроме доступности: Я, к сожалению, не настолько богат, чтобы купить себе домой лицензию VCS. Поэтому, дома приходится пользоваться сильно простенькими тестбенчами. Правда, я ещё не пробовал тестбенчи на systemverilog с интерфейсами, SVA и т.п. Если бы дома был VCS, то к iverilog'у я бы и не притронулся, а так - притронулся и мне понравилось. Что радует - разработчик iverilog совершенно не против патчей, которые добавляют функционал SystemVerilog в iverilog. Если будет прогресс, то можно будет подумать над использованием OpenVera.

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

Во-первых, они позволяют создавать массивы, длина которых вычисляется во время выполнения программы, а не во время компиляции. И во-вторых: в С11 есть _Thread_local

Conan, этот метод стандартный для C89. Если на момент вызова функции, которая должна только заполнить буфер, размер буфера уже известен, а у вас в пункте 1 так, то с этим в C99/С11 прекрасно справляется автоматическая модель памяти, нет нужды рисковать с использованием ручного управления памятью. Я понимаю, что лучший инструмент - это не тот, который лучше, а тот, который вы знаете, и это нормально. Но советовать такое в 2017 - это ретроградство, и даже немножко вредительство, насколько мне изветсно, даже Будда терял самообладание, когда ему приходилось пользоваться malloc'ом. По пункту 2. Врапперы вокруг free и malloc полностью поддерживаю там, где без malloc и free не обойтись. Но в полседнее время мало встречаю необходимости в malloc. А вот free нужна гораздо чаще. Как по мне, malloc нужен там, где потом будет использоваться realloc, но, повторюсь, нужды в этом сейчас куда меньше, чем об этом написано в книжках 80-х и 90-х годов. P.S. Не знаком с WinApi, но Win в начале позволяет говорить о том, что это microsoft'овское, а у них компилятор не поддерживает C99/C11. По крайней мере, отказ о поддержке этих стандартов языка был официально объявлен, когда я последний раз рассматривал возможность прикоснуться к Visual Studio.

Откровенно странный способ, ваш компилятор не поддерживает С11 или C99?

http://lmgtfy.com/?q=d+flip-flop+verilog

Так они и отделены. Извините, но не вижу гибкости в: в отличие от возможности ввести в поле при внесении в базу данных как 2200, 2200 пФ, 2200pF, 2n2, что приведётся во внутренний формат БД, а уж в отчёт (как и в поля компонента в САПР) потом можно выводить как хочешь. Но тут каждый решает сам, исходя из того, где у него больше ошибок - при разборе ввода машиной, либо при вводе новых компонентов людьми. У меня люди больше ошибались, в т.ч. и я сам.

Странно. Я считал, что для электронных таблиц это куда удобнее делается приведением к одному базису (например, к пикофарадам), а нанофарады, пикофарады, микрофарады и т.д., в общем, всё для вывода "отчётов" из этого получаются условным форматированием. (В общем-то, я и сейчас так считаю).

Аналогично. Кстати, практическую целесообразность не с позиции руководителя видно не всегда. Будучи инженером, писал скрипты, чтобы "отчетики" автоматически генерировались всё более и более отвечающими ГОСТовским требованиям. Потому что была практическая целесообразность "Это требование сертифицирующих органов". Так обосновывали те, кто отвечал за нормоконтроль и сертификацию. А когда стал начальником, то общался со многими сертифицирующими органами напрямую, и был приятно удивлён, что им на это плевать, и что они прекрасно осознают, что в их зоне ответственности, а что нет. После чего написание скриптов было заморожено на той стадии, где было, а дальнейшие интерпретации нормоконтроля были возложены на них же, в виде обязанности автоматизировать вывод документации в соответствии с их же требованиями. Но на момент заморозки вывелось бы как 2200 на схеме, 2200 пФ в перечне элементов, в ВП и спецификации выводил либо только Part Number и производителя для критичных компонентов, либо, если компонент не критичный, то к этому добавлялись параметры компонента, и тогда там тоже было 2200 пФ.

А вот воспринимать информацию - далеко не каждый, и вам бы стоило поработать над этим, а не на форуме выделываться. Да, конечно по-другому. Вот как вы написали: Это совсем другое. Взрывозащита, особенно для портативных приборов - это жизни людей. Из-за вашего неумения читать и писать могут одни люди погибнуть, а другие сесть. Так что это не "придирки к словам", как вы изволили ляпнуть, а конкретизация. Виды взрывозащиты не ограничиваются типом взрывозащиты d - Взрывонепроницаемая оболочка (кстати, она может быть и тоненькой сеткой). Имеются и другие, например, герметизация компаундом, кварцевое заполнение оболочки и другие. Но открытые контакты во взрывоопасной среде могут быть только при использовании вида взрывозащиты "искробезопасная электрическая цепь".

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

Портативное устройство тоже находится вне зоны, когда к нему подключено ЗУ. Существуют, но это противоречит первой цитате. Это возможно, когда всё устройство полностью соответствует виду взрывозащиты "искробезопасная электрическая цепь", включая зарядные цепи и выходные цепи зарядного устройства.

Может быть. Однако, на мой взгляд, ключевое в моём посте - это то, что я на другой стороне. Это мне приходилось отвечать за провалы других людей, и я знаю, в каком случае провалов случается меньше. Вот вы и Бэкенд, когда берёте работу, как фрилансер, отдаете на аутсорс и отвечаете за результат, или делаете сами? Настолько внутренний, что аж наружу выходит, для него даже разъёмы есть.

Я и не знаю, как вы так протирали штаны в ВУЗе... Есть стандартные операции со штатными сотрудниками, в т.ч. касающиеся допуска к конфиденциальной информации, тестирования, и т.п. Контроллируемые. А вы предлагаете отдавать это непойми кому. То есть, прибавить ещё достаточно много вещей по контролю. Хорошо справляющийся со своей работой внешний исполнитель - это исключение из правил, если нужно что-то сложнее, чем соединить два устройства по стандартному интерфейсу (и-то если не нужно при этом ещё и ПО). В общем-то в офисе то же самое, только процесс обучения контроллируемый. Как и про то, что офисный инженер работает 40 часов в неделю и ничуть не больше. Да, таких большинство, как и бестолочей среди фрилансеров, а те, которые исключения - они тоже, после ухода из офиса не перестают работать, и часто с решением проблемы приходят из дома после выходных или после отпуска. Если попадается фрилансер с таким отношением - это хорошо, с таким и решают проблемы допуска к конфиденциальной информации, и т.п. (И да, такого сразу же захочется получить в штат). Но, повторюсь - их абсолютное меньшинство. А с основной массой лучше работать в офисе, именно по той причине, что указано в цитате вашего поста - и так есть, чем заняться

Такое ощущение, что молод вы ещё и горяч. Чтобы принимать работы у фрилансеров, контроллировать промежуточные результаты, нужен не менее квалифицированный (а чаще - более квалифицированный) инженер, у которого, например, на то, чтобы самому делать проекты либо нет времени, либо уже нет желания. Да и множество других задач. А такого не появится со стороны. Ну и чисто для интереса, приборы-то есть у вас, чтобы контроллировать PCI-E, или хотя бы ethernet?

1. Не всегда нужен наспех сделанный проект. Иногда его нужно ещё и поддерживать. Нередко нужен свой специалист в штат, который будет решать не только вопросы текущего проекта. 2. Результат работы фрилансеров часто удручающий. 3. То, о чём вы говорите, имеет место быть, но редко. Чаще вот так: http://pikabu.ru/story/frilanser_4608849

Они и не смогли, зато у нас появилась бумажка, которая затыкает громкие рты "на раз-два". Есть у монтажников компы. Однако, технолог готовит производство в бумажниевом виде, отмечая цветами позиции одинаковых элементов, и, если необходимо, разбивает на этапы первые образцы (например, сначала питание, потом после того, как провирили работоспособность - интерфейсы, и т.д.). Но для этого они предпочитают либо простой Assembly вывод из AD, либо, если что-то посложнее, чертёж с детализациями, который вполне успешно делается Draftsman'ом. До определённого момента всё, что сверх необходимого (необходимое каждый раз обосновывалось) подсчтитывалось и переводилось в деньги, после предосталвялось начальству. Последним штрихом стало финаносово обоснованное требование оградить высокооплачиваемых сотрудников (разработчиков) от влажных фантазий менее высокооплачиваемых сотрудников, и на выбор два варианта: 1. Принять наши предложения по оформлению. 2. Нанять оформителя чертежей для удовлетворения требований (полная ставка) и добавить в бюджет подразделения затраты на него.

ГОСТ 2.111-2013. п.п. 6.5, дополнительно 7.3. Так что, право имеет, если ему не показывали до этого. Как совет, попробуйте добиться возложения обязанности обеспечения автоматизации оформления документации на отдел стандартизации (если у вас в нём нормоконтроль, как это обычно), и весь перечень замечаний нормоконтроля в приложение к докладной записке о неисполнении отделом стандартизации их прямой обязанности.

Плохой код надо не комментировать, а переписывать. Плохую плату надо не тщательно документировать и оформлять в соотвтетсвии с требованиями, а переделывать. Даёт для приёмки и для согласования требований, особенно, если плата разрабатывается под интеграцию в чужое устройство, в чужой корпус. Но, вот в том, что нормоконтроллёры страдают синдромом вахтёра и не понимают своего прямого назначения (большниство из них даже не знают о наличии ГОСТ 2.111) - полностью с вами согласен.