serjj1333

Наверное. Если бы вы его показали, можно было бы глянуть что нужно поправить.

Посмотрите в настройках, я просто всегда пользовался stand alone Modelsim'ом и команду vsim заполнял сам. Зашифрованные библиотеки также вручную компилил.

signed тут не причём. Подозреваю, что в случае $unsigned( ((~one_bit) << select) ) сначала выполняется то что в скобках с приведением типов после уже для расширенного числа (операция <<), а, если $unsigned опустить, то сначала произойдёт приведение типов, а именно расширение разрядности one_bit до разрядности результата, операция ~ при этом даст 1 во всех добавленных битах, простая логическая операция без привязки к signed/unsigned представлению. Вот и знаменитое автоматическое согласование разрядностей верилога :rolleyes:

Для зашифрованных компонентов требуется библиотека cyclonev_ncrypt, я не нашёл её линковку в вашей команде запуска vsim

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

то что это не весь стек, а только опция, которая вам нужна, для обеспечения надежности передачи важной информации, если таковая требуется. При этом добавляемые избыточность/сложность минимальны и определяются разработчиком. ip входит в udp. Через хаб это работать будет. Настроить ip адрес по сетке через предложенную схему тоже можно (я собственно так и делаю). Я в своих рассуждениях отталкивался только от оговоренной задачи. Исходя из условий, не вижу тут никакой надобности в универсальном сетевом изделии с поддержкой всевозможных протоколов, имхо для простой связи железка - свич - пк перечисленных трех протоколов хватает. ps. ну и если есть желание включать железку, которая работает по точка-точка, в большую сеть, то есть немалая вероятность призвать админов :rolleyes:

Вам tcp/ip тут совершенно не нужен. Точка-точка, смешная скорость, udp пойдёт на ура, а с tcp запаритесь, кроме того у него избыточность выше чем у udp, он ещё меньше подходит для вашей задачи частой передачи маленьких сообщений. А в чём проблема с baremetal? Суть такая же как и в Nios. Для периферии используется hwlib. Хелпом на него являются его исходники, а именно h файлы, там по каждой функции избыточная справка дана. Дрова вам нужно будет писать не на HPS компонент, а на собственный eth, банальнейший memory map device. Если есть опыт с avl, но нет с axi, то можно смело писать под avl, т.к. qsys автоматически обеспечивает поддержку с avalon'ом при подключении hps компонента через fpga2hps. К драйверу нужно добавить 3 простых протокола: arp(для определения в сети), icmp(пинг) и udp(данные), а в программулине у вас сделать если требуется надстройку в виде контроля целостности (например по frame id, но это уже совсем тривиально). Здесь всё будет прозрачно и написано вами. А теперь представте, что у вас на вашей плате (не отладочной) под линухом, который вы доблестно собрали начинаются проблемы с tcp/ip, ваши действия?

Ну это всего 8 Мбит/с. Посылать 4 байта через Eth нецелесообразно, если есть возможность, то лучше копить несколько слов, хотя бы байт до 32-64, а потом уже слать их. Eth не предназначен для частой посылки сверхмалых пакетов. Гораздо выгоднее слать сразу пачку. У вас точка-точка или устройство должно будет работать в сети со сложной топологией? Зачем вам tcp/ip? Может лучше взять обычный udp, который прост как валинок? Если у вас данные супер отвественные, то можно сгородить собственную систему подтверждения доставки и запроса на пересылку в случае ошибки. Если всё так, то вам можно не связываться с EMAC в составе HPS, линухом, dma и прочим. Вы можете взять свой/чужой простенький Eth контроллер с интерфейсом Avalon/AXI4, он на ура подключается к AMR через FPGA2HPS bridge. На него пишется простенький драйвер с поддержкой UDP/ARP/ICMP, больше вам ничего не понадобится.

Какая скорость? Какой протокол?

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

У вас какие полосы? Посмотрите stm32 M4, там есть FPU и уже готовые библиотеки с реализованными FFT на вкус и цвет. Дёшево и сердито. А с discovery достаточно одного дня, чтобы уже начать под него писать.

Что за функция Delay(0xFFFF); ? Смотрите, что делается в функции alt_tick(). Есть подозрение, что у вас таймер не до конца настроен.

Если вы хотите использовать глобальные define'ы, используйте include для подключения хедера, в котором они объявлены.

У меня R2010b, возможно они поменяли с того времени набор функций из fi тулбокса. fi_radix2twiddles и fi_m_radix2fft_withscaling не входят в состав стандартных функций (на них даже хелпа нет), я их вытащил из примера. Вставил в свой скрипт, он их откуда-то из своих недр добыл. Собственно в примере есть их исходники.

Вот модель, меняя параметр WIDTH можно сравнивать реализацию fixed point FFT и floating point single precision FFT. clear all; Ns = 4096; fs = 100e3; Ts = 1/fs; t = 0:Ts:(Ns-1)*Ts; SNR = 30; df = fs/Ns; f = 0:df:(Ns-1)*df; f0 = 7e3; f1 = 19e3; A0 = 1e0; A1 = 1e-1; x = real(A0*exp(1i*2*pi*f0*t) + A1*exp(1i*2*pi*f1*t)); y = awgn(x, SNR, 'measured'); WIDTH = 16; y_fi = sfi(y, WIDTH); w = fi_radix2twiddles(Ns); w_fi = sfi(w, WIDTH); %y = y.*w; Y_fp = abs(fft(single(y))); Y_fp = Y_fp/max(Y_fp); Y_fi = abs(fi_m_radix2fft_withscaling(y_fi, w_fi)); Y_fi_ver = double(Y_fi); Y_fi_ver = Y_fi_ver/max(Y_fi_ver); err = Y_fp - Y_fi_ver; err = err .* err; str = sprintf('fixed point n%d', WIDTH); figure(1); clf(); subplot(2, 1, 1); hold on; plot(f, 20*log10(double(Y_fp) + 1e-15), 'b'); plot(f, 20*log10(double(Y_fi_ver) + 1e-15), 'xr'); title('ABS(FFT) result'); xlabel('frequency, Hz'); ylabel('abs(fft), dB'); legend('floating point single', str); grid on; hold off; axis([0 fs/2 -60 1]); subplot(2, 1, 2); plot(f, 10*log10(err + 1e-15)); grid on; xlabel('frequency, Hz'); ylabel('Square error, dB'); axis([0 fs/2 -120 0]); Пример графика для вашего случая Для 15 бит, как видно из графика, ошибка fixed point реализации пренебрежима мала в сравнении с разрешающими способностями Фурье.

А если система заведомо широкополосная, т.е. ширина полосы сопоставима с несущей, такая терминология допускается? Подозреваю, что "видеосигнал" идёт от т-ща Скляра, интересно, как в оригинале у него они называются, video signal или всё таки baseband signal? )

Всем доброго. В ходе реализации на stm32 фильтра Маджвика для системы акселерометр-магнетометр-гироскоп столкнулся с проблемой, что азимут считается неверно. Например плата находится в горизонтальной плоскости, а ось Z датчика направлена вниз (нормальное положение, А). Далее переворачиваем плату на 180 градусов так, что бы ось Z датчика была направлена вверх (инверсное положение, Б). И видим, что рассчитанный азимут изменился на 20-30 градусов (пока точнее я сказать не могу, нет стенда). При этом углы крена и дифферента считаются нормально для данной системы и фильтра. Добавил рассчёт модуля векторов ускорения и магнитной индукции. Начинаю менять положение платы, и если модуль ускорения изменяется в малых пределах (в основном из-за вибрации), то вектор индукции сильно растягивается строго в соответствии с положением платы. Физически в данной конкретной точке пространства магнитное поле Земли имеет определённое значение и направление, соответственно то что происходит, неверно. У меня есть подозрение, что проблема с рассчётом азимута кроется в этом, т.к. на азимут в случае, если плата находится в горизонтальной плоскости, влияет именно магнетометр (влияние гироскопа в стационарном случае можно не учитывать для простоты). Коллеги, есть ли соображения по этому поводу?

у вас data_master и instruction_master подключены к s1 порту on-chip ram?

Я под 12-м не пробовал, когда запускал это, делал на 13.1 (но в принципе должно быть тоже самое). ресет вектор оставить как было (у меня был на on-chip ram) когда вы добавляете epcs/epcq контроллер после регенерации bsp в eclipse в spl должна появиться папочка с либой дравера для общения с флешкой, подключаемая #include "epcs_commands.h" в ней вас должны заинтересовать функции epcs_write_enable epcs_sector_erase epcs_read_device_id epcs_read_buffer epcs_write_buffer вот например unsigned int epcq256_write (unsigned int offset, alt_u8 *data, int length) { #ifdef EPCQ_SUPPORT // specify offset alt_u8 rddata [EPCQ256_PAGE_SIZE]; // enable write operations epcs_write_enable(EPCQ256_BASE); // write buffer to specified offset epcs_write_buffer(EPCQ256_BASE, offset, data, length, EPCQ256_FOUR_BYTES_MODE); // read recently written data epcs_read_buffer(EPCQ256_BASE, offset, rddata, length, EPCQ256_FOUR_BYTES_MODE); // compare written and read data if (memcmp(data, rddata, length)) { // if some inequality exists, return 0 return 0; } return offset + EPCQ256_PAGE_SIZE; #else return 0; #endif } я сейчас по кусочкам вспоминаю, там мб ещё какие-то подводные камни были, в рабочем проекте я это всё практически выкорчевал, т.к. перешёл на NAND+ARM, но потом мб ещё придётся к этому вернуться.. ну и когда добавляете в qsys epcs/epcq контроллер, там есть галочка, что он сам ножки разводит (на зарезервированные под флешку), тогда у контроллера порт external не появляется. Я вроде бы так и оставил.

На 5-м циклоне просто ставишь в qsys корку контроллера и в ниосе подрубаешь драйвер, ножки он сам все разводит как надо автоматически.

Они не левые, они просто не ieee'шные, их сделали synopsis для synopsis. А то что у xilinx на них много, что сделано, ну так там тоже люди работают, многие начинали давным давно на synopsis и не хотят переделывать что либо, ибо "работает-не трожь". Но если поискать, то можно найти, что xilinx рекомендует в новых дизайнах использовать именно numeric_std.

Комплексная огибающая имеется в виду baseband signal а для модели можно "эквивалентная модель для комплексной огибающей BPSK/QPSK/QAM16/8PSK/подставь свою модуляцию сигнала"

Почитайте вот эту тему. Погуглите на тему совместного использования акселерометра и гироскопа для определения углового положения твердого тела. Акселерометр и магнетометр дадут вам зашумлённую оценку, которая будет фатально зависеть от вибраций и флуктуаций вектора ускорения, связанные с изменением скорости твердого тела. Вам нужно научиться комбинировать данные от датчиков для получения правильной оценки. Начните читать с комлпементарного фильтра, там всё просто. Вы можете, найдя угловое положение твердого тела, оценить составляющую вектора ускорения в плоскости oXY Земной системы координат. Эта составляющая не содержит ускорения свободного падения, т.к. гравитация в системе координат Земли направлена всегда вниз. Таким же образом вы можете найти oZ компоненту вектора ускорения в Земной системе координат. Z составляющую линейного ускорения тела можно оценить, вычтя из этой проекции 9,8. Переход осуществляется либо через матрицу вращений либо через умножение вектора ускорения в связанной системе координат (то что намерял акселерометр) на сопряжённый кватернион вращений.. В приведённой выше ссылке вроде бы всё это есть. Но я вам подробнее рассказывать не стану (в формулах), т.к. это не будет работать. Алгоритм получается неустойчивым, значительные шумы акселерометра и его ненулевое смещение дадут при интегрировании большую ошибку вычисления скорости, которая даст в свою очередь ещё большую ошибку вычисления перемещения (ещё одно интегрирование очевидно). Для того, чтобы это работало вам нужен ещё один источник информации о положении тела, который не подразумевает интегрирования (например GPS). Всё тоже самое как и для нахождения углового положения. Собственно в теме под ссылкой в одном из сообщений приведена ссылка на статью, где предлагается использовать упрощенный фильтр Калмана для определения линейного перемещения объекта по данным от измерителя скорости (интегральная часть) и измерителя положения (пропорциональная часть). Успехов.

Угу, для std_logic_vector операция "+" не определена, поэтому и ошибка. Поэтому либо сразу объявлять счётчик как unsigned либо приводить типы.

Оформите в виде исходного файла + простенького тб в архиве блоки // next all ... // calculate ... имхо лучше сделать как обычные циклы под always@(posedge Clock) и always@(*) соответственно ну и если вруг не лениво, то небольшую справку по результатам имплементации на любой понравившейся ПЛИС, чтобы человек, если вдруг заинтересуется, имел представление во что это ему может вылиться.