Как загрузить ПЛИС с микроконтроллера ? Опции

[Dimetor Kilov]

Добрые люди подскажите начинающему где найти исходники под микроконтроллер(лучше какой нибудь Атмега128), для загрузки с него плис и документирование описание сего процесса.

[Skorp]

Выше рассматривался Spartan II. А как обстоят дела со Spartan3? Есть ли характерные отличия?

На данный момент пытаюсь загрузить XC3S400 посредством Atmega128 в режиме SlaveSerial.
Пока что не удалось получить 1 на DONE по окончании загрузки.

В связи с чем вопрос:
1. На сколько я понял в исходниках к xapp502 для заданного режима биты передаются начиная с LSB,
тогда как выше говорилось, что требуется "Задвигать данные со старшего бита байта" - как все таки правильно?
2. Требуются ли дополнительные тактовые импульсы по окончании загрузки и где про это почитать?
3. Судя по рисунку 6 из даташита(ds099.pdf) после INT_B -> 1 данные должны начинать поступать со второго фронта сигнала CCLK - я правильно понимаю?

[Boris_TS]

1. На сколько я понял в исходниках к xapp502 для заданного режима биты передаются начиная с LSB,
тогда как выше говорилось, что требуется "Задвигать данные со старшего бита байта" - как все таки правильно?

Для Spartan-II в режиме SerialSlave биты действительно надо задвигать начиная со старшего бита байта. Со Spartan-3 еще не успел поиметь дел, поэтому ничего точно сказать не могу.

3. Судя по рисунку 6 из даташита(ds099.pdf) после INT_B -> 1 данные должны начинать поступать со второго фронта сигнала CCLK - я правильно понимаю?

Возможно имелся ввиду "Figure 4: Waveforms for Master and Slave Serial Configuration" (под официальным номером DS099-3_05_041103 - лучше указывать этот номер, в нем все сказанно: что, откуда и какой версии).

У Xilinx был принят мелкий стандартик: начинать прошивку (файл *.bin) с кода 0xFFFFFFFF - это команда простоя для ПЛИС. Очень выжно, чтобы до окончания стирания ОЗУ в ПЛИС (пока еще INIT = 0), на DIN появилась устойчивая единица, тогда даже при наличии лишних CCLK в ПЛИС будут записывать комманда простоя, непосредственно загрузка ПЛИС начинается с того момента, как в последовательном потоке будет обнаружена подходящая комманда (отличная от 0xFFFFFFFF). В Spartan-II не требовалось никаких лишних CCLK, т.е. с первого же положительного фронта фиксировался бит данных. В пасивном состоянии CCLK необходимо было держать в '1'. Я думаю, что и в Spartan-3 Xilinx не отошел от прошлых нароботок, ибо это никак не отражено в документации.

И еще, почему-то для Spartan-3 Xilinx советует держать ноги CS_B и WRITE_B в '1' - может в этом дело в вашем случае?

От подтяжки Done можно и отказаться, но надо тогда поставить флажок Drive_Done_HIGH, так и стабильней, и резистор не нужен.

[makc]

1. На сколько я понял в исходниках к xapp502 для заданного режима биты передаются начиная с LSB,
тогда как выше говорилось, что требуется "Задвигать данные со старшего бита байта" - как все таки правильно?

Для Spartan-II в режиме SerialSlave биты действительно надо задвигать начиная со старшего бита байта. Со Spartan-3 еще не успел поиметь дел, поэтому ничего точно сказать не могу.

Чтобы не быть голословным, приведу ссылку на _http://direct.xilinx.com/bvdocs/appnotes/xapp176.pdf
Цитаты из него же:
(1)

In serial configuration mode, the FPGA is configured by loading one bit per CCLK cycle. In
Master Serial mode, the FPGA drives the CCLK pin. In Slave Serial mode the FPGAs CCLK pin
is driven by an external source. In both serial configuation modes, the MSB of each data byte
is always written to the DIN pin first.

(2)

The standard bitstream, currently generated by BitGen, follows the format shown in Table 8, Table 9, and Table 10. This format assumes D0 is considered the MSB. It has been broken into three tables to follow the three command sets described in the previous subsection.

Объединяя (1) и (2) можно очень легко придти к выводу, что задвигать нужно начиная с LSB в x86 архитектуре. Да и многих других.

И, на сколько мне известно, порядок загрузки в Spartan-3 не поменялся.

[Boris_TS]

The standard bitstream, currently generated by BitGen, follows the format shown in Table 8, Table 9, and Table 10. This format assumes D0 is considered the MSB. It has been broken into three tables to follow the three command sets described in the previous subsection.

