Перейти к содержанию
    

AsJohnAs

Свой
  • Постов

    120
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о AsJohnAs

  • Звание
    Частый гость
    Частый гость

Контакты

  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

1 800 просмотров профиля
  1. Если refclk хороший(40ppm), то хорошобы проверить что у самого SFP точно указано что он в 10G работает. Есть такие у которых это надо явно задавать. И еще качество питания надо проверить, может кто там шумит или оно чуууть ниже нужного
  2. У вас применяется код 64b/67b, но в Xilinx Aurora применяется 8b/10b. Т.е система кодирования у xilinx применена более мощная. Вы делали сравнение вашей системы и Xilinx Aurora на одних и тех-же линиях. Когда тестировали свою систему как проводили тесты? Аттенюаторы на линии или там подключение внешних генераторов или еще что. Интересен сам способ тестирования.
  3. Мне самому очень интересно как такое можно обрабатывать на ПЛИС..... Потому как при постановке задачи что сессий может быть почти любое кол-во и их размер то-же не ограничен. То выделение ресурсов должно будет выполнено динамически. Такие задачи не очень свойственны ПЛИС. Т.е. для такой задачи ножен процессор. Но так как сессий может быть очень много этот процессор должен собирать сессию без задержки так как сами пакеты могут быть разными. Надо сделать так чтоб приход короткого пакета не убивал разбор длинного. А у вас какая концепция - с какого бока планируете подойти?
  4. Ну для начала надо посчитать какое количество IPсессий все-же необходимо. Затем прикинуть какой размер IP сессии возможен. Далее рассматривается 10Гбит/c то какую скорость должна обеспечить память. Если сессий не очень много - ну допустим ~100 то может можно поставить небольшие 8ми битные процессоры, но много - по одному на IP сессию. Вообщем при расчете как я понимаю самая большая проблема будет в количестве блочной памяти внутри ПЛИС
  5. Закрываю тему - не правильно был написан IBUFDS_GTXE1 поэтому просто не было референса.
  6. Судя по посту тема уже давняя, но я попал ровно на тоже самое... plllkdet так-же не поднимается на плате ml605, а на ml505 работает на ура - референс беру с платы ml505
  7. А на счет исходников - то я поднимал тему на которую потом сам и ответил вот: http://electronix.ru/forum/index.php?showt...mp;#entry816857
  8. Да это сигналы разрешения использования сигналов запятых. Они нужны например в том случае если обучение нужно проводить только в самом начале работы или в определенных фазах
  9. А если чипскопом смотреть напряжение ядра? Оно менялось?
  10. Отличить те корки котрые симулейшен онли по исходникам очень легко :) А на счет попадались или нет... ну это как говориться кто ищет :) (вообще вопрос не корректный :) )
  11. Так чего в тех поддержку - я их код vhdl вижу. Там все нормально. Вообще кстати аккуратно написано и каждый процесс имеет свой комментарий.
  12. С лицензиями точно все в порядке - проверил логи. Да и теперь я собираю все из исходников... По поводу суппорта: а что я им скажу - у меня глючит ваша корка которую я случайно нашел? На счет исходника в студию... ну на самом деле не очень жалко но там просто набор корок Xilinx - как их выкладывать? исходники не буду :( А вот это то как раз самое удивительное!!! Это то и хочется понять! Сегодня по утру новые данные. Я оставлял множество плат с большим кол-вом экспериментов: Выяснил что выжила плата в которой было сделано так: --------------------------- TIMEGRP "DATA_GROUP1" =FFS ......./rxd_sync*; TIMEGRP "DATACE_GROUP1" =FFS ....../rxc_sync*; TIMEGRP "MAIN_GROUP1" = "DATA_GROUP1" "DATACE_GROUP1"; # Устанавливаем растояние между энейблом и данными меньше удвоенной тактовой TIMESPEC "TS_MAIN_GROUP1" = FROM DATA_GROUP1 TO DATACE_GROUP1 3.0 ns; --------------------------- Т.е. получается что rxd_sync и rxс_sync проходили разный путь находясь в одном блоковом домене но при этом сильно расходились так что это приводило к метастабильный триггера! И это не показывала среда разработки при отдельных констрейнах!. Да и вообще как могут два сигнала у которых нормально выполняются констрейны вместе не работать? Эта ситуация реально разрушает все мои понятия о том что xilinx называет синхронным дизайном. Может это еще не все и надо еще погонять прошивку. Да и вообщем вопрос не снят. Что происходит? откуда метастабильность! Еще не сказал что тактовая частоты около 150МГц для достаточно большого чипа Virtex5 fx100 причем самого быстрого(-3). Это значит что 10 часов на этой частоте это очень очень долго. Так как чип быстрый ему не очень тяжело перекладывать эти шины. Но с другой стороны так как чип большой - дизайн тоже не маленький....
  13. Если метастабильность то от куда? Констрейны выполняются и нет мультиклоковости, ресет чистый с выхода тригера. Прошивку проверял верифаем - она нормальная целая ..... И еще раз все сигналы образующие условие точно не асинхронны. И еще раз хочу отметить что это вырожение находиться по центру IP корки xilinx А вырожение находиться в нутри процесса и имеет синхронный ресет-я думал это понятно - сорри за не точность Ах да глюк проявляется на уйме плат - проверил на 6.
  14. Есть большая проблема с определением причины очень странного глюка: В кристалл Xilinx зашиваем проект и он нормально работает, но от 7 до 10 часов а потом одна его часть зависает. Теперь подробней: Путем долгих экспериментов выяснилось что зависает триггер причем внутри корки Xilinx (т.е. выходного сигнала перестает быть): start_flag <= (((EQUAL(rxd_sync(63 downto 56), SFD)) and (not rxc_sync(7))) or preserve_preamble) and start_code_found and enable; Сигнал start_flag перестает работать. При этом подача Reset на данный блок и соответственно на триггер который образуется данным условием не приводит к выводу системы из этого "зависшего" состояния. Причем даже после того как случилось это странное зависание можно с помощью чипскопа лицезреть наличие всех правильных сигналов которые присутствуют в условии. Проверялось: 1. Качественность раскладки сигнала в FPGAEditor 2. Констрейны 3. Питание ядра 4. Наличие reset и их синхронность для всех сигналов(reset заходит на ВСЕ сигналы-это отдельно проверено) 5. Глюк не связан с работой близ лежащей техники так как проявляется на платах расположенных в других отделах фирмы. 6. Без куллера кристалл нагревается до 71 градуса, но специально нагревал больше - вызвать глюк быстрее 6-и часов не смог Большущая просьба генерировать по больше разных версий из-за чего такое может быть!
×
×
  • Создать...