v_mirgorodsky

На данный момент используем в проекте Cyclone EP2C8F256. Для синтеза используем Synplify версии 8.5. В большинстве случаев результаты синтеза неудовлетворительные :( Synplify не имеет временных параметров моделей памяти и не умеет нормально синтезировать аппаратные умножители. В результате получаются, мягко говоря, странные результаты синтеза. Последующая имплементация в целевую микросхему с туго затянутыми параметрами многое исправляет, однако далеко не все. Таким образом получается дизайн, который не разгоняется до своей нормальной рабочей частоты. Приходится в Quartus генерить все примитивы и вставлять их в RTL код, что уменьшает его переносимость и добавляет проблем при отладке. Не знает ли кто, как бороться с этой напастью ? Может поменять синтезатор ? На какой ? У кого какие впечатления от менторовских продуктов ? Если я правильно помню, у них их два. Чем они отличаются друг от друга ?

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

К сожалению FPGA совсем не подходит для работы с FAT32 :( Скорость получится очень незначительной, да и поддержка файловой системы превратится в кошмар. Для поддержки файловой системы нужен процессор. Можно встроенный в FPGA. Другим методом может быть предварительное форматирование устройства на назком уровне в формате FAT32 с расположением по фиксированным секторам таблицы ссылок на непрерывные файлы. Таким образом для пользователя карта памяти будет выглядеть как куча файлов и один файл ссылок. FPGA считывает файл ссылок из фиксированного места, пишет свою инфу в своем формате в заранее пресозданные файлы, а пользователь может их считывать потом в USB Mass Storage. Таким образом все существенно упрощается.

Путаеш, по стандарту 4 штуки максимум. Дальше необходимо ставить мосты. Если посмотреть PCI-Scope'ом на шину, то получится что на 5 PCI слотов стоит два моста. По крайней мере это имеет место быть в нашей рабочей материнке.

А зачем нужно временное моделирование? Еще раз перепроверить математику Quartus или ISE? Реально файл задержек является порождением математического аппарата соответствующего програмного продукта. Даже если временные модели содержат серьезную ошибку то это не будет заметно при временной симуляции, при том что оконечное устройство может не работать или сбоить. Временной анализ проекта на 5-6 тысяч логических ячеек вполне может оказаться нереализуемой в реальные сроки задачей. В то же время временная симуляция небольших кусков кода не имеет смысла, потому как оконечные результаты сильно зависят от оконечной раскладки.

Угу, но в последовательной цепи через все элементы схемы течет одинаковый ток. Потому, если на входе у меня 2мА, то 2мА будет и на приемнике, а значит на активном нагрузочном сопротивлении в конце линии будет 0.15В и какая разница какое напряжение должен выдать мой выходной усилитель чтобы обеспечить этот ток в линии? Да, есть небольшая проблема в необходимости аналоговой линии задержки в цепи управления, но это сейчас решаемо.

А можно сильно чайниковский вопрос По идее во всех приемниках исходя из требований по волновому сопротивлению практически обязательно будет активное сопротивление номиналом 50-75 Ом. Таким образом ставим на передающем конце токовый шунт, меряем ток в линии, а дальше все должно получиться просто. При этом на приемном конце не нужны никакие корректоры АЧХ, можно передавать видеосигнал хоть на 10 км, лишь бы выходной каскад был достаточно мощным. При этом передающий усилитель автоматом настроится на любую протяженность линии. При этом нет необходимости изменять схемотехнику приемника. Короче - слишком хорошо, чтобы быть правдой :cranky: Возможным недостатком решения будет отсутствие гальванической развязки между передатчиком и приемником и необходимость "махать" дурными вольтами на сравнительно высоких частотах (по оценкам на 10 км необходимо "махать" выходным напряжением порядка 20-30 вольт :blink: ). Если в моих рассуждениях есть логика, то почему так не делают? Если делают, то где можно посмотреть схемы и примеры решений?

Степень "случайности" генерируемой последовательности для конкретно этой задачи значения не имеет. Если два соседних числа отличаются хотя бы одним битом, то SHA1 даст абсолютно разные решения. Даже если генерируемая последовательность будет не вполне "случайна", то период ее все равно будет много больше реально "перебираемых" вариантов. Гораздо более серьезным вопросом является возможность считывания кода из EEPROM под электронным микроскопом. Если верить моим знакомым, то здесь за ATmega с битом защиты у них просили около 10-12k$ - не думаю, что далласовская EEPROM-ка будет стоить намного дороже.

С точки зрения банальной эрудиции а также парадоксальной логики и учтывая скольжение парашута по наклонной плоскости, введя поправку на положение Нептуна в области Гончих Псов можно придти к следующим выводам ... Не сочтите за неуважение, однако именно так, с моей точки зрения, выглядят коментарии на вышезаданный вопрос. По моему разумению - отвечать человеку необходимо в пределах его понимания вопроса, или сказать, что вопрос слишком сложен и не может быть детально рассмотрен в пределах форума. IMHO, просто обидно, когда интересный и познавательный вопрос превращается в повод для профессионального флейма участников, терминология которого понятна, в основном, только отвечающим.

Поздравляю :) Что-то в этом роде я и предполагал ;)

