[Koctix 0]

Здравствуйте, я занимаюсь разработкой приемопередатчика SpaceWire, передатчик я сделал, необходим приемник. Протокол SpaceWire использует DS-кодирование для передачи информации, это кодирование имеет две линии Strob и Data, Strob изменяется всегда, когда не меняется Data, в сигнале закодирован тактовый импульс, восстановить его можно на другой стороне с помощью операции XOR. Есть два основных подхода к реализации приемников, назовем условно их "синхронный" и "асинхронный", синхронный по событиям от внутреннего тактового импульса считывает сигнал, асинхронный восстанавливает тактовый сигнал из самого DS-кода с помощью XOR. Я реализовал асинхронный прием, однако в ходе симуляции оказалось, что поднять скорость приема выше 300Мбит/сек не выходит, а связано это с тем, что XOR реагирует на пришедший сигнал с небольшой задержкой и восстановленный тактовый импуль после него не успевает запустить событие в модуле приема до того как сигнал данных изменится. Если это все компоновать вместе с передатчиком и машиной состояний (необходима для реализации других уровней протокола), то скорость может упасть и до 100Мбит/сек. Была идея задержать сигнал данных до модуля приема с помощью пустой логической операции, в симуляции отдельно для приемника получалось достичь более 500 Мбит/сек, однако это все сильно зависило от выбранных пинов и при изменении их выбора менялась скорость, в сочитании со всем остальным наполнением скорость не повысилась. Вопрос в следующем, может кто-то сталкивался с такой проблемой и знает решение или же я пошел не по тому пути и нужно делать иначе, слышал что оптимизировать трассировку можно с помощью Constraints, но так и не нашел как правильно ими пользоваться для таких задач. Модуль приема описан следующим образом:

