Это правило очень любимое менеджментом, но ему придают незаслуженное значение. Вот разрабатываете вы кардиостимулятор. Его нужно разработать, отладить, протестировать. Принцип Паретто работает на каждом этапе, но что с того? Большая часть работы сделается сразу, а потом тянется отладка и тестирование. Вы не можете выпустить как-то разработанное, отлаженное и кое-как протестированное устройство. Время придётся тратить столько сколько нужно, а нужно столько чтобы не было никаких косяков для гарантированного прохождения сертификации.
HDL код представляет собой не последовательность инструкций, а описание цифровой схемы: арифметико-логических элементов и связей между ними. Примерно так же, веб-разработчики описывают разметку страницы на HTML.
Никак это не "примерно" и сравнение вообще некорректно. HDL код за 1 такт выполняется весь! Нет никакого построчного исполнения программы - каждый во всём исполняемом коде меняется всё. Если человек 10 лет писал на "обычном" языке программирования, например, на С для микроконтроллеров, то при знакомстве с HDL впервые ему очень нелегко. А ведь схема может быть ещё и многотактовая...
Почему бы не использовать второй BUFGCTRL, гарантируя одинаковость задержек верхней и нижней тактовых сетей? Чтобы САПР не умничала управление буфером куда-нибудь подключить, но, естественно, никогда не менять) Или в базе компонентов лежит один и тот же примитив, просто в коде порты разные вытащены?
У всех, конечно, разный опыт. Просто лично у меня такой, что само по себе программирование занимает в цикле разработки прошивки не такое уже превалирующее время. Нужно разобраться с аппаратной частью и ТЗ, декомпозировать задачу, продумать архитектуру, разработать модули, что-то промоделировать, развести проект (для высокоскоростного ЦОС это иногда сама по себе целая задача), потом придётся заниматься отладкой. В этой цепочке трата времени на непосредственное программирование - ну так себе траты. Зато строгость VHDL не даст себе в ногу выстрелить, а потом героически отлаживать некорректное присвоение векторов разных разрядностей)
Ознакомился по ссылке - стало понятно. Правда не очень понятно почему "мир сдвинул") Кода на верилоге конечно можно настрочить больше, но вхдл безопаснее.
Например Джон сдвинул мир от VHDL к Verilog, когда в 1997 году организовал хакатон по проектированию, для которого выбрал девять разработчиков на Verilog и пять на VHDL, после чего оказалось, что большинство пользователей Verilog выполнили задание, а большинство пользователей VHDL - нет.
Интересно, это что ж там такое, что успешность решения зависит от языка программирования? Правда изначально напрягает соотношение 9-к-5 и сразу на ум приходят мысли о качестве отбора)
Для новичка это вообще ловушка, выходить из которой придётся путём жёсткой перезагрузки или хардовым отключением питания компа. Зато после этого можно узнать про nano)
Программировать худо-бедно можно научить любого. Хороший программист будет отличаться от плохого тем, что в процессе разработки автоматически учтёт граничные ситуации. В результате код получится надежнее и красивее того, в который вынужденно придётся втыкать костыли, парируя провалы тестирования.
То же самое в бизнесе. Если изначально акция была рассчитана медленно и на 2000 единиц, то стоило её ограничить понедельно (для "медленно) и по времени (для "2000"). И не было бы вот всей этой запарки. Недосыпы, красные глаза и разраб как тень - ну так себе организация, оно того стоило? Жирный плюс - это выявление косяка управления в виде вранья руководству о ситуации. Но с системной точки зрения что было сделано? Просто провести беседы и уволить людей - это не решение первопричины: почему люди скрывали, почему такие люди оказались на руководящих постах? Практика показывает, что руководство всегда считает себя правым, а всю картину портят те, кого нужно уволить)
С другой стороны, бизнес зачастую развивается и двигается благодаря возможностям. Возникли благоприятные условия - ресурс бросается на её отработку. Спланировать это зачастую невозможно, нужно просто это не упустить. Вот и получается, что приходится отрабатывать шоки и афтешоки. А уж как это получается - зависит от умения заранее предвидеть граничные ситуации.
Да ладно вам, тут всего-то на 3 минуты чтения. Дальше написано ещё трешовее)
Дисклеймер в конце в принципе и не особо-то нужен, так как к нему уже совсем всё понятно становится. Но нужно уметь чувствовать иронию, да и в целом ЧЮ обладать.
За эти годы производители научились оптимизировать работу контроллеров и алгоритмы записи данных, поэтому выросли не только скорости, но и ресурс.
Несколько спорный вопрос. По сравнению с современными QLC, SLC и ранние MLC будут почти вечные. Именно поэтому на барахолках за Samsung 960 PRO до сих пор просят весьма ощутимые деньги.
Перечисленное имело бы смысл, если бы последним пунктом была ссылка хотя бы на исходный код клиента, который можно было бы самостоятельно собрать. А так это весьма идеалистическое представление об устройстве мира)
Это не идейность. Это банальный интерес к тому что ты делаешь. Который можно банально потерять. И тут может быть момент, который руководство может не видеть или не осознавать. Или не хочет видеть или осознать.
Я не знаю конкретно вашу ситуацию, поэтому прошу сразу не принимать далее написанное на свой счет. Обычно работодателю нужно быстро, дешево и качественно. А так не бывает) Хотите сократить промежуточные итерации - дайте работнику х3 по срокам для собственного ревью и моделирования. Но получится медленно, а надо быстро. Или наймите х2 разрабов и декомпозируйте задачу. Но получится дорого, а надо дешево. Или наймите мега крутого инженера за х10 денег, который работает быстро. Но получится очень дорого и это очень не правильно с точки зрения бизнес-процесса.
В вашем случае надо разбираться почему возникает "сделал и сделал, потом исправлю"? Одно дело если человек сделал и просто сидит полмесяца и сериалы смотрит и совсем другое дело если он тянет сразу 1,5 проекта и ещё по 2 типа сданным проектам его постоянно дергают, а руководство трудоемкость этого оценивает обычно где-то около нуля. Вот я как-то в жизни больше наблюдаю второе и недовольство руководства в том, что люди лентяи, плохо работают, не хотят выкладываться и всё такое.
Ну вот спроектировали вы плату. Сделали её на заводе, вам прислали. Вы её слегка проверили и подаёте на неё питание. Всё стартует, никакого дыма, в микроконтроллере начинает программа работает. И вдруг она начинает после обеда подглючивать иногда. Раз в час программа работает как-то не так. Ничего не понятно, всё это как-то непериодически. Некоторые дни вообще всё нормально работает! Но у вас есть "инженер с Claude"! Какие его действия?
Какое-то тут противоречие вижу я...
А где гарантия, что он в следующей модели не будет кривым? Вот люди эти риски и отрабатывают...
Ну тогда вообще никакой код не исполняется) После работы компилятора там будет всё несколько иначе, чем лаконичное описание на экране.
Но вашу мысль я понял.
Это правило очень любимое менеджментом, но ему придают незаслуженное значение. Вот разрабатываете вы кардиостимулятор. Его нужно разработать, отладить, протестировать. Принцип Паретто работает на каждом этапе, но что с того? Большая часть работы сделается сразу, а потом тянется отладка и тестирование. Вы не можете выпустить как-то разработанное, отлаженное и кое-как протестированное устройство. Время придётся тратить столько сколько нужно, а нужно столько чтобы не было никаких косяков для гарантированного прохождения сертификации.
Никак это не "примерно" и сравнение вообще некорректно. HDL код за 1 такт выполняется весь! Нет никакого построчного исполнения программы - каждый во всём исполняемом коде меняется всё. Если человек 10 лет писал на "обычном" языке программирования, например, на С для микроконтроллеров, то при знакомстве с HDL впервые ему очень нелегко. А ведь схема может быть ещё и многотактовая...
Зачем мне покупать и следить за доменом? Зачем мне всё это в локальной сети?
Почему бы не использовать второй BUFGCTRL, гарантируя одинаковость задержек верхней и нижней тактовых сетей? Чтобы САПР не умничала управление буфером куда-нибудь подключить, но, естественно, никогда не менять) Или в базе компонентов лежит один и тот же примитив, просто в коде порты разные вытащены?
У всех, конечно, разный опыт. Просто лично у меня такой, что само по себе программирование занимает в цикле разработки прошивки не такое уже превалирующее время. Нужно разобраться с аппаратной частью и ТЗ, декомпозировать задачу, продумать архитектуру, разработать модули, что-то промоделировать, развести проект (для высокоскоростного ЦОС это иногда сама по себе целая задача), потом придётся заниматься отладкой. В этой цепочке трата времени на непосредственное программирование - ну так себе траты. Зато строгость VHDL не даст себе в ногу выстрелить, а потом героически отлаживать некорректное присвоение векторов разных разрядностей)
Ознакомился по ссылке - стало понятно. Правда не очень понятно почему "мир сдвинул") Кода на верилоге конечно можно настрочить больше, но вхдл безопаснее.
Интересно, это что ж там такое, что успешность решения зависит от языка программирования? Правда изначально напрягает соотношение 9-к-5 и сразу на ум приходят мысли о качестве отбора)
В соответствии с тематикой статьи, тогда уж это ближе к Экзистенции!
Для новичка это вообще ловушка, выходить из которой придётся путём жёсткой перезагрузки или хардовым отключением питания компа. Зато после этого можно узнать про nano)
Это не классика, а база. Классика - это mc )
Если бы было написано тезисно, со списками и структурой, то автора упрекали бы в очередном нейрослопе ))
Программировать худо-бедно можно научить любого. Хороший программист будет отличаться от плохого тем, что в процессе разработки автоматически учтёт граничные ситуации. В результате код получится надежнее и красивее того, в который вынужденно придётся втыкать костыли, парируя провалы тестирования.
То же самое в бизнесе. Если изначально акция была рассчитана медленно и на 2000 единиц, то стоило её ограничить понедельно (для "медленно) и по времени (для "2000"). И не было бы вот всей этой запарки. Недосыпы, красные глаза и разраб как тень - ну так себе организация, оно того стоило? Жирный плюс - это выявление косяка управления в виде вранья руководству о ситуации. Но с системной точки зрения что было сделано? Просто провести беседы и уволить людей - это не решение первопричины: почему люди скрывали, почему такие люди оказались на руководящих постах? Практика показывает, что руководство всегда считает себя правым, а всю картину портят те, кого нужно уволить)
С другой стороны, бизнес зачастую развивается и двигается благодаря возможностям. Возникли благоприятные условия - ресурс бросается на её отработку. Спланировать это зачастую невозможно, нужно просто это не упустить. Вот и получается, что приходится отрабатывать шоки и афтешоки. А уж как это получается - зависит от умения заранее предвидеть граничные ситуации.
Да ладно вам, тут всего-то на 3 минуты чтения. Дальше написано ещё трешовее)
Дисклеймер в конце в принципе и не особо-то нужен, так как к нему уже совсем всё понятно становится. Но нужно уметь чувствовать иронию, да и в целом ЧЮ обладать.
Несколько спорный вопрос. По сравнению с современными QLC, SLC и ранние MLC будут почти вечные. Именно поэтому на барахолках за Samsung 960 PRO до сих пор просят весьма ощутимые деньги.
Перечисленное имело бы смысл, если бы последним пунктом была ссылка хотя бы на исходный код клиента, который можно было бы самостоятельно собрать. А так это весьма идеалистическое представление об устройстве мира)
Это не идейность. Это банальный интерес к тому что ты делаешь. Который можно банально потерять. И тут может быть момент, который руководство может не видеть или не осознавать. Или не хочет видеть или осознать.
Я не знаю конкретно вашу ситуацию, поэтому прошу сразу не принимать далее написанное на свой счет. Обычно работодателю нужно быстро, дешево и качественно. А так не бывает) Хотите сократить промежуточные итерации - дайте работнику х3 по срокам для собственного ревью и моделирования. Но получится медленно, а надо быстро. Или наймите х2 разрабов и декомпозируйте задачу. Но получится дорого, а надо дешево. Или наймите мега крутого инженера за х10 денег, который работает быстро. Но получится очень дорого и это очень не правильно с точки зрения бизнес-процесса.
В вашем случае надо разбираться почему возникает "сделал и сделал, потом исправлю"? Одно дело если человек сделал и просто сидит полмесяца и сериалы смотрит и совсем другое дело если он тянет сразу 1,5 проекта и ещё по 2 типа сданным проектам его постоянно дергают, а руководство трудоемкость этого оценивает обычно где-то около нуля. Вот я как-то в жизни больше наблюдаю второе и недовольство руководства в том, что люди лентяи, плохо работают, не хотят выкладываться и всё такое.
Ну вот спроектировали вы плату. Сделали её на заводе, вам прислали. Вы её слегка проверили и подаёте на неё питание. Всё стартует, никакого дыма, в микроконтроллере начинает программа работает. И вдруг она начинает после обеда подглючивать иногда. Раз в час программа работает как-то не так. Ничего не понятно, всё это как-то непериодически. Некоторые дни вообще всё нормально работает! Но у вас есть "инженер с Claude"! Какие его действия?