per_aspera_ad_astra

Самое главное что-бы у вас _N и _P в правильном месте были (на одном буфере)! Может в этом и проблемма?

LVDS интерфейс оперирует разницей уровней на N и P выводах (дифференциальным напряжением), поэтому возможно реализовать (хотя конечно это неправильно). Например на Spartan-6 в DC характеристиках (ds162.pdf) LVDS_25, LVDS_33 идут одной строкой VL = 1.25 – 0.125 B, VH = 1.25 + 0.125. Посмотрите подобные параметры на микросхему которую хотите подсоединять и на ПЛИС.

Тем кто думает стоит покупать в Китае или нет (если такие имеются), пару комментариев: 1. Микросхемы из Китая будут упакованы не в фирменной вакуумной, антистатической, с силикагелем, индикатором влажности и надписью "монтировать в течении 360 часов" упаковке, а в куске отпиленного палета, завернутого в пищевую пленку; 2. Оплата через юридическое лицо превращается в геморой с таможенным контролем, так что придется покупать за начичку на домашний адрес и соответственно разница в цене будет уже не такой значительной.

Обратно в ISE проекте Pblock появляется в ucf-файле. Вы отдельный проект для этого модуля в PlanAhead создавали? Можно добавить эту часть в общую ucf проекта, либо запустить PlanAhead из под ISE (User Constraints -> I/O Pin Planing (PlanAhead) - Post-Synthesis), тогда проекты будут связаны. Не забудьте только в VHDL поставить атрибут на модуль, что-бы он иерархию сохранил. attribute KEEP_HIERARCHY : string; attribute KEEP_HIERARCHY of wrapper_gtx_dru_inst : label is "TRUE"; Да... и ucf скопируйте (особенно если он у вас красиво отформатирован) куда нибудь отдельно, а то PlanAhead когда будет свои констрейнты дописывать вам его подпортит :-)

Существует два основных подхода это Implement Design in XPS и Implement Design in ISE. В первом случае вы используете EDK, а что-то внешнее (ваши модули) подключаете как Peripheral к процессору. Во втором наоборот, вы в свой VHDL/Verilog подключаете процесор как обычный модуль или IP-core, для работы с ним из ISE будет подгружаться EDK. Сигналы которые вы увидите в описании PPC как компонента, это external signal в EDK (все внутренние соединения, такие как память, MPMC, BRAM в ISE будут не видны). Второй путь во всех документах помечен как - deprecated, но я так понял по вашему посту вас это совсем не смущает, а даже радует :-) Вообще эта тема достаточно интересная и можно долго по этому поводу спорить. У нас тоже все разработчики только на ISE сидят и никакие маршруты (мировозрения) менять не хотят.

Пропускную способность хотелось-бы получить порядка 160 Мбайт/с. А со сколькими линиями у вас используется Aurora? И какие показатели получаются? Она у вас с потоковом или пакетном режиме работает? А по LocalLink сколько получается?

Подскажите, кто как делает связь между кристаллами на одной плате (линии порядка 50-70мм)? На плате стоят два кристалла, но в маленьких корпусах (665), поэтому есть соблазн увеличить пропускную способность, между кристаллами используя дифференциальную линию, подключенную к RoctketIO. Пока решили использовать протокол от Xilinx Aurora, но это пока только прикидки, на всякий случай сделали возможность изменять REFCLK под другие стандарты.

Если тактов хватает, то можно через общее кратное, через 8 битную FIFO. Вся логика это 2 счетчика (один до 3-х второй до 2-х) и никаких FSM. Самое главное это лишнего чего не прочитать из нее, а для этого нужно флаги заполненности правильно запрограммировать, чтобы быть уверенным, что в FIFO есть больше или хотя бы два байта.

Здравствуйте! Все логично, он указывает на байт H4 заголовка VC-4(3) (POH), по которому мы понимаем какой именно из байтов V1, V2, V3 и V4 заголовка VC-12 находиться в данном кадре STM (Figure 8-9/G.707). Но не понятно, какое положение этого байта (положение сигнала ICTMF) нужно указывать, а как же цифровое выравнивание? Если оно произойдет во входном потоке, получается нам тоже его «двигать» придется? Раз ICTMF появляется раз в 4 фрейма, тогда на какое значение байта H4 (на какой из V1, V2, V3 или V4 указывает)? Просто если следовать рекомендации он должен появляться каждый фрейм и изменять 2 бита, образуя там самым мультифрейм. Получается начало контейнера VC-4(3) находится на 522м байте… а оно всегда там будет (опять к вопросу о выравнивании)? Насколько я понимаю, есть обратная связь. Мы смотрим заголовки, которые приходят из входного потока, и формируем в соответствии с ними сигналы на входе или мы подаем какую-то идеальную «картину» а TRANSWITCH уже сам преобразует в соответствии с тем что идет во входной линии… что-то я совсем запутался…