module Resiv_sem_var2(
    input Din,// линия данных
    input Sin, // линия строба
    input Codes_Check, //маркер символа управления
    input reset,
    output clk, // тактовый сигнал образованный операцией XOR
    output reg [1:0] Data, //выход данных (собирает по два бита)
    output reg [2:0] count=3'b100, //(счетчик указывает на номер пары битов в символе)
    output reg Start=0
    //output Din_buf
    );
    
    assign clk=(Din==Sin)?0:1; // XOR
    
    reg Start=0;
    reg DataLeft=0;
    
    
    always @(posedge clk)begin
        DataLeft<=Din;
        if (reset==1) DataLeft=0;
    end
    
    always @(negedge clk)begin
        Start<=1;
        if (reset==1)begin // сброс
            count=3'b100;
            Data=0;
            Start=0;
        end
        else begin
                if(Codes_Check==0)begin //счетчик для N-Char
                    if (count<3'b100) count<=count+1;
                    else count<=0;
                end
                if(Codes_Check==1)begin // счетчик для L-Char
                    if (count<3'b001) count<=count+1;
                    else count<=0;
                end
            Data[1]<=Din;
            Data[0]<=DataLeft;
        end
    end
endmodule

 

[Yuri124 1]

On 5/30/2023 at 10:43 AM, Koctix said:

с помощью Constraints

указать диапазон задержек (минимальное значение/максимальное значение) сигналов восстановленного клока и данных.

Может быть - для облегчения состыковок сигналов во времени - подать входной поток на 2 разных пина (входа) FPGA. Один вход - для восстановления клока (работает чуть раньше), второй вход - данные (они несколько задержаны для того, чтобы в дальнейшем правильно состыковать оба сигнала.

On 5/30/2023 at 10:43 AM, Koctix said:

Была идея задержать сигнал данных до модуля приема с помощью пустой логической операции

триггер для этой цели никак не подходит?

[des00 25]

2 hours ago, Yuri124 said:

указать диапазон задержек (минимальное значение/максимальное значение) сигналов восстановленного клока и данных.

не поможет.

3 hours ago, Koctix said:

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

т.е. вы в рукопашку разруливаете 500 мегабит, на плисах с нагрузкой на тактовое дерево 500-600МГц (хилые средние и топовые семерки, топовые альтеры) максимум и хотите сделать еще больше? А если у вас там какой нить артикс 50, да еще и первого спидгрейта то радоваться надо что 300 мегабит пролезло.

[_4afc_ 25]

1 hour ago, Koctix said:

Есть два основных подхода к реализации приемников, назовем условно их "синхронный" и "асинхронный", синхронный по событиям от внутреннего тактового импульса считывает сигнал, асинхронный восстанавливает тактовый сигнал из самого DS-кода с помощью XOR.

Я реализовал асинхронный прием, ... однако это все сильно зависило от выбранных пинов и при изменении их выбора менялась скорость

...слышал что оптимизировать трассировку можно с помощью Constraints, но так и не нашел как правильно ими пользоваться для таких задач.

Скорость передачи сигнала со входа ноги до выхода триггера обычно больше чем триггер-лут-триггер. Рядом с ногой есть только регистр. Если вы хотите сделать XOR двух ног, то получается мы ведём 2 wire до некого LUT в глубине ПЛИС затем до FF.

Можно подвинуть LUT ближе к этим ногам, а FF к LUT и зафиксировать в планере.

Можно задать констрейнами время прохода этих сигналов.

 

1 hour ago, Koctix said:

оказалось, что поднять скорость приема выше 300Мбит/сек не выходит

    always @(posedge clk)begin
        DataLeft<=Din;
        if (reset==1) DataLeft=0;
    end
    
    always @(negedge clk)begin
            Data[1]<=Din;
            Data[0]<=DataLeft;
        end

У вас работа по двум фронтам клока, следовательно максимальная частота делится на два.

 

1 hour ago, Koctix said:

 Если это все компоновать вместе с передатчиком и машиной состояний (необходима для реализации других уровней протокола), то скорость может упасть и до 100Мбит/сек.

1. До машины состояний тоже доходит двухфронтовая логика.

2. У Xilinx LUT6, значит ля максимальной частоты автомат должен принимать решение на основе не более 6 переменных, включая CE, RST, IF, CASE...

[sazh 3]

В 30.05.2023 в 10:43, Koctix сказал:

    input Din,// линия данных
    input Sin, // линия строба
    input Codes_Check, //маркер символа управления
    

 

У Вас на входе приемника две линии. И больше ничего. Маркер символа управления - от лукавого. Наверно не надо от ПЛИС ожидать невозможного. тем более 400 Мб/c.

Протокол сложный. Быстродействие ограничено узким горлышком с рукопожатием (fifo на 64 слова). Проект наверно должен быть гибок (параметризирован) для использования на любых семействах. Есть наш ГОСТ SPACEWIRE-RUS. Там указано требование по приему.

Наверно в проекте нужно три системных клока. Клок передатчика (от 10 МГц до 100МГц) , клок приемника (от 125 МГц до 166 МГц), клок state машины (на системной частоте ЦПУ). И переходы из одного клокового домена в другой. И с тактированием фифо по приему и передаче - тогда без проблем. Посмотрите в руководстве наших микроконтроллеров со space wire на каких частотах они работают. (Любой сдвиг между  input Din и input Sin приведет к приему ложной информации и state машина будет очень часто сидеть в состоянии idle, если конечно Вы следуете госту). Так что только синхронный прием. По одному фронту. Кстати. Передатчик логически еще сложней приемника. Если следовать госту. Сплошные if -else if -else if-else if.

[Koctix 0]

Спасибо за ответ!

20 часов назад, Yuri124 сказал:

указать диапазон задержек (минимальное значение/максимальное значение) сигналов восстановленного клока и данных.

Хотел так сделать, но никакого руководства не нашел по этому поводу не нашел, пытался сделать "в слепую", получилось в худшую сторону изменить результат, думаю можно и в лучшую, если есть какое-то руководство у вас буду признателен.

 

20 часов назад, Yuri124 сказал:

Может быть - для облегчения состыковок сигналов во времени - подать входной поток на 2 разных пина (входа) FPGA.

Да такое можно сделать, тем более все и должно закончится созданием печатного узла и будет возможно организовать задержку, но хотелось бы получить максимальные скорости без этого, тем более что 500Мбит получилось сделать, но без остальной "обвязки", то есть думаю возможно настроить именно "правилами" проектирования.

 

20 часов назад, Yuri124 сказал:

триггер для этой цели никак не подходит?

Триггер же тактировать надо будет чем-то, или может я не понял что вы имеете ввиду.

18 часов назад, des00 сказал:

т.е. вы в рукопашку разруливаете 500 мегабит, на плисах с нагрузкой на тактовое дерево 500-600МГц

Я не хочу получить больше, такие значения вышли при симуляции отдельно взятого приемника, но при объединении всех модулей скорость падает, как сделать так чтобы скорость приема осталась прежней? в целом и 400Мбит терпимо. Я вижу путь решения через "Constraints", однако не уверен правильно ли понимаю, как он работает и можно ли эту разницу в скорости прихода сигналов сделать определенной. 

[Koctix 0]

19 часов назад, _4afc_ сказал:

Можно подвинуть LUT ближе к этим ногам, а FF к LUT и зафиксировать в планере.

Надо попробовать, спасибо, но как зафиксировать в планере?

 

19 часов назад, _4afc_ сказал:

До машины состояний тоже доходит двухфронтовая логика.

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

 

19 часов назад, _4afc_ сказал:

У вас работа по двум фронтам клока, следовательно максимальная частота делится на два.

Согласен, но почему-то скорость в симуляции достигала 500Мбит/сек и эта скорсть зависит от выбора портов, следовательно это зависит от имплементации в том числе

[des00 25]

1 hour ago, Koctix said:

Я не хочу получить больше, такие значения вышли при симуляции отдельно взятого приемника, но при объединении всех модулей скорость падает, как сделать так чтобы скорость приема осталась прежней? в целом и 400Мбит терпимо. Я вижу путь решения через "Constraints", однако не уверен правильно ли понимаю, как он работает и можно ли эту разницу в скорости прихода сигналов сделать определенной. 

моделирование мелкого блока для типовой усредненной плис, в конкретной температурной точке...в общем ни о чем. про констрейны я уже ответил, не поможет. если уж так принципиально, то прибивать гвоздями, собирать RPM макрос, писать кучку скриптов проверки времянки для успокоения (именно проверки, а не применения), а потом всю партию изделий пропускать через термокамеру под требуемый климат.

[des00 25]

1 hour ago, Koctix said:

Надо попробовать, спасибо, но как зафиксировать в планере?

искать на сайте хилых/в сети по ключевым словм RPM macro, XDC macro

[_4afc_ 25]

1 hour ago, Koctix said:

Надо попробовать, спасибо, но как зафиксировать в планере?

Добавить в xdc мышкой, типа такого:

# set ADC_IBUF/ADC_Over_T2_reg
set_property BEL AFF [get_cells ADC_IBUF/ADC_Over_T2_reg]
set_property LOC SLICE_X0Y0 [get_cells ADC_IBUF/ADC_Over_T2_reg]

 

[Koctix 0]

21 час назад, des00 сказал:

моделирование мелкого блока для типовой усредненной плис

Вообще у меня на столе сейчас лежит мост SpaceWire/Ethernet он по SpaceWire обеспечивает скорость в 500 Мбит/сек, как на передачу, так и на прием, там стоит 2 ПЛИС одна альтеровская вторая хилых, хилых отвечает за SpW, альтера за Ether, плис напрямую подключена к портам SpaceWire без каких либо микросхем между ними, это Virtex 5. Вот и как они это сделали ?  То есть у меня подход не правильный начиная с описания блока на verilog?

В 31.05.2023 в 01:23, sazh сказал:

Наверно не надо от ПЛИС ожидать невозможного. тем более 400 Мб/c.

Не стал вам сразу отвечать, разбирал мост SpaceWire/Ethernet который от компании MiT проверял какие микросхемы у них на плате, кроме плис Xilinx в части SpaceWire больше нет ничего, обеспечивает 500Мбит/сек и туда и обратно, у меня Artix 7. Может быть проблема в чипе?

[fingertouch 2]

2 часа назад, Koctix сказал:

Вообще у меня на столе сейчас лежит мост SpaceWire/Ethernet он по SpaceWire обеспечивает скорость в 500 Мбит/сек, как на передачу, так и на прием, там стоит 2 ПЛИС одна альтеровская вторая хилых, хилых отвечает за SpW, альтера за Ether, плис напрямую подключена к портам SpaceWire без каких либо микросхем между ними, это Virtex 5. Вот и как они это сделали ?

В кристаллах Кзайлинкса есть локальные тактовые ресурсы, позволяющие работать на частоте выше, чем глобальное тактовое дерево. IDELAY, ISERDES. Найдите Select IO user guide на ваш кристалл, там расписано, как с ними обращаться. 

[des00 25]

13 hours ago, Koctix said:

Вообще у меня на столе сейчас лежит мост SpaceWire/Ethernet он по SpaceWire обеспечивает скорость в 500 Мбит/сек, как на передачу, так и на прием, там стоит 2 ПЛИС одна альтеровская вторая хилых, хилых отвечает за SpW, альтера за Ether, плис напрямую подключена к портам SpaceWire без каких либо микросхем между ними, это Virtex 5. Вот и как они это сделали ?  То есть у меня подход не правильный начиная с описания блока на verilog?

вроде выше же написал как, в ручную: код с ручной вставкой IBUF/BUFIO/BUFR/H/BUFG/IDELAY/IDDR и т.д. Потом минимальная логика до моста в систему, ручная расстановка + ее фиксация RPM макросами. Потом все обвязать констрейнами для проверки, чтобы убедиться что будет работать. Просто натянуть констрейны не сработает. Софт не будет интерфейс вытягивать, не обучен он этому.

13 hours ago, Koctix said:

Не стал вам сразу отвечать, разбирал мост SpaceWire/Ethernet который от компании MiT проверял какие микросхемы у них на плате, кроме плис Xilinx в части SpaceWire больше нет ничего, обеспечивает 500Мбит/сек и туда и обратно, у меня Artix 7. Может быть проблема в чипе?

Зайлинкс, зайлинксу рознь. Вот ваш артикс, у него 500МГц даже по чипу не может бегать для первого спидгрейта, для второго прям на бровях и только третий, при использовании определенных ресурсов может что-то дать, исключение BUFIO чтобы быстро на IDDR данные собрать и половинной частоте в систему отдать.

[sazh 3]

В 01.06.2023 в 07:06, Koctix сказал:

Вообще у меня на столе сейчас лежит мост SpaceWire/Ethernet он по SpaceWire обеспечивает скорость в 500 Мбит/сек, как на передачу, так и на прием, там стоит 2 ПЛИС одна альтеровская вторая хилых, хилых отвечает за SpW, альтера за Ether, плис напрямую подключена к портам SpaceWire без каких либо микросхем между ними, это Virtex 5. Вот и как они это сделали ?  То есть у меня подход не правильный начиная с описания блока на verilog?

Не стал вам сразу отвечать, разбирал мост SpaceWire/Ethernet который от компании MiT проверял какие микросхемы у них на плате, кроме плис Xilinx в части SpaceWire больше нет ничего, обеспечивает 500Мбит/сек и туда и обратно, у меня Artix 7. Может быть проблема в чипе?

Мы никогда не узнаем, как они это сделали. Может годами этим занимаются. DS кодирование по определению не может выдать гигабитных скоростей. Если напрямую подключена - связь по lvds. Уже по выбору кристалла понятно, выбран влоб по частоте и структуре ячейки кристалла, при этом понимая что само ядро займет меньше 1 % ресурсов кристалла. Более того в нашем госте есть дополнение GigaSpaceWire, где перешли от DS кодирования к 8B10B кодированию с куда меньшими для этой реализации требуемыми ресурсами и на куда большие расстояния. Сетевой и транспортный уровни SpaceWire сохранены, что позволяет легко интегрировать каналы GigaSpaceWire в сети SpaceWire. Все проекты, что я видел в открытом доступе по SpaceWire не работают, кроме одного. В Вашем случае я вижу два подхода.

1. купить ip core Ваш кристалл, что вряд ли получиться.

2. написать свой и посмотреть что получиться.

Стандартный синхронный подход. Я других для ПЛИС не знаю.  И Artix 7 Ваш подойдет. Единственное достоинство DS кодирования - это безразличие к частоте приема, передачи в разумных пределах. Согласно стандарта обмен начинается на частоте 10МГц. Поэтому если Вы будете выдавать в линию 10Мб/c, ничего Вам за это не будет. Все все примут. Обычно в передатчике делаю градации скорости. от 10 МГц до возможной вашего проекта. С приемником тоже самое. Добиваетесь работы  на максимальной для вашего кристалла частоте F и говорите мосту что выше частоты F/2 работать не можете (там должен быть выбор частот передачи).  Короче - Вы съэкономили конторе деньги при незначительном понижении скорости обмена. Потому что основной затык именно в DS кодировании, ибо оно не позволяет выделить из потока данных начало пакета (там и нет понятия пакета на физическом уровне). Именно поэтому ввели машину состояний которая 20 мкс тратит каждый раз по любому сбою на разъединение и соединение  точка точка. Мне было интересно, я реализовал на бумаге линк SW. Для дома , для семьи. Синтезируется и моделируется. В соответствии с нашим гостом (как я думаю). Я с xilinx не работал. Посмотрите, мне интересно на каких частотах ваш кристалл это потянет. Надеюсь, что не ввиду Вас этим в еще больший ступор. Ибо Вы позволяете в своем проекте использовать одновременно операторы блокирующего и неблокирующего назначения. 

sw_link.zip

[Koctix 0]

В 02.06.2023 в 00:49, sazh сказал:

Посмотрите, мне интересно на каких частотах ваш кристалл это потянет.

Спасибо за ответ! Я попробовал запустить ваш проект, до 100Мбит/сек на прием работает (возможно можно увеличить за счет поднятия частоты тактирования, но я оставил все так как у вас описано), мой на 200, хотя мой криво написан в части машины состояний и поэтому у меня есть проблемы при введении ошибок в канал (ваш же работает в этой части без проблем абсолютно), да и в целом ваш код професиональнее, постараюсь почерпнуть что-то у вас, благодарю. По-поводу одновременного использования блокирующего и неблокирующего, просто экспериментировал с ними (хотя я действительно ниже среднего уровня в программировании ПЛИС), в данном случае синтезируется в одну и ту же схему, вот и не поменял назад, с этим могут возникнуть проблемы?

Изменено 3 июня, 2023 пользователем Koctix