Jump to content

    

lexx

Свой
  • Content Count

    183
  • Joined

  • Last visited

Community Reputation

0 Обычный

About lexx

  • Rank
    Частый гость

Recent Profile Visitors

2135 profile views
  1. Вы плохо о них думаете. На job fair на одного белого приходится по 10 индусов. И они стараются тянуть остальных вверх. В любой тиме есть как минимум один начинающий, даже в коммерческих проектах. Верификация как раз индусами завалена. Код у них не очень, hls как раз минимизирует объем кода. Откуда скачивается большая часть софта и так известно. Также большая часть плат там же производится. И им не нравиться работать за копейки по 6 дней в неделю. А теперь вопрос почему аутсорсинг не завален предложениями, если цена софта не так и высока, а исполнение не слишком затруднено?
  2. Нет, реально думаете что открыли сундук с богатством? Сотни тысяч китайцев и индусов могут делать аналогичную работу, но только рынок не завален этим, как то плохо стыкуется.
  3. А если нет такой корки, либо цена превышает бюджет, либо что-то не так коркой, там ведь не боги горшки обжигают.
  4. Согласен, однако тот кто начинает снизу тот и вверх поднимется, для него ясно почему нужно прийти, только инструмент отличен. А вот случае разработки полностью нового это уже проблема, я уже не говорю о том, что он никогда не сможет подняться на уровень ASIC, но возможно это и не нужно. У каждого свои задачи и способы решения.
  5. Идёт расхождение аудитории: первые пишут свои ядра на чистом коде, вторые используют смешанный подход и третьи - приложение на кодогенераторе. Все зависит от приложения, ничем не плохо использование готовых ядер, если результат всех устраивает. Хотя конечно обидно, что то что раньше занимало кучу времени сейчас легко генериться, вроде как в пустую потраченное время. Но к счастью и свои собственные ядра также писать нужно и тут уже высокий уровень не работает.
  6. Новички то как раз найдут это, а вот со стариками разговор уже будет на разных языках, возможны расхождения.
  7. Если это для обучения и багов не возникает, то какая разница на чем стоит.
  8. Да, это не догма, я даже сам не всегда следую этому правилу, но вот недавно столкнулся с тем, что часть скриптов упрощающих жизнь используют поиск файлов по имени в папках, вместо абсолютного пути. Всё возможно, но если имя файла уникально, то это минимизирует ошибки.
  9. Есть несколько вариантов реализаций, я предложил самый простой. Здесь больше вопрос в поиске значений за минимальное количество тактов. P.S. неплохая задача для лабораторной или курсовой работы, весь вопрос в ресурсах кристалла и числе тактов на поиск.
  10. Да потому, что задача конечна. Как раз для студентов, решается просто, никаких corner cases, шины данных и тому подобное. Один always на чтение и счётчик адреса. 2й на вывод
  11. Что за ВУЗ?
  12. Наличие экспертов конечно решает, но до определённого предела. Дальше без верификации никак, сложные вещи еще предусмотришь, а на какой-то ерунде завалишься.
  13. Как раз для больших компаний увеличение площади не критично, гораздо более важен стабильный результат. А 128 и 2048 х8 оптимальны для SRAM, и не нужно городить ничего лишнего.
  14. Одно из правил линта как раз требует чтобы имя модуля совпадало с именем файла. Максимум видел индусский case на 14тыс. строк, как же проблемно было высчитывать начала и конца, приходилось перекидывать файлы со станции на PC, чтобы нормально разделить и прочесть код. Но 20МБ RTL кода, это за гранью нормального. Это скорее всего релизный вариант, чтобы отдать одним файлом, но не работать с ним.
  15. Проще в 1е засунуть generate, вывод сделать через арифметику и одновременно запись в регистр по положительному фронту. 2е имеет фундаментальные ошибки.