Если не ошибаюсь, то 'currently' было в декабре 1999. Могло и поменяться, не даром Xilinx поставила это слово.

Объединяя (1) и (2) можно очень легко придти к выводу, что задвигать нужно начиная с LSB в x86 архитектуре. Да и многих других.

Нехорошо перечить админу, посему высылаю файл прошивки для Spartan-2E и программу, написанную для загрузки оной через CPLD стоящую на ISA (*.bin - сгенерирован на ISE 7.1, *.cpp слеплен на BC 3.1). Естествено все это работало, и даже неплохо.
По синхронизационным кодам в *.bin файле можно точно сказать, где лег MSB, а *.cpp запихивает MSB(в смысле x86) в ПЛИС первым. Если чего не так, поправьте меня.

Сообщение отредактировал Boris_TS - Jan 30 2007, 10:18

Прикрепленные файлы

 TEST.RAR ( 12.89 килобайт ) Кол-во скачиваний: 44

 

[makc]

The standard bitstream, currently generated by BitGen, follows the format shown in Table 8, Table 9, and Table 10. This format assumes D0 is considered the MSB. It has been broken into three tables to follow the three command sets described in the previous subsection.

Если не ошибаюсь, то 'currently' было в декабре 1999. Могло и поменяться, не даром Xilinx поставила это слово.

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

Объединяя (1) и (2) можно очень легко придти к выводу, что задвигать нужно начиная с LSB в x86 архитектуре. Да и многих других.

Нехорошо перечить админу, посему высылаю файл прошивки для Spartan-2E и программу, написанную для загрузки оной через CPLD стоящую на ISA (*.bin - сгенерирован на ISE 7.1, *.cpp слеплен на BC 3.1). Естествено все это работало, и даже неплохо.

Внимательное чтение _http://direct.xilinx.com/bvdocs/appnotes/xapp502.pdf может пролить свет на эту проблему. В особенности раздел "Data Formatting and Byte-Swapping". Приведу ряд цитат:

Since the configuration bitstream will be loaded into some memory connected to the processor,
most likely it will have to be formatted in a way that the processor (or whatever device programs
the memory) can use. There are a number of different formats that the Xilinx tools can produce.

Generally, either the .bin or .hex files are the most useful data source for programming
non-volatile memory. Some additional formatting may be required, and the Perl script included
with this application note (bitformat.pl) can provide some assistance. This Perl script uses the
.bit or .rbt file as a source and produces a user-customizable ASCII file that can be helpful in
programming the on-board memory. Xilinx implementation software must be installed on the
machine running this Perl script because the PROMGen program is called from within the script
(For details, see the bitformat.readme file that is included).

In terms of data ordering, Slave Serial configuration is very simple. Start with the first bit in the
bitstream and load one bit at a time until the end of the file is reached.

Data ordering for SelectMAP configuration is slightly more complex. Configuration data is
loaded one byte on each CCLK, and the MSB of each byte is presented on the D0 pin, not the
D7 pin. Because of this non-conventional ordering, presenting the data “as is” from the .bin file
is generally incorrect. The reason is that most processors interpret D7 (not D0) as the most
significant bit in each byte. Connecting D7 on the processor to the D7 on the FPGA SelectMAP
data bus effectively loads the data “backwards.” Thus, the configuration will not be successful.
For this reason, the source data stream may need to be “byte-swapped.” This means that bits
in each byte in the data stream are reversed. Figure 3 shows two bytes (0xABCD) being
reversed.

Notice that the MSB of each byte of the data needs to go to D0 regardless of the orientation of
the data. However, in the byte-swapped version of the data, the bit that needs to go to D0 is the
rightmost bit and, in the non-byte-swapped data, the D0 bit is the leftmost bit. The Perl script
included in this application note can be customized to produce byte-swapped files or not, as
needed (see the bitformat.readme file for details). In the Xilinx software, the .mcs, .exo, and
.tek files are always byte-swapped, and the .bit, .rbt, and .bin files are never byte-swapped.
Hex files may be produced byte-swapped or not according to command-line options.

Поскольку у меня в проекте использовались .mcs и .hex файлы прошивок, то биты были переставлены и загрузка шла с младших битов каждого байта. В Вашем же примере используется .bit файл с нереверсированным порядком битов. Поэтому загрузка у Вас - со старших. Так что мы оба правы, каждый по-своему.

По синхронизационным кодам в *.bin файле можно точно сказать, где лег MSB, а *.cpp запихивает MSB(в смысле x86) в ПЛИС первым. Если чего не так, поправьте меня.

Да. Все правильно. Просто были не до конца определены исходные данные (формат файла).