Хоть программистом! Сам на эту специальность учился. Вообще специальность очень обширная. Раньше, когда микросхемы были большими, была специальность Конструирование и технология радиоэлектронных средств. Со временем стало понятно, что нужны не чисто конструкторы и технологи, которые знают как правильно сконструировать устройство для определенных условий эксплуатации, как его охлаждать, как сделать так чтобы микросхемы не отлетели когда устройство в космос полетит, как ручки расположить и какие они должны быть чтобы пилот самолета в штопоре на нее нажать смог, как плату, в конце концов, правильно развести, а также госты... ту... госты... ту... госты... (мало не покажется) Но еще и схемотехники со знанием радиоэлектроники, чтобы знать что-за волновое сопротивление такое и как его посчитать, и два проводника рядом на платке, наверное, не просто так, и крышечки какие-то жележненькие припаяны. Поэтому изменили одно слово и добавили в программу еще предметов :) Идея-то хорошая была.. но... как и везде... беда с образованием у нас в стране. Получается в итоге эдокий бакалавр (магистр) который во многих областях верхушек нахватался. В общем если у вас лежит душа к различным микросхемам и платам, то вы и научитесь, если нет, то поищите другую специальность для себя. Из моего потока только пару человек работают непосредственно по специальности. Но за счет того, что кругозор во время изучения разносторонних предметов у народа повысился им легко найти себя в любой смежной области.

На выставке (какой не помню) был красивый стенд фирмы Jtag-Technologies (http://www.jtag-technologies.ru) их продукты позволяют делать переферийное сканирование, в принципе как они обьясняли в этом вся фишка и есть их продукции + быстрые модули ввода-вывода ихнего-же производства. Мы рассматривали данную технологию в качестве альтернативы летающим щупам, но остановились почему-то именно последнем варианте :-)

В UDP возможны потери пакетов, скорости которые приведены это учитывают? А каким методом вы проверяли потери пакетов и какова была конфигурация сети?

Сталкнулись с проблеммой, сделали трафарет для нанесения паяльной пасты напрямую с платы (экспортом слоя с контактными плащадками), с незначительной дороботкой которая касалась в разбиении больших контактных площадок на фрагменты (для того что-бы рекелем пасту паяльную не выгребать). В итоге получилось что некоторые ножки микросхем спаиваются, слишком много пасты. Трафарет в итоге пришлось переделывать. Скажите, нет-ли какого нибдь CAMа позволяющего правильно расчитывать необходимый обьем паяльной пасты и учитывая толщину трафарета изменять размеры отверстий или их форму? Заранее спасибо!

В природе нет такого триггера который может по двум фронтам работать. Ставьте два. Один по CLK0 второй по CLK180. Если речь идет о DDR то ставьте специализированные компоненты название у них различное, в зависимости от того какой кристалл используете. Например в Virtex-4/5 это IDDR/ODDR.

:bb-offtopic: Я-бы сказал пожалуй так: "Только в Москве FPGA специалист вообще хоть что-то зарабатывает". А во Владимире мест где может работать FPGA специалист можно пересчитать по пальцам одной руки, а про зарплату вообще стыдно говорить даже... И самое обидное то, что Владимир в трех часах езды от Москвы и специфика работы позволяет работать удаленно не мотаясь каждый день. Но а 1С программист везде нужен! :)

Проблемма скорее всего в том что модели памяти поведенческие (в вашем случае файл mt48lc4m32b2.vhd/.v) и просто не предназначены для Post-Map и Post-Route моделирования. Посмотрите внимательнее на исходный код.

А кто такой брам? Если имелось в виду RAMB, то можно сделать к примеру так: RAMB16_S4_S18_loop : for i in 0 to 1 generate RAMB16_S4_S18_inst : RAMB16_S4_S18 port map ( DOA => DOA(i*4 + 3 downto i*4), -- Port A 4-bit Data Output DOB => DOB(i*16 + 15 downto i*16), -- Port B 16-bit Data Output DOPB => open, -- Port B 2-bit Parity Output ADDRA => ADDRA, -- Port A 12-bit Address Input ADDRB => ADDRB, -- Port B 10-bit Address Input CLKA => CLKA, -- Port A Clock CLKB => CLKB, -- Port B Clock DIA => DIA(i*4 + 3 downto i*4), -- Port A 4-bit Data Input DIB => DIB(i*16 + 15 downto i*16), -- Port B 16-bit Data Input DIPB => "00", -- Port-B 2-bit parity Input ENA => ENA, -- Port A RAM Enable Input ENB => ENB, -- PortB RAM Enable Input SSRA => SSRA, -- Port A Synchronous Set/Reset Input SSRB => SSRB, -- Port B Synchronous Set/Reset Input WEA => WEA, -- Port A Write Enable Input WEB => WEB -- Port B Write Enable Input ); end generate; DIA и DOA теперь 8 разрядные а DIB и DOB - 32-х. Я думаю не существенно какой порт какой, поскольку они в данном случае равнозначны!? А вообще в CORE Generator есть Block Memory Generator, можно сделать им все что душа пожелает :) .

Изначально полагалось что брутфорсер на FPGA делаться будет!? А удельная цена разве основной критерий? Да и понятно что киты универсальные и не все что там есть будет использоваться, но если покупать FPGA отдельную, то у нее цена не сильно различаться будет от стоимости готового кита. Хоть распаивай и на свои платы ставь! Как правильно заметил drop669 это политика такая, я не удивлюсь что фирмы которые свои чипы (интерфейсы, память, питание и т.д...) еще доплачивают чтобы их продукт на кит поставили.