Тады надо смотреть взаимные отношения между Arinc_rise_time и Data_in_X. Возможно моменты их изменений совпадают или "плавают" вокруг совпадения. Я бы попытался "подвигать" строб разрешения данных по импульсу взад-вперед для проявления полной картины. В чем разница синтеза. Это хороший вопрос. Похоже, что вы пользуетесь одной из последних версий ISE и сравнительно старой версией Synplify. ISE в последнее время поменял стратегию размещения элементов на кристалле для минимизации интерконнектов между элементами схемы, а Synplify вашей версии все еще размещал элементы геометрически. Возможно в этом есть вопрос. Еще - возможно включена опция ретайминга. В этих случаях Synplify умеет активно двигать триггера по ассинхронным цепочкам для максимизации рабочей частоты. Это тоже может быть проблемой в вашем случае. Ну вот и все мои идеи и предположения. На схему из десятка триггеров с двумя компараторами больше ничего придумать не получается :( Был бы очень заинтересован услышать окончание истории, потому как ситуация очень нестандартна. А в общем - чудес не бывает. Это означает, что данное поведение имеет какое-то рациональное объяснение. Как я понимаю, ваши рабочие частоты очень далеки от критических, потому схему обязательно надо подружить с Synplify или понять что идет не так. Потому как в последствии эта ошибка может проявиться при перемещении элементов по кристаллу или при большом заполнении кристалла.

Похоже, что Data_in_X ассинхронна по отношению к clc. Потому я думаю, что проблема кроется в метастабильности входного триггера tRising_X. Как синхронизатор tRising_X работать будет плохо, потому как имеет некоторое количество логики между триггерами. Для начала я бы попробовал поставить дополнительных два триггера на Data_in_X без enables, resets, etc. Может быть поможет. А еще посмотрел бы на способ формирования Arinc_rise_time - возможно ее перепад совпадает с изменением данных. На сколько я понимаю - Arinc_rise_time - это enable, подстроенный под бодовую частоту.

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

Просто он будет иметь больше времени для разрешения метастабильности. Потому на высоких частотах и ставят три и более триггеров в синхронизационную цепочку. Более того, триггера должны быть без дополнительной логики управления и расположены как можно ближе друг к другу. Количество триггеров в цепочке и MTBF определяются по специальным формулам, которые на практике использовать лень :) потому, если частота работы триггера далека от теоретически максимальной, то в большинстве случаев двух триггеров в цепочке достаточно. В ASIC есть специальные ячейки у которых второй триггер имеет очень высокий коеффициент усиления входного каскада. Таким образом разрешая метастабильность более еффективно, нежели стандартные триггера в FPGA.

Больше всего о метастабильности мне понравилось у Ховарда Джонсона. Он предлагает моделировать триггер как входной конденсатор и усилитель. В то время, когда триггер чувствителен к входному сигналу входной сигнал "заряжает" этот конденсатор. Если времени было недостаточно, то триггер в конце концов "сползет" к одному из известных состояний, однако это может занять сравнительно длительное время. Таким образом триггер будет находиться в метастабильном состоянии тем дольше, чем дальше от фиксированных значений находится его условный входной "конденсатор". Это объясняет повышение вероятности метастабильных состояний с ростом частоты и необходимость установки более чем одного триггера в синхронизирующую цепочку при определенных частотах. Касательно вашей проблемы - вероятнее всего у вас ошибка в логике. Потому как метастабильность имеет случайный характер, а у вас проявление сбоя всегда одинаково.

www.micron.com - там тебе помогут :) Сами отлаживали свой контроллер пользуясь их моделями.

WiFi - сокращение для Wireless Ethernet, подробно описан в семействе стандартов IEEE 802.11. Datashit - в написании есть грамматическая ошибка - правильно будет DATASHEET - техническое описание любой микросхемы или любого другого компонента, даже целого устройства, обычно создается и модифицируется производителем компонента, устройства и т.п. Еще проще пользоваться Wikipedia: Datasheet, WiFi Человек, ответивший Вам в ключе - "будет и на вашей улице праздник" - просто нахамил :maniac: Думаю, что при желании Вы можете обратиться с жалобой на его действия к модератору форума.

