Jump to content

    

VslavX

Свой
  • Content Count

    1046
  • Joined

  • Last visited

Posts posted by VslavX


  1. Итак, от моделирования наконец добрался до практической трассировки платы. Ситуация относительно простая - один 64-битный банк, 16x4.

    Напрягает шина данных DDR и выравнивание проводников в ней. По временнОму бюджету по чтению тут такая ситуация - контроллер допускает разброс данных в 750ps относительно строба, самое неприятное, что это параметр не зависит от частоты - на 266/333/400 одинаково (видать реализация контроллера DDR основана на фиксированной задержке строба). То есть при неудачной трассировке послаблений не будет - снижение частоты никак не поможет. Из этих 750ps сама микросхема DDR "отъедает" 450ps, остается всего 300ps допустимого разброса.

    Изначально я предполагал провести все проводники в каждой отдельной byte lane одинаковым способом, но это топологически оказалось затруднительно (многорядный BGA) - часть проводников пришлось разбросать по разным слоям. Поскольку на внешних и внутренних слоях скорости сигнала разные, то выравнивание проводников по длине между собой потеряло смысл. К тому же число vias на каждой дорожке оказалось разным.

    Теперь у меня вопрос - насколько корректно в данном случае ориентироваться на табличку задержек моделируемую HyperLynx в пакетном режиме? Достаточно ли проконтроллировать задержки в группе по табличке и все? Кто-нибудь уже успешно трассировал DDR в разных слоях, какие методы контроля задержек использовались?

  2. Цитата №1 из datasheet на NAND flash K9WAG08U1A:

    An initial invalid block(s) does not affect the performance of valid block(s) because it is isolated from the bit line and the common source line by a select transistor.

    Из чего я делаю вывод: в структуре NAND при производстве могут возникать некоторые глюки, которые отлавливаются на этапе заводского тестирования и после их нахождения блок, который их содержит отключается от шины IO.

    ИМХО, здесь немного неверное прочтение - не отключается при"на заводе", а блокирован в процессе работы закрытым транзистором - это что-то вроде сигнала Chip Select. То есть, при обращении к рабочему блоку, активируется "select transistor" для этого блока, для всех остальных блоков (включая дефектные) - "select transistor" закрыты и блоки никак не влияют на обращение к активному блоку.

    Переходя от теории к практике... Есть платка - на ней одна flash на гиг, ПЛИС, которую научили писать, читать, стирать эту flash. Самопальное тестирование этой flash производится следующим образом:

    а. Стираем всю flash.

    А вот выполнять операции с дефектными блоками Самсунг не рекомендует. В каком-то из даташитов я читал, что заводское тестирование массива намного более полное чем возможно выполнить на упакованном чипе через интерфейс, и не факт что дефект удастся обнаружить простой записью моделей и последующим сравнением. Например - утечка заряда в блоке. Записали-прочитали - все OK. Через полчаса - половина битов в блоке принимает левые значения. И никакой Хэмминг тут не поможет. Так что самый ценный ресурс чипа NAND - это его карта битых блоков :)

    1. Если кто работал с flash - расскажите пожалуйста, всегда ли bad block возвращает значения 0х00 для каждой ячейки блока?

    2. Эти самые initial invalid block'и - они если не работают - они всегда не работают? Или все дело в том, что через раз? (то есть один раз считывает правильно, но после стирания и записи может прочесться что-то не то, а потом опять нормально?)

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

  3. Есть очень горячее желание сделать на CycloneII программируемую задержку шаг которой

    Можно еще попробовать использовать программируемые задержки на входах Циклона.

    Например, сначала сдвигаем синхронно, на нужное число по 4нс на 250МГц, а потом выходим наружу и синхронно подаем на набор из 8 входов со сдвигами от 0 до 3.5нс, ну и нужную фазу потом уже выбрать коммутатором. Плохо, конечно, что приходится выходить из кристалла наружу, но можно попытаться.

  4. У меня было что-то подобное. Хотя сильно париться не стоит - для задач, решаемых Hyperlynx, ориентация падов не особо важна. Кстати, можно проверить, промоделировать с обычным падом и с повернутым :wacko:

    Ясное дело, что не особо важно, просто немного неприятно.

    После разбирательства выяснилось что виноват все-таки транслятор - он почему-то флипнутые пады на 90 градусов доворачивает - в итоге пинам в .hyp назначается не тот тип падстека.

    Слева - тестовая платка в PCAD-2004SP4, один и тот же компонент в разных ориентациях и на разных сторонах, справа - результат трансляции в HyperLynxL75

     

    post-10038-1168520285_thumb.jpg post-10038-1168520299_thumb.jpg

     

    Посмотрим, если будет особо напряжно и не особо лениво - напишу корректирующий скриптик для .hyp файлов.

  5. У меня в HL v7.5 при импорте платы с PCAD200x появляется интересный эффект - пады микросхем и вообще всех SMD компонентов, расположенных на обратной стороне платы (flipped которые) почему-то отображаются повернутыми на 90 градусов. Причем в .hyp файле пады и их аттрибуты записываются верно. То есть собственно к транслятору претензий вроде как нет.

    "Ручками" на 90 корректируем (изменяем, например, 180 на 90 в определении PADSTACK в .hyp-файле)-начинает отображаться правильно (но как оно будет моделироваться пока неясно - определение пада -явно же недостоверное).

    Пады компонентов на лицевой стороне отображаются всегда нормально - до сих пор проблем с "односторонними" платами не было.

    У кого-нибудь еще такое "падовращение" наблюдается?

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

    Автор (ИМХО) имел ввиду, что очень многие в схемотехнике (ограничимся областью электроники) сейчас оперируют готовыми узлами (микросхемами), как черными ящиками, практически не задумываясь, а что же там внутри, и как оно устроено. В итоге нет глубокого понимания принципов работы таких устройств и много различных схемотехнических ошибок.

    Вот автор и предлагает выяснить - как много формучан смогут из дискретных элементов (резистор, конденсатор, транзистор) сконструировать АЦП. В принципе - в любом нормальном ВУЗе рассказывают как устроены АЦП разных типов (в моей альма-матер упоминали про прямые, последовательного приближения и интегрирующие :)), так что задача это типовая и несложная, но как показывает ветка - народ даже слабо представляет, что называется дополнительным кодом.

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

    Сможете при таких условиях повторить (изобретение принципиально новых технологий, доступных с таким Синтезатором, тут не предполагаем), ну хотя бы что-то вроде iTunes? Хорошо представляете как устроена флэш, SRAM (DRAM), принципы функционирования процессорного автомата, кварцевого генератора, сигма-дельта АЦП/ЦАП и напоследок, УНЧ?

  7. Для частных лиц - оплата через Сбербанк, квитанцию для оплаты высылаем по email.

    Скидки предусмотрены только для студентов и преподавателей - для них стоимость участия 100 р.

    А киевлянам как проплатить? В Москве будем только 15-го утром.

  8. вопрос - делал ли кто нибудь для DDR2 "простые терминаторы" (т.е. 100 ом на питание 1.8 и 100 ом на землю) ? Не хочется городить отдельное питание Vtt...

     

    Корпус памяти 1, клоки 218MHz, DDR2.

    Иногда в простых случаях можно вообще без терминаторов - только с последовательным согласованием. Промоделируйте и подсчитайте энергию в overshooting и если чипы памяти

    и контроллера переносят такую нагрузку без проблем, то параллельные терминаторы можно

    не ставить.

    Еще вариант для DDR2 - ODT заюзать.

  9. Только что сдали проект с DDR2. Цепляли к Xilinx 4. Думаю, Вы конечно в курсе, но на всякий пожарный, про разность в скорости распространнения сигнала на внешних и внутренних слоях не забыли?

    Нет, не забыл :) Разные характеристики слоев - это отдельная тема.

    По своему вопросу скажу, что производитель процессора ответил что все критические цепи внутри BGA согласованы и учитывать "внутреннюю длину" пина не надо.

  10. А что, 34.19 все еще на Эль-Гамале построен? Мне почему-то казалось что там должна быть эллиптика?

    У нас эллиптические алгоритмы уже года 4 как стандартизованы.

  11. Как писали выше все ОЧЕНЬ сильно зависит от мастерства программиста.

    Например, неделю назад писал функцию автокалибровки (C8051F06x, есть 9 каналов по 8 под

     

    Одно дело - асм 51-го:

    [метка:] мнемоника

    + [операнд приемник]

    + [операнд источник]

     

    Другое дело - асм ARM:

    [метка:] мнемоника

    + [суффикс типа]

    + [условный суффикс]

    + [операнд приемник]

    + [первый операнд источник]

    + [второй операнд источник]

    + [код операции сдвига второго операнда]

    + [аргумент операции сдвига]

     

    Видите сколько возможностей во втором случае? И далеко не всегда самый оптимальный путь сразу очевиден. Даже для опытного человека :)

  12. 1) Никто и не предлагает писать 100 к на ассемблере

    2) Переносимость си с ядра на ядро тоже не является легким делом, не будем лукавить. У всех ядер свои архитектурные особенности, свои компиляторы со своими багами, и если все это учитывать - про переносимость в большинстве случаев тоже можно забыть :glare:

    "Тяжело только первую тысячу лет" © Шекли

    В-общем-то, один из наших проектов - 100K+ сишных строк мигрировал так: x186->AVR->MSP430->MBM90->ARM7.

    Сложным был только первый порт (до двух недель ковырялись), а все остальные - за день-два. То есть - один раз себя дисциплинируешь, а дальше оно само катится.

    Что до subj - имхо, ARM имеет очень "враждебный" по отношению к человеку ассемблер. Писать на нем нудно и долго. И не всегда эффективно. У меня был пример - процедура вычисления кода Хемминга для сектора NAND - сначала я этот кусочек написал на ассемблере, потом - на C. И надо признать, что GCC компилятор у меня в тот раз выиграл. И не потому, что я плохо знал архитектуру ARM :) Просто компилятор - он же "железный" - рассматривает все возможные оптимизации и выбирает лучший вариант. А программисту обычно лень подумать несколько раз над одной и той же проблемой. В итоге, в моем случае C-компилятор хитро поскрещивал арифметические операции со сдвигами и уловными флагами и получил код в полтора раза быстрее и короче чем мой "ручной". Мне оставалось только "убить сибя ап стену" :)

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

    Собственно данные в DDR/DDR2 и являются одной из самых критичных частей.

    Линии данных группируются в "байтовые дорожки" (byte lane), в каждую из которых помимо собственно 8 бит данных еще входит строб DQS (+ ~DQS, если используется дифференциальный вариант для DDR2) и маска данной lane - DQM. У разных производителей (чипов памяти, модулей, (встроенных) контроллеров памяти) немного разные требования к выравниванию различных цепей, но все они сходятся в одном - в пределах байтовой дорожки данные должны быть выровнены с максимально возможной точностью. Как правило указывается предел +-25 милс.

    Далее, есть любопытный момент - соотношение длин проводников в дорожке с тактовым сигналом CK, а также соотношение длин дорожек между собой. Тут уже надо смотреть на конкретный случай, и читать аппноты производителя контроллера памяти. Например, AMD для своего Au1200 рекомендует разводить методом daisy chain, тактовые проводники на разные банки явно имеют разные длины, разброс длин между дорожками до 3 дюймов :blink:. FreeScale для своих чипов рекомендует иметь разброс между дорожками и тактовыми сигналами не более 1 дюйма, и все тактовые должны быть выровнены между собой.

    Ситуация может также существенно различаться, в зависимости от того, трассируется DIMM-овница или дискретные микросхемы. Самый сложный случай - комбинация DIMM-овницы и дискретных чипов, тут уже надо долго и серьезно моделировать, и вполне возможно что устройство будет работоспособно не со всеми DIMM-ами. При использовании DIMM-ов обычно еще налагаются доп требования по выравниванию управляющих цепей (Адресов, RAS/CAS etc), хотя тут имеется некоторое послабление в виде режима 2T.

    Терминирование-согласование - это вообще отдельный слой вопросов "сверху" - подбор StackUp, волнового сопротивления дорожек, выбор топологии цепей, консультации с технологами производителя платы, выбор места для резисторов, etc - простор для трудовой деятельности просто невероятный :)

  14. пина своя. Сейчас ищу способ получить эти длины скопом в каком-либо отчете, а не вставляя 700+ пинов в LineSim.

    На самом деле можете просто открыть IBIS и посмотреть сколько разных вариантов параметров R,L,C есть в секции Pin. По идее количество этих вариантов равно или меньше кол-ва рядов на корпусе BGA.

    Т.е. вариантов будет десяток. а не 700+

    Не-а, я тоже так думал :( Но в IBIS у каждого пина прописаны свои R, L, C (+ модель буфера, вот моделей действительно всего с десяток-другой). R - четыре цифры, L,C - по три значащих цифры. Если подумать, то они и не могут быть одинаковыми для разных пинов - например, два разряда шины данных в двух разных рядах, по разному удалены от кристалла, и ессно имеют разные R,L,C - длина и путь внутри корпуса разные (BGA вроде как на PCB с микроотверстиями сделан).

  15. В IBIS может быть задано R, L, C, для каждого пина (раздел Pin в файле) это и есть, насколько я понимаю, представление проводника внутри корпуса. Бывает также задано R_pkg, L_pkg и C_pkg со значениями мин. тип. макс. это значения по умолчанию для всех пинов у которых нет своих R, L, C.

     

    Учесть эту длину просто: создать эквивалентную схему цепи в HL (насколько я понял она уже у вас есть) и при моделировании выяснить нужные конечные длины трасс, которые и использовать при трассировке.

    Угу, именно так HL и делает (я пока предварительно LineSim использую с подключенными IBIS) - делаешь трассу до последовательного резистора 200 милс, запускаешь Termination Wizard, а он ругается - "эффективная длина 300 милс до Rs великовата" и цифра 300 изменяется - для каждого пина своя. Сейчас ищу способ получить эти длины скопом в каком-либо отчете, а не вставляя 700+ пинов в LineSim.

    P.S. Всем спасибо за комментарии.

  16. В данный момент трассируется плата с DDR-400. По аппнотам производителя контроллера памяти рекомендуется выравнивание цепей на плате в группах данных с точностью не хуже 25 милс. Но сам корпус чипа довольно большой - BGA 35x35 мм и некоторые ножки в группах разнесены достаточно далеко.

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

    Каким образом эту внутренюю длину пинов следует учесть? Задать предварительные параметры цепей, получить общую эффективную длину предварительным моделиорванием и потом использовать ее при трассировке? Или предварительно отказаться от точного выравнивания цепей и выравнивать уже на финише с моделированием и с подгонкой общего времени распространения, а не тупо по длине.

    Как "правильнее" делается в таких случаях?

  17. Похоже что атмель просто боится опубликовать реальные данные по своим флешам - видать флеши не валом, по сравнению с конкурентами. В свое время пришлось писать им на фирму = в ответ был

    Да, Атмел ничего конкретного по ресурсу и времени сохранения не говорит (недавно только дали что-то на новые флеши). Но сами 45-ки очень неплохие - мы используем их с 1998 года. Поскольку тогда вообще никакой информации о надежности не было, то был проведен такой эксперимент:

    - заполнили весь чип AT45 псевдослучайными данными

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

    - никакого рефреша по рекомендация Атмела не производилось, просто перезаписывались несколько тестируемых страниц, остальной массив не трогался.

    - имелась возможность сравнить и проверить начальное заполнение - на предмет искажения информации из-за отсутствия рефреша.

    Тест крутился несколько суток, первый сбой массива произошел примерно на 300K цикле (суммарно 2-3 миллиона записи страниц), причем любопытно, что бит "стерся" - то есть был 0, стал 1. И он был "плавающим", то есть каждый раз мог прочитаться по-разному.

    На истирание ту 45-ку проверить в итоге не получилось - цифра приблизилась к миллиону, а перезатираемые страницы все не дохли. Конечно, значение в 1M не критерий супернадежности, это просто цифра полученная в однократном эксперименте и в определенных условиях. Но факт любопытный.

  18. задержек. Общий смысл такой: пускаем по плате еще одну трассу с клоком0. В приемной плис на DCM заводится этот клок0 и собственный клок1 вырабатывается с той же фазой, что и приходящий снаружи. Т.о. с потоком данных можно работать внутренним клоком плис (клок1) с уже учтенными задержками.

    (само собой клок0 и клок1 по частоте должны совпадать)

    Doka, а можете пояснить какой глубокий смысл во внутреннем клоке с той же фазой что и внешний?

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

     

    попробую:

    смысл в том, чтобы вся плис работала в одном клоковом домене - по клоку1.

    клок0 только для "обучения" DCM.

    Это-то понятно (Ведь DCM - это блок с PLL-кой в Xilinx-е?). У меня сейчас стоит вопрос введения нескольких доменов синхронизации (попросту появляется несколько разных клоков) при переносе проекта с acex1k на cycloneII - вот я во все это и вникаю. В Асексе была такая фича - ClockLock называется, судя по документации - делает, то что Вы описали:

    "The ClockLock circuitry uses a synchronizing PLL that reduces the clock delay and skew within a device. This reduction minimizes clock-to-output and setup times while maintaining zero hold times".

    Ну "clock delay" уменьшить можно, если соответственно сдвинуть вперед фазу выходного сигнала, это не фокус. А вот как уменьшается skew в пределах чипа - непонятно. (хотя возможно под "device" тут имеется ввиду вся плата целиком, а не собственно Альтерина).

    C "clock-to-output" тоже ясно - раньше даем клок, раньше получаем результат. Тоже не фокус.

    А вот с "Setup times" - непонятки :( Клок-то внутри раньше щелкнет, значит данные надо на входы ПЛИС пораньше подать, то есть -"Setup times" должны увеличится. Чего-то я упустил?

  19. задержек. Общий смысл такой: пускаем по плате еще одну трассу с клоком0. В приемной плис на DCM заводится этот клок0 и собственный клок1 вырабатывается с той же фазой, что и приходящий снаружи. Т.о. с потоком данных можно работать внутренним клоком плис (клок1) с уже учтенными задержками.

    (само собой клок0 и клок1 по частоте должны совпадать)

    Doka, а можете пояснить какой глубокий смысл во внутреннем клоке с той же фазой что и внешний?

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

  20. Взял на заметку.С реле не хочется связываться.Я уже подумываю переделать сдвоенный выключатель

    (для люстр).Но не все их конструкции мне нравятся.

    Такие выключатели называются проходными - есть практически у всех производителей электрофурнитуры начиная от самых дешевых типа Мakel. Полно на любом хозрынке.

  21. Я публично предлагаю Вам пари.

     

    Я утверждаю, что моя организация не является кадровыми агентством, но является прямым работодателем и все, что написано в объявлении о работе – правда. Я предлагаю следующий способ доказательства – Вы приходите в нашу компанию, где я Вам показываю следующее

     

    1. Существует Multinational Hi-Tech company

    2. Я возглавляю офис этой компании в Петербурге

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

  22. Вот результаты тестирования SD/MMC карточек в оптимизированых устройствах, т.е. максимально возможная практическая скорость.

    http://www.caxapa.ru/echo/arm.html?id=49592

    Это скорости новых карт и именно на оптимизированном обрудовании - "подбирайте карту к оборудованию" :). Встроенные в чипы контроллеры далеко не всегда оптимизированные. Например, упомянутый 2410 - там SD/MMC тактируется от периферийного клока PClk, обычно это составляет четверть от ядра - макс 66МГц (оптимизация по скорости, ядро на максимуме @266МГц). Потом внутри SD контроллера этот клок, ессно, делится пополам - имеем 33 МГц, а потом уже есть опциональный прескайлер. И какое значение прескайлера выбрать? Ставим 0 - имеем 33 МГц на SD шине, для v1.0 это много (25МГц макс). Ставим 1 - имеем 33/2->17МГц, это уже недобор :(

    Короче, вершина видна, но для ее достижения обычного альпснаряжения может не хватить :)

  23. Здравствуйте, господа разработчики.

    У кого есть опыт чтения карт CompactFlash ARM-ом? Расскажите, какая скорость была достигнута на каком процессоре, через какой интерфейс, разрядность шины (8/16 бит). Вообщем буду благодарен за любую информацию на эту тему. Текже интересуют и SD/MMC.

    Скорость CF зависит от многих факторов:

    - способа подключения - TrueIDE, I/O, Memory;

    - разрядности и скорости использованной шины - насколько быстро можно выполнять единичные транзакции чтения-записи байта/слова;

    - быстродействия самой карточки;

     

    Мой практический опыт использования CF в комплекте с XScale:

    - подключение в режиме TrueIDE

    - через 16-битную внешнюю шину с тактовой 66МГц (позволяет настроиться на максимально быстрый режим PIO4 - 120 нс цикл)

     

    Реально полученная пиковая скорость - 10-11МБ/с, на нее влияет собственно синхронизация внешней шины с внутренней AHB процессора, а также способы кеширования (поскольку процессор может кешировать указанное адресное пространство - в этом случае при чтении обмен идет пакетами размером со строку кеша)

     

    Средняя скорость на чтение- 1-8 МБ/с - зависит от самой карточки, и способа чтения. Также влияет способ чтения - по одному/несколько секторов, команды READ/READ MULTIPLE. Например, древняя CF32MB при чтении по одному сектору дала скорость всего 1МБ/с. При чтении 16-секторными блоками - около 3 МБс, более новые карточки при чтении 16-секторными блоками достигали 8 МБ/с. С записью ситуация похуже - на моих картах была в 2-4 раза медленее чтения.

    Это был режим TrueIDE, возможно в режиме Memory ситуация получше.

     

    При использовании MMC версий до 3.2- физически скорость ограничена 20Мбит/сек, SD - 4x25 Мбит/сек

    И также влияют те же самые факторы - чтение посекторно или блоками, и насколько долго карта "думает" после получения команды. Максимум, что мне удалось достичь на Samsung 2410 для MMC - чтение в среднем 1.5МБ/сек, запись 0.8МБ/сек. SD - чтение в среднем 6 Мбайт/сек, запись - 2МБайт/сек. Обе карточки были трех-четырех летней давности, новые карты могут быть побыстрее.