PENDER ELECTRONIC DESIGN GmbH

FAQ

FAQ / Frequently Asked Questions

Is there an FPU (Floating Point Unit)?...
Power supply quality...
What about the availability of the FT model?
Writing to the prom / WP
PROM width definition and PIO settings....
Using different clock rates
The board continually resets....
Why does the 'Errorn' LED light up upon power up?
Is it possible to 'switch off' the SRAM and use only the SDRAM?
Can I use more than 2 UARTs?
I get I/O card parity interrupt F000:C591 error?
How can I test the Ethernet interface?
Help! Something has gone wrong with programming the Xilinx Proms
Programs generated with Mkprom don't execute properly
How can I stop an application cleanly within DSUMON?
How can I use DDD for debugging with DSUMON?
Spartan-3 Configuration - JTAG configuration completes successfully, but the device is not fully operational or a verify fails
Why doesn't Flash Prom programming work with GRMON?
Programming an 'empty' GR-XC6S doesn't work

Is there an FPU available....

Aeroflex Gaisler has recently announced a floating point unit specially designed for the Leon processor: . Both GRFPC and GRFPU are immediately available. The cores are released and have production quality. The VHDL model can be synthesised with synplify (fpga) and synopsys (asic).

For evaluation purposes a free download of a virtex-2 netlist of the combined cores, which can be integrated with the recently released leon2-1.0.20-xst is provided. Also provided is a free fpga bitfile for the low-cost GR-PCI-XC2V development board, leon_eth_pci_grfpu.bit.zip , allowing users to use and evaluate the new FPU core. The GR-PCI-XC2V board can also be shipped with the GRFPC/GRFPU bitfile pre-loaded into the fpga configuration proms.

To make sure that the core is IEEE-754 compliant, testing has been performed using sotware suites including Testfloat, UCBTEST and IeeeCC754. Addtionally, several real applications have been tested, including the AOCS software for the Space Station control computers (DMS-R).

For further details and licensing, contact Aeroflex Gaisler

Power supply quality....

Q. The board starts up ok, but when a program is executed it fails/the board resets itself...

A. It could be that your power supply does not have a sufficient current rating...

Typically the board takes about 0.5A at idle, but during operation this can rise to ca. 0.9A when the memory is being exercised. If the power supply is not sufficently well regulated, then this can cause the Reset IC (U8) to generate a reset pulse if the voltage drops momentarily below 4.65V.

You may be tempted to use a 5V 'wall socket' type power supply. However, the regulation of these devices is generaly not so good at high currents. Using a Bench lab supply with sufficient current rating will probably provide much better regulation.

What about the FT model and its licensing?

The 'FT' verson of the GR-PCI-XC2V board incorporates the additional memory chips and data path necessary to implement EDAC memory check bits on the SRAM and SDRAM memories. This makes it suitable to implement the LEON-FT model on the board. However, Pender/Gaisler are not able to provide the LEON-FT version of the Leon VHDL model. For information concerning this model, its availability and licensing, it is necessary to contact the European Space Agency.

Note that the FT version of the board can be used for both FT and standard (non-FT) designs.

Writing to the PROM....

The DSUMON program includes commands in order to read/write the Proms on the GR-PCI-XC2V board. However, for the program to be successfully writen to the prom, remember it is necessary that the prom is first 'enabled' (command = flash enable) and that the appropriate data blocks of the prom are unlocked (command = flash unlock all). The 'load' command will then write the program to the flash prom memory locations (assuming of course that the program has been linked to the ROM memory area).

PROM width definition and PIO settings....

The MEMCFG1 register should read 0x00000233 to indicate that the board has 32 bit wide Prom. Instead it reads 0x00000033. Why?....

The Leon processor reads the PIO pins PIO0 and PIO1 at power up in order to determine the PROM width. To use the 32 bit wide flash prom memory it is necessary to set the PIO switches on S1 as follows:

S1-0 ON = '0'
S1-1 OFF = '1'

