Этим и отличается SoC-дизайнер / ASIC-архитектор от инженегров. Он знает, когда использовать ARM (и какой), когда ASIP, когда написать свое ядро. Знает, когда использовать AXI4, а когда можно и AXI3, а когда и AHB пойдет, и когда лучше шину пошире и помедленнее, а когда лучше поуже и побыстрее. Знает, как испортить жизнь своим программистам (например, дать им многоядерный проц с некогерентными кэшами и DMA). Знает, какое IP можно купить на рынке. Знает, как все это должно работать, если надо динамически менять частоту, или выключать питание в части кристалла, и кто будет все это верифицировать.
Короче, единственный надежный способ — устроиться к кому-то, кто все это уже знает, подмастерьем.
Мне нравится вопрос «Представим, что Вы написали максимально простую HDL-модель 5-стадийного RISC-процессора. Как будете её верифицировать? (Вопрос повышенной сложности)». Буду спрашивать на собеседованиях.
SoC-дизайнер должен знать и уметь и железо, и софт, который будет на нем вертеться. Ни один RTL-дизайнер еще не стал SoC-дизайнером, разрабатывая свистелки по чужим спекам.
Простейший вопрос, который я задал бы любому, желающему попробовать себя в роли SoC-дизайнера: нарисуй схему айфона и расскажи, где какая пропускная способность шин нужна. И как сделать так, чтоб он работал три дня без подзарядки. И чтоб андроед на нем видео показывал, а не слайд-шоу.
Вообще в больших проектах то, что ты наваял, верифицирует другой человек. Поэтому у нас, например, ни один синьор стафф архитект ничего никаким UVM-ом не верифицирует, а пишет сам себе какие-то маленькие тестбенчи, после чего шлет специально обученому индусу, который уже облепляет модуль всякими Verification IP и дальше по тестплану гоняет его и шлет гневные письма дизайнеру, когда все в очередной раз сломалось.
Бесплатный альтеровский модельсим каверыдж ведь не считает?
Вообще нужно студентов учить разработке на FPGA вот так:
для всех лаб, кроме последней, даем какую-нибудь маленькую и дешевую платку, и пусть хоть чипскопом, хоть методом тыка в нее тычут.
для последней лабы припасаем плату, которй у студентов нет. Даем ее описание и задание на лабу. Студент пишет и верифицирует, как может. После этого даем ему одну попытку продемонстрировать работоспособность на реальном железе. Заработало — молодец, за экзамен пятерка. Не заработало — двойка. Сурово, зато как в жизни.
Публиковать надо там, где есть хаб FPGA, то есть на Гиктаймс. Вопрос о том, кто это такой одаренный перенес этот хаб туда, где размещают «информацию преимущественно научно-популярного характера и не относящуюся к программированию, разработке и другим тематикам», к делу, считаю, не относится.
Есть какая-нибудь причина для использования gate-level симуляции для записи SAIF? Мы записываем SAIF в процессе RTL-симуляции (только активность на выходах регистров), а потом этот файл аннотируем на нетлист, при этом DC автоматически вычисляет активность на входах и выходах комбинационных логических элементов между регистрами (т.к. знает активность на регистрах). Если нужно симулировать хоть сколько-нибудь большой проект, то так гораздо быстрее, а точность почти такая же. К тому же один и тот же SAIF можно использовать с разными нетлистами (например, синтезированными под разную частоту, с разным процентным соотношением LVT/SVT/HVT-элементов, и т.д.)
Короче, единственный надежный способ — устроиться к кому-то, кто все это уже знает, подмастерьем.
Простейший вопрос, который я задал бы любому, желающему попробовать себя в роли SoC-дизайнера: нарисуй схему айфона и расскажи, где какая пропускная способность шин нужна. И как сделать так, чтоб он работал три дня без подзарядки. И чтоб андроед на нем видео показывал, а не слайд-шоу.
Вообще нужно студентов учить разработке на FPGA вот так:
Ну а далее по порядку:
— делитель напряжения
— RC-фильтр
— транзисторы
— операционники (аналоговые сумматоры и т.д.)
Жаль, если даже для Цыклона теперь нужны 64 бита.
Virtex7 2000T внутри. Но это для ASIC prototyping, не для телекоммуникаций.
Кстати, а вы namemap файл использовали?