Кто сталивался с такой траблой........

Имеется PCI target(собственный, построен на Спартане2)...
Смысл заключается в следующием........Внутри кристала организовываю 3 регистра(для тестирования) которые тактируются по CLK. В первый регистр данные пишутся при записи по 2 адресу, и читаются(путем открывания буферов) тоже по 2 адресу... все ок, что записал то и прочитал,.......... но если в такой же регистр записать по предположим 3 адресу, а прочитать по 4 ( адрес не имеет значение главное что бы адрес записи и чтения были разные) то читается по 4 не то что было записанно по 3, а 00. Но если между командами записи в 3 и чтением 4 вставить команду записи в 4 FF то все проходит нормально(прочитаю в 4-ом то что записал в 3-й)..... или пример чтения константы предположим по 6 адресу........ константа прочитается в том случае если перед чтением регистра будет стоять команда записи в этот регистр значения FF........

Читал и спеку и книгу ничего подобного не нашел.....(прошу не путать с чтением BARов, там читается, как раз так)... но почему это происходит Вводом-выводом? непонятно...(((

Если потребуется могу выложить принт скрины регистров.....

Какой размерности регистры? Байтовые?

Да......
Пишу, читаю, байт

Почитайте внимательно раздел 3.2.2. Addressing спецификации (особенно обратите внимание на использование бит AD(1:0) в операциях с портами ввода/вывода). Может, что и прояснится. Все ли трехстабильные буферы активны при чтении (независимо от BE)?
Моделировать пробовали? В железо имеет смысл соваться только после успешных результатов временнОго моделирования.

Читал......Байт на шине ориентирую исходя из адреса (00:01:10:11) в этом вроде проблем не возникало........
Моделить пробовал (не гуру... но вроде все так...)

Только что провел тест... (что то вроде инициализации портов) перед всеми записями и чтениями записал по нужным адресам FF, все пашет ок...... потом хоть 10 раз пиши, читай все ок.....
Смущает то что не понятно что это такое(((

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

Управляющая программа работает под DOS или под чем-то еще?

Под МСВСом ...
И при загрузки углядел интересненькую строчку....: I/O 4096 (0xFFFFFFFF)

Сочувствую. Однако у меня под этой же самой системой при работе с PCI в части пространства ввода/вывода из-под пользовательского приложения (iopl + inw и т.п.) и из-под драйвера (модуля ядра) никаких проблем не наблюдалось. Работал со множеством разных устройств.



Лето, телепаты в отпусках. Остались простые люди. Вы бы посвятили нас - где именно Вы такое увидели? И что говорит 'cat /proc/pci'?

Нда... туго без телепатов...
Строка появляется после того как происходит выбор операционки и начинается загрузка ядра и в этих именно строчках и появляется...
По 'cat /proc/pci' скажу в понедельник... Хочу попробовать на другой машине и с нормальной линухой...попоробую на федоре..

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



А еще лучше и результаты dmesg приведите. После этого, если Вы дадите пример Вашей программы, можно будет уже сказать что-нибудь более определенное.

/dmseg
...
blk: queue c0358740, I/O limit 4095Mb (mask 0xFFFFFFFF)
...

/proc/pci

Bus 0, dev 1, func. 0:
Miltimedia controller: Moxa tehnologies Co Ltd Smartio c16 H/PCI
irq 9
Master, Latensy=80
I/O at 0xd87f
Non prefetchable 32 bit memory at (0xe70010ff)
I/O at 0xDC1f

МСВС 3.0

программа выполнена в виде модуля в котором и организованно обращение к регистрам...
outb...
inb..
printk
3 оператора, ничего другого нет....

О чем я и говорил: эти строки к Вашему устройству ни коим образом не относятся (это соощения подсистемы блочного ввода/вывода).



Вы цитируете вывод этой программы или по памяти его перепечатываете?
На подозрения наводит "Latensy" и базовые адреса пространства ввода/вывода, у которых младший байт не равен 00.



Вот бы еще увидеть, что именно Вы в ней делаете (код) и каким образом получаете адреса и обращаетесь по ним...

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

Базовые адр. конечно с 00(d800 и dc00 соотв.(просто переписывал))
Программа отлажена на PLX9050
Программа не моя... пишет программист-начальник... она отлажена, как уже писал на plx9050

printk("\n ------------PCI present-----------\n");
// ПРТЕДЕМСЕН ОБМЙЮЙЕ БДБРТЕТБ бул32
ret_val=pcibios_find_device(0x1393,0x1680,0,&busnum,&devnum);
if(ret_val == PCIBIOS_SUCCESSFUL)
printk("\nret=%d busnum=%d devnum=%d",ret_val,busnum,devnum);
else {
printk("\n ADAPTER NOT FOUND ...ended... \n");
return 1;
}
//ЮЙФБЕН ЛПЖЙЗХТБГЙА БДБРФЕТБ бул
//Vendor_id Device_id
pcibios_read_config_dword(busnum,devnum,0,&val1);
printk("\n Device_id & Vendor_id =%x",val1);

//---------------------------------------------------------------------------------------------
//ВБЪПЧЩК БДТЕУ 0
pcibios_read_config_dword(busnum,devnum,PCI_BASE_ADDRESS_0,&val1);
printk("\n Bas.Adr.0 =%x",val1);
if((val1 & 0x1) == 0x1) {
//ЬФП РПТФЩ МПЛБМШОЩЕ
reg00=val1-1;
}

//ВБЪПЧЩК БДТЕУ 1


/*обращение к портам*/

//outb(0xff,reg0+4);
//outb(0xff,reg0+2);

temp1=inb(reg0+4); /* константа которая должна чиаться по 4 адресу(читаю ... */
printk("\nREG4==%X\n",temp1); /* путем открывания буферов) прочитается она если только */
/* по 4 адр. прописать предварительно FF

outb(0x55,reg0+4); /* в порт и.о. по 4 адресу пишем 55 и через передатчик по кольцу заводим на*/ temp1=inb(reg0+2); /* приемники и читаем по 2 адресу... все прочитается, если перед записью в */
printk("\nREG2==%X\n",temp1); /* 4 поставить запись во 2 регистр этих самых FF

//outb(0xff,reg0+4); /* */
temp1=inb(reg0+4); /* так же прочитается константа если раскоментровать строку выше*/
printk("\nREG4==%X\n",temp1);


return 1;

На первый взгляд все в порядке. Но на мысли наводит то, что Вы используете PLX9050, который может быть настроен совершенно по-разному. Например, у него может быть включен Prefetch для используемого Вами региона, который некорректно обрабатывается на локальной шине PLX. Запись может приводить к тому, что буфер Prefetch'a для чтения сбрасывается и мост еще раз производит чтение - на этот раз уже правильно.

Каковы настройки моста и его локальной шины? Думаю, что копать нужно в этом направлении.

Немного не понял.....(((
Про ПЛХ9050, я имею ввиду что он работает нормально.......
Данная проблема(с записями FF) проявляется на Target(e) собственной разработки (Spartan2)

Пардон, я уже переключился на него.
Вернемся к одному из исходных вопросов - Вы свой Target моделировали?

Бывает.......

Да...
Начиная от конфигурирования, заканчивая обращением к портам I/O, результаты моделирования вроде нормальные(не гуру... но все же)

Если результаты моделирования нормальные - следующий этап - посмотреть, что творится на шине. Для этого можно воспользоваться замечательным средством под названием ChipScope Pro, с помощью которого можно захватить сигналы на шине в нужный момент и посмотреть, что выдается на шину.

Спасибо....... сейчас попробую...