xSignals. Доступ к членам класса из delphi скрипта. Опции

[Vasen]

Добрый день, уважаемые форумчане.

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

Утилита еще сыровата, но с полторы сотни дифф пар я справился быстро.
Дошел вопрос до выравнивания шин DDR3. Для выравнивания оных я использовал классы xSignal и правила для этих классов, но это без использования утилиты.
И встал вопрос как получить доступ к элементам класса xSignal из скрипта. В типе TObjectId нет поля соответствующего данному классу.

[Vasen]

Коротко по интерфейсу.

D2D skew tolerance - погрешность выравнивания в между дифф парами группе;
P2N skew tolerance - погрешность выравнивания внутри пары между P и N цепями;
Delay - задержка распространения сигнала в материале, пс/мм;

Lic - длина (время) вносимая IC;
Lb - длина разведенная;
Leb - требуемая длина для обеспечения параметра D2D skew tolerance;
Lsum - суммарная длина;
D2D - результат обеспечения параметра D2D skew tolerance;
P2N - результат обеспечения параметра P2N skew tolerance.

Почему он ориентирован на выравнивание DDR? че-то я не догоняю...
Он тупо добавляет отростки, что внутри микросхемы...

Я его использую и для FMC, все ОК

Мы об одном и том же скрипте говорим - LengthTuningHelper_v1.0.

Если да, то Сам автор об этом говорит. В конечном итоге получилось на данный момент, то что получилось.

[peshkoff]

Коротко по интерфейсу.

D2D skew tolerance - погрешность выравнивания в между дифф парами группе;
P2N skew tolerance - погрешность выравнивания внутри пары между P и N цепями;
Delay - задержка распространения сигнала в материале, пс/мм;

Lic - длина (время) вносимая IC;
Lb - длина разведенная;
Leb - требуемая длина для обеспечения параметра D2D skew tolerance;
Lsum - суммарная длина;
D2D - результат обеспечения параметра D2D skew tolerance;
P2N - результат обеспечения параметра P2N skew tolerance.



Мы об одном и том же скрипте говорим - LengthTuningHelper_v1.0.

Если да, то Сам автор об этом говорит. В конечном итоге получилось на данный момент, то что получилось.

Да, именно об этом.
Он пишет, что изначально задумывался для DDR3, но в коде ничего такого нет, да, собственно и быть не может.
ASCii файл не несет в себе данных ддр3 это или нет...

сейчас единственная засада, .pkg файлы получаются в пикосекундах, нельзя прямиком подсунуть.
Я тогда екселем конвертирую.

в общем, подожду тогда описание, пока не понятно

[Vasen]

Да, именно об этом.
Он пишет, что изначально задумывался для DDR3, но в коде ничего такого нет, да, собственно и быть не может.
ASCii файл не несет в себе данных ддр3 это или нет...

сейчас единственная засада, .pkg файлы получаются в пикосекундах, нельзя прямиком подсунуть.
Я тогда екселем конвертирую.

в общем, подожду тогда описание, пока не понятно

Все правильно. Но мне тогда идея создания треков не понравилась. И каким образом после задавать правила контролирующие процесс разводки.
Как не тужил мозг, так и не придумал как этот скрипт правильно прикрутить.

Алгоритм работы такой.
Оператор запускает скрипт и выбирает класс дифф пар. Если необходимо учитывать задержку FPGA, то выбирает микросхему и загружает файл.
Забив необходимые значения в поля skew tolerance, выполняет трассировку пар. Скрипт производит вычисления и обновляет данные в окне.
Все введенные оператором данные, а также последний выбранный класс сохраняются в папке с проектом, те после перезапуска скрипта можно возобновить работу.
При работе скрипта не создается никаких PcbObject-ов. По сути данный скрипт дополняет/заменяет окно PCB.

[Владимир]

Все правильно. Но мне тогда идея создания треков не понравилась. И каким образом после задавать правила контролирующие процесс разводки.
Как не тужил мозг, так и не придумал как этот скрипт правильно прикрутить.

Алгоритм работы такой.
Оператор запускает скрипт и выбирает класс дифф пар. Если необходимо учитывать задержку FPGA, то выбирает микросхему и загружает файл.
Забив необходимые значения в поля skew tolerance, выполняет трассировку пар. Скрипт производит вычисления и обновляет данные в окне.
Все введенные оператором данные, а также последний выбранный класс сохраняются в папке с проектом, те после перезапуска скрипта можно возобновить работу.
При работе скрипта не создается никаких PcbObject-ов. По сути данный скрипт дополняет/заменяет окно PCB.

Это замечательно. но нужно отчет в пихнуть в отчет DRC или самостоятельный отчет.
При формировании герберов это необходимо. Мало-ли где дернули топологию. Все время помнить и залазить в эту панель вручную--человеческий фактор. Можно и забыть

[Vasen]

Это замечательно. но нужно отчет в пихнуть в отчет DRC или самостоятельный отчет.
При формировании герберов это необходимо. Мало-ли где дернули топологию. Все время помнить и залазить в эту панель вручную--человеческий фактор. Можно и забыть

Вывод отчета в файл в планах.

Если не получится с xSignal, буду думать как слепить на основе FromTo объектов.
На данный момент скрипт имеет помимо некоторых багов, еще и пару недостатков. При работе скрипта не работает панель фильтра. Видимо фильтрация у них сделана тоже на основе скриптов,
потому как ругается на запущенный скрипт, а выполнять сразу 2 не может. В связи с этим не реализована функция перехода на диф пару на плате по клику на строку в таблице.
Выбор же на плате цепи, виа или пада принадлежащих паре производит выбор соответствующей строки в таблице. На данный момент учет задержек IC только у одного пина.

Сообщение отредактировал Vasen - Mar 30 2015, 21:09

[Владимир]

Если не получится с xSignal,

Должно получится, если не используете дополнительные отрезки

буду думать как слепить на основе FromTo объектов.

Забудьте. Там можете получить больше проблем

[Vasen]

Должно получится, если не используете дополнительные отрезки

Забудьте. Там можете получить больше проблем

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

[Владимир]

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

Да, должны учитывать. Хотя не проверял.
Проблемы при наложении Track и мусоре внутри Pad остаются. В Xsignal они решены.
В общем с появлением xSigna --- FromTo превратились в атавизм и развивать это тупиковое направление нет особого смысла

[Vasen]

Да, должны учитывать. Хотя не проверял.
Проблемы при наложении Track и мусоре внутри Pad остаются. В Xsignal они решены.
В общем с появлением xSigna --- FromTo превратились в атавизм и развивать это тупиковое направление нет особого смысла

Понятно, будем думать. Написал запрос на доступ в ветке http://forum.live.altium-ru.com/#posts/209547. Пока тишина.

[peshkoff]

Понятно, будем думать. Написал запрос на доступ в ветке http://forum.live.altium-ru.com/#posts/209547. Пока тишина.

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

[Владимир]

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

я знаю 4-5 пользователей, которые достучались. Значит их реально намного больше