[a123-flex 0]

Возникла потребность сделать pin planning на xilinx.

 

В проекте есть всякое - и source - синхронное и mgt и eth mac и ddr и еще по мелочи.

Вроде задача не самая страшная, даже постеснялся выложить в работу.

 

Но нескольких вполне приличных разработчиков спросил: времени - неделя, денег - плачу.

Все в отказ - говорят очень много хочешь, боимся не уложиться в срок.

 

Однако вот здесь: https://forums.xilinx.com/t5/Spartan-Family...cks/td-p/156482

тичер from хилых говорит "да что вы ребята, вам что часа-двух жалко, чтобы проверить все свои страхалки ?"

 

Хочется понять, это я такой дремучий и неприятный, или просто тичер работать не хотел, и отделался рекламой?

[jojo 0]

Возникла потребность сделать pin planning на xilinx.

 

В проекте есть всякое - и source - синхронное и mgt и eth mac и ddr и еще по мелочи.

Вроде задача не самая страшная, даже постеснялся выложить в работу.

 

Но нескольких вполне приличных разработчиков спросил: времени - неделя, денег - плачу.

Все в отказ - говорят очень много хочешь, боимся не уложиться в срок.

 

Однако вот здесь: https://forums.xilinx.com/t5/Spartan-Family...cks/td-p/156482

тичер from хилых говорит "да что вы ребята, вам что часа-двух жалко, чтобы проверить все свои страхи ?"

 

Хочется понять, это я такой дремучий и неприятный, или просто тичер работать не хотел, и отделался рекламой?

 

Что сами не сделаете тогда за неделю? Одна ножка не туда - и IP не взлетает, а плату - в ведро... Опасно.

[alexadmin 0]

Чисто технически (с точки зрения RTL-разработчика) - надо взять всю вашу периферию, особенно высокоскоростную, посмотреть в каких режимах она подключена и сделать соответсвующий проект-затычку, содержащий все ip-ядра, клоки, скоростные интерфейсы и т.п. Час-два это излишне оптимистично (разве что ничего специфического нет, но ваш случай выглядит сложнее), но неделя - вполне разумная величина с запасом, чтобы накидать нечто проходящее компиляцию.

Другое дело, что вам ведь требуется не проверить имеющуюся раскладку, а спланировать - а тут уже надо влезать в вопросы выбора питания банков, трассировки платы, габаритов и т.п. Возможно потому никто и не хочет заморачиваться.

[a123-flex 0]

Чисто технически (с точки зрения RTL-разработчика) - надо взять всю вашу периферию, особенно высокоскоростную, посмотреть в каких режимах она подключена и сделать соответсвующий проект-затычку, содержащий все ip-ядра, клоки, скоростные интерфейсы и т.п. Час-два это излишне оптимистично (разве что ничего специфического нет, но ваш случай выглядит сложнее), но неделя - вполне разумная величина с запасом, чтобы накидать нечто проходящее компиляцию.

 

м. я может чего-то не понимаю. Но ведь синтезатор очень умный, и все что реально не используется, он просто выкинет.

Это значит что должна еще быть некая логика, связывающая между собой ядра...

 

Именно на это и нужно время (как по мне).

Как тогда этот гуру предполагал уложиться за час, если речь шла именно о скоростных source-синхронных интерфейсах именно на 6 спартане, у которого куча ограничений на раскладку клока ?

 

Или имеется в виду воткнуть ядра и запретить их выбрасывать ?

[alexadmin 0]

м. я может чего-то не понимаю. Но ведь синтезатор очень умный, и все что реально не используется, он просто выкинет.

Это значит что должна еще быть некая логика, связывающая между собой ядра...

 

Именно на это и нужно время (как по мне).

Как тогда этот гуру предполагал уложиться за час, если речь шла именно о скоростных source-синхронных интерфейсах именно на 6 спартане, у которого куча ограничений на раскладку клока ?

 

Или имеется в виду воткнуть ядра и запретить их выбрасывать ?

 

Ну в этом смысле все не так фатально - достаточно подать биты со счетчика на выходные интерфейсы или собрать все входы логикой и вывести на любой неиспользуемы пин - и соптимизировать уже не получится (ну либо кнстрэйны специальные наложить, запрещающие оптимизацию). Если говорить об о скоростных интерфейсах на обычных i/o, то основная проблема - в зависимости от выбранной схемы реализации могут быть разные требования к тактированию (разные буферы, разные пути прихода клока). И тогда уже "затычки" может не хватить, а нужно разработать полноценный интерфейс. Если у вас уже такой есть под текущее семейство FPGA - тогда вопрос действительно на час-два, а если нет - то пока в живую не заработает наверняка и не скажешь ;)