Random Microblaze notes to self

A mix of issues not deserving a post of their own.

COM port issues (with Windows XP)

The SDK has its own terminal, which can be set to run with a serial port. It works fine.

As for Hyperterminal, by all means configure a connection with a specified Hyperterminal configuration file. Just setting the properties of the current connection holds the terminal in disconnected mode until some key is pressed on the keyboard, ignoring incoming data. This can make it look as if nothing is sent from the other end.

More important, when the card is turned on, the COM port will not appear if Hyperterminal is open. So Hyperterminal has to be closed and reopened every time the card is powered on.

The setting is basically 9600 baud, 8 bits, 1 stop bit, no parity and no flow control. Despite some official guides, it looks like it’s not necessary to go to the Device Manager, right-click CP210x USB to UART Bridge Controller and set up Properties of the interface on that level. Note that they revert to default every time the USB interfaces disappear and reappear. At least with Hyperterminal, there have been no problems with having wrong values in the Bridge’s own settings.

A simple led toggling application

XGpio GpioOutput;

#define LED_CHANNEL 1

int main()
{
 volatile int Delay;
 int Status;
 int count = 0;

 Xil_ICacheEnable();
 Xil_DCacheEnable();

 print("---Entering main---\n\r");

 Status = XGpio_Initialize(&GpioOutput, XPAR_LEDS_4BITS_DEVICE_ID);
 XGpio_SetDataDirection(&GpioOutput, LED_CHANNEL, 0x0);

 while (1) {
 count++;

 XGpio_DiscreteWrite(&GpioOutput, LED_CHANNEL, (count & 0xf));

 for (Delay = 0; Delay < 1000000; Delay++);
 }

 // Never reached

 Xil_DCacheDisable();
 Xil_ICacheDisable();

 return 0;
}

Making the processor with command line

Example set for the generation of a Microblaze processor:

platgen -p xc6slx45tfgg484-3 -lang verilog    -msg __xps/ise/xmsgprops.lst system.mhs

If the processor isn’t going to be at top level, go:

platgen -p xc6slx45tfgg484-3 -lang verilog   -toplevel no -ti system_i -msg __xps/ise/xmsgprops.lst system.mhs

or ngdbuild will complain about double IO buffers.

That creates an hdl directory with a toplevel system module, a system_stub.v for instantiation, and several other HDL files. Configuration files for synthesis are written into the “synthesis” directory. The actual cores are in NGC format. Almost all core HDL files are wrappers (in VHDL).

To synthesize, change directory to “synthesis”

cd synthesis

and run the main synthesis script

synthesis.cmd

That’s a quick synthesis, because it’s all wrappers. The script ends with an exit 0, possibly making the command window close in the end.

Anyhow, a system.ncd file (netlist) was just created in the implementation directory.

Implementation with:

xflow -wd implementation -p xc6slx45tfgg484-3 -implement xflow.opt system.ngc

After PAR is OK (and a Perl script verifies that). But hey, the xflow.opt is generated by EDK, so this hardly helps. But this looks like a common implementation.

Notes for using system.ngc directly

That is, creating a black box within a regular project for the processor. This can also be done by embedding the processor into an ISE project, but sometimes ISE needs to be avoided.

• Create the netlist files manually with platgen, with the non-toplevel option mentioned above. Or alternatively, include a system.xmp in a plain ISE project, and allow the NGC files to be generated from there.
• Copy all NGC and NCF files in the “implementation” directory (possibly excluding system.ngc) to somewhere ngdbuild looks for binaries (as specified with the -sd flag). Don’t copy NGC files from its subdirectories.
• Copy the system.v file from the “hdl” directory. This has several black modules for all .ngc files except for system.ngc
• For non-Linux use, copy edkBmmFile.bmm from the main implementation directory to somewhere, and use -bm flag on ngdbuild to point at this file. This helps the data2mem block RAM initialization utility change the right places in the bitstream. This is necessary on standalone applications, for which the start address is zero. Linux systems start directly from external memory.
• Add -sd flag in the .xst file used for parameters by the XST synthesizer, so it points at where the Microblaze’s NGC files can be found. This will make XST read the cores so it reads cores at the beginning of Advanced HDL Synthesis. It’s recommended to verify that this indeed happens. This is important, because some of the cores include the I/O buffers. When the cores are read, XST prevents itself from putting its own I/O buffers where they are already instantiated by the cores. Failing to read these cores will result in Ngdbuild complaining about I/O buffers being connected in series: One generated by XST and one by the core.
• Implementing a bitstream file directly from an system.ngc may fail if too many I/Os are connected. A large number can make sense when they go to logic, but not to actual pins. If the purpose of this bitstream generation is to export it to the SDK for the sake of setting up a BSP (or generating a Device Tree), the solution is to remove these external ports, implement, and then return these ports. This is easiest done by editing the MHS file directly. It also seems like running Project Navigator’s “Export Hardware Design To SDK without Bitstream” process, which is available for XMP sources in the design, will work without removing ports.

References

• Main start-off source: xilinx.wikidot.com
• Using the genace (TCL) script
• Linux 2.6 for Microblaze main page
• Linux on Xilinx devices (PPC) — useful, also has the command line for formatting the Compact Flash
• A bit about setting up the device tree: In the Linux source, Documentation/devicetree/bindings/xilinx.txt
• In the Linux source, arch/microblaze/boot/dts/system.dts — A sample DTS file (not the one to use!)