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

Есть неплохая книга ...
"Advanced FPGA Design Architecture, Implementation, and Optimization"
Steve Kilts\Spectrum Design Solutions\Minneapolis, Minnesota

Может материал из нее пригодится для вашего начинания.

а вот меня она не впечатлила. как-то куцо всё и на систематическое изложение не тянет.

Ради интереса, а какая впечатлила?
В частности - по сходной тематике.
Да и вообще по FPGA design.
А вообще - было бы интересно сделать рейтинг книг по FPGA design....

извините, по имплементации на ПЛИС настольной библией не обзавёлся. по крайней мере так чтобы какую-то одну выделить(как например для верификации книжка Бергерона) не могу/всё как-то самостоятельно пробовал, что конечно не всегда на пользу из-за возникновения ложных стереотипов и вредных привычек/. хотя идея составить рейтинг была бы очень позитивна. может создадите топик, а потом после набора книг-кандидатов можно составить рейтинг?

Задачка: описать 2х-портовый триггер на синтезируемом HDL,
поведение при "совпадении фронтов" - произвольное (выбирайте сами).

описать наподобие двухпортовой памяти. Только использовать массив 1 длины (с одной ячейкой памяти)
Или нельзя?

Давненько не брал в руки шашек... Но скоро опять предстоит.
Как-то так?

Да

А практический смысл в чем.
Выход чем подхватить.

Пример - многопортовый регистровый файл на распределенной памяти (с несколькими портами записи).

Ну это «навеяно фланктером». Когда-то хоть и работал с альтерой, но xilinx-овский сайт тоже изучал.

Тю, у них был ещё html-ный вариант с нормальными картинками-схемами. А сейчас только pdf-ка с плохими.
Надо порыться в тогдашних архивах, может, где-то рядом с AHDL-кусочками и страничка с сайта сохранена.

а двупортовая память чем не устраивала? В чем разница в использовании?
PS Ее (память) ж можно реализовать как на распределенной логике так и с ипользованием блочной памяти.

http://www.floobydust.com/flancter/Flancter_App_Note.pdf - нагуглил(про фланктер - не знал).





Попробуйте описать асинхронную память с двумя портами чтения и записи (чтение - асинхронно, запись - по клоку) - на блочной не реализуется, на распределенной - только если самому хитро описать, в лоб - софт соберет на триггерах, а не на ЛУТ-ах (давно делал, на новом софте не проверял).

Тут ещё и информации больше, спасибо.

Картинка не полностью описывает поведение триггера. Что должно быть внутри блока с Q (оно будет не только при совпадении фронтов) - &, 1, =1? После этого можно сделать (один из вариантов уже показали). На мой взгляд, сама задумка неправильная с точки зрения гонок, метастабильных состояний. Зачем два тактовых сигнала? И вообще, для этого нужно было создать отдельную тему в будущем разделе.

По аналогии с 2х-портовой памятью.



- моделируется, но не синтезируется.


Частный случай этой "задумки" - Flancter.

Еще пример использования "многопортового триггера".

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





(на другом форуме за эти "издевательства" над Верилогом - забанили на несколько суток).

При совпадении (± зона переходных процессов) понятно что бардак, а так, на мой взгляд, всё понятно — в зону входов для CLK1 входит только D1, поэтому по фронту CLK1 в Q должно записаться значение D1 без никакой связи со значением на D0.

Про бан не понятно.
А в Flancter увидел свой вариант.
Работа по разным фронтам клока. И отработка событий как по одному плечу, так и по другому.
Ничего не теряя.
Конвеер событий.

Ooopss!!!!
Сообщение выше как бы от Alex1961 — было от меня.
Что-то крепко на форуме с куками и запоминанием входа глюкнуло. Ща жаловаться буду.

Flancter:

+1
Именно от этой точки («а, ну так это нужен такой триггер, из которого таким вот образом получится фланктер») обратным ходом от фланктера и был получен приведеный код.

всем привет!
это конечно не трюки, но наверное кому-нибудь пригодится:
есть у меня склад всяких разных элементов вычислительных на которых я когда-то в стародавние времена учился Верилогу.
я их тогда вроде верифицировал, но может быть что-то и не доглядел, так что "доверяй, но проверяй". сейчас перепроверять уже не хочется.
единственное, что я подправлю, так это переделаю чуть-чуть шапки на манер SV ANSI и комментарии в заголовках вставлю, чтобы было юзабельно.
выкладывать буду по мере. кто чего будет доделывать-переделывать не забывайте добавлять свои имена и какой-нить лог о переделках.

первый релиз-кандидат целочисленный последовательный знаковый/беззнаковый делитель с коррекцией остатка
при операндах 32 на 32 бита синтезица в Ксайлинкс В2Про 2VP2fg256 грэйд -6 примерно на 140 МГц жрамши 277 слайсов
16х16 бит на xc2vp70 -6 примерно 150 МГц при 131 из 33088 слайсах
описание:
sequential integer divider with reminder correction
takes in 2 arguments of adjustable width (parameters op_A_width, op_B_width)
and divide the first one by the second treating them either signed or unsigned depending on op-type input
which takes op_A_width+1 clock cycles + 1 cycle for reminder correction, provided that stall_n signal is deasserted
rdy_n output indicates completion of operation with result(rez) and reminder containing valid results
the unit provides additionally an overflow and division by zero exception flags

а для того чтобы не ждать так долго каждое деление был сделан массив из таких делителей(кол-во ктых зависит от ширины делимого) с вращающимся по кругу раздатчиком операндов /сборщиком результатов