Remember also that, if you are using the Serial Expansion board connected to J4, then it is necessary to set the correct PIO setting also on the DIP switch S1 on the expansion board.

Using different clock rates....

The GR-PCI-XC2V board is fitted with a 40MHz oscillator as standard.

To run the board at a different clock frequency there are several options:

The 40 MHz oscillator on the GR-PCI board is socketed. You can exchange the oscillator, but the replacement must also be a type which is designed for 3.3V power supply.
The 33MHz clock of the PCI interface can be used instead of the 40MHz oscillator if the VHDL model option clock generation / use PCI clock as system clock is selected when configuring the Leon model.
Other frequencies can be also be defined by using the frequenecy sythesis features of the Virtex-II digital clock manager (DCM) This can be selected when setting up the Leon model in the option: clock generation / use Virtex-II DCM for clock generation.

The board continually resets....

If the WATCHDOG option has been enable in the VHDL model then the watchdog signal will cause a reset of the board each time it times-out.

To prevent the watchdog signal from triggering a reset of the board make sure DIP switch 7 on S1 is in the off position.

To enable the watch dog function, set the DIP switch S1-7 to the off position. To usefully use the watchdog, it is necessary to correctly set up the Timer registers, and write a suitable timer handling routines (see section 6.4 of the Leon-2 Manual).

Why does the 'Errorn' LED light up upon power up?

The ERRORN LED lights up if the processor goes into error mode and asserts its ERRORN pin. At power up or reset, (if the DSUBREAK button is not pressed), the processor will start its normal execution sequence and start reading the data from the PROM. If the PROM is empty, then an invalid instruction will be executed with the result that the processor halts in error mode.

Is it possible to 'switch off' the SRAM and use only the SDRAM?

This is controlled by the SI (SRAM disable) and SE (SDRAM enable) bits the MEMCFGREG2 register (see Leon-2 manual). Normally the SRAM begins at memory location 0x40000000 and SDRAM at 0x60000000. However, if the SRAM is disabled, SDRAM will be mapped to start from location 0x40000000.

When generating a Prom image to be executed from Prom at boot-up, it is necessary to specify some additional parameters when executing Mkprom. The initialisation code generated by Mkprom will then set the Leon memory configuration registers appropriately.

Use something like the following:

mkprom -freq 40 -baud 38400 -nosram -sdram 16 -col 8 hello.exe -o hello.prom

As described in the mkprom manual:

-nosram: this forces the MEMCFGREG2 to disable the SRAM and enable the SDRAM.
-sdram 16: this sets the RAM memory size to 16 Meg
-col 8: defines the number of column address lines (for 16Meg this is 8 and for 64 Meg this is 9. This value is reported by the DSUMON during the initialisation)

The values for the trc, refresh etc can also be defined, but the default are most likely to be fine (see the Mkprom manual)

Note: Make sure that you are using the mkprom 1.3.8 (or later) which is distributed with leccs-linux-1.1.5.3.tar.gz / leccs-cygwin-1.1.5.3.tar.gz.

Can I use more than 2 UARTs?

Yes. We have developed a Mezzanine card which provides 4 UART interfaces for serial communications.

Some modifications to the VHDL code are required to add and appropriately connect two additional UART entities to the Leon model. The necessary changes are explained in the user manual of the 4uart mezzanine board. These VHDL changes and example bit files for the GR-PCI-XC2V board can be downloaded.

I get I/O card parity interrupt F000:C591 error?

Users have reported that when using the GR-Target PCI interface and plugging the GR-PCI-XC2V card into the PC results in the following message at boot up of the PC:

I/O card parity interrupt F000:C591 Shut off NMI, Reboot, other keys

This error has been seen with some Dell PC's and is related to the way which the PCI core generates the PCI bus parity, depending also on whether the PCI Parity is enabled in the BIOS. A modification has been made to the GR-Target PCI interface (pci_gr.vhd) in leon2-1.0.21-xst to fix this problem.

How can I test the Ethernet interface?

Try the following:

