Добрый день!
Иногда возникает вопрос насколько оптимально Labview преобразует ту или иную часть vi в HDL код.
В частности есть ощущение, что для достижения высокой тактовой частоты регистры ставятся куда надо и не надо.
Для общей производительности это некритично, а вот латентность сильно страдает.
Чтобы проверить когда и куда эти регистры подставляются очень желательно было бы посмотреть итоговый HDL код (verilog или vhdl).
Есть ли способы это сделать ?
Спасибо!
подсмотреть hdl код, возможно ли ?
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 126 раз
- Контактная информация:
Re: подсмотреть hdl код, возможно ли ?
Если только ассемблерный код: http://www.labview-rus.blogspot.ru/2010/01/3.html В настоящее время даже DFIR-граф не посмотреть толком, NI не предоставляет средств для тонкой отладки, кроме тех, что в меню программы. Посмотрите также тему http://www.labviewportal.org/viewtopic. ... 77&p=48682 , может чем-то поможет.
-
Konstantin Sumenko
- expert
- Сообщения: 1439
- Зарегистрирован: 17 июл 2008, 12:20
- Награды: 2
- Версия LabVIEW: 2010
- Откуда: Moscow
- Поблагодарили: 1 раз
- Контактная информация:
Re: подсмотреть hdl код, возможно ли ?
dadreamer, к FPGA модулю это имеет опосредованное отношение. За то куда ставятся регистры отвечает не LabVIEW, а маппер xilinx, соответственно нужен map report. Вообще один и тот же vhdl код может трассироваться в кристалле по-разному, пока укладывается в рамки заданных констрейнов или пока явно не указано куда ставить примитивы. Может быть зайти с другой стороны: в чем возникают проблемы?
- toshas
- assistant
- Сообщения: 105
- Зарегистрирован: 05 апр 2009, 22:45
- Версия LabVIEW: 9.0
- Благодарил (а): 13 раз
- Поблагодарили: 7 раз
- Контактная информация:
Re: подсмотреть hdl код, возможно ли ?
Не совсем так, mapper только расставляет регистры, а вот есть они или нет, определяется в исходном коде.
А задача, которая у нас возникла, вполне конкретная, нужно захватить сигнал, выполнить ряд вычислений и вывести сигнал наружу.
При этом важна латентность, а т.к. fpga умеют делать несколько вещей одновременно выбран модуль на базе ПЛИС.
Функции ввода, обработки и вывода занимают много тактов и не позволяют тем самым использовать Timed Loop.
А при применении обычного Loop латентность неоправданно увеличивается на сдвиговом регистре на один период выполнения цикла.
Как нам кажется, это получается из-за дополнительной конвеирезации кода.
Вот поясняющие картинки:
1) в случае последовательного кода, время выполнения всего цикла 4 мкс (должно быть 5 мкс т.к. на нашем модуле myRio 2 мкс - ввод, 2.8 мкс - вывод, но это отдельный вопрос откуда 4)
и латентность сравнима ~ 5 мкс, что корректно
2) в случае параллельного кода, время выполнения всего цикла 2.5 мкс (соответствует времени вывода, как самого длительного процесса в цикле) это правильно.
а вот латентность стала 7 мкс, что больше, чем в случае последовательного кода и это странно, т.к. сам цикл выполняется быстрее.
фактически получается в данный момент идет вывод N-2 значения, N-1 хранится где-то в промежуточном регистре, а N измеряется.
Как с этим боротся пока неясно, на форуме NI тоже пока молчат.
За любые подсказки буду весьма благодарен!
А задача, которая у нас возникла, вполне конкретная, нужно захватить сигнал, выполнить ряд вычислений и вывести сигнал наружу.
При этом важна латентность, а т.к. fpga умеют делать несколько вещей одновременно выбран модуль на базе ПЛИС.
Функции ввода, обработки и вывода занимают много тактов и не позволяют тем самым использовать Timed Loop.
А при применении обычного Loop латентность неоправданно увеличивается на сдвиговом регистре на один период выполнения цикла.
Как нам кажется, это получается из-за дополнительной конвеирезации кода.
Вот поясняющие картинки:
1) в случае последовательного кода, время выполнения всего цикла 4 мкс (должно быть 5 мкс т.к. на нашем модуле myRio 2 мкс - ввод, 2.8 мкс - вывод, но это отдельный вопрос откуда 4)
и латентность сравнима ~ 5 мкс, что корректно
2) в случае параллельного кода, время выполнения всего цикла 2.5 мкс (соответствует времени вывода, как самого длительного процесса в цикле) это правильно.
а вот латентность стала 7 мкс, что больше, чем в случае последовательного кода и это странно, т.к. сам цикл выполняется быстрее.
фактически получается в данный момент идет вывод N-2 значения, N-1 хранится где-то в промежуточном регистре, а N измеряется.
Как с этим боротся пока неясно, на форуме NI тоже пока молчат.
За любые подсказки буду весьма благодарен!
- Вложения
-
- doctor
- Сообщения: 2210
- Зарегистрирован: 28 июн 2012, 09:32
- Награды: 3
- Версия LabVIEW: 2009..2020
- Откуда: город семи холмов
- Благодарил (а): 27 раз
- Поблагодарили: 26 раз
Re: подсмотреть hdl код, возможно ли ?
проблемы могут быть с тактированием выполнения операций ввода- вывода, а не с регистрами программы. работа с модулем производится по spi интерфейсу + на борту модуля стоит своя fpga. поэтому на железную реализацию "записал-выдал" рассчитывать не стоит... может быть на ацп и цап стоят разные тактовые генераторы.
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение