jorikdima

Там нет zcu104. Тот четырехканальный ftdi (vcu1525) не подразумевает наличие арма

Я неправильно задал вопрос. Я имел ввиду, будет ли отладчик АРМа работать без этого сигнала?

Приветствую. Прочитал топик. Тоже нужен дамп. Тревожит сигнал SRST, его нету (подозреваю) в VCU1525 так как там не zynq. А вот в zcu111 или zcu104 именно zync, поэтому если у кого все же есть такая плата и дамп с нее был бы благодарен. Зачем вообще этот сигнал?

lms6002 попроще и дешевле. 35 баков на диджикее Есть limesdrmini поисчите на crowdsupply Я заказал, но он на 7002 На 6002 вещь очень охожу на минилаймсдр делаю я :) В луучшем случае доделаю :) Не в лучшем - не доделаю вообще :) Трудоемко. такие полноценные и самодостаточные универсальные фронтэнды больше никто не делает, насколько я помню. везде где-то чего-то не хватает. где ац требуют внешний, где генератор опоры. тут же есть все.

блок, изображенный по середине, дожден быть Dual Clock FIFO. Это и есть согласование

Да. Можно подсунуть в нумпай. По высокоуровневости Матлаб сход с питоном.

Как то видимо исторически пошло упоминание именно двухканального преобразователя. Хотя одноканальный так же подходит. Лично сделал на ft232h - работает без вопросов. В Revial очень нехватает заливки прошивки. В Сигнал тапе функционал программатора скопирован, пользуешься одним тулом, а тут туда сюда. Еще вопрос. Пусть немного офтоп, но коль уж пошли про дебаггеры. Есть ли возможность одновременной отладки логики и LatticeMico32 софта? Дебаггер то один? Я пробовал, как-то через одно место иногда работало. Но все как-то вкривь вкось. Не могут видимодва дебаггера один физ канал поделить. В альтере так же?

Требования на нахождение компании в России так прям важно? https://www.oshstencils.com/# Пользовался. Работают. По вашим размерам 35 баксов за стальной на одну сторону! Плюс доставка если не срочно несколько баксов.

У меня, возможно, ощущения еще десятилетней давности, но всегда казалось, что нечто сгенеренное матлабом (HDL или Си код) не очень применим в реальной жизни, ввиду своей говености. Это уже не так? И тут палка о двух концах. Если мы говорим о запуске на микроконтроллере то да, наверно можно получить си код из матлаба. А вот если у нас есть условная малина, то там можно и родной питон запускать, без конвертации (которая по любому должна быть встроена как-то в головной код МК). А матлаб на малине не взлетит :)

Вы, веротно, с питоном не знакомы. Он не про быстрый отклик как раз. И я совершенно н еприводил это как аргумент в его пользу. И про визуализаци вы тоже не правы.

А там что математика сложная? По-моему СТМ32 с такой задачей справится, чего там экзотику (относительную) брать? И да, если в душе не фпгашник, то нечего тут геморой с плисами искать.

1. Изучать матлаб (как таковой а не его тулбокс работы со звуком) можео любой. 2007 в том числе. Это не С#, изучив который 10 лет назад, я не понимаю современный код. 2. Что касается работы со звуковой картой, я не пробовал, но уверен считать данные оттуда не проблема, так как устройство довольно стандартное. 3. По объявленной задаче, имхую, что матлаб справится с потоком со свуковой карты в реальном времени. В том числе обработку, если она не сложная. 4. Я был приверженцом матлаба. Но сейчас его в области научных счислений двигает связка Python+NumPy . На вашем месте при отсутсвии опыта там и там, я бы ударился в питон. Работает везде, хоть в разпберри пай. Бесплатен. Популярен. Матлаб хорош тулбоксами. Если у вас нет обработки, где использовался бы один из тулбоксов очень активно, сэкономив вам время, я бы не брался за матлаб сейчас. А питон даст вам сильный плс в резме, если плюсы там нужны, конечно.

разве в RL есть подтяжка ресета? По-моему надо снружи подтягивать. И еще (по памяти, не проверял), по-моему DP надо подтягивать. В 232RL у них требуется богатая обвязка. В новх микрухах они все внутрь убрали, включая еепром и кварц, там вообще обвязка минимум.

Согласен, Интел (с Альтерой) и Латтис из разных миров. Тут просто Китай так вложился в экономику местную, чтоего начинают побаиваться. В дорогих городах куча покупателей недвиги - китайцы с кэшем (простому американцу за кэш не купить обычно, его просто нету). Есть просто китайские города с сотнями тысяч населения и это не тот самый чайна таун, другие.

какой же Китай хороший и послушный? Тут его боятся все поболее России.

Перед оцифровкой нужен фильтр, чтоб 2010МГц убрать как минимум. Вообще в идеальном случае образа быть не должно, если сигнал ни на каком этапе вещественным не становился.

Да, спасибо. Я эти и все остальные доки пересмотрел много раз и этот исходник тоже видел. Но там много лишнего для меня раз и второе, я, вероятно из-за нулегого опыта в верилоге и ртл вообще, почти ничего там не понимаю :) Я буквально в исходниках хотел найти ответ на свой вопрос, но... просто дебри :crying: Сейчас в процессе добавления вышеобсужденной логики, пока кажется там не такой уж огород как я думал, может пока. Спасибо.

Спасибо. Ясно. Да фифо поднимает флаг именно в момент последнего чтения данных тоже по фронту. Фифо не самопальное, а из латиссовского IP. Доп. регистр на выходе опционально имеется, хотя его смысл мне не очень ясен, ну или преимущество его наличия в моем случае. Мои надежды, что я чего-то не понимаю не оправдались :rolleyes: Придется городить огород с валидностью, читай непрочитанностью, данных на выходе моего локального фифо. И все только потому, что ФТ600 неудосуживается чуть заранее проинформировать меня об окончании транзакции...

