Я так понимаю, представленный материал есть не что иное как глубинная основа STA - static timing analysis. Проблема в том, что даже для основ изложено слишком математизированно. Конечно, если абстрагироваться от физики проводников и полупроводников, то выглядит вполне. Но вот если рассматривать вопрос более практично, то у DAG (directed acyclic graph или по русски направленный ацикличный орграф) появляются дополнительные ребра в виде setup/hold/recovery/removal check, прохождение по графу учитывает полярность сигнала и возможность его инверсии при прохождении вершин .. и т.д. - куча усложнений, притягивающих всю изложенную математику к практике. Материала на русском по этой тематике действительно мало. Лет 10 назад было много научных публикаций и даже диссеры в Зеленограде ... но до написания софта так дело и не дошло. Я в свое время учил это все (практическую часть STA, т.к. нужно было для работы) по скачанным лекциям MIT. И даже сделал небольшой пост здесь https://habr.com/ru/post/273849/ Собственно, именно по прикладной STA очень и очень не хватает публикаций, а в идеале учебника на русском. На уровне лекций MIT и даже глубже - языком математики, как вы и запостили. Для будущих инженеров, если страна все же сможет выбраться из под санкций.
Клюнул на название, и честно говоря слегка "прифигел". Потому что 20 лет занимаюсь пректированием чипов, но после первого прочтения "вскользь" не понял вообще ничего. После второго, подробного прочтения, уже понял, что это алгоритмика, никаких кристаллов здесь нет и в помине, но материал вполне попадает под классификацию чипостроения в качестве логического дизайна. Причем дизайна весьма специфического, поскольку, как я понимаю, для имплементации рассматриваемых алгоритмов предлагается не использование процессора с ограниченным числом инструкций, а имплементация "в лоб" путем построения автомата (поправьте, если не прав). И вот здесь я оказался в тупике, поскольку сходу не смог придумать, для чего это может быть нужно. Т.е. автору я бы посоветовал включить в книгу и практические примеры, где эти алгоритмы могут быть использованы.
Еще небольшой комментарий по вводной части. В логическом дизайне время различают на физическое и логическое. Логическое время измеряется в шагах алгоритма, и может течь как с той же скоростью, что и физическое время (синхронная работа от внешних "часов"), так и без привязки к физическому времени (асинхронная работа). Соотвественно, автомат может проектироваться как для синхронной работы по шагам state <= next_state (Мур, Мили), так и с использованием параллельных процессов (модель Хаффмана). Это более широкая классификация, чем просто "дискретное время". Полагаю, автор предлагает проектирование именно синхронных автоматов.
Ни на что не претендую, просто высказал свое мнение человека - не из целевой аудиотрии, т.е. случайно заглянувшего.
Как только вы обеспечиваете нормальную себестоимость и рыночные цены, вы можете быть востребованы. У Байкал Электроникс гораздо больше шансов, чем у МЦСТ в силу того, что они совместимы с огромным количеством доступного на рынке софта.
Аргумент интересный и правильный, но вывод странный. Под совместимостью понимается преимущество использования архитектуры АРМ, полагаю. Но вот вопрос в том, а как Байкал будет покупать ядра АРМ следующих поколений (в условиях санкций). На мой взгляд, у АРМ в РФ нет будущего, надо искать другие ниши/архитектуры.
По x-talk/noise и защелкивание асинхронных схем напишу чуть подробнее.
Любая асинхронная схема так или иначе содержит RS защелки: в явном виде, либо в виде С-элемента, либо в составе NCL элементов. RS защелка это бистабильный триггер, для переключения которого нужен импульс с некоторой минимальной энергией. Для простоты будем считать что амплитуда сигнала фиксирована, и тогда вместо энергии можно говорить просто о длительности импульса, а однократное переключение будем считать импульсом с бесконечной энергией/длительностью. Так вот, если длительность импульса слишком мала, то переключения не произойдет, а если длительность чуть выше, но все равно недостаточна, то получим бистабильное состояние, выражающееся биениями/генерацией на выходе. У меня есть хорошая статья, поясняющая этот эффект. В нашем контексте, импульс это наведенное паразитное переключение.
А теперь представьте, что в Вашей NCL-подобной схеме какой то элемент сработал неверно за счет наведенного импульса. Сработал, и защелкнул неверное состояние. Вот об этой проблеме я и писал выше. Есть еще проблема защелкивания управления, но если его проектировать как и в синхронных схемах, т.е. с экранированием, то проблем быть не должно. В любом случае, нужны исследования.
Согласен со всем, и в частности с недостатком классического dual rail в виде орфанов и повсеместного нарушения DI. Но тут важно понимать, чего мы хотим добиться, и какой ценой. Поясню:
Наиболее серьезный недостаток асинхронных схем, это защелкивание (когда схема просто встает). Причем на практике стоит опасаться не эффектов вида SEU в где то в транзисторах (хотя и это случается тоже), а куда более распостраненного эффекта X-talk/ noise, который как Вы верно написали, в синхронных схемах маскируется клоком, а вот асинхронную схему просто убьет. Причем современные тулы проектирования топологии кристалла помогают снизить этот эффект до приемлемого (для синхронных схем) уровня, но полностью от этого избавиться может и не получится (для синхронных схем это не требуется). И я подозреваю, что данный аспект проектирования асинхронных схем пока вообще никто не изучал. Были пара американских патентов с троированием, и схемой watchdog, которая при срабатывании делала сброс, но .. это какие то убогие костыли, а не системное решение проблемы.
Получается, что на фоне борьбы с защелкиванием, проблеммы с чистотой DI смотрятся уже более чем бледно. И возникает вопрос - а может и вовсе не делать индикацию в логике? Ведь избавившись от индикации (в логике, но не в регистрах) кроме очевидного бенефита в виде скорости/площади/потребления мы получаем еще хоть и небольшую, но защиту от x-talk/noise - случись это где то в середине комбинационной схемы, отголоски такого сбоя могут и не докатиться до выходов. А могут и докатиться, тут как повезет. Скажем, если электромагнитный импульс был наведен снаружи, а не изнутри схемы, то ничего уже не спасет от защелкивания.
Итого, все зависит от задач и имплементации. Но если расставлять приоритеты, то может оказаться, что DI в комбинационной логике не нужно и даже вредно. Причем проблема x-talk/noise - электрическая, т.е. можно сменить CMOS на что то еще, но провода то останутся. Нужны исследования, не хватает практики. По борьбе с защелкиванием в асинхронных схемах практически ничего нет.
У NCL реализации комбинационных схем есть два серьезных недостатка:
Первое - в NCL каждый логический элемент ожидает окончание переходных процессов(ПП). Таким образом вычисление функции и ожидание окончания ПП происходит последовательно. В классическом же dual-rail подходе индикация окончания ПП производится параллельно с вычислением функции, а значит работает быстрее.
Воторое - NCL это проприетарная (!!!) библиотека элементов. Практически в каждом элементе сожержится защелка (С-элемент) для хранения состояния. И если сравнить реализации на NCL и классический dual rail с параллельной схемой индикации ПП, то во втором случае общее число таких защелок получится меньше, т.к. они используются более еффективно. По крайней мере, так получалось у меня в экспериментах, когда я занимался данной тематикой.
Итого, причины не использовать NCL более чем весомые. Да и сам метод dual rail (перекрестная реализация по Варшавскому) мне кажется сильно проще, особенно тем что можно использовать коммерческие синтезаторы синхронных схем DC / Genus. Т.е. приведенный в статье новый (?) метод синтеза - хорошо, но польза от него сомнительна.
В дополнение, и это уже много раз обсуждалось, в том числе и здесь, непонятно где вообще имеет смысл использовать dual rail кодирование для реализации асинхронных комбинационных схем. Не асинхронных схем вообще, а именно комбинационных, т.е. где требуются вычисления. Потому что автоматы (FSM) прекрасно синтезируются и без dual rail.
А картинки по метастабильности честно стырены с хабра, одна лично мной нарисована (про сетап и холд). Но не суть важно, просто в целом, с учетом вышесказанного, впечатление слегка подпорчено.
Кстати, по явлению метастабильности плохо написано, мне кажется, автор не до конца понимает материал. В часности, в западных лекциях обязательно рассказывается о MTBF, и чем специальные селлы-синхронизаторы отличаются от просто цепочки из защелок или флопов.
Есть еще китайские фабы. К примеру Ядро заявляло чип по тех. процессу, доступному на нескольких фабах, включая SMIC. Я не знаю, что будет с лицензиями на тулы, но китайцы врят ли запретят у них выпускаться. А может, и с лицензиями помогут. Мне кажется, тут есть еще место для маневра.
Это выводом средств называется. Разумеется, не бесплатно - смотрите тарифы банка на выводы валюты для ИП. Валютный контроль есть, насколько я понимаю, но если со своего счета на свой (а по другому никак), то подтверждающих документов не нужно, и вообще все просто. Правда, есть хитрый закон, когда счет могут заблокировать вместе с суммой на проверку длинной н-цать месяцев, но если вы не со сбером/втб работаете, то "шанс крайне мал". Кстати по закону, гражданам РФ запрещено делать переводы в валюте другим гражданам РФ. Только в рублях, и никак иначе. Причем запрещено, даже если вы живете за границей и налоговый резидент другой страны. Карается штрафом в размере суммы перевода - если узнают. Нормативный документ искать влом, сорри.
Это как если сравнить инструмент для сборки шкафа из икеи с набором из обрезных досок, фурнитуры, и кучи всевозможных инструментов от пилы до ручных резцов и приборчика по выжиганию. Вроде бы инструмент схожий и там и там, но вот количество, назначение инструмента, и число операций по сборке во втором кейсе - совершенно другое. Как и результат, к слову. Но, тут важно понимать, что автор статьи немного не в той области работает, о которой пишет здесь. Так что без углубления в детали выглядит как бы норм, а если углубляться .. лучше что то другое почитать
Если вас интересует мой личный опыт, то сумма была гдето очень близко к 6 млн, но не могу сказать - превышала или нет. Думаю, один год все же превышала. Что там банк с контрактом делал - без понятия. Контракт был зарплатный, с цифровой подписью, на фиксированную сумму, но при этом реальная сумма плавала в обе стороны очень сильно. Были и бонусы и авансы, и аут-оф-покет возвраты, и несколько месяцев платили заметно меньше. Никаких проблем. Проработал я так около 3 лет, потом закрыл ИП. Закрытие было ровно таким же, как и открытие - банк с налоговой договорился сам, а я только заявление сьездил подписать.
Я как бы вам с самого начала намекаю, что для работы это все знать не нужно. Можно разобраться, но не нужно. Тем более это не нужно, если материал для начинающих.
- валютный контроль, это любое зачисление валюты по инвойсу, не только изучение договора. Для пользователя прозрачно, делает сам банк.
- квартальные отчисления равно как и налоговые делает мобильная бухгалтерия. Снимает рубли со счета и сама шлет куда нужно (налоговая, ПФР и т.д.). Для пользователя прозрачно, нужно только счета подписывать.
- вопросом я действительно особо не владею, но это и не было нужно (в десятый раз уже пишу).
У меня складывается ощущение что в сбере вам там здорово по мозгам проехались. Нормальный банк (никакой рекламы!) - это условный 1% в добавок к УСН 6%, и никаких проблем и заморочек - ни с чем. По крайней мере, если у вас просто зарплатный контракт.
Отвечаю, с чем не согласен. Нет тонкостей, нет ухищрений, нет квартальных отчетов и нет прохождения валютного контроля. Для пользователя ничего этого нет. Все делает банк и мобильная бухгалтерия. Мой опыт ИП - с 2018 по 2020, т.е. не много, но и не мало.
Не согласен. Я не вижу смысла пугать людей тем, что было много лет назад и сбивает их с толку стеной текста. _Сейчас_ получение зарплаты в валюте через ИП описывается двумя предложенями, что я и продемонстрировал выше.
Если честно, то я вообще не понял, о чем столько текста. Мой опыт - открыл ИП на УСН, октрыл долларовый счет (модульбанк - не реклама), отослал им контракт, оплатил мобильную бухгалтерию, и каждый месяц отсылал инвойсы и получал на счет баксы, конвертил в рубли и слал на личный счет в тинькоф (не реклама). Все! Одним предложением.
Закрытие выглядело так же просто - подал заявление в налоговую, уведомил банк (они отослали что требуется). Все! Тоже одним предложением. Не напрягался ни разу.
Нет здесь курицы и яйца, все проще: групп проектирования мало, потому что заказчик один, т.е. рыночная экономика не работает и никогда не работала в российской микроэлектронике. Со всем вытекающим из этого факта.
Нну, все же рынок вакансий для программистов в РФ огромен, он просто гиганский. А по эсикостроению - практически отсутствует (по физ дизайну совсем отсутствует). Со всем вытекающими в виде зарплат и выбора ( выполняемых задач, коллективов, локации и т.д.). Зато этот выбор есть в Европе, о чем каждый раз напоминает автор данной публикации
В РФ действительно почти нет работы по обсуждаемой специальности. Байкал и Ядро не круглый год людей хантят, а команды физ дизайна в российский фирмах/нии - едва ли пара десятков человек, это вам не эппл с единицами тысяч. Т.е. рынок труда в этом сегменте очень маленький, в нем тесно, иногда на хедхантере месяцами нет вакансий. Студентов с удовольствием берут за копейки, а профессионалы боятся голову поднять, чтобы не уволили. Это очень очень плохая и нездоровая ситуация, длящаяся уже десятилетиями, не годами. В качестве примера выступаю я сам - почти год сидел без работы, и в результате уехал. Т.е. посыл обсуждаемой статьи мне лично совершенно очевиден - учиться, чтобы уехать. Проблема только в том, что наших не очень то и жалуют там, т.е. рецепт для уехать физ дизайнером - тоже весьма сомнительный, ведь будучи программистом это сделать куда как проще (просто по статистике). Т.е. как ни крути, а ребенка бы я не стал сейчас не то что на физ дизайн, а вообще в электронный вуз отдавать. Такое вот личное мнение
Про память с калькулятором - не понял связи. Лично я писал про: когерентность кеша, совместный доступ к памяти, реализации арбитров и семафоров, а так же про специализированные интерфейсы и фабрики.
На мой взгляд, знать об этом нужно хотя бы в общеобразовательных целях (собственно, задача обсуждаемого учебника), иначе снова получаем порядком устаревший курс. Да, работа над первым учебником была проведена колоссальная. Но, данный учебник уже третий, и пора бы сделать качественный шаг вперед (а не просто переписать несколько страниц под новую уархитектуру).
Нужно обязательно про многоядерность писать. Одно ядро - вчерашний день, сейчас даже микроконтроллеры стали многоядерными. При этом качественная разница между одноядерным и многоядерным процессором примерно такая же, как между однотактовой и конвеерной организацией вычислений. Для пятых рисков это наверное пока не очень актуально, а вот АРМ - да, учитывая что эппл отъело гиганский кусок рынка со своими М1 процессорами, основанными на АРМ64. Т.е. при всем многообразии организаций многоядерных вычислений появился совершенно четкий пример, как делать хорошо (архитектура М1/АРМ). Это давно уже не будущее, а настоящее (и лет 15 как прошлое), поэтому включать такой материал в учебник надо обязательно
Я так понимаю, представленный материал есть не что иное как глубинная основа STA - static timing analysis. Проблема в том, что даже для основ изложено слишком математизированно. Конечно, если абстрагироваться от физики проводников и полупроводников, то выглядит вполне. Но вот если рассматривать вопрос более практично, то у DAG (directed acyclic graph или по русски направленный ацикличный орграф) появляются дополнительные ребра в виде setup/hold/recovery/removal check, прохождение по графу учитывает полярность сигнала и возможность его инверсии при прохождении вершин .. и т.д. - куча усложнений, притягивающих всю изложенную математику к практике. Материала на русском по этой тематике действительно мало. Лет 10 назад было много научных публикаций и даже диссеры в Зеленограде ... но до написания софта так дело и не дошло. Я в свое время учил это все (практическую часть STA, т.к. нужно было для работы) по скачанным лекциям MIT. И даже сделал небольшой пост здесь https://habr.com/ru/post/273849/ Собственно, именно по прикладной STA очень и очень не хватает публикаций, а в идеале учебника на русском. На уровне лекций MIT и даже глубже - языком математики, как вы и запостили. Для будущих инженеров, если страна все же сможет выбраться из под санкций.
Клюнул на название, и честно говоря слегка "прифигел". Потому что 20 лет занимаюсь пректированием чипов, но после первого прочтения "вскользь" не понял вообще ничего. После второго, подробного прочтения, уже понял, что это алгоритмика, никаких кристаллов здесь нет и в помине, но материал вполне попадает под классификацию чипостроения в качестве логического дизайна. Причем дизайна весьма специфического, поскольку, как я понимаю, для имплементации рассматриваемых алгоритмов предлагается не использование процессора с ограниченным числом инструкций, а имплементация "в лоб" путем построения автомата (поправьте, если не прав). И вот здесь я оказался в тупике, поскольку сходу не смог придумать, для чего это может быть нужно. Т.е. автору я бы посоветовал включить в книгу и практические примеры, где эти алгоритмы могут быть использованы.
Еще небольшой комментарий по вводной части. В логическом дизайне время различают на физическое и логическое. Логическое время измеряется в шагах алгоритма, и может течь как с той же скоростью, что и физическое время (синхронная работа от внешних "часов"), так и без привязки к физическому времени (асинхронная работа). Соотвественно, автомат может проектироваться как для синхронной работы по шагам state <= next_state (Мур, Мили), так и с использованием параллельных процессов (модель Хаффмана). Это более широкая классификация, чем просто "дискретное время". Полагаю, автор предлагает проектирование именно синхронных автоматов.
Ни на что не претендую, просто высказал свое мнение человека - не из целевой аудиотрии, т.е. случайно заглянувшего.
Аргумент интересный и правильный, но вывод странный. Под совместимостью понимается преимущество использования архитектуры АРМ, полагаю. Но вот вопрос в том, а как Байкал будет покупать ядра АРМ следующих поколений (в условиях санкций). На мой взгляд, у АРМ в РФ нет будущего, надо искать другие ниши/архитектуры.
По x-talk/noise и защелкивание асинхронных схем напишу чуть подробнее.
Любая асинхронная схема так или иначе содержит RS защелки: в явном виде, либо в виде С-элемента, либо в составе NCL элементов. RS защелка это бистабильный триггер, для переключения которого нужен импульс с некоторой минимальной энергией. Для простоты будем считать что амплитуда сигнала фиксирована, и тогда вместо энергии можно говорить просто о длительности импульса, а однократное переключение будем считать импульсом с бесконечной энергией/длительностью. Так вот, если длительность импульса слишком мала, то переключения не произойдет, а если длительность чуть выше, но все равно недостаточна, то получим бистабильное состояние, выражающееся биениями/генерацией на выходе. У меня есть хорошая статья, поясняющая этот эффект. В нашем контексте, импульс это наведенное паразитное переключение.
А теперь представьте, что в Вашей NCL-подобной схеме какой то элемент сработал неверно за счет наведенного импульса. Сработал, и защелкнул неверное состояние. Вот об этой проблеме я и писал выше. Есть еще проблема защелкивания управления, но если его проектировать как и в синхронных схемах, т.е. с экранированием, то проблем быть не должно. В любом случае, нужны исследования.
Согласен со всем, и в частности с недостатком классического dual rail в виде орфанов и повсеместного нарушения DI. Но тут важно понимать, чего мы хотим добиться, и какой ценой. Поясню:
Наиболее серьезный недостаток асинхронных схем, это защелкивание (когда схема просто встает). Причем на практике стоит опасаться не эффектов вида SEU в где то в транзисторах (хотя и это случается тоже), а куда более распостраненного эффекта X-talk/ noise, который как Вы верно написали, в синхронных схемах маскируется клоком, а вот асинхронную схему просто убьет. Причем современные тулы проектирования топологии кристалла помогают снизить этот эффект до приемлемого (для синхронных схем) уровня, но полностью от этого избавиться может и не получится (для синхронных схем это не требуется). И я подозреваю, что данный аспект проектирования асинхронных схем пока вообще никто не изучал. Были пара американских патентов с троированием, и схемой watchdog, которая при срабатывании делала сброс, но .. это какие то убогие костыли, а не системное решение проблемы.
Получается, что на фоне борьбы с защелкиванием, проблеммы с чистотой DI смотрятся уже более чем бледно. И возникает вопрос - а может и вовсе не делать индикацию в логике? Ведь избавившись от индикации (в логике, но не в регистрах) кроме очевидного бенефита в виде скорости/площади/потребления мы получаем еще хоть и небольшую, но защиту от x-talk/noise - случись это где то в середине комбинационной схемы, отголоски такого сбоя могут и не докатиться до выходов. А могут и докатиться, тут как повезет. Скажем, если электромагнитный импульс был наведен снаружи, а не изнутри схемы, то ничего уже не спасет от защелкивания.
Итого, все зависит от задач и имплементации. Но если расставлять приоритеты, то может оказаться, что DI в комбинационной логике не нужно и даже вредно. Причем проблема x-talk/noise - электрическая, т.е. можно сменить CMOS на что то еще, но провода то останутся. Нужны исследования, не хватает практики. По борьбе с защелкиванием в асинхронных схемах практически ничего нет.
У NCL реализации комбинационных схем есть два серьезных недостатка:
Первое - в NCL каждый логический элемент ожидает окончание переходных процессов(ПП). Таким образом вычисление функции и ожидание окончания ПП происходит последовательно. В классическом же dual-rail подходе индикация окончания ПП производится параллельно с вычислением функции, а значит работает быстрее.
Воторое - NCL это проприетарная (!!!) библиотека элементов. Практически в каждом элементе сожержится защелка (С-элемент) для хранения состояния. И если сравнить реализации на NCL и классический dual rail с параллельной схемой индикации ПП, то во втором случае общее число таких защелок получится меньше, т.к. они используются более еффективно. По крайней мере, так получалось у меня в экспериментах, когда я занимался данной тематикой.
Итого, причины не использовать NCL более чем весомые. Да и сам метод dual rail (перекрестная реализация по Варшавскому) мне кажется сильно проще, особенно тем что можно использовать коммерческие синтезаторы синхронных схем DC / Genus. Т.е. приведенный в статье новый (?) метод синтеза - хорошо, но польза от него сомнительна.
В дополнение, и это уже много раз обсуждалось, в том числе и здесь, непонятно где вообще имеет смысл использовать dual rail кодирование для реализации асинхронных комбинационных схем. Не асинхронных схем вообще, а именно комбинационных, т.е. где требуются вычисления. Потому что автоматы (FSM) прекрасно синтезируются и без dual rail.
А картинки по метастабильности честно стырены с хабра, одна лично мной нарисована (про сетап и холд). Но не суть важно, просто в целом, с учетом вышесказанного, впечатление слегка подпорчено.
Кстати, по явлению метастабильности плохо написано, мне кажется, автор не до конца понимает материал. В часности, в западных лекциях обязательно рассказывается о MTBF, и чем специальные селлы-синхронизаторы отличаются от просто цепочки из защелок или флопов.
Есть еще китайские фабы. К примеру Ядро заявляло чип по тех. процессу, доступному на нескольких фабах, включая SMIC. Я не знаю, что будет с лицензиями на тулы, но китайцы врят ли запретят у них выпускаться. А может, и с лицензиями помогут. Мне кажется, тут есть еще место для маневра.
Это выводом средств называется. Разумеется, не бесплатно - смотрите тарифы банка на выводы валюты для ИП. Валютный контроль есть, насколько я понимаю, но если со своего счета на свой (а по другому никак), то подтверждающих документов не нужно, и вообще все просто. Правда, есть хитрый закон, когда счет могут заблокировать вместе с суммой на проверку длинной н-цать месяцев, но если вы не со сбером/втб работаете, то "шанс крайне мал".
Кстати по закону, гражданам РФ запрещено делать переводы в валюте другим гражданам РФ. Только в рублях, и никак иначе. Причем запрещено, даже если вы живете за границей и налоговый резидент другой страны. Карается штрафом в размере суммы перевода - если узнают. Нормативный документ искать влом, сорри.
Это как если сравнить инструмент для сборки шкафа из икеи с набором из обрезных досок, фурнитуры, и кучи всевозможных инструментов от пилы до ручных резцов и приборчика по выжиганию. Вроде бы инструмент схожий и там и там, но вот количество, назначение инструмента, и число операций по сборке во втором кейсе - совершенно другое. Как и результат, к слову. Но, тут важно понимать, что автор статьи немного не в той области работает, о которой пишет здесь. Так что без углубления в детали выглядит как бы норм, а если углубляться .. лучше что то другое почитать
Если вас интересует мой личный опыт, то сумма была гдето очень близко к 6 млн, но не могу сказать - превышала или нет. Думаю, один год все же превышала. Что там банк с контрактом делал - без понятия. Контракт был зарплатный, с цифровой подписью, на фиксированную сумму, но при этом реальная сумма плавала в обе стороны очень сильно. Были и бонусы и авансы, и аут-оф-покет возвраты, и несколько месяцев платили заметно меньше. Никаких проблем. Проработал я так около 3 лет, потом закрыл ИП. Закрытие было ровно таким же, как и открытие - банк с налоговой договорился сам, а я только заявление сьездил подписать.
Я как бы вам с самого начала намекаю, что для работы это все знать не нужно. Можно разобраться, но не нужно. Тем более это не нужно, если материал для начинающих.
- валютный контроль, это любое зачисление валюты по инвойсу, не только изучение договора. Для пользователя прозрачно, делает сам банк.
- квартальные отчисления равно как и налоговые делает мобильная бухгалтерия. Снимает рубли со счета и сама шлет куда нужно (налоговая, ПФР и т.д.). Для пользователя прозрачно, нужно только счета подписывать.
- вопросом я действительно особо не владею, но это и не было нужно (в десятый раз уже пишу).
У меня складывается ощущение что в сбере вам там здорово по мозгам проехались. Нормальный банк (никакой рекламы!) - это условный 1% в добавок к УСН 6%, и никаких проблем и заморочек - ни с чем. По крайней мере, если у вас просто зарплатный контракт.
Отвечаю, с чем не согласен. Нет тонкостей, нет ухищрений, нет квартальных отчетов и нет прохождения валютного контроля. Для пользователя ничего этого нет. Все делает банк и мобильная бухгалтерия. Мой опыт ИП - с 2018 по 2020, т.е. не много, но и не мало.
Не согласен. Я не вижу смысла пугать людей тем, что было много лет назад и сбивает их с толку стеной текста. _Сейчас_ получение зарплаты в валюте через ИП описывается двумя предложенями, что я и продемонстрировал выше.
Если честно, то я вообще не понял, о чем столько текста. Мой опыт - открыл ИП на УСН, октрыл долларовый счет (модульбанк - не реклама), отослал им контракт, оплатил мобильную бухгалтерию, и каждый месяц отсылал инвойсы и получал на счет баксы, конвертил в рубли и слал на личный счет в тинькоф (не реклама). Все! Одним предложением.
Закрытие выглядело так же просто - подал заявление в налоговую, уведомил банк (они отослали что требуется). Все! Тоже одним предложением. Не напрягался ни разу.
Если это в сбере столько хлопот - бегите оттуда.
Нет здесь курицы и яйца, все проще: групп проектирования мало, потому что заказчик один, т.е. рыночная экономика не работает и никогда не работала в российской микроэлектронике. Со всем вытекающим из этого факта.
Нну, все же рынок вакансий для программистов в РФ огромен, он просто гиганский. А по эсикостроению - практически отсутствует (по физ дизайну совсем отсутствует). Со всем вытекающими в виде зарплат и выбора ( выполняемых задач, коллективов, локации и т.д.). Зато этот выбор есть в Европе, о чем каждый раз напоминает автор данной публикации
В РФ действительно почти нет работы по обсуждаемой специальности. Байкал и Ядро не круглый год людей хантят, а команды физ дизайна в российский фирмах/нии - едва ли пара десятков человек, это вам не эппл с единицами тысяч. Т.е. рынок труда в этом сегменте очень маленький, в нем тесно, иногда на хедхантере месяцами нет вакансий. Студентов с удовольствием берут за копейки, а профессионалы боятся голову поднять, чтобы не уволили. Это очень очень плохая и нездоровая ситуация, длящаяся уже десятилетиями, не годами. В качестве примера выступаю я сам - почти год сидел без работы, и в результате уехал. Т.е. посыл обсуждаемой статьи мне лично совершенно очевиден - учиться, чтобы уехать. Проблема только в том, что наших не очень то и жалуют там, т.е. рецепт для уехать физ дизайнером - тоже весьма сомнительный, ведь будучи программистом это сделать куда как проще (просто по статистике). Т.е. как ни крути, а ребенка бы я не стал сейчас не то что на физ дизайн, а вообще в электронный вуз отдавать. Такое вот личное мнение
Про память с калькулятором - не понял связи. Лично я писал про: когерентность кеша, совместный доступ к памяти, реализации арбитров и семафоров, а так же про специализированные интерфейсы и фабрики.
На мой взгляд, знать об этом нужно хотя бы в общеобразовательных целях (собственно, задача обсуждаемого учебника), иначе снова получаем порядком устаревший курс. Да, работа над первым учебником была проведена колоссальная. Но, данный учебник уже третий, и пора бы сделать качественный шаг вперед (а не просто переписать несколько страниц под новую уархитектуру).
Нужно обязательно про многоядерность писать. Одно ядро - вчерашний день, сейчас даже микроконтроллеры стали многоядерными. При этом качественная разница между одноядерным и многоядерным процессором примерно такая же, как между однотактовой и конвеерной организацией вычислений. Для пятых рисков это наверное пока не очень актуально, а вот АРМ - да, учитывая что эппл отъело гиганский кусок рынка со своими М1 процессорами, основанными на АРМ64. Т.е. при всем многообразии организаций многоядерных вычислений появился совершенно четкий пример, как делать хорошо (архитектура М1/АРМ). Это давно уже не будущее, а настоящее (и лет 15 как прошлое), поэтому включать такой материал в учебник надо обязательно