Перейти к содержанию
    

rolin

Участник
  • Постов

    36
  • Зарегистрирован

  • Посещение

Весь контент rolin


  1. Увы, нет. В Верилоге идентично, что 7:0 что 0:7. Вы просто указываете необходимый диапазон адресов в удобной для вас форме, но реверса не будет. Эта оказия часто обсуждается, можете по стековерфлоу пройтись. Говорят, что в SystemVerilog есть спецкоманда компилятора для реверса адрессации, но я не особо специалист в этих вещах, просто хобби.
  2. Ну так это то же самое. Будет выбран указанный диапазон линий, старший к старшему, младший к младшему, без реверса. Видимо сама структура Плис не позволяет так вольно обходиться с адрессацией.
  3. Исходники проекта бутлоадера https://github.com/Dfinitski/Odyssey-2_2017...ssey_BL_2.0.zip И программа на Питоне для ПК для работы с ним https://github.com/Dfinitski/Odyssey-2_2017...tLoader_2.0.pyw Бутлоадер реализует 4 слота для хранения прошивок, один из них используется для загрузки самого бутлоадера ( по нулевому адресу). Написано для специфичного девайса, коряво, но работает. Модуль Remote не обновлять, его предупреждение игнорировать, иначе не будет работать, не знаю почему. Также может представлять интерес Gigabit Ethernet trough RGMII стек с ARP, ICMP, UDP уровнями.
  4. Разобрался, все работает. Оказалось, что в Верилоге byte <= byte[0+:7] не реверсирует биты, несмотря на кажущуюся логичность записи. А вообще - берем rbf файл, пишем его по нужному адресу во флешку не забыв реверсировать биты в каждом байте и вперед, все работает.
  5. У нас немного разные сиcтемы. У меня нет процессора и все делает плисина. В Верилоге обратить байт этo просто byte <= byte[0+:7] Rbf ,шьется во штатную флеш из которой она же потом грузится в режиме AS.
  6. И чем это отличается одно от другого ? Если я работаю с массивом 256*8 бит, то проще отобразить биты данных еще на моменте формирования буфера, чем потом сушить мозг над адрессацией.
  7. Всем привет. Занимаюсь вот чем-то подобным. Пишу бутлоадер для устройства. Программа на компьютере открывает rbf файл и шлет его кусками по 256 байт на устройство, плисина заливает эти куски постранично во флешку EPCS64. Перед записью производится стирание нужного участка флехи посекторно, участок заведомо больше rbf файла. После записи каждой страницы производится чтение ее из флехии и сравнение с буфером, ошибок нет, пишется правильно. Пишу по нулевому адресу. Проблема в том, что после перезагрузки плисина не грузится. Уже не знаю что делать, ошибок не вижу. Байты перед записью во флеху переворачиваю задом-наперед. Подскажите что-нибудь.
  8. На такую, чтобы температура в точке пайки была 200 градусов для свинцовой и 220-240 для безсвинцовой технологии.
  9. 484 ноги с шагом 1 мм не бог весть что. Воздушной станцией с нижним подогревом разумеется.
  10. В результате всего этого безобразия было испорчено 11 чипов 4CE55F23 и 5 печатных плат потеряло товарный вид в результате большого количества перепаек. Симптоматика повреждений самая разная. Некоторые чипы потеряли контакты на некоторых ногах внешних рядов, что подтвердило обычная прозвонка тестером - защитные диоды не звонятся. Интересно, что будучи запаянными на плату, при нажатии пальцем на чип в том районе, некоторые контакты временно восстанавливались, то есть поведение как будто плохая пайка. У одного чипа было замыкание между линиями питания 1.2 и 3.3 вольта Одни грузятся из памяти циклически, другие даже не грузятся. Ну и частично рабочие, как уже описано выше было. Проблему я вижу в калибровке паяльной станции. Температура подогрева у меня меряется снизу платы и естественно, требуемые 200 градусов на верхней поверхности не достигаются. С учетом еще и необходимой калибровки, температура подогрева была увеличена на 55 градусов от того что было, чтобы на поверхности было 200 градусов. Температура фена была в принципе правильно откалибрована по температуре воздуха в центре сопла, но какую температуру нужно выставлять, чтобы снизу чипа было 200 градусов ? Фен же сверху дует. Я поставил чип на подставку и выяснил, что для того чтобы снизу чипа было 200 градусов, температура воздуха должна быть 280 градусов. Таким образом, температура воздуха была уменьшена на 70 градусов от того что было. Время пайки при этом практически не изменилось. Правда, проверить новые установки не получается пока - плисины кончились :laughing: Тем не менее, температура фена 280 градусов уже превышает максимальную допустимую температуру пайки для чипа 270 градусов, но делать нечего, иначе низ не прогреется достаточно. Таким образом, можно сделать вывод, что печка - наиболее безопасный способ пайки благодаря равномерному прогреву, а фен - опасный, так как приходится превышать температуру воздуха на фене.
  11. Решил я перепаять плисины между эталонной платой, которая работает и проблемной платой. Плисина, в которой не работал ПЛЛ, так и осталась нерабочей, а плисина, которая работала, поломалась, только перестал работать другой ПЛЛ, который от 125МГц работал. И пришел я к выводу, что я неправильно паяю чипы и в результате этого они портятся. Паяю на воздушной станции с подогревом, подогрев 200 градусов, температура воздушного потока 350. Понизить температуру не получилось, так как при этом резко возрастало время пайки и от этого могло быть только хуже. Поэтому единственной реальной причиной мог стать слишком быстрый нагрев чипа. Я включал фен сразу на 350 градусов и макимальной подачей воздуха, и плисина, еще не имеющая теплового контакта с платой через шары могла быстро разогреваться до опасных температур за считанные секунды. После пайки, когда я выключал фен, он быстро охлаждался и относительно холодный воздух дул на чип, что могло вызвать деформации корпуса. Теперь я включаю фен на 200 градусов и подымаю температуру ступенчато по 50 до 350. Заканчиваю пайку в обратном порядке. В тоге я перепаял новые плисины на платы и они обе нормально работают. Такие дела.
  12. Оказалось, что это не плисина сдохла, а один из источников питания плохо пропаян был, но это не было причиной проблемы. Чтобы подтвердить или опровергнуть мою догадку, что ПЛЛу не нравятся определенные входы, пробовал подключать один и тат же ПЛЛ к разным входам плисины, благо плата позволяет это дело. Это ничего не дало, наблюдал разного рода спецэффекты, обьяснить которые в здравом рассудке невозможно. Иногда было такое, что перезагрузка плисины меняла картину происходящего. Заменил плисину на новую, но ничего не изменилось. Эталонная плата работает с тем же кодом. Имеется такое предупреждение, связанное с ПЛЛ, повторяется раз 6: Warning (332009): The launch and latch times for the relationship between source clock: PLL_inst|altpll_component|auto_generated|pll1|clk[0] and destination clock: PLL_122|altpll_component|auto_generated|pll1|clk[0] are outside of the legal time range. The relationship difference is correct, however the launch time is set to 0. PLL_inst - это первый ПЛЛ, работающий от источника 125 МГц и от которого у меня моргают светодиодики и вообще шевелится вся схема. PLL_122 - выдает только одну частоту 80кГц, используемую для таймера сброса и работает от другого источника 122.880 МГц. Какая между этими ПЛЛ связь, ума не приложу, но Квартус видит между ними какую-то связь. Спасибо за советы, но тут у меня и перепайка и другая плата уже, но не помогает. Схема давно отлажена, устройство можно сказать серийное. В настоящий момент наблюдаю проблему - PLL_122 выдает частоту примерно в 1000 раз меньше, чем задано. Например, задаю 8 МГц на выход, осциллограф фиксирует примерно 7.3 кГц, частота нестабильная, сигнала locked нет. Другой ПЛЛ PLL_inst работает без проблем.
  13. Похоже у плисины проблемы с конкретными входами тактовых сигналов. Пытался завести клок с другой стороны плисины, не работало, потом заработало, но выходная частота немного отличалась от заданной и плавала в небольших пределах, потом выход заглох, но сигнал locked продолжал оставаться в высоком состоянии. А потом плисина сдохла и перестала грузиться с памяти. (наверное бензин кончился :) )
  14. Значит используются счетчики от неиспользуемых выходов ПЛЛ, только виззард ничего об этом пользователю не говорит. Работает это и на третьих циклонах, проверено. Думаю, в мире наберется тысщенка плат с третьим циклонами и с ПЛЛ выдающими 80кГц.
  15. Первые циклоны в корпусе F484 ? Ну не знаю. У них же вроде ноги не совпадают, вообще работать не будут. Даже если бы были третьи циклоны перебитые, то жрало бы так, что я бы заметил. Кстати, некоторые экземпляры плат потребляют больше остальных, какое-то непостоянство у них в этом. Виззард говорит, что может и по факту работает у меня уже давно и на третьем циклоне еще тоже работало. Главное, чтобы счетчики не были заняты на других выходах ПЛЛ. Факт, что работает, если я на вход подаю такт 125 МГц от другого источника и ПЛЛ вдруг "выздоравливает". Хотя, я не тестирую на 80кГц, я поставил 800кГц, но я проверял и на других частотах выходов и даже пытался вывести тутже частоту, что и зашла - не работает ПЛЛ именно когда вход у нее с этого источника
  16. Так как генератор ПЛЛ работает в диапазоне 500 -600МГц, то работать на 41 он вообще не должен. Но видимо не ьак все просто там.
  17. Я формирую 80 кГц из 122.88 . Это не всегда работает, но если это единственный выход ПЛЛ то работает точно. Ниже не пробовал, без надобности. В пятом циклоне можно делать каскадное включение выходов, то есть следующий выход будет предыдущий поделенный счетчиком. Смысла в этом мало, так как счетчик и в коде можно завсегда поставить. Попробовал тестовый код на эталонной плате - оба ПЛЛ работают без проблем. Похоже, какие-то бракованные плисины попадаются или я не знаю что и думать.
  18. Сброс никак не помогает. В общем, ситуация такова: Есть два одинаковых клока 122.880 на входе от двух АЦП, на разных банках, оба 1.8 вольт Есть два одинаково настроенных ПЛЛ, выходы которых выведены наружу для контроля на осциллографе. Если первый ПЛЛ подключен к первому клоку а второй ПЛЛ ко второму, то первый ПЛЛ не работает а второй работает нормально Если оба ПЛЛ подключены к первому или второму клоку - оба ПЛЛ не работают Если первый ПЛЛ подключен ко второму клоку а второй к первому, то кроме того, что оба они не работают, то еще тухнет третий ПЛЛ, который работает себе от совсем другого клока 125МГц от другого источника и вообще не при делах. Если кто-то видит в этом систему, пишите. А я наверное попробую сменить версию Квартуса.
  19. Да, это обьяснило бы происходящее. Но я проверил еще раз все пины связанные с ПЛЛ и все правильно. VCCD_PLLx подключены к 1.2 вольта, VCCAx к 2.5 вольт, GNDAx на земле. Здравая мысль. попробую сброс поставить, может он приведет его в чувство. Ну что вы, так нагло подрезать клок идущий наружу через пин это наврядле. Не забывайте, что с той же прошивкой прекрасно работает эталонная плата и с десяток собранных ранее.
  20. Дык смотрю осциллографом. Вывел выходы ПЛЛ наружу и смотрю. Один из ПЛЛ работать с данным входом категорически отказывается Сам вход рабочий, ибо подключил к нему делитель на счетчике и получил требуемую частоту без проблем. По схеме там ничего интересного, такт приходит от АЦП, банк io и сам АЦП запитан от 1.8 вольт. Единственное, оба спецвхода и прямой и инверсный у меня замкнуты и на них обоих подается частота.
  21. Входы опорной конечно же специальные выводы, иначе Квартус даже не подключит их к ПЛЛ. Да, CMOS, никаких извращений.
  22. Всем привет. Собираю платы на EP4CE55 уже не впервой, конструкция можно сказать обкатанная временем. Вдруг, один из экземпляров не работает, но как-то странно - плисина успешно грузится но половина ее схемы не шевелится. Очевидно, что нет такта от одной из PLL. Заменил чип, все заработало. Думаю, ну брак, бывает. Как же я удивился, когда следующие две платы тоже не работают, причем плисины из разных партий, даже корпусом отличаются. Пришлось углубиться. Тренируюсь на тестовой прошивке. Проверил, доходит ли внешний опорник до входа PLL - доходит. Сделал еще один PLL, с такой же конфигурацией как и неработающий, начал играться с коэффициентами и в общем-то не могу сказать ничего определенного. Получал на выходе самые разные комбинации. Например первый ПЛЛ выдает какие-то герцы вместо килогерц, сигнала locked нет, второй при этом отлично работает. Оба выдают неправильную сильно заниженную частоту, оба не выдают никакого сигнала. Бывало, на выходе какие-то хаотичные импульсы, бывало со старта работает полсекунды и глохнет. Какой-либо системы не выявлено, полный хаос. Опорник - 122.8 Мгц 1.8 вольт, входной порт указан как 1.8 Вольт вход. На плате есть также еще один опорник с почти такой же частотой - 125МГц 3.3 вольта. При подаче его на вход ПЛЛ они работают хорошо. Конечно, при больших коэффициентах деления бывает не работает, но с этими приколами я знаком давно. Есть какие-то мысли что может быть и что делать ? Работаю с циклоном 4 уже не первый год, никогда проблем не было, а тут массовый падеж.
  23. Вот, га что меня хватило.... Работает только на увеличение усиления, стабилизации нет, на уменьшение не работает. Что-то я не понимаю, видимо // AGC reg [23:0] agc_control = 24'd0; // 83888608 wire [23:0] max_gain = 23'd8000000 - step_up; wire [23:0] min_gain = 23'd1 + step_dwn; wire [23:0] step_up = 23'd56000; // 1 sec wire [23:0] step_dwn = 16'd560; // 10 msec wire [23:0] gate = 24'd8000000; wire signed [47:0] mult_out; mult_24Sx24S_w agc_mult(det_out, agc_control, mult_out); wire signed [23:0] agc_mult_out = mult_out[35:12]; reg [5:0] state = 0; wire [23:0] mod = agc_mult_out[23] ? ~agc_mult_out : agc_mult_out; always @(posedge clock) begin case (state) 0: if(det_out_strobe) state <= state + 1'd1; 1,2,3 : state <= state + 1'd1; 4: begin if(mod > gate) if(agc_control > min_gain) agc_control <= agc_control - step_dwn; if(mod < gate) if(agc_control < max_gain) agc_control <= agc_control + step_up; state <= state + 1'd1; end 5,6,7: state <= state + 1'd1; 8: begin agc_out <= agc_mult_out; agc_out_strobe <= 1; state <= state + 1'd1; end 9: begin agc_out_strobe <= 0; state <= 1'd0; end default: state <= 1'd0; endcase end
  24. Кто-нибудь может поделиться кодом АРУ на verilog , ну или в крайнем случае VHDL ? Умаялся я уже с этим AGC.....
  25. Трудно сказать, код, что выше эту ошибку не выдает. Согласно коду выше, если бы Remote выдал бы эту ошибку, то процесс не пошел бы дальше и до переконфигурации не дошел. Причем ошибку не выдает даже когда я намеренно неправильно готовлю образ флешки. Непонятно, на каком этапе происходит проверка CRC фактически, но проверка этого флага в коде происходит после установки адреса и перед командой реконфиггурации. Как-то странно это. Прошивку для флешки делаю так
×
×
  • Создать...