Странно как-то, почему-то для увеличения производительности рассматриваете только распараллеливание алгоритма, но совсем не учитываете частоту, на которой все это дело работать будет. И еще в сравнении смотрите только на количество Slices, и не смотрите на количество Block RAM, или они в вашем алгоритме не используются? Мне кажется оптимальным в вашем случае именно что-то покупное, просто существует некоторая вероятность ошибиться в первом релизе чего-то самодельного (поправить я как понимаю бюджета не хватит). Например, можно посмотреть вот на это http://www.xilinx.com/products/devkits/HW-V5GBE-DK-UNI-G.htm только он предназначен для проектов с Gigabit Ethernet, но зато подешевел! :)

Как написано в одной умной книжке: "Одним из главных частных критериев выбора между аппаратной и программной реализацией функции является время, за которое эта функция должна выполнять свои задачи: • Пикосекундная и наносекундная логика — должна работать безумно быстро и реализуется аппаратно (в структуре ПЛИС). • Микросекундная логика — умеренно быстрая и может реализовываться как аппаратно, так и программно. Тип логики, при котором основная масса времени тратится на определение того, каким путём пойти. • Миллисекундная логика — используется при реализации интерфейсов, таких как опрос состояния переключателей или зажигание светодиодов. Основные усилия будут направлены на замедление аппаратной части при реализации этих функций; например, используя громаднейшие счетчики для генерации задержек. Таким образом, зачастую такие задачи лучше реализовывать в микропроцессорном коде, так как процессор позволяет снизить скорость по сравнению с аппаратной частью, но при этом задача может оказаться очень сложной." вроде все вполне логично...

Наверное, тема уже закрыта, но хотелось кое что добавить... и спросить… Делаем собственную разработку, один из модулей в ней ищет синхронизацию в потоке Е1. Алгоритм поиска сделан вначале был в принципе также как и описывалось выше (считается количество правильных и ошибочных FAS в четных кадрах и проверяется бит в нечетном и в зависимости от этого принимается решение), только с учетом того что байт потока Е1 не выровнен по границе байта входного потока, поэтому добавилось несколько стадий выравнивания по байту (ищется похожие на FAS данные) ну и компонент многоканальный (256 каналов). Но в реальных условиях обнаружилась интересная вещь: в одном из информационных тайм-слотах идет (причем очень длительное время) комбинация FAS, на которую пробуем синхронизироваться, но поскольку нечетные кадры не верны, сбрасываем поиск и начинаем новый. Но самое печальное, что опять попадаем не в «то место» (опять информационный тайм-слот) и все начинается сначала. В итоге пришлось модифицировать алгоритм, теперь он запоминает «неправильные места» и пропускает их, ну конечно если более лучшего ничего не найдет он будет пробовать опять тоже место. Но насколько это правильно??? Очень интересно как именно реализован алгоритм поиска в реальных микросхемах? Подскажите, пожалуйста, где найти документацию на микросхему, в которой это описано?

Возникла проблема - кристалл заполнился, и ядро (FGA Virtex 2Pro) начало потреблять около 6А. Самое время ( :) ) подумать об оптимизации не как обычно занимаемого ресурса и частоты работы, а потребления! Из мат.части знаем что КМОП логика потребляет только в момент переключения. Возникает вопрос, как грамотно описывать устройство, чтобы его потребление минимизировалось? Интересно, сколько потребляют встроенные умножители и блоки памяти и как правильно с точки зрения потребления с ними работать? Возникала у кого нибудь подобная задача?

Посмотрите еще MIG (Memory Interface Generator). У меня стоит ISE 9.2i IP Update 2, в нем две версии MIG 1.72 и MIG 2.0. Я пользовался последней версией. На ML506 SODIMMвская планка (DDR2) заработала без особых проблемм.

Долго думали и в итоге решили сделать две петли одна как на плате, вторая как в datasheet. Скоро уже должны приехать платы, посмотрим что из этого получиться.

Кто нибудь пробовал подключать DDR к Virtex2pro? В MIG (у меня стоит версия 2.0) можно сгенерировать контроллер под Virtex4-5 и Spartan3, но нет Virtex2pro… Хотя удивительно Spartan3 это урезанная версия Virtex2pro или даже Virtex2, если я ничего не путаю. Пробовал синтезировать контроллер под Spartan3 на Virtex2pro получилось без особых проблем (различия были только в подключении DCM). Все это делалось под плату собственной разработки. Вопрос собственно вот в чем, у DDR контроллера под Spartan есть два сигнала “dqs_div_in” и “ dqs_div_out ”, которые на отладочных платах под Spartan соединены между собой трассой, длина которой равна, если верить datasheet сумме длин проводников тактового сигнала (на DDR) и шины DQS. Но если повнимательнее изучить Gerber то длина меньше (приблизительно равна DQS). Так какой же должна быть длина этой трассы? Подскажите, если кто-нибудь знает, альтернативные решения как подключить DDR к Virtex2pro.