[Kuzmi4 0]

Здравствуйте.

 

Столкнулся тут недавно с интересной баго-фичей в Modelsim SE 10.0c. Суть:

Открываю файло через $fopen с указанием "r" - то есть просто чтение, размер файла 307215 байт. Далее вычитываю из него байтики в DUT через $fgetc, видно что идут они по порядку - всё как надо, НО на 12770 байте узнаю что это был последний байт файла :1111493779: смотрел и ошибки и описания - по всем признакам видно, что Modelsim решил что файло реально кончилось :smile3046: .

Если открывать файло с указанием "rb" - всё прочитывается до конца.

В описании к $fopen я намёка на что то похожее не находил. Кто нибудь сталкивался с этим интересным поведением? Проектик приложил, нужно менять файл host_bfm.v, cтрока 84:

si_file = $fopen(p_FNAME, "r");

Проверьте пожалуйста у себя кто может. Так же интересно было бы проверить это на других симуляторах.

verilog_file_io.7z

[BSACPLD 14]

На 10.1b абсолютно то же самое.

[doublekey 0]

Похоже на известную багу с символом "Я", у которой код 0xFF в ASCII, и оно воспринимает этот символ как конец файла.

[arexol 0]

Под линуксом в моделсиме 10с вроде нет ошибок

 

и в нцсим тоже вроде всё идентично - нет ошибок

[Flood 13]

Разве 'r' не означает, что файл открывается как текстовый? А file00.pgm - совсем не текст.

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

Для двоичных данных есть 'rb', почему бы его не использовать?

[Kuzmi4 0]

2 Flood

по стандарту - означает, НО согласно тому же стандарту:

c = $fgetc( fd );

Read a byte from the file specified by fd.

Или байты в текстовых и бинарных файлах отличаются ?

[Flood 13]

2 Flood

по стандарту - означает, НО согласно тому же стандарту:

 

Или байты в текстовых и бинарных файлах отличаются ?

 

Да, в тексте сказано "Read a byte from the file specified by fd", но при этом глава стандарта называется "17.2.4.1 Reading a character at a time".

Опять-таки если апеллировать к стандарту, там есть пункт 17.2.1, и в нем:

"The "b" in the above types exists to distinguish binary files from text files. Many systems (such as Unix)

make no distinction between binary and text files, and on these systems the "b" is ignored. However, some

systems (such as machines running NT or Windows) perform data mappings on certain binary values written

to and read from files that are opened for text access."

 

Т.е. вернется байт, но перед этим он будет как-то проинтерпретирован системой.

Вот вам и ответ, почему под линуксом работает, а под Windows - нет. Т.к. тип файлового дескриптора полностью соответствует C-функции fopen, стоит ожидать, что в симуляторе происходит вызов именно этой функции. Далее обработка символов будет зависеть от системы.

 

Общее правило - никогда не обрабатывать бинарные данные как текстовые.

[ReAl 0]

"(such as machines running NT or Windows) perform data mappings on certain binary values written to and read from files that are opened for text access."

В частности, ^Z (26, 0x1A) является признаком конца текстового файла, в С-программах файл, открытый c "rt", получает -1 на fgetc() при считывании этого байта.

Ну и еще конец строки в Win в текстовых файлах пишется как \r\n (0x0D 0x0A), но при чтении в программу при "rt" байты '\r' 0x0D в таких местах подавляются, в С-программу передаётся только '\n' (0x0A). Так что читать двоичный файл как текстовый в Win крайне не рекомендуется :-)