connect the GR-PCI-XC2V board to your Ethernet port on your Linux machine with a cross cable.
If your machine uses DCHP to get an ethernet address you probably have to disable this and force it to use a fixed IP address. You can do this by editing your /etc/rc/d/rc.inet1 file and comment out the line 12: USE_DHCP=yes In this example 192.168.1.15 is used as the fixed address for the Linux machine.
Reboot your machine (alternatively it might be ok to just restart the network daemon).
When rebooted, in one terminal session, start minicom in order to see the output of the GR-PCI-XC2V board on Uart.
In second terminal session, start dsumon, load the rtems-ttcp program and run it:

> dsumon -i -nosram dsu > load rtems-ttcp dsu > run
The GR-PCI-XC2V board starts and automatically goes into ttcp receive mode.
In third terminal session, run the ttcp program:

> ttcp 192.168.1.66 -s -t bigfile
This sends a file (in this example 'bigfile') to your GR-PCI-XC2V board. After a pause of about half a minute you should get the output on the minicom terminal.

Some notes:

The rtems-ttcp program, which needs to be run on the GR-PCI-XC2V board should already be somewhere in your rtems installation, in a directory called 'samples'. You will probably have to 'make' them first.

In the file 'networkconfig.h' the IP address of the GR-PCI-XC2V board has been pre-defined as 192.168.1.66, but you could edit this if you re-make the rtems-ttcp program.

When you start DSUMON you must use the option '-nosram' in order to force the leon to use only the SDRAM on the board, starting at 0x40000000. The SRAM is not large enough to hold the complete ttcp program.

The network driver written by Jiri automatically checks the clock frequency of the board. If the board is running at 50MHz or higher it will try to put the ethernet interface into 100Mbit/s mode. Otherwise it will use 10Mbit/s mode. This is because for the fifos in the ethernet core to work properly the Leon must be operating at twice (or more) than the ethernet clock frequency of 25MHz.

Something has gone wrong with programming the Xilinx Proms

Symptom: After (failed) programming of the Xilinx configuration Proms, the board takes significant excess current (hopefully your power supply is current limited to a resaonable level), and the configuration doesn't work.

This can happen if the Programming fails (e.g. power interruption during programming, or a bad cable connection), or if the wrong .mcs file has been asssigned to the wrong prom when using the Impact programming utility. At power up of the board the Xilinx FPGA will load its configuration out of the proms, but will receive a corrupted configuration. This can set the Xilinx into an undefined or conflicting configuration. This leads to signal contentions and excess currents being drawn. It is then not possible to reprogram the Xilinx Proms because the board is in an over-current state.

To solve the problem, remove jumper JP16 and power up the board. Removing JP16 prevents the Xilinx FPGA from loading its configuration from the Xilinx Proms. Now program the Xilinx proms as normal. Restore JP16, and power up the board again, and all should be ok

Programs generated with Mkprom don't execute properly

Make sure that the Mkprom options have been set correctly, and that they reflect accurately your hardware. (See the Mkprom manual). In particular make sure that the ramsize (-ramsize option) is correct to ensure the stack pointer will be at the correct location, and use the -rmw option to ensure that the memory controller will perform read-modify-write cycles (unless of course your hardware has been designed specifically to allow 'byte-writes' with separate strobes for each byte of the data words).

How can I stop an application cleanly within DSUMON?

To stop the application from dsumon, just press ctrl-c which will put the processor back into debug mode. Alternatively the DSU Break push button on the board can be pressed to achieve the same effect.

If you want to exit dsumon and continue the application, do a 'detach'. Otherwise, just do 'quit' to exit and keep the cpu halted.

How can I use DDD for debugging with DSUMON?

Try something like this:

