Dual-port & Two-porm RAM, реализация с [b]НЕЗАВИСИМЫМ[/b] тактированием чтения/записи Опции

[RXgade]

Необходима информация по реализации Dual-port и Two-porm RAM с НЕЗАВИСИМЫМИ тактовыми сигналами для чтения и записи данных (именно независимыми!!!) по всем канала.

Кто может дайте ссылки на статьи/книги где описаны ньюянсы реализации или реализации на HDL (бозотносительно технологии ПЛИС). спс

[RXgade]

Посмотрите описание (даташит) Cyclone 2 от Altera, рисунок 8-13 - структурная схема такой памяти. Там присутствует Write Pulse Generator. То есть видимо сама память состоит из триггеров - защёлок, на входы разрешения после дешифрирования подаются по ИЛИ импульсы записи двух портов.
Причём Write Pulse Generator включает в себя устройство асинхронной задержки, то самое делать которое своими силами производители ПЛИС вовсю не рекомендуют. На HDL его трудно записать.

Посмотрю. спс.

А с каким производителем работаете? У альтеры в хэндбуке на квартус есть такой пример :

Код

Example 11–15. Verilog HDL Simple Dual-Port, Dual-Clock Synchronous RAM

не то?

Работаю с ACTEL.

В этом примере очевидна проблема с потерей целостности данных...Если активные фронты клоков на запись и чтение близки по времени (при одинаковых адресах записи и чтения) то может произойти искажение считываемых данных (в идеале хочется чтобы было считано либо старое значение либо новое... но никак не искаженное).

В первом сообщении темы было "безотносительно технологии ПЛИС". То есть видимо на любой. Хочется код, для которого не важно какая ПЛИС.

Тут даже вопрос не в том, что на "любой" а в том что: "можноли написать синтезируемых HDL код для такой памяти не использую стандартные блоки памяти зависящие от технологии ПЛИС." При этом HDL-код для конктетной ПЛИС не обязан совпадать с кодом для другой.

Вопрос стоит некорректно. Код из примера Example 11–15. Verilog HDL Simple Dual-Port, Dual-Clock Synchronous RAM. будер работать безотносительно технологии ПЛИС в любом симуляторе, но то как он будет синтезирован в целевую ПЛИС отдается на откуп синтезатору. И если синтезатор, посчитает что описание не попадает под его критерии по которым он инферит память, то он сделает как умеет.

В свое время, для моделирования я делал DWC двухпортовую память, работало отлично, но в симуляторе. Попытки объяснить синтезатору что нужно вставить RAMB16 блок, вместо кучи логики успехом не увенчались. То же самое и про опцию byte_enable.

Поэтому, безотносительно технологии ПЛИс это будет классический

Код

always_ff @(posedge pipa_clk) begin
...
end

но во что это синтезируется и каким свойством будет обладать (Read First, Write First, Don't care) будет зависить целиком и полностью от умности синтезатора.

да.

[DmitryR]

В этом примере очевидна проблема с потерей целостности данных...

Видите ли, проблема в том, что inferred code работает (может работать) в железе не совсем так, как он описан. Поэтому вы не смотрите, какие проблемы могут теоретически возникнуть в HDL-описании памяти, смотрите на то, как быдет работать блок, в который этот код превратится.

[RXgade]

Видите ли, проблема в том, что inferred code работает (может работать) в железе не совсем так, как он описан. Поэтому вы не смотрите, какие проблемы могут теоретически возникнуть в HDL-описании памяти, смотрите на то, как быдет работать блок, в который этот код превратится.

Почитав описания некоторых реализаий Dual-port Ram-ов пришел к выводу (поправте меня если не прав): 100% защиту от нарушения целостности данных при одновременном и независимом доступе по одному адресу на запись/запись или чтение/запись обеспечить невозможно. Все равно есть отраничения взаимное изменение сигналов тактирования.

...а раз так, то появились некоторые соображения по реализации на "защелках". Если что получится то сразу отпишусь.

[des00]

...а раз так, то появились некоторые соображения по реализации на "защелках". Если что получится то сразу отпишусь.

безумству храбрых поем мы песню %)