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

    

Lutovid

Свой
  • Публикаций

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

  • Посещение

Репутация

0 Обычный

Информация о Lutovid

  • Звание
    Частый гость
  • День рождения 17.05.1992

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Москва

Посетители профиля

898 просмотров профиля
  1. Да видимо это самый удачный метод, спасибо,
  2. Можно и в 1 строку набить, если без табуляции и переноса строки. Я попробовал так как мне было проще, не получилось, буду по другому)
  3. Да реализация не самая удачная - при чем задача простая - на входе 32 сэмпла по 16 бит, а на выходе эти данные должны выдаться с задержкой до 448 сэмплов. В принципе есть еще 2 варианта реализации: 1) написать блоки module signal_delayer_tmp #( parameter integer MAX_DELAY_VAL = 448,//in 16bit samples parameter integer DELAY_VAL = 0//in 16bit samples )( input [MAX_DELAY_VAL*16-1 : 0] big_shift_reg, input [15:0] delay_val_i; output [511:0] out_delayed ); assign out_delayed = (delay_val_i==DELAY_VAL) ? big_shift_reg[DELAY_VAL*16+:512] : '0; генерэйтом набить из 448 штук, а выходы побитово просуммировать - но возможно будет слабое место в побитовом суммировании - их там 448 проводов все же 2)вставить память с циклическими параллельными записью и чтением со смещением адреса - но этот вариант подольше писать, так что я пока его не рассматривал Про ваш пример - я сначала так и написал, но по констрейнтам не сошлось и я решил, что возможно мне помогут директивы распараллеливания
  4. Привет всем! Возникла следующая проблема - есть сдвиговый регистр большой длины, есть управляющий сигнал, по управляющему сигналу должна выбраться часть этого большого регистра и выдаться на выход Написал такой код module signal_delayer_behav #( parameter integer MAX_DELAY_VAL = 448//in 16bit samples )( input axis_aclk, input axis_aresetn, (*keep = "true"*)input [15:0] delay_val, (*keep = "true"*)input [511:0] axis_s_tdata, (*keep = "true"*)input axis_s_tvalid, output axis_s_tready, (*keep = "true"*)output reg [511:0] axis_m_tdata, (*keep = "true"*)output reg axis_m_tvalid, input axis_m_tready ); assign axis_s_tready = axis_m_tready; (*keep = "true"*) reg [MAX_DELAY_VAL*16-1 : 0] delay_tdata_shift_reg; (*keep = "true"*) reg [MAX_DELAY_VAL-1 : 0] delay_tvalid_shift_reg; (*keep = "true"*) wire srstn; xpm_cdc_async_rst #( //Common module parameters .DEST_SYNC_FF (4), // integer; range: 2-10 .RST_ACTIVE_HIGH (0) // integer; 0=active low reset, 1=active high reset ) xpm_cdc_async_rst_inst ( .src_arst (axis_aresetn), .dest_clk (axis_aclk), .dest_arst (srstn) ); always @(posedge axis_aclk)begin if(!srstn) delay_tvalid_shift_reg <= 'b0; else begin delay_tvalid_shift_reg <= {delay_tvalid_shift_reg[MAX_DELAY_VAL-1-32 : 0], {32{axis_s_tvalid}}}; delay_tdata_shift_reg <= {delay_tdata_shift_reg[512*(MAX_DELAY_VAL/32-1)-1 : 0], axis_s_tdata}; end end integer i; always @(posedge axis_aclk)begin for (i=0; i <= MAX_DELAY_VAL-32; i=i+1) begin: output_delayed if(delay_val==i)begin axis_m_tdata <= delay_tdata_shift_reg[16*i+:512]; axis_m_tvalid <= delay_tvalid_shift_reg[i]; end end end endmodule Вопрос по последнему блоку always - в таком формате он не будет аналогом case и не выстроит все в параллель - так показал результат синтеза на 17.1 вивадо. Попробовал unique но это не работает корректно когда нет else if. Есть какие-то грамотные решения такой проблемы? Мне бы вообще последний блок сделать в асинхронке always (*), ну то есть не асинхонке а без задержки на такт. Но если сделать так то синтезатор ругнется на логикал луп, Забыл дописать - управляющий сигнал условно константный - меняется очень редко - его изменение обрабатывается нормально
  5. Я пытался решить проблемы с констрейнтами сменой стратегии разводки на оптимизацию по быстродействию - как правило величина слэка не менялась.
  6. Привет всем! У меня глупый вопрос, но поверхностное гугление не дало особых результатов. Перехожу вынужденно с 2017.2 на 2018.2.1. Там я так понял они ввели новую библиотеку lwip202 с которой у меня благополучно мой код не заработал. Разбираться в чем проблема времени нет пока, поэтому хотел пока старой библиотекой обойтись, при чем вроде она есть в комплекте 2018.2, судя по тому, что в установочной папке лежит. Но вот проблема - в гуе bsp settings нет этих старых библиотек(lwip141), а если вписать в .mss насильно то что я хочу: BEGIN LIBRARY PARAMETER LIBRARY_NAME = lwip141 PARAMETER LIBRARY_VER = 1.8 PARAMETER PROC_INSTANCE = microblaze_0 PARAMETER phy_link_speed = CONFIG_LINKSPEED1000 END То эта библиотека не подключается нормально. Подскажите, как это делается пожалуйста.
  7. С трансиверами встречал разные проблемы - возможно стоит копнуть в сторону эквалайзеров dfe/lpm? Убедитесь что эквализация включена
  8. Здравствуйте! не подскажете пожалуйста материал по акси интерфейсу с нормальными временными диаграммами? я вот пока ищу, но как оказалось это не так просто, у ксайлинкса их нет, я так понял надо у arm искать, но все что я пока нашел - это не то что хотелось бы=/. Я просто решил попользовать прегенерируемый код вивадо(акси мастер) - он вроде работает, поменял ширину шины на 512 бит и выставил величину берстов до 128 и наблюдаю, что промежутки между берстами уж слишком большие - приводят к понижению пропускной способности в 2 раза(миг на входе 512 бит и соответственно мастер под него я делаю 512 бит, соединены через акси интерконнект), все что я вижу - это то что акси интерконнект сигнал bvalid выставляет поздно, после этого начинается новый берст, но чтоб разобраться, нужно все таки изучить акси стандарт

    Извините что пишу в личные сообщения, показалось, что так проще будет

    1. Показать предыдущие комментарии  Ещё #
    2. Lutovid

      Lutovid

      Спасибо! буду изучать референс. Для меня не понятным является тот факт, что когда я завершаю транзакцию(то есть берст в моем случае), та нога, которая является статусом выполнения транзакции, как вы написали, поднимается через большой промежуток времени. Не понятно что интерконнект все это время делает=/. Пропускная способность слэйва позволяет гнать хоть непрерывный поток... Для моей задачи это прям очень критично, поэтому надо будет докапываться до истины.

    3. RobFPGA

      RobFPGA

      Приветствую!

      axi4_b* сигнализирует тогда когда транзакция записи пробежала весь путь от вас к памяти и обратно. Понятное дело что будет большой latency. Для ускорения как я и писал можно делать конвеер - генерируете новые транзакции на axi4_aw* и axi4_w* (или на axi4_ar*) не дожидаясь прихода статуса на axi4_b* (или прихода данных на axi4_r*). В настройках интерконекта есть параметр (write|read)issule который задает сколько транзакций может быть в "полете" у данного интерконнекта. Ну и ваш FSM фактически должен состоять из 3 - один генирирует запросы на шину axi4_aw* и на второй FSM, который шлет данные на axi4_w* и в конце бурста плюсует счетчик третьему FSM, который проверяет на axi4_b* что запись прошла. 

      Удачи! Rob.

    4. Lutovid

      Lutovid

      ааа, спасибо! теперья понял вас! Так и сделаю)

  9. Спасибо! CPU мне не нужен, почитаю про AXI_DataMover
  10. Я полагаю для этх задач уже есть готовые решения, поэтому хотелось бы избежать такого метода
  11. Спасибо за ответ! Объединить нужно вглубь, свой CDC делать времени к сожалению нет. Так что я сразу рассчитывал на первый вариант впросы правда остались - пропускная способность изменится ли? как я бы мог использовать приведенные вами готовые блоки? я не имел опыта работы с ними(кроме интерконнекта - про который я и думал - идея была использовать только его и миги, а мастером свою стэйт машину) Хотя вопрос наверно глупый, так как я скупо описал задачу, но суть пока только в том, что бы циклично писать, источник данных - акси стрим, единственное решение, которое я сейчас ищу - это упрощение интерфейса общения - в стандартном мэмори мэпд интерфейсе слишком много ног и всякой интерфейсной логики + сохранение пропускной способности
  12. Привет всем! У меня появилась задача сделать ринг буффер на ддр. Циклично писать по очереди все адреса ddr4. Я уже реализовывал подобную задачу для одной микросхемы - выбирал нэтив интерфейс и писал стейт машину, но в этот раз задача - объединить 2 микросхемы в одну область адресного пространства. Возник вопрос как это сделать корректнее - никогда не использовал DMA, на сколько целесообразно его использовать и чем он поможет? или объединить через акси интерконнект? основная проблема в том, что приходится ставить два MIG контроллера у которых свой клоковый домен. Мне бы хотелось писать свою стейт машину на одном клоковом домене и управлять данными и адресами чере какой-то переходник. Велосипеды делать желания нет. Соответственно вопрос - как решать такую задачу корректнее и быстрее И изменится ли пропускная способность при использовании доп. ядер? Необходимо циклично писать в обе ддр на максимально допустимой пропускной способности. Может быть есть какие-то примеры - я пока не нашел? Пока я вижу только подключение обоих мигов через интерконнект к моей стейт машине(мастеру). Но является ли это решение оптимальным? Работа с акси стримом все таки по проще.
  13. Да, ошибся, подзабыл уже это уточнение, но вероятность встретить плисины с одинаковым DNA все же довольно низкая, и сомнительно, что у кого-то это получилось.
  14. По идее в даташитах пишут, что в рамках одного семейства они должны быть уникальны