Open two terminal sessions
In first terminal session, start DSUMON or GRMON. At the prompt type 'gdb'. You get:
> gdb interface: using port 1235
or with grmon, it is port 2222 instead of 1235.
In second terminal type:
> ddd --debugger sparc-rtems-gdb --attach-window
and ddd should start up, and be defined to use the sparc-rtems-gdb as its debugger.
You can optionally add the name of the executable file and this will be automatically opened. If the source file (.c) is present in the directory, and you have compiled your executable with the -g option (include debugging symbols) the source code will also be loaded, and you can do symbolic debugging using the source code, set breakpoints in source code etc.
Now you have to connect the ddd to the instance of the dsumon which is communicating with the hardware. At the ddd prompt type:
(gdb)> target extended-remote localhost:1235
and you should get a message like
(gdb)> Remote debugging using localhost:1235
In the first terminal window dsumon will indicate 'connected'
Now you must load your program on to the leon hardware. At the ddd prompt type
(gdb)> load
You see a message "loading section....text" etc.....
In the source code assign your breakpoints. With your mouse cursor in the furthest left column of the source code line where you wish a breakpoint, right click and select Add Breakpoint. Now type run: gdb) run and the code should start, and then stop at your breakpoint.

Under some circumstances the ddd and gdb might disconnect from each other, but you reconnect them by retyping the 'target extended....etc' command

Also each time you re-run the program from the start you must perform the 'load' again.

Also, under the menu 'Commands/Define Commands' you can assign buttons to user defined commands so that the 'Connect' and 'Load' etc. can be more easily performed by pressing the buttons instead of typing the command at the prompt.

Spartan-3 Configuration - JTAG configuration completes successfully, but the device is not fully operational or a verify fails

"When operating on a Spartan-3/-3E via JTAG, programming succeeds, but my design fails to work. If a 'Verify' is performed, this will fail as well. This occurs when the PROM is programmed with a different image than what is being loaded in the FPGA, and the FPGA is in master mode".

The 'normal' mode of operation of the board is 'Master Serial Mode' whereby the FPGA configuration is automatically read out of the the FPGA configuration proms at power up of the board. This mode corresponds to header JP9 not having any jumpers installed (=> M0='0', M1='0', M2='0')

The Xilinx Datasheets and documentation indicate that which ever 'mode' the FPGA mode pins are set to the JTAG programming interface should be able to 'override' this, and reprogram the FGPA.

However this is not the case as explained in the Xilinx Answer Record: 22255:

"The problem is that iMPACT will cause the mode pins to be sampled. If the device is in master mode, the CCLK will be produced and the PROM will begin to load the device with data. This occurs before iMPACT issues the instruction to begin configuration. When this occurs, the JTAG logic gains control over the configuration logic and loads the device with the bit stream. The fabric of the Spartan-3/-3E needs to be initialized before it can be written over, so frames that have been written to by the PROM will not configure correctly. The CRC check will pass as this occurs while data is passed into the device. The device will get through the start-up sequence, DONE will go High, and the device will become operational. The problem is that the first few frames of the device have been corrupted and the design might not work successfully, and a verify with iMPACT will fail. To fix this problem, change the mode pins to BSCAN mode or out of Master Mode."

On the GR-XC3S-1500 board, the solution is therefore to explicitly set the JTAG programming mode (M0='1', M1='0' and M2='1') by installing the Jumpers JP9 1-2 and 5-6 (see section 3.3 of the User Manual).

Why doesn't Flash Prom programming work with GRMON?

Flash programming does work with GRMON, but you must use the command: flash load program.prom whereas the older DSUMON used the command: load program.prom

Therefore to erase and write a new program to the prom use the following sequence:

flash enable flash unlock all flash load new_program.prom

Programming an 'empty' GR-XC6S doesn't work

When both the board's FPGA and SPI PROM are blank, it is sometimes not possible to directly program the SPI PROM even though the generation of the SPI PROM .mcs file was successful. In principle this should be possible and appears to be a Xilinx/Impact bug, related to "Known Issues for the iMPACT 14.x tools (http://www.xilinx.com/support/answers/47890.html)". This issue and similar issues were supposed to be fixed from impact 14.2, however, it has been reported that this still happens.

As a work around, programming of the SPI Flash prom is successful, if any bit file is loaded in to the FPGA first using impact, before the SPI prom programming is attempted.