синтез для 16х16 на xc2vp70 -6 даёт примерное 130МГц при 2889 из 33088 (8%)
32 на 32 даже страшно проверять (кому не страшно может сам попробовать)

ЗЫЖ внимание, сборщик не защёлкивает результаты в регистры на выходе

конвеерный пирамидальный умножитель знаковых/беззнаковых чисел

16 х 16 на xc2vp70 -6 примерно 180 МГц при 564 из 33088 слайсах

описание:
pipelined integer multiplier
takes in 2 arguments of adjustable width (parameters op_A_width, op_B_width)
and multiply the first one by the second treating them either signed or unsigned depending on op_type input
with op_B_width clock cycles of initial latency, provided that stall_n signal is deasserted

Спасибо за код. Любопытно будет посмотреть, особенно, когда потребуется для конкретной задачи. Одно маленькое замечание - в коде большие отступы, похоже, делались табуляцией по 8 символов. Понимаю, что у каждого свое понятие о красоте и целесообразности, но, может быть отступы в 2-3-4 пробела покажутся вам удобнее. Я лично пользуюсь отступами в 2 пробела.

Так там натальные табуляции и стоят (что мне кажется правильным), в редакторе любимом можно поставить размер табуляции какой нужно, при желании и попросить конвертнуть под установленный размер.

Я уже заменил (автоматически), пользуюсь EditPlus. В начале кода были пробелы. А по-нормальному табуляция - 8 пробелов.

да я тоже пользуюсь 2-пробельной табуляцией. именно поэтому так широко размазано и получилось. но думаю это переживабельно.

очередь с рукопожатием на обоих портах. может быть сконфигурирована на использование block RAM так и на обычной логике (в зависимости от установленного атрибута).
для указателей на концы очереди использована тривиальная схема кодирования (бинарный код) так что не советую использовать в самолётах, спутниках и в районе экватора. можно только для поиграться.
есть две ноги для заглядывания в будущее (может быть полезны для поддержания непрерывного потока данных интерфейсных КА).

замеры не делал, потому как там мало управляющей логики.

Исправленный код выложен тут

описание:
parameterizable queue with a trivial pointer encodings
can be implementer eather with on-chip Block RAM or distributed memory, subject to synthesis attribute setting of the stack memory
when implemeted with a RAM block adopt the first-word-falls-through policy for zero latency immediate pop
provides forward read and write grant signals for smooth operation of FSMs controlling the data-flows on both ports of the channel(queue)

2 'CaPpuCcino': Ну что, даёте добро на оформление этих схемотехнических приёмов в виде статей на wiki или нет? И если да, то на нашей вики выкладывать (будет выглядеть как моноширинный текст) или в Викиучебник (будет с подсветкой синтакиса и автоматической нумерацией строк)?

выложил в сеть, значит каждый может делать с этим что его душе угодно. тем что выложил в открытый доступ уже дал согласие на свободное использование.
но а разве в отстойнике эти коды не нужно подержать? так может кто покритикует, народ ошибки поищет, а то может быть там что неправильно, или какая у нас по этому направлению политика?
в принципе мне-то всё равно где это висеть будет. я в команду трюкачей не записывался и как вы положили сии дела вести не знаю.
ЗЫ: вот например FIFO как минимум могли бы обсудить, ведь разные схемы кодирования указателей существует. бинарный код не самый лучший вариант.

для синхронного проекта по барабану %)

ЗЫ. Извиняйте коллеги, навесили на меня 2 проекта самостоятельных (со сроком готовности вчера) + проект со студентом 80/20 (со сроком готовности январь-декабрь), зашиваюсь по самые помидоры.

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

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

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

фифо что ли ?

оно.

У Xilinx'а эта корка синтезируется с чистого VHDL'я. Единственно, что там было архитектурно зависимого - вызов внешней процедуры (через PLI из dll) для явного плейсмента BRAM модулей (видимо относительно друг друга)
Внутри выглядит жутковато - по количеству оберток напоминает капусту

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

а можно увидеть это чисто VHDLное описание, из которого синтезируется кросс-доменная очередь? очень интересно.

У хилых есть еще иксаппы по теме ФИФО. Я их код причесал и параметризовал. Если интересно, могу выложить.

P.S. VHDL.

спб. а в реальной разработке использовали, хорошо работает?


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

самая зачетная из них, это сверхбыстрое фифо на LFSR счетчиках.

использовал, чему там не работать то ?

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

Вечерком дойду до дома, отправлю (если я ее не потер )

Вот только непонятно, почему сверхбыстрое ассоциируется с LFSR. Самый тормоз во всей схеме updown счётчик для контроля состояния фифо, разрядность у него такая же, как и у адреса, так зачем же LFSR да ещё же с ущербом с одно слово? Логикорное фифо похоже на lfsr, а скорость там так себе. Ещё понимаю LFSR на внешних шинах для уменьшения SSO, но внутри?

этот счетчик выкидывается и фифо делается без него.

через сравнение адресов? Так ведь lfsr это не грей, между клоковыми доменами его так просто не перетащишь. Поделитесь кодом!

да через сравнение. А по поводу асинхронного фифо, если мне память не изменяет оно там синхронное было.

Увы, потер
В принципе ее просто получить - заходите в C:\Xilinx\coregen\ip\xilinx\primary\com\xilinx\ip\fifo_generator_v3_2 и декодируете все исходники, которые там есть (в поддиректориях тоже)
Потом идете в iputils, blkmemdp_v6_2 и blk_mem_gen_v2_2 и декодируете все оттуда тоже. Полученная свалка, плюс генерируемые GUI файл конфигурации (с define'ами) и есть корка
Декодировал я это прогой xldecomp.exe (из закромов, кажется)