Jump to content

    
Sign in to follow this  
Perdachillo

Очистка RAM на SystemVerilog

Recommended Posts

7 минут назад, Nick_K сказал:

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

То есть сделать массив регистров по количеству  записей в таблице коммутации, где каждый регистр будет содержать флаг валидности  записи в таблице? 

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

Share this post


Link to post
Share on other sites
On 8/2/2019 at 6:04 PM, Perdachillo said:

То есть сделать массив регистров по количеству  записей в таблице коммутации, где каждый регистр будет содержать флаг валидности  записи в таблице? 

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

Вообще я немного не то имел ввиду, но так тоже можно. Если количество записей ограниченное и имеет стандартный паттерн, то можно создать на максимальное количество регистр, а на входе повесить дешифратор адреса, который будет определять в какой зоне валидные, а в какой невалидные данные. Туда же можно будет добавить счётчик устаревания.

Если же данные с различной длиннной, тогда проще подключить ещё одну память (распределённую) и просто хранить указатели начала валидных записей.

В любом из вариантов скорее сложности в правильном описании, чем в физическом резальтате.

Share this post


Link to post
Share on other sites
On 8/2/2019 at 6:04 PM, Perdachillo said:

Смущает, что он все таки прилично логики займёт. 

Можно и на RAM сделать, возьмите максимальную ширину шины данных N, но понимайте, что по каждому адресу этой памяти у вас хранится N флагов валидности основной памяти.

Тогда, по маске, на записи можете адресовать любой бит, а при "стирании" сразу по N бит будете "зачищать".  Ресурсоав минимум, но есть латенсия.

Trade-off между ресурсами и задержками Вам выбирать. 

Share this post


Link to post
Share on other sites
30 минут назад, Mad_kvmg сказал:

Тогда, по маске, на записи можете адресовать любой бит, а при "стирании" сразу по N бит будете "зачищать".  Ресурсоав минимум, но есть латенсия.

Trade-off между ресурсами и задержками Вам выбирать. 

Хорошая идея, получится настраиваемый компромисс между количеством тактов для сброса и объёмом памяти. 

1 час назад, Nick_K сказал:

Туда же можно будет добавить счётчик устаревания.

Да, надо весь механизм с устареванием сюда грамотно засунуть. Если использовать ram для хранения информации о валидности, а не регистры, то это несколько усложняет это дело

1 час назад, Nick_K сказал:

В любом из вариантов скорее сложности в правильном описании, чем в физическом резальтате.

По простому походу не выйдет) придётся засесть.. 

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

 

Спасибо за помощь! 

 

Share this post


Link to post
Share on other sites
52 minutes ago, Perdachillo said:

Да, надо весь механизм с устареванием сюда грамотно засунуть. Если использовать ram для хранения информации о валидности, а не регистры, то это несколько усложняет это дело

Наоборот проще некуда. При заполнении таблицы актуальности данных сформируйте для каждой записи в таблицу счётчик максимальной величины (к примеру по 4 бита на счётчик) тогда при проходе состояния актуализации декрементируйте все значения на 1, в результате у вас данные устареют на 16 проходе без обновления. Что в RAM, что на распределённой логике - описание раз плюнуть.

Share this post


Link to post
Share on other sites

Вспоминая рекомендации в соответствующем упоминавшемся здесь документе "Recommended styles...", я в подобном случае поместил память в отдельный файл.
Получилось более громоздко, чем через generate в том же модуле, где память используется.

Но синтезатору это более понятно.

Так что отделите шины каждого блока памяти, вынесите память в отдельный модуль, а в основном модуле в generate добавьте instance этих модулей памяти.

Share this post


Link to post
Share on other sites
26 минут назад, Nick_K сказал:

Наоборот проще некуда. При заполнении таблицы актуальности данных сформируйте для каждой записи в таблицу счётчик максимальной величины (к примеру по 4 бита на счётчик) тогда при проходе состояния актуализации декрементируйте все значения на 1, в результате у вас данные устареют на 16 проходе без обновления. Что в RAM, что на распределённой логике - описание раз плюнуть.

Получается память будет двухпортовая? Один порт будет добавлять (или перезаписывать) записи во время поступления нового Mac адреса, а второй порт (параллельно этому) будет опрашивать последовательно все записи и декрементировать счётчики реализуя механизм устаревания?

33 минуты назад, Juzujka сказал:

Вспоминая рекомендации в соответствующем упоминавшемся здесь документе "Recommended styles...", я в подобном случае поместил память в отдельный файл.
Получилось более громоздко, чем через generate в том же модуле, где память используется.

Но синтезатору это более понятно.

Так что отделите шины каждого блока памяти, вынесите память в отдельный модуль, а в основном модуле в generate добавьте instance этих модулей памяти.

Попробую. Я почему-то думал, что generate сам по себе создаёт несколько отдельных модулей

Share this post


Link to post
Share on other sites
48 minutes ago, Perdachillo said:

Получается память будет двухпортовая? Один порт будет добавлять (или перезаписывать) записи во время поступления нового Mac адреса, а второй порт (параллельно этому) будет опрашивать последовательно все записи и декрементировать счётчики реализуя механизм устаревания?

Вообще вся память на кристалле двухпортовая - не принципиально. Но всё зависит от верхнего автомата. Если у вас есть Управляющий FSM у которого одно положение - приём Маков (самое длительное по времени), но есть и состояния актуализации, перезаписи, другие состояния (минимальные по времени), тогда можно обойтись однопортовой RAM. В противном случае задействуйте 2 порта. Напоминание: с некоторыми оговорками нельзя писать/читать по одной и той же ячейке памяти (да оно вам и не нужно, но возможна коллизия раз в год)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this