alex_k

to Link. Узнал у начальства - сказали не беспокоить, дело это не ближайшего будущего, надо текущую систему добить, так что извини за беспокойство...

To Link, my english is very bad that is why very sorry. May be you russian undersand better. I try. Я так понял что вы разработали собственное ядро pci express для virtex2pro. У нашей конторы есть довольно давний и как я понимаю (я не руководитель) давольно серьезный интерес к такого рода весчи. В связи с чем вопрос если руководству стало бы моя инфа (относительно вас) интересна, можно ли с вами связаться на вопрос о покупке ... (сколько стоит фирменное я ориентировочно знаю и эта цена по понятным причинам совершенно не приемлема пока еще так не разбагатели). Сейчас разрабатываем спецсистемы в формате compact pci, но хотим освоить compact pci express. На конструктив (разъемы и т.д.) уже закуплена соответствующая спецификация. Нет ядра. Если вам это интересно отзовитесь (возможно мое руководство заитерисует и какая нибудь другие формы сотрудничества, пока излагаю только свои мысли точку зрения руководства не знаю, но знаю одно о pci express разговоры идут и довольно часто. Сейчас делаем систему compact pci так на ней уже заложены для других нужд разъемы compact pci express. Извиняюсь что так много написал, перерыв себе устроил...

to tegumay действительно интересная инфа, я по сайту ксалинкса шарился шарился так ничего подобного и не нашел, обязательно попробую. Собственно в этом и была задача, описать данную конструкцию без всяких дополнительных телодвижений (RPM макросы, RLOC в ucf).

Может я конечно что-то не понял, но Floorplaner производит размещение определенной entity архитектуры в прямоугольной области, определяя размер необходимый для размещения, и далее я устанавливаю эту часть в заданную область клистала, т.е. делается RLOC_ORIGIN размещение с заданными координатами и от трансляции к трансляции без нового переразмещения не меняется. Таким образом floorplaner может и даст объединить брамку и умножитель но он привяжет их к определенному месту (хотя этого делать не надо было), тогда уже лучше RLOC/U_SET для умножителя и брамки.

Попробую потранслировать в ISE 7 может там подхватит, а суть проблемы такова, что если еспользуется схема с умножителями и брамками, получается следующая питрушка. Когда прасе-роут размещает схему, он в схеме брамка+умножитель может поставить какую либо брамку и какой либо умножитель из тех которые он посчитал будет удобней использовать (лишь бы выполнялись констрейны) и соединить их. По архитектуре плис (в частности Virtex2 Pro) брамка и умножитель стоят рядом специально для построения быстрых схем (аля фильтр). При таком несовсем корректном размещении получается что свободную брамку стоящую рядом с занятым умножителем уже нельзя корректно использовать (опять же ругается пласе-роут). Вообщем ресурсы едятся двойными темпами (имеется ввиду брамки).

Даже вот такой код - ниже описывать уже некуда, и тот пласе-роут надежно (ни раз на раз, а чтоб от трансляции к трансляции) размещать рядом нихотит. Таблетка XC2VP20, ISE 6.2.03i, опции по умолчанию, какие-то вроде пробовал менять, но без LOC/RLOC в ucf так ничего и не получилось. entity bram_mult is Port ( ADDRCOEFF : in std_logic_vector(9 downto 0); A : in std_logic_vector(17 downto 0); CLK : in std_logic; RST : in std_logic; P : out std_logic_vector(35 downto 0)); end bram_mult; architecture RTL of bram_mult is component RAMB16_S18_S18 port (DIA : in STD_LOGIC_VECTOR (15 downto 0); DIB : in STD_LOGIC_VECTOR (15 downto 0); DIPA : in STD_LOGIC_VECTOR (1 downto 0); DIPB : in STD_LOGIC_VECTOR (1 downto 0); ENA : in STD_logic; ENB : in STD_logic; WEA : in STD_logic; WEB : in STD_logic; SSRA : in STD_logic; SSRB : in STD_logic; CLKA : in STD_logic; CLKB : in STD_logic; ADDRA : in STD_LOGIC_VECTOR (9 downto 0); ADDRB : in STD_LOGIC_VECTOR (9 downto 0); DOA : out STD_LOGIC_VECTOR (15 downto 0); DOB : out STD_LOGIC_VECTOR (15 downto 0); DOPA : out STD_LOGIC_VECTOR (1 downto 0); DOPB : out STD_LOGIC_VECTOR (1 downto 0) ); end component; component MULT18X18S port (P : out STD_LOGIC_VECTOR (35 downto 0); A : in STD_LOGIC_VECTOR (17 downto 0); B : in STD_LOGIC_VECTOR (17 downto 0); C : in STD_LOGIC; CE : in STD_LOGIC; R : in STD_LOGIC ); end component; signal MULT_B_IN_i : std_logic_vector(17 downto 0); begin coeff_bram_inst : RAMB16_S18_S18 port map( DIA => (others => '0'), DIB => (others => '0'), DIPA => "00", DIPB => "00", ENA => '1', ENB => '1', WEA => '0', WEB => '0', SSRA => RST, SSRB => RST, CLKA => CLK, CLKB => CLK, ADDRA => ADDRCOEFF, ADDRB => (others => '0'), DOA => MULT_B_IN_i(15 downto 0), DOB => open, DOPA => MULT_B_IN_i(17 downto 16), DOPB => open ); mult_inst : MULT18X18S port map( P => P, A => A, B => MULT_B_IN_i, C => CLK, CE => '1', R => RST ); end RTL;

Возникла следующая фича при проектировании в ISE. Сделал я такой модуль - есть умножитель (A,B 18-и битные входы, P 35-и битный выход) и есть BRAM (RAMB16_S18_S18). Необходимо выходные данные одного из портов брамки подцепить на вход умножителя. Раньше память коэффициентов была вообще 32-х битная и 32-х битный умножитель был собран из 4-х 18х18. Смысл проблемы в том что пласе-роут ни в какую не хочет использовать брамки расположенные рядом с умножителями. Сейчас у меня получился только один вариант RAMB16_S18_S18 + MULT18X18 и непосредственное задание физразмешения в ucf файле через LOC. Собственно вопрос можно ли так описать эту конструкцию чтобы пласе-роут сам нормально их разместил рядом без описания привязки в ucf.

Мы делали плату, на плис Xilinx Virtex + PCI ядро Target\Master на базе ядра Xilinx. Так вот, под нее я делал такой тест - инициируется передача буфера 1 МБ в память ПК (Bus Master), ожидается прерывание завершения передачи, все это дело повторяется заданное число раз (т.е. без обработки данных) и засекается время всего этого. Далее рассчитывается якобы пропускная способность шины.Все это дело работаль под виндой. Вобщем получалось не менее (на той машине) 112 МБ\сек, пиковая 120 МБ\сек. Но такой тест по сути разовая повторяющаяся пересылка - один раз быстрее другой раз медленее. Был у нас на базе этой же платы другой проект в котором необходимо было реализовать непрерывную передачу потока данных в компьютер естественно с обработкой. Были построены так называемые "качели" - один буфер передается в ПК, другой в это время обрабатывается. Вопрос стоял так что время затрачиваемое на обработку буфера естественно будет заведомо меньше времени передачи следующего буфера. В общем все это под виндой кончилось тем что и следовало ожидать. Видна для таких задач СОВСЕМ не подходит (покрайней мере без каких либо модификация). Простенькая тестовая программа отрисовывала конец двух переданных буферов, дабы показать на сигнале что между буферами нет разрыва. Данные были с АЦП. Если данную программу запустить и на компе ничего не трогать (даже не шевелить мышку) удавалось (то время что я на нее дуплил) достигнуть передачу 80 МБ\сек непрерывного потока. Но естественно это не работы. Вообщем у меня сложилось мнение что в связи со спецификой построения современных настольных ПК аля IBM PC, когда на PCI шине сидит до черта устройств, единственный вариант это использование каких либо спец операционных систем (QNX или оптимально собранный Linux или еще что-то) c полным управлением всеми устройствами на шине и возможностью выполнения обработки без переключения на другие задачи. Тогда наверно этом процессом можно будет управлять и добится непрерывного потока данных по PCI ну скажем приближающегося к пиковому или заведомо работающего необходимого меньшего.

Я моделировал в ModelSim контроллер генерируемый Xilinx MemoryGenerator (mig007_rel6) совместно с vhdl моделью DDR SDRAM 256Mbitx16 от Samsung - модель на работу контроллера реагирует без ошибок, а вот насчет физического размещения в таблетке мне пока просто приходится верить на сам MemoryGenerator, он типа делает физразмещение в выбраной плис с заданной привязкой контактов, вроде проходит синтез и пласе-роут, вроде все констрейны выполняются, но как только будет готово железо буду запускать. В любом случае, от генерит собственно исходник контроллера и на базе него наверняка можно будет собрать работающий и под необходимые функции.

У Xilinx на сайте есть куча xapp-ов с исходниками построения контроллеров, также есть какой-то MemoryGenerator - вообщем материала довольно много просто зайти на сайт www.xilinx.com раздел memory corner.

Посмотрел исходник контроллера DDR SDRAM от Xilinx, так у них сигналам CS и DM просто присваивается "0". Кто нить реально подключал CS или DM на землю (минуя подключение их ПЛИС), отзовитесь!!!. Подтвердите предположение, пожалуйста, что будет работать, а то плата уже в трассировке, а ощущение что можно потом попасть в большую ж-у приследует ежеминутно.

В даташитах на микроновскую и самсунговскую DDR SDRAM память приведены логические уровни нуля и единицы (декларируется что они соответствуют стандарту SSTL-II): MIN MAX Input High (Logic 1) Voltage Vref+0.15 Vdd+0.3 Input Low (Logic 0) Voltage -0.3 Vref-0.15 Вроде из этого следует, что неиспользуемые CS и DM можно подключить к земле, таблице приведенной в даташите это не противоречит. Есть ли какие нибудь по этому поводу идеи (замечания)?.

to gammanoid А какую фпга (ядро pci-e) собираетесь использовать если не секрет?

Если не предполагаеться использовать паралельно подключенные несколько микросхем и переключать их CS и нет надобности управлять маской при записи DM можно ли просто повесить данные сигналы на землю. Необходимость возникла в связи с катастрофической недостачей контактов на фпга.

В StarterKit к Spartan3 есть исходный текст проекта (его можно скачать с сайта Xilinx) для данной отладочной платы. В нем реализована система на базе MicroBlaze и к ней привинчен контроллер VGA. Данный контроллер текстового режима, т.е. содержит знаковый генератор и текстовый видеобуфер построенные на брамках. Его можно взять за основу и поковырять, в частности выбросить весь этот текстовый режим и расширить число бит на цвет до 8. Еще мощный графический контроллер видел на www.opencores.org. Он с шиной WISHBONE, очень навороченный и довольно здоровый. В приложенных файлах Reference Design SVGA контроллера от Xilinx. bm_mode_svga.pdf BM_MODE_SVGA.zip