Во, отлично! Это так же как думал я. Оставить данные на шине до следующего раза. После следующего спада TXE тогда нужно подождать один клок, прежде чем вычитывать данные с локального фифо, так как они вычитаны были в прошлый раз. Но! Два вопроса. 1. Что делать в самый первый раз? В самом начале после ресета. Получается, что по вышеописанной логике, после спада TXE я должен расчитывать, что у меня на шине фифо данные уже есть с прошлого раза и я должен начать с передачи именно их. Но в самый первый раз их же нету. Мне нужно городить логику, которая позволить отличить самый первый раз от не первого? 2. Меньшая проблема, но все же. Я расчитываю на использование флага empty от моего локального фифо, чтобы узнать есть непереданные или нету. В этом случае если представить, что я не успел передать только оно слово, то флаг empty стоять уже будет, хотя по факту еще одно слово не передано. Спасибо за ответы.

Хорошо, спасибо. Тогда главный вопрос, ради которого и описывал все это. Вот рассмотрим финальную стадию передачи. Предположим, что во время передачи FT600 решил остановить процесс и поднять TXE - имеет право в любой момент. На картинке у меня это происходит на желтом спаде. Проблемя в том, что к этому моменту я уже вычитал данные из моего фифо на красном фронте, в надежде передать их на синем фронте. Но надеждам не суждено сбыться, на синем фронте ФТ600 уже ничего лэтчить не будет. Как быть? Я же не могу назад запихать данные в фифо. Это уже вопрос именно постоения схемы, как фпгашники поступают в таком случае? Получается заранее фт600 не предупреждает о своей беспомощности в приеме данных. У меня сейчас имплементация именно от этого и страдает, при окончании, а точнее временном перерыве передачи данных теряется одно слово, которое из фифо вычитывается, но не передается в ФТ600. Спасибо. Спасибо, но как бы это печально не звучало, я не очень заинтересован в глубинных знаниях по этому вопросу. Это совсем не моя тема, тут просто нужно неосновную часть проекта сделать и забыть Да и часовые пояса сильно разные.

Я наверно криво сформулировал название, но придумать точнее не могу. Вопрос по реализации на верилоге, возможно вопрос какой-то глупый, но я в этом направлении начинающий :) Есть плис, к ней подключен мост FT600 . Речь идет о передачи данных из плис в мост, чтоб прочитать на компе. Так вот в плис данные лежат в фифо и по готовности FT600 их надо ему закачать. Интерфейс у Ft600 напоминает синхронное фифо, поэтому я и написал что нужно перегнать данные с фифо в фифо. Я привожу две катинки, чтобы описать временную диаграму Ft600: CLK - клог генерируемый Ft600 TXE - сигнал готовности Ft600 к приему (выход Ft600) WR - сигнал валидности данных (вход Ft600) Остальные сигналы не очень важны. Цветом я обозначил перепады в конце, на которые буду ссылаться. В примере на картинке данные я в плис должен выставить по зеленому спаду. По красному фронту Ft600 из залэтчит. Затем поймет что более не хочет/ не может принять и на следующем желтом спаде уберет сигнал готовности приема. На следующем синем фронте он уже проигнорирует то, что стоит на шине. Хотя я зачем-то согласно времянке должен еще один такт держать WR активным. Теперь о той части, что в плис, но без картинок. В плис фифо, у фифо на входе клок, сигнал разрешения чтения и данные. Читается по фронту (сигнал разрешения чтения я должен выставить по спаду за пол клока до этого). Вот наконец мы подошли к вопросу номер один. Как я должен это все организовать? У меня два варианта: 1. Я согласно времянке должен выставить данные на шину Ft600 по спаду, чтоб по фронту он прочитал. Я могу инвертировать клок у себя и подать его на мой фифо, тогда данные будут читаться как бы по спаду входного клока. 2. Никакой клок не инвертировать. Читать из фифо по фронту. Тогда например, по тому фронту, что перед зеленым я данные прочитаю из фифо, выставлю на шину, но Ft600 уже по этому фронту не успеет эти данные увидеть и залэтчит их на следующем фронте. Таким образом он их лэтчить будет как бы с задержкой на клок. И это у меня даже работает. Как обычно делают??? Я так понимаю первый вариант он более правильный что ли, но при этом сразу же вдвое снижается максимальная частота работы. Так как на все задержки остается пол клока. А во втором случае целый клок. Я надеюсь хоть что-то понятно в вопросе. Будет еще вопрос номер два, но лучше после первого. Спасибо.

Тоже тема интересна. Сам разве что могу удивиться даже отсутствию возможности делать проводники арками. Ну то есть не 45/90 градусов. Это правда для RF более важно, а не HiSpeed. Может его допилят лет через 5..... этот КиКад

Личного опыта нет. Но насколько знаю, работает. Проблема не столько в деньгах за растаможку (она полноценная), сколько за работу федэкса как брокера при растаможке. Ценник может удивить очень. Но это информация по памяти 5-7 летней давности, когда я для себя отметил, что этот путь нельзя использовать ни при каких условиях. Можно воспользоаться мэйлфорвардинговой системой. Пусть даже в штатах. Недорого, быстро. Например, shipito.com Ну либо найти кого за бугром, где прием федэксом проблемой не станет.

200 -это порог только для курьеров типа федэкса. Поэтому ими дорого по-любому. Для почты России и ЕМС - 1000.

Боюсь, что вы неправы. 1000 в месяц и точка. На одно лицо. Проблемы которые могут возникнуть, могут возникнуть, если есть передатчик на борде. Тут такого нет. Ну и похерить могут :) :crying: