ArAhis

Неужели никто не подскажет :( :( :(

Э-э-э? А почему у меня переход ноль—ноль не вызывает на осцилограмме ну никаких отклонений от прямой? :-) эт хорошо! это справедливо для всех внутренних сигналов ПЛИС?

Кто-нибудь делал, у кого-нибудь есть, или может кто-нибудь знает где взять??? Если у кого есть, поделитесь пожалуйста, очень нужно, буду очень благодарен!!! [email protected]

я первый:)!!!! проси в свои =))))))

как много ответов!!! Всем огромное спасибо!!!

Привожу кусок кода: entity TxUnit is port ( Clk : in Std_Logic; TxD : out Std_Logic; ...); end entity; architecture Behaviour of TxUnit is signal TReg : Std_Logic_Vector(7 downto 0); -- transmit register signal BitCnt : Unsigned(3 downto 0); -- bit counter ... begin process(Clk,Reset,Enable,Load,DataO,TBuff,TReg,tmpTRegE,tmpTBufE) constant CntOne : Unsigned(3 downto 0):="0001"; ... begin ... case BitCnt is ... when "0001" | "0010" | "0011" | "0100" | "0101" | "0110" | "0111" | "1000" => TxD <= TReg(0); TReg <= '1' & TReg(7 downto 1); BitCnt <= BitCnt + CntOne; end case; ... end process; end Behaviour; Что означает строка: TReg <= '1' & TReg(7 downto 1);

Есть микросхемка - приемопередатчик MLX90121. Никак не могу до конца разобраться с режимами ее приема! У нее 2 режима приема: - Direct Reception; - Majority Voting (MV) Reception. 1. В режиме Direct Reception цифровые данные с микросхемки поступают без синхросигнала, так ли это??? Если так, то как лучше организовать прием сигнала? 2. В режиме MV Reception прием начинается с подачей '1' сигнала CK, только вот вопрос, когда подать эту самую '1'??? Судя по примеру (Example in ISO1569-Dual Sub-carrier), логическое значение '1' сигнала CK нужно подавать тогда, когда на входе (в ПЛИС) DOUT появится '1', но тогда, во-первых, появляется неизвестная нам задержка и получается рассогласование обработчика Majority Voting и данных, а во-вторых, мы не примем первые '0'??? Может я не совсем правильно понял даташит, растолкуйте кто может! Datasheen смотри во вложении или качай отсюда: http://www.melexis.com/Asset.aspx?nID=4755 MLX90121_REV6.pdf

Вопрос: есть ли вероятность того, сигнал 00, сверх-семплированный, допустим в 5 раз быстрее будет принят как 00001 00000, при условии, что 5-й бит попадет на переход 1-й ноль -> 2-й ноль?

Вообще-то там дальше было написано про подсчёт единиц или нулей, ага? 110 000 111 001 — 2 0 3 1 — 1 0 1 0 111 000 110 000 — 3 0 2 0 — 1 0 1 0 Если k взять побольше, всё будет с приличной вероятностью. «Идеальный» приём сигнала в таких условиях представляется задачей в общем случае не разрешимой. Если два устройства питаются независимыми синхросигналами, то синхронизовать их в общем случае без передачи синхросигналов нельзя. Например передаётся ноль. За какое-то время генераторы в устройствах разойдутся так, что сказать сколько нулевых бит прошло между двумя моментами времени достоверно будет нельзя и никакие ресурсы ПЛИС тут не помогут. Единственный вариант — делать сверх-семплирование способом, который я уже описал и надеятся на то, что по каналу пробегает достаточно ноликов и единичек для переодической синхронизации буфера. Размышлял тут по поводу сверх-семплирования и пришел к следующим выводам: - сверх-семплирование с частотами большими в 2, 4, 6, 8,... раз частоты входного сигнала не поможет, поскольку в анализируемых 2, 4, 6, 8,...-битных выборках может быть равное число '1' и '0', и тогда не понятно какой сигнал выбирать - '1' или '0'; - сверх-семплирование с частотами в 3, 5, 7,... раз больше частоты входного сигнала также непонятно: может возникнуть ситуация, когда фронт сигнала совпадет с центральным отсчетом сверх-семплированного сигнала; например, сигнал 01, сверх-семплированный с частотой в 5 раз больше может приняться как сигнал 00011 или как сигнал 00111 (центральный бит попал на фронт перехода 0->1) и тогда не понятно, что брать - '1' или '0'.