Да действительно при регистрации проекта цена на чип падает примерно в два раза, но это все равно очень дорого для этого проекта. :(

Не-а, цена на Virtex4 слишком большая :blink: порядка $200 за корпус. А так, решение с Virtex4FX было бы очень даже ничего :)

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

Возникла задача создания устройства со следующими характеристиками: средней скорострельности CPU c GPIO под управлением *nix подобной ОС поддержка ATA/SerialATA/CompactFlash HDD с FAT32 поддержка TCP/IP по Ethernet 10/100 возможность доступа к локальному винту через USB Mass Storage возможность оперативной отправки части записываемой информации на винт по сети возможность подключения к устройству стандартных коммуникационных USB устройств Отсюда выглядит так, что в качестве операционной системы системы необходимо брать обычный Linux. Он сам по себе умеет работать с FAT32, имеет поддержку IDE, сетевых протоколов и для него существуют драйвера под стандартные коммуникационные USB устройства. К списку приведенному выше придется дотачать собственно, прикладную программу, занимающуюся обработкой данных, записью их на винт и отправкой в сеть, драйвер источника этих самых данных и арбитраж с внешней системой, пытающейся получить доступ к внутреннему винту по USB Mass Storage. Все остальное тем или иным образом включено в ядро Linux или может быть откомпилировано в качестве прикладных программ. Теперь к выбору процессора. Существуют ли процессора, имеющие на борту все из выше перечисленных интерфейсов? Самым перспективным на данный момент является AXIS ETRAX100LX. У него на борту есть встроенный IDE, DDR SDRAM контроллер, Ethernet 10/100, USB Host (к сожалению, только 1.1), он поддерживает GPIO и на него честно портирован Linux. Плюс в процессоре реализованы механизмы управления виртуальной памятью, a-la x86 Protected Mode. Сильно смущает только его частота, составляющая "всего" 100MHz. Другим кандидатом в процессора для этой системы выступает ARM AT91RM9200. Управление виртуальной памятью, как я понял из даташита - отсутствует. У него частота повыше, однако у него нет встроенного IDE, а это значит, что драйвер IDE под Linux придется разрабатывать самому. К тому же не до конца ясен статус порта Linux ядра для него. Я знаком с отладочной платой AndiBig, однако еще не видел информации об успешном запуске на этом процессоре полноценной OС. Плюс не ясно, как может функционировать Linux ядро без полноценной системы виртуальной памяти. Вот так и проходит время :cranky: Мож у кого есть какие мысли в пользу одного или второго решения?

Пасибо, успокоил :cheers: В принципе, мы уже во многих местах узнавали, никто не дает никаких серьезных причин этого не делать. Все говорят что нестандартно, а раз нестандартно, то есть вероятность проблем. Короче, выглядит так, что надо все проверять на реальном железе :cranky:

Наш изготовитель дал идентичные цены на плату со стандартным падстеком и на этот падстек, потому шестислойная плата будет значительно дороже :blink:

структура действительно оригинальная... не совсем понятно зачем Вы между слоями питания размещаете сигнальные слои? В такой структуре заложены следующие неприятности: 1. Сигнальные трассы становятся Вам недоступны и если что - Вы не сможете их подкорректировать скальпелем :) 2. Слои питания разнесены и уже не работают как высокочастотный конденсатор. Для работы полигонов питания как ВЧ конденсатора имеет значение расстояние между слоями. В нашем случае расстояние между полигонами питания на 0.125 мм больше, что составляет ~10% по сравнению с классическим расположением слоев, приведенным в Вашем посте. Ну, здесь все верно, за исключением общей толщины платы :) Общая толщина платы в нашем случае составляет около 1.5 мм, 5 - это милы :cheers: При размещении 0402 конденсатора непосредственно под выводами BGA обеспечивается минимально достижимая индуктивность между конденсатором и выводом питания. Расходы на подключение конденсатора к полигону питания и в одном и во втором случае практически идентичны. В нашем случае даже немного лучше, так как соединение с полигоном питания осуществляется без использования "лишнего" переходного отверстия. Расстояние между 2-ым и 3-им слоями составляет 1.25 мм, при толщине платы 1.5 мм. А это уже на ВЧ не такой хороший конденсатор :cranky:

2 Jul: Общая толщина платы получается порядка 1.5 мм, переходные отверстия - 0.2 мм отверстие и 0.4 мм - поясок в пределах BGA корпусов и 0.3/0.5 в других областях. На внутренних слоях неподключенные пояски мы собираемся удалить для большей целостности полигонов. 2 Zeroom: Не знаю, производитель китайский, плату в таком падстеке изготовить берется. Остальное для меня несущественно. Габариты платы - 120 x 50 мм.