Чтение данных из CPU в FPGA, vhdl Опции

[%-)]

сигналы:
ce - выбор ПЛИС (активное 0)
we - запись в ПЛИС (активное 0)
d[7 downto 0] - данные которые надо записать в ПЛИС

как сделать простейшее чтение данных из шины процессора в ПЛИС на vhdl ?

наподобие как запись в SRAM

[Shivers]

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

Код

module simple_reg (CKOUT, d, nce, noe, nwe);
  inout [7:0] d;
  input nce, nwe, noe,CKOUT;

  reg [7:0] din_1d,din_2d, din, dout;
  reg nce_1d, nwe_1d, noe_1d, nce_2d, nwe_2d, noe_2d;

  // sync
  always @(posedge CLKOUT)
   begin
    nce_1d  <= nce;
    nce_2d  <= nce_1d;
    nwe_1d <= nwe;
    nwe_2d <= nwe_1d;
    noe_1d  <= noe;
    noe_2d  <= noe_1d;
    din_1d[7:0] <= d[7:0];
    din_2d[7:0] <= din_1d[7:0];
   end

//latches
  always @(posedge CLKOUT)
   begin
    if(nwe_2d & ~nwe_1d) din[7:0] <= din_2d[7:0];
    if(.....)  dout[7:0] <= ...
   end

  assign d = (nce | noe) ? 8'hzz : dout;

endmodule

Так получатся наилучшие сетапы, холды и общая fmax. Но будет больше потреблять, займет больше места внутри плис и т.д. В общем, свои + и -

[des00]

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

при работе на CLKOUT в режиме source-synchronus синхронизаторы вообще не нужны, а при работе на другом асинхронном клоке на все сигналы ставить синхронизаторы, это простите меня бред. К тому же чреватый потенциальными проблемами, данные и адрес хлопать на триггерах не имеет смысла, т.к. это мультицикловые пути и условие по setup/hold легко выполняется протоколом шины.

[Shivers]

при работе на CLKOUT в режиме source-synchronus синхронизаторы вообще не нужны, а при работе на другом асинхронном клоке на все сигналы ставить синхронизаторы, это простите меня бред. К тому же чреватый потенциальными проблемами, данные и адрес хлопать на триггерах не имеет смысла, т.к. это мультицикловые пути и условие по setup/hold легко выполняется протоколом шины.

Это не бред, а помехоустойчивость. Если CKOUT - синхронный клок, то можно защелки и сразу ставить, бесспорно. Но если асинхронный, то двойная классическая схема синхронизация обязательна, иначе будете ловить все помехи на шине. В частности, в мостовых схемах асинхронных магистральных интерфейсов без этого никуда - внешний тактовый сигнал и сплошные схемы синхронизации. Опять же оговорюсь, этот кусок кода предназначен для помехоустойчивости, стабильности и хорошей времянки. Минусы емкость, ну и т.д. - писал выше.

Сообщение отредактировал Shivers - Nov 23 2009, 12:41

[des00]

Это не бред, а помехоустойчивость. Если CKOUT - синхронный клок, то можно защелки и сразу ставить, бесспорно. Но если асинхронный, то двойная классическая схема синхронизация обязательна, иначе будете ловить все помехи на шине. В частности, в мостовых схемах асинхронных магистральных интерфейсов без этого никуда - внешний тактовый сигнал и сплошные схемы синхронизации. Опять же оговорюсь, этот кусок кода предназначен для помехоустойчивости, стабильности и хорошей времянки. Минусы емкость, ну и т.д. - писал выше.

Вы одно с другим путаете. Может быть в асинхронных магистральных интерфейсах вы и правы. Но тут стоит проц, на его шине висит фпга, Шина параллельная, синхронная, работающая в асинхронном режиме (расстояние между процом и фпга не выше ~10см). CLKOUT определяет на шине все. Если посмотрите внимательно на картинку то видно что проц выдерживает и setup/hold самостоятельно. Еще раз при работе от CLKOUT (source-synchronus) синхронизаторы ставить вообще смысла нет, адрес/данные это мултицикл, нужно только вырезать фазу сигнала записи/чтения. А при работе на клоке фпга в асинхронном режиме, ставить синхронизаторы как это делаете вы тоже смысла не имеет, т.к. проц опять же выдерживает setup/hold. Смысла в синхронизаторах на адресе/данных нет.

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

[Shivers]

Вы одно с другим путаете. Может быть в асинхронных магистральных интерфейсах вы и правы. Но тут стоит проц, на его шине висит фпга, Шина параллельная, синхронная, работающая в асинхронном режиме (расстояние между процом и фпга не выше ~10см). CLKOUT определяет на шине все. Если посмотрите внимательно на картинку то видно что проц выдерживает и setup/hold самостоятельно. Еще раз при работе от CLKOUT (source-synchronus) синхронизаторы ставить вообще смысла нет, адрес/данные это мултицикл, нужно только вырезать фазу сигнала записи/чтения. А при работе на клоке фпга в асинхронном режиме, ставить синхронизаторы как это делаете вы тоже смысла не имеет, т.к. проц опять же выдерживает setup/hold. Смысла в синхронизаторах на адресе/данных нет.

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

Я выше написал, что согласен насчет не-нужности двукаскадных схем синхронизаций для УЖЕ синхронного интерфейса. Тем не менее, первый каскад защелок кмк все равно надо ставить, даже если пути - малтисайкл. Точнее не так -
Если исходить из концепции простоты дизайна и нацеливаться на low power asic, то можно сразу ставить защелки с использованием незащелкнутых управляющих сигналов - т.е. делать простой интерфейс "как на россыпи".
Но! Если требуется стабильная и быстродействующая прошивка для ПЛИС, или же мы боремся со снижением нагрузки на цепи в асике, то имеет смысл ставить один(1) каскад d-триггеров на весь входной интерфейс, и уже потом разгребать всю логику внутри. Преимущества уже указаны - снижение нагрузки на цепи. С большой нагрузкой может и мальтисайкл 3 не спасти, а про разброс времянки от_разводки_к_разводке я и вовсе молчу. По крайней мере, отлаживая модель для PCI я добивался большей производительности именно введением дополнительных d-триггеров. Впрочем, в PCI еще и адрес/данные мультиплексированы, немного сложнее ситуация.
Итого, я с самого начала не опровергаю правильность первого кода, просто указал на возможную альтернативу более синхронной реализации, со своими + и - ессно. А картинку смотрел невнимательно, сразу не понял, что интерфейс синхронный, каюсь.