Не факт, что принимаемый сигнал будет 111000111000! Если один из фронтов тактового сигнала совподет с фронтом входного сигнала, то может получиться следующее: пусть, например, фронт входного сигнала совпадает с каждым 3-м фронтом синхросигнала, тогда по этому фронте мы можем принять, либо '1' либо '0', причем не факт, что входной сигнал на этом фронте всегда будет искажаться в одну сторону, например, мы можем принять любой из следующих сигналов: 110000111001 или 111000110000 и т.д. Т.е. на каждом 3-м фронте тактового сигнала, мы можем принять как '1', так и '0', не зависимо от фронта входного сигнала (1->0 или 0->1)!!! Вообще, меня интересует такой общий вопрос: как грамотно (наиболее просто, с наименьшими затратами) принять (в регистр) цифровой сигнал (1 битовый), поступающий с известной заданной частотой, при условии, что тактовый сигнал не поступает, имея в распоряжении все возможности ПЛИС? Может быть уже существуют оптимальные методы, я не в курсе!!!

Вот именно, при приеме используется режим Direct Reception, по даташиту в этом режиме синхросигнал не поступает (вроде бы, хотя может в даташите ошиблись)!!! Так все же как посоветуете поступить, использовать Clock Data Recovery, если да, то что это такое (где про него можно почитать)? А может стоить использовать другие способы приема сигнала (например, в ПЛИС взять синхросигнал частота которого в 4 раза быстрее частоты входных данных, и уже на основании 4-х выборок определять значение входного бита (мои догадки, не факт что это работает))???

Есть на входе (в ПЛИС) цифровой сигнал, поступающий с определенной частотой (ну, скажем 10МГц), только этот самый тактовый сигнал НЕ ПОСТУПАЕТ (так сделано в приемопередатчике MLX90121 (режим Direct Reception))! Посоветуйте как грамотно принять этот цифровой сигнал, имея при этом свой (внутренний) тактовый сигнал любой частотой??? Тупо брать тактовый сигнал той же частоты, с которой поступает цифровой сигнал не получится, т.к. фронты обоих сигналов могут совпасть и получим неправильно принятый сигнал!!! Если я не правильно понял datasheet на MLX90121, поправьте меня. Хотя по другому его понять сложно! Если что, datasheet находится здесь: http://www.melexis.com/Asset.aspx?nID=4755

Не забываю, это в тестбенче делаю. Я же написал, что это тестовый кусок кода, на самом деле сигналу dout присваивается сумма всех 64-х значений data(i), суть не в этом, а в том что ModelSim не хочет выводить сигналы массива в сигнал dout. Если есть другие предложения как передать бит din(35) в биты (41 downto 35) сигнала din_42, буду только рад! В данном случае сигнал clk не используется, это тестовый пример по которому я хотел бы разобраться, почему сигналы массива не передаются в выходные сигналы (если смотреть в ModelSim'е)

Вот такой вот кусок кода: entity accum is port ( n : in std_logic_vector(5 downto 0); clk : in std_logic; din : in std_logic_vector(35 downto 0); dout : out std_logic_vector(41 downto 0) ); end accum; architecture Behavioral of accum is type accum_64_t is array (0 to 63) of std_logic_vector(41 downto 0); signal din_42 : std_logic_vector(41 downto 0); signal data : accum_64_t; begin din_42(34 downto 0) <= din(34 downto 0); gen1 : for t in 35 to 41 generate begin din_42(t) <= din(35); end generate; data(0) <= din_42; ... dout <= data(0); end Behavioral; Это тестовый кусок кода, в котором я просто пытался понять, почему Modelsim 5.8d на выход dout выводит "UUU..."! Если вместо dout <= data(0); написать dout <= din_42; моделирование будет происходить нормально, на выходе dout будет сигнал din_42?? С чем это связано, может я не правильно использовал массив???

К сожелению, у нас не было курса по алгоритмам реализации математических операций и функций, а также не было нормального курса по цифровой схемотехнике :( приходиться все изучать самому Спасибо за пример, попробую всетаки реализовать табличным методом с целью уменьшения задержки и увеличения точности