Loki5000

Все еще актуально.

Ищем тополога печатных плат с опытом работы в KiCad. Работу нужно выполнить именно в KiCad. Трансляция из других САПР-ов не подходит. Удаленная работа. Но если нужно, можем предоставить постоянное рабочее место в офисе (г.Москва). Есть схема устройства в двух вариантах. Второй вариант отличается от первого, в основном, отсутствием части схемы. К моменту старта работ по разводке схема уже будет реализована в KiCad. Если схема будет еще не готова и потребуется участие в ее доработке, то эта работа будет оплачена дополнительно. Необходимо быстро, но с хорошим качеством развести 2 набора печатных плат. I набор состоит из: - основная плата (6-8 слоев); - вспомогательная плата, на которую вынесены датчики (1-2 слоя). II набор состоит из: - плата с разъемами и вторичным источником (4 слоя); - основная плата (6-8 слоев); - вспомогательная плата, на которую вынесен светодиод индикации (1-2 слоя). Особенности: - высокоскоростные дифференциальные линии передачи данных (1,5 Гигабит, точка-точка); - минимальный шаг компонентов: 0.4мм Конструктив плат определен. Есть представление о компановке. Требования к топологии ответственных цепей определены. Однако, рекомендации, основанные на собственном опыте, приветствуются и обсуждаются. По консенсусной оценке нескольких специалистов, при наличии должного опыта, и неполной занятости (1/2) разводка одного набора должна занять приблизительно 1 месяц. Завершение работы быстрее и без потери качества приветствуется и будет вознаграждено дополнительно. Разводку каждого из наборов можем отдать разным людям. Разводку одного набора, без учета дополнительных вознаграждений, оцениваем в 85 000руб. Для получения более детальной информации о проекте можно подъехать к нам в офис. В настоящий момент схема существует только в виде эскизов. Кандидату необходимо подтвердить уровень своих компетенций примерами своих работ. Полную конфиденциальность полученной информации гарантируем. В откликах просьба указать: - опыт в разводке печатных плат (стаж, ключевые навыки); - опыт работы в KiCad; - сколько времени можете уделять работе; - когда можете приступить к работе. Пишите, пожалуйста, в личку.

Спасибо за наводку. К ним еще не обращались. А такие вообще есть? Те, что выдают себя за большие конторы, на деле состоят из пары человек. Этим мы и заняты. По нашим оценкам даже больше указанных сумм. Мы представляем себе масштаб бедствия. Мы уже обращались в "большие конторы" и знаем во сколько это выливается. Так вот за эти деньги вполне реально содержать команду действительно дорогих специалистов на все время проекта.

Ищем специалиста (команду специалистов) по промдизайну на выполнение сдельной работы. Желательно из Москвы. Либо из относительно недалеких городов, т.к. личная встреча обязательна. Санкт-Петербург, например, тоже готовы рассмотреть. Требуется разработать корпуса для 3х устройств в 2х исполнениях. Итого 6 корпусов: 3 из пластика + 3 металлических. Корпуса в двух исполнениях будут похожи друг на друга, но не полностью. В одном из 6и корпусов (том, что из пластика) есть поворотные элементы и соответствующий механизм. К корпусам из металла предъявляются требования по соответствию IP67. Дизайн корпусов так же требуется разработать. Требуется сопровождение процесса изготовления прототипов разработанных корпусов. Работа будет считаться завершенной только после получения прототипов, удовлетворительного качества. Выполнять работу можно как удаленно, так и на территории работодателя (необходимое рабочее место (места) организуем). Наличие опыта подобных разработок обязателен. Подтверждение опыта путем демонстрации портфолио тоже обязательно. Готовы рассмотреть вариант разделения задачи между несколькими исполнителями. Исполнения из пластика могут делать одни, а из металла другие. Разработку дизайна можно также отдать отдельному человеку. Сроки выполнения работ: 6 месяцев (обсуждаемо), включая изготовление прототипов. Сумма вознаграждения: Договорная. Ориентируемся на цену выше рынка, т.к. качество работ имеет ключевое значение. Ищем настоящих профессионалов в этом деле. <мой_Ник_на_форуме>@yandex.ru

+1 Полностью разделяю это мнение и применяю UVM на практике находясь в России. Скажу честно, понимание нахожу далеко не всегда. Однако ситуация со скрипом меняется.

http://verificationhorizons.verificationac...et_vh-v8-i2.pdf К слову, ресурс http://verificationacademy.com очень рекомендую. Там можно найти ответы на почти все вопросы. А остальные просто задать. Для полного доступа там нужна регистрация, но ее не так сложно пройти. Обладать лицензиями Mentor Graphiсs при этом не обязательно. 100% Code coverage нужен только тогда, когда вы занимаетесь проектированием ради самого процесса проектирования. При решение реальных задач перфекционизм не уместен. Даже если речь об авионике и прочих ответственных задачах 100% Code coverage никогда не бывает. Верификация всегда базируется на балансе между достигаемым эффектом и затраченными усилиями. UVM, помимо прочего, призван это соотношение улучшить. Улучшить, но не идеализировать. Вообще 100% проверку теоретически может дать только формальная верификация. Но это больше красивая теория. А теперь нужно вспомнить о функциональной верификации (functional verification). И это куда более важный аспект верификации, чем просто code coverage. Потому как код вы может и проверифицируете, а вот делает ли ваш код то, что задумано - большой вопрос! И куда более важный. И вот здесь уже % coverage субъективный параметр. Т.к. все зависит от того, насколько детально и правильно вы описали требуемую функциональность устройства. Грубо говоря, процесс может превратится в бесконечный. Здесь решающим фактором будет являться опыт людей, ставящих задачу верификаторам. Но это вы прям как не в России живете. ;) Отрадно слышать, что кто-то здесь еще верит в справедливость мира...

Скорее "Молодой, но образованный коллектив." Опыт и ученые степени - отнюдь не одно и то же. По вами же указанной ссылке написано, что сейчас в работе версия только со 100 ядрами. Версия с 1 000 ядер пока только планируется. Оба проекта, при этом уже опаздывают от планируемых дат, как минимум, на 3 года. А указанных в начале 10 000 ядер даже и в планах пока нет. За такие навыки, на мой взгляд, вы маловато (80-130 на руки) предлагаете. Так же вы зря намешали к этим требованиям еще кучу всего, что знали. Знание Xilinx Vivadо, программирования embedded-систем на языках Си, ассемблер и т.п. Складывается впечатление, что в проект требуется "спасатель". Т.е. тот, кто заставит это все работать, да еще и в кристалл положит на tsmc.

Круто! :a14: Удивительно, но в мануале Квесты про то, что можно одну библиотеку мэпить на другую. (т.е. как у вас: vmap work lib_8) ни словечка не сказано! Написано только: "The vmap command defines a mapping between a logical library name and a directory by modifying the modelsim.ini file." А то, что вместо directory можно указывать имя другой библиотеки, ни словечка. Это как раз то, что я имел ввиду, когда писал в первом посте: "Возможно, этот недостаток можно обойти, если использовать ссылки на библиотеку work." Спасибо за помощь! Теперь буду применять предложенный метод к проекту. Возможно, всплывут еще какие-нибудь моменты. По результатам, отпишусь!

Вы правильно помните, generic в vhdl передать нельзя. Я не до конца понимаю в вашем предложении вот что: Например, библиотека c описанием типов шины называется Amba. Обе версии контроллера ссылаются на две разные копии библиотеки (по разному сконфигурированные). (т.е. содержат: use Amba.axi.all;) Тогда при компилировании первой библиотеки в QuestaSim мы получаем скомпилированную библиотеку Amba и my_ram_ctrl_data_x8_lib. Но ведь при компилировании второй библиотеки мы получаем опять скомпилированную библиотеку Amba и my_ram_ctrl_data_x16_lib. Т.е. у нас две скомпилированные библиотеки Amba. Как мы их можем подключить в один проект? Где я рассуждаю не правильно? :laughing: Может все станет ясно, если вы поясните мне, что именно вы подразумеваете под термином "compilation unit"? Из мануала к Квесте я понял, что фокус с "compilation unit" можно делать для system verilog. Цитата: "vlog -mfcu Instructs the compiler to treat all files within a compilation command line as a single compilation unit. Optional. The default behavior is to treat each file listed in a command as a separate compilation unit, per the SystemVerilog standard. Prior versions concatenated the contents of the multiple files into a single compilation unit by default." А как провернуть такое для vhdl?

А разве упомянутые вами vqm файлы это не "Verilog Quartus Mapping File"? Изъяснялись бы тогда без аббревиатур. По моему можно обойтись только одним враппером, т.к. проблема изначально состоит именно в совместном использовании двух блоков на одном уровне иерархии. Часть проекта, использующая одну из конфигурций, будет компилироваться для моделирования и синтезироваться в нетлист отдельно. И подключаться в проект уже в скомпелированном виде. Решение не самое удобное. Но все же это решение. Спасибо за идею! Геморой только в данном случае. При использовании в одном проекте двух разных конфигураций. В остальных случаях ссылаться на одни и те же исходники из множества проектов, очень даже удобно. Даже удобнее чем: Хотя так конечно тоже можно поступать. Да, можно было бы все-таки пойти по варианту 1 с unconstrained std_logic_vector. А в компонентах сажаемых на шину завести соответствующий generic. Но тут встает проблема с еще одним ограничением vhdl. unconstrained std_logic_vector нельзя использовать в record-e. Приведу сразу "проблемные" строки: файл 'axi_config_pkg.vhd': constant c_XDataWidth : positive := 64; constant c_XWStrobeWidth : positive := 8; файл 'axi_pkg.vhd': subtype st_XData is std_logic_vector(c_XDataWidth - 1 downto 0); subtype st_XWStrob is std_logic_vector(c_XWStrobeWidth - 1 downto 0); type t_XWDCh is record WID : st_XID; WDATA : st_XData; WSTRB : st_XWStrob; WLAST : std_ulogic; end record;

Описанный вами путь подходит для сборки готового, отлаженного проекта. А как сделать его таковым? Т.е. как его отладить? Надеюсь вы согласитесь, что моделировать нетлисты с целью отладки - лишено смысла. Так что позвольте не согласиться, проблема тут есть!

Попробую описать проблему по-другому. Имеется некоторый компонент, состоящий из иерархии более мелких под-компонентов. Компонент и все под-компоненты используют некий под-тип (subtype) определенный в общем для этих компонентов packag-e. Стоит задача использовать в проекте 2 экземпляра (instanc-a) этого компонента отличающихся друг от друга определением под-типа (subtype). Т.е. использующих разные (каждый свой) packag-и для определение этого под-типа. Например. Имеется контроллер памяти способный работать с памяться разной ширины (n = 8, 16,.. бит). При этом он использует под-тип: subtype st_MemData is std_logic_vector(n-1 downto 0); определенный в packag-e. Где n задается взависимости от ширины используемой памяти. Как использовать 2 экземпляра этого контроллера в одном и том же проекте для 2-х памятей разной ширины? Чтобы один экземпляр используя тип st_MemData работал, например, с std_logic_vector(7 downto 0) а второй, используя тот же тип st_MemData работал с std_logic_vector(15 downto 0)? :help: Вот нашел обсуждение этой же проблемы на буржуйском форуме: http://www.velocityreviews.com/forums/t293...dl-package.html Тут она описана по-другому, но смысл тот же.

Потому, что придется делать две копии всех блоков разработанных под эту шину. Одна копия будет ссылаться на одну библиотеку, а вторая на другую. Блоки постоянно совершенствуются. Изменения придется делать в обеих копиях. А использовать обе копии одного и того же блока на одном уровне иерархии будет нельзя, т.к. имена типов буду совпадать. Если использовать развернутые имена типов или вообще переименовать их, то это уже далеко ни одна строчка. А точнее это то же самое, что еще одна копия шины и всех блоков под нее отличающихся только названием библиотеки и названиями типов. Т.е. все разработки x2

Да, сопряжение компонентов из разных библиотек это еще отдельная задачка. Вижу пока такой вариант: В top-е компонент осуществляющий переход из одной шины в другую преобразует интерфейс сначала к стандартным типам. Затем этот интерфейс подключается к блоку, содержащему в себе всю часть схемы относящуюся ко 2-ой шине. А внутри этого блока происходит преобразование стандартных типов уже в типы 2-ой шины (2-ой библиотеки). Таким образом, в top-e объявляется 1-ая библиотека, а в этом блоке 2-ая библиотека. Тем самым мы избегаем неопределенности и соответственно необходимости развернутого указания типов. Спасибо. Буду рад любой помощи!

Так а я как раз хочу в этом месте оставить одинаковые названия! т.е. ссылаться на одноименные packag-и находящиеся в разных библиотеках. У каждого компонента в его библиотеке свой package. А т.к. вместо имени библиотеки я хочу подставить work, то указанная строчка будет выглядеть одинаково в компонентах из разных библиотек. Вопрос будет ли это работать? Я использую менторовский HDL Designer, и могу соотвественно во второй библиотеки сделть просто link на файл с архитектурой из первой. Оставив тем самым единственный "исходник", а значит все изменения в нем будут распространяться на обе библиотеки сразу. Вариант 3. А как на счет использования конфигураций для решения указанной задачи? Кто-нибудь использовал их в таком ключе?