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

rolin

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

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

  • Посещение

Сообщения, опубликованные rolin


  1. Обычно биты нумеруются так [MSB:LSB]. И, если заметили, я присвоил игреку икс. Т.е., напишите так, конкретно, и биты прицепятся, как нужно.

    Y[7:0] = X[0:7].

    Это же просто "провода".

    Увы, нет. В Верилоге идентично, что 7:0 что 0:7. Вы просто указываете необходимый диапазон адресов в удобной для вас форме, но реверса не будет. Эта оказия часто обсуждается, можете по стековерфлоу пройтись. Говорят, что в SystemVerilog есть спецкоманда компилятора для реверса адрессации, но я не особо специалист в этих вещах, просто хобби.

  2. А просто выбрать биты Y = X[0:7]?

    Ну так это то же самое. Будет выбран указанный диапазон линий, старший к старшему, младший к младшему, без реверса.

    Видимо сама структура Плис не позволяет так вольно обходиться с адрессацией.

  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. Вы БГАшну микросхему с таким количеством ног паяете одной лишь воздушной станцией???

    484 ноги с шагом 1 мм не бог весть что. Воздушной станцией с нижним подогревом разумеется.

     

  9. В результате всего этого безобразия было испорчено 11 чипов 4CE55F23 и 5 печатных плат потеряло товарный вид в результате большого количества перепаек.

     

    Симптоматика повреждений самая разная.

     

    Некоторые чипы потеряли контакты на некоторых ногах внешних рядов, что подтвердило обычная прозвонка тестером - защитные диоды не звонятся. Интересно, что будучи запаянными на плату, при нажатии пальцем на чип в том районе, некоторые контакты временно восстанавливались, то есть поведение как будто плохая пайка.

     

    У одного чипа было замыкание между линиями питания 1.2 и 3.3 вольта

     

    Одни грузятся из памяти циклически, другие даже не грузятся.

     

    Ну и частично рабочие, как уже описано выше было.

     

    Проблему я вижу в калибровке паяльной станции. Температура подогрева у меня меряется снизу платы и естественно, требуемые 200 градусов на верхней поверхности не достигаются.

    С учетом еще и необходимой калибровки, температура подогрева была увеличена на 55 градусов от того что было, чтобы на поверхности было 200 градусов.

     

    Температура фена была в принципе правильно откалибрована по температуре воздуха в центре сопла, но какую температуру нужно выставлять, чтобы снизу чипа было 200 градусов ? Фен же сверху дует. Я поставил чип на подставку и выяснил, что для того чтобы снизу чипа было 200 градусов, температура воздуха должна быть 280 градусов. Таким образом, температура воздуха была уменьшена на 70 градусов от того что было.

     

    Время пайки при этом практически не изменилось.

     

    Правда, проверить новые установки не получается пока - плисины кончились :laughing:

     

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

     

     

  10. Решил я перепаять плисины между эталонной платой, которая работает и проблемной платой.

    Плисина, в которой не работал ПЛЛ, так и осталась нерабочей, а плисина, которая работала, поломалась, только перестал работать другой ПЛЛ, который от 125МГц работал.

     

    И пришел я к выводу, что я неправильно паяю чипы и в результате этого они портятся.

     

    Паяю на воздушной станции с подогревом, подогрев 200 градусов, температура воздушного потока 350. Понизить температуру не получилось, так как при этом резко возрастало время пайки и от этого могло быть только хуже.

     

    Поэтому единственной реальной причиной мог стать слишком быстрый нагрев чипа. Я включал фен сразу на 350 градусов и макимальной подачей воздуха, и плисина, еще не имеющая теплового контакта с платой через шары могла быстро разогреваться до опасных температур за считанные секунды.

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

     

    Теперь я включаю фен на 200 градусов и подымаю температуру ступенчато по 50 до 350. Заканчиваю пайку в обратном порядке.

     

    В тоге я перепаял новые плисины на платы и они обе нормально работают.

     

    Такие дела.

  11. Оказалось, что это не плисина сдохла, а один из источников питания плохо пропаян был, но это не было причиной проблемы.

     

    Чтобы подтвердить или опровергнуть мою догадку, что ПЛЛу не нравятся определенные входы, пробовал подключать один и тат же ПЛЛ к разным входам плисины, благо плата позволяет это дело.

    Это ничего не дало, наблюдал разного рода спецэффекты, обьяснить которые в здравом рассудке невозможно. Иногда было такое, что перезагрузка плисины меняла картину происходящего.

     

    Заменил плисину на новую, но ничего не изменилось. Эталонная плата работает с тем же кодом.

     

    Имеется такое предупреждение, связанное с ПЛЛ, повторяется раз 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 работает без проблем.

  12. Похоже у плисины проблемы с конкретными входами тактовых сигналов.

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

     

    А потом плисина сдохла и перестала грузиться с памяти.

     

    (наверное бензин кончился :) )

  13. Так на самом деле может работать при каскадировании счётчиков (ранее я думал, что в Cyclone IV это ещё не поддреживается).

    Значит используются счетчики от неиспользуемых выходов ПЛЛ, только виззард ничего об этом пользователю не говорит.

    Работает это и на третьих циклонах, проверено. Думаю, в мире наберется тысщенка плат с третьим циклонами и с ПЛЛ выдающими 80кГц.

  14. Посмотрите внимательно маркировку плисин, мы один раз нарвались на перемаркированные 1-ые Циклоны.

    Первые циклоны в корпусе F484 ? Ну не знаю. У них же вроде ноги не совпадают, вообще работать не будут. Даже если бы были третьи циклоны перебитые, то жрало бы так, что я бы заметил.

    Кстати, некоторые экземпляры плат потребляют больше остальных, какое-то непостоянство у них в этом.

     

    Может быть ТС просто повезло с некоторыми PLL? 80 кГц - это очень мало и они не должны работать на такой частоте...

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

     

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

    Факт, что работает, если я на вход подаю такт 125 МГц от другого источника и ПЛЛ вдруг "выздоравливает".

     

    Хотя, я не тестирую на 80кГц, я поставил 800кГц, но я проверял и на других частотах выходов и даже пытался вывести тутже частоту, что и зашла - не работает ПЛЛ именно когда вход у нее с этого источника

  15. Чтобы получить 80кГц - надо иметь частоту VCO всего 41МГц. Очевидно, что стабильно это работать не обязано.

    Так как генератор ПЛЛ работает в диапазоне 500 -600МГц, то работать на 41 он вообще не должен. Но видимо не ьак все просто там.

  16. ТС, "Например первый ПЛЛ выдает какие-то герцы вместо килогерц", в Altera можно PLL-ом генерировать килогерцы? В Xilinx ниже 4 МГц вроде как нельзя...

    Я формирую 80 кГц из 122.88 . Это не всегда работает, но если это единственный выход ПЛЛ то работает точно. Ниже не пробовал, без надобности.

    В пятом циклоне можно делать каскадное включение выходов, то есть следующий выход будет предыдущий поделенный счетчиком. Смысла в этом мало, так как счетчик и в коде можно завсегда поставить.

     

     

     

    Попробовал тестовый код на эталонной плате - оба ПЛЛ работают без проблем. Похоже, какие-то бракованные плисины попадаются или я не знаю что и думать.

     

     

  17. Сброс никак не помогает.

     

    В общем, ситуация такова:

    Есть два одинаковых клока 122.880 на входе от двух АЦП, на разных банках, оба 1.8 вольт

    Есть два одинаково настроенных ПЛЛ, выходы которых выведены наружу для контроля на осциллографе.

     

    Если первый ПЛЛ подключен к первому клоку а второй ПЛЛ ко второму, то первый ПЛЛ не работает а второй работает нормально

     

    Если оба ПЛЛ подключены к первому или второму клоку - оба ПЛЛ не работают

     

    Если первый ПЛЛ подключен ко второму клоку а второй к первому, то кроме того, что оба они не работают, то еще тухнет третий ПЛЛ, который работает себе от совсем другого клока 125МГц от другого источника и вообще не при делах.

     

    Если кто-то видит в этом систему, пишите.

     

    А я наверное попробую сменить версию Квартуса.

  18. Я про VCCD_PLLx говорю.

    Да, это обьяснило бы происходящее. Но я проверил еще раз все пины связанные с ПЛЛ и все правильно. VCCD_PLLx подключены к 1.2 вольта, VCCAx к 2.5 вольт, GNDAx на земле.

     

     

    То есть при работе от АЦП возможно надо через некоторое время после загрузки ПЛИС подать сброс на PLL.

    Здравая мысль. попробую сброс поставить, может он приведет его в чувство.

     

     

     

    Посмотрите отчеты Timequet !

    Присутствуют ли в этих отчетах синтезируемая частота на PLL ?

    Если в отчётах частота не присутствует - значит Quartus удалил одну из частот... Этот гад может так сделать. А самое главное будет молчать как партизан !

    Ну что вы, так нагло подрезать клок идущий наружу через пин это наврядле. Не забывайте, что с той же прошивкой прекрасно работает эталонная плата и с десяток собранных ранее.

  19. Тогда наверное имеет смысл посмотреть осцилографом, что там происходит. Ну и может быть уже запостить схему.

    Дык смотрю осциллографом. Вывел выходы ПЛЛ наружу и смотрю. Один из ПЛЛ работать с данным входом категорически отказывается Сам вход рабочий, ибо подключил к нему делитель на счетчике и получил требуемую частоту без проблем.

    По схеме там ничего интересного, такт приходит от АЦП, банк io и сам АЦП запитан от 1.8 вольт.

    Единственное, оба спецвхода и прямой и инверсный у меня замкнуты и на них обоих подается частота.

  20. По таблице ножек (питаниям) нужно пройтись, для PLL еще свои отдельные выводы бывают. Чтобы все соответствовало.

    Входы опорной конечно же специальные выводы, иначе Квартус даже не подключит их к ПЛЛ.

     

    Стандарты ввода-вывода совпадают, LVCMOS-LVCMOS?

    Да, CMOS, никаких извращений.

  21. Всем привет.

     

    Собираю платы на EP4CE55 уже не впервой, конструкция можно сказать обкатанная временем. Вдруг, один из экземпляров не работает, но как-то странно - плисина успешно грузится но половина ее схемы не шевелится. Очевидно, что нет такта от одной из PLL. Заменил чип, все заработало. Думаю, ну брак, бывает.

     

    Как же я удивился, когда следующие две платы тоже не работают, причем плисины из разных партий, даже корпусом отличаются.

     

    Пришлось углубиться. Тренируюсь на тестовой прошивке.

     

    Проверил, доходит ли внешний опорник до входа PLL - доходит.

     

    Сделал еще один PLL, с такой же конфигурацией как и неработающий, начал играться с коэффициентами и в общем-то не могу сказать ничего определенного.

    Получал на выходе самые разные комбинации. Например первый ПЛЛ выдает какие-то герцы вместо килогерц, сигнала locked нет, второй при этом отлично работает. Оба выдают неправильную сильно заниженную частоту, оба не выдают никакого сигнала. Бывало, на выходе какие-то хаотичные импульсы, бывало со старта работает полсекунды и глохнет.

    Какой-либо системы не выявлено, полный хаос.

     

    Опорник - 122.8 Мгц 1.8 вольт, входной порт указан как 1.8 Вольт вход.

     

    На плате есть также еще один опорник с почти такой же частотой - 125МГц 3.3 вольта. При подаче его на вход ПЛЛ они работают хорошо. Конечно, при больших коэффициентах деления бывает не работает, но с этими приколами я знаком давно.

     

    Есть какие-то мысли что может быть и что делать ? Работаю с циклоном 4 уже не первый год, никогда проблем не было, а тут массовый падеж.

     

     

  22. Вот, га что меня хватило....

    Работает только на увеличение усиления, стабилизации нет, на уменьшение не работает. Что-то я не понимаю, видимо

     

        //  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

  23. Ну и что за причина перезагрузки? Судя по всему, должна быть "CRC Error".

    Трудно сказать, код, что выше эту ошибку не выдает. Согласно коду выше, если бы Remote выдал бы эту ошибку, то процесс не пошел бы дальше и до переконфигурации не дошел.

    Причем ошибку не выдает даже когда я намеренно неправильно готовлю образ флешки.

    Непонятно, на каком этапе происходит проверка CRC фактически, но проверка этого флага в коде происходит после установки адреса и перед командой реконфиггурации. Как-то странно это.

     

    Прошивку для флешки делаю так

    config.jpg

     

     

×
×
  • Создать...