Hello everyone,

My name is Jake and I am new to FPGA products, and I am having some problems getting minisoc working on my setup. Currently, this is what I have:

- GNU GCC 4.5.1 or32-elf and or32-linux compiled seems to be working
- Linux kernel with a ramfs busybox image able to be simulated with or1ksim
- Digilent ATLYS with spartan6 xc6lx45
- ISE Webpack 13.1

Where I am getting stuck is on installing minisoc, as it appears that the spartan6 is not supported out of the box. I read the documentation and did the following configuration changes.
- modified the spartan3e ufc file with the correct pinouts associated with my board
- in minisoc_defines.v uncommented 'define XILINX_FPGA, FPGA_TAP and SPARTAN3E.

Big surprise, it errors the spartan6 is not supported by BSCAN_SPARTAN3. Reading further, it appears the there is specific code for the JTAG and memory management sections but I am not sure how they differ exactly.

Is there anyone willing to point me in the right direction so I can try to port this board to minisoc?

Thanks for your time,
Jake

I can't help you with the memory, but I can tell you how to (probably) fix the debug. There is a component in the advanced_debug_system (used by minsoc) called xilinx_internal_jtag. This is actually a very thin wrapper around a Xilinx IP block, the BSCAN_* block you mention. Xilinx thoughtfully made a different version of the BSCAN_* core for each FPGA they make (unlike Altera, BTW, who were smart enough to put exactly the same virtual jtag core in every chip). You'll need to find out what the BSCAN_* core in your chip is called - very likely, it's called BSCAN_SPARTAN6.

Then comes the hard part - you need to compare it to the existing BSCAN_* devices, and figure out which one it acts like (assuming it's not entirely new and different). Every one of the !#@$?'ing things is a little different. You'll need to read the docs on the BSCAN cores, there's some strange behavior with DRCK vs. TCK, and probably some other stuff I don't remember. If it doesn't make any sense to you, I can probably help if you can send me a copy of the docs.

Once you figure out which BSCAN_* core the SPARTAN6 acts like, wire the BSCAN_SPARTAN6 into xilinx_internal_jtag.v in the same way, make a define for it in the header file, and send me a patch. :)

Thanks for the insight! I will start working on it.

Also note that you may have problems with the most recent GNU toolchain, I did. Minsoc only seems to work correctly with up to version 6.8 of gdb and version 4.2.2 of gcc.

gdb-7.2 might have some issues but the rest of the toolchain should be good for bare-metal stuff. ORPSoC has been going strong with it, at least.

Hi all, Nathan,

minsoc uses actually minsoc_xilinx_virtual_jtag.v instead of xilinx_virtual_jtag.v for two reasons.

1) minsoc must define SPARTAN3 and SPARTAN3E separately
2) minsoc's jtag includes minsoc_defines.v instead of the jtag_options.v

Issue 1 could be possibly easily adapted for compatibility. Maybe we could arrange something for 2 too, like if there is some MINSOC definition it will include minsoc_defines.v instead of the other. Would you be up for it?

Anyways, please add the SPARTAN6's jtag chain module to minsoc_xilinx_virtual_jtag.v not to xilinx_virtual_jtag.v.

Best regards,
Raul

Raul - it would be easy to add a compiler directive at the top of xilinx_internal_bscan.v, something like:

`ifdef SPARTAN3E
`define SPARTAN3
`endif

For a custom include file, it might depend on the tools. Can you define a verilog macro on the command line, like the -D switch in GCC? If so, then this would work:

`ifdef XIJ_CUSTOM_INCLUDE
`include `XIJ_CUSTOM_INCLUDE
`else
`include xilinx_internal_jtag_options.v
`endif

At least, it might work - I don't know if you can use a macro in an include statement.

Julius - There is definitely a problem in GDB 7.2, it can be produced by debugging on hardware and trying to set the PC ($pc=0x100). I'm assuming it's a stack frame problem, similar to what happened in v6.8, but the patch that fixed 6.8 has no effect on the behavior of 7.2.

Jake - To get your system to work, put the changes where Raul said. But send me a patch anyway and I'll put it in the advanced debug system main line.

At least with the provided uart test program with minsoc, the latest version of gcc also fails for simulation and hardware.

Hi firefalcon,

Could you post details of the GCC test that fails. GCC 4.5.1 should be the most robust version of the compiler we have ever had, based on its regression testing. So anything that shows a fault is very interesting.

GDB (all versions) is known to be broken with the new compiled code. I'm working on it.

Thanks,

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

It may be the program itself, but when I build minsoc's UART test program using the latest version of the toolchain and debug using gdb 6.8, it appears if the PC is advancing like it should, but the UART doesn't actually output anything.

All,

I made the updates to include spartan6 jtag and memory and I successfully synthesized and made a bit file. I got about 500 warnings, is that normal?

As was previously stated, GDB is being worked on so does that mean I am not able to upload a .hex file to test the system?

Thanks,
Jake

Hi Jake,

I'm not an expert on minsoc, but I believe GDB should be fine for file upload. The problems are largely with stack analysis.

HTH

Jeremy

I get around 700-800 warnings. Many are not so important, delay ignored for synthesis for example. It should work nevertheless, you can bother about them later, when/if you want to work on OpenRISC.

I didn't try the new tools yet, gdb 7.2 or gcc-4.5. There are binaries for the installation of the older tools, I'd recommend you use them for now, and will be good to go. We are going to take a look what are the issues with gcc-4.5 soon and let people informed.

Would you mind sending an email to minsoc@googlegroups.com with the FPGA specific modules you included for SPARTAN6?

Best regards,
Raul

Hi guys,

Not sure if you were able to resolve this or not but here's a list of the things I had to do to get minsoc working on the Digilent Atlys board:

1. Create a spartan6_atlys directory as described on the minsoc wiki.
2. In your new spartan6_atlys directory, make the following mods:
- Use xc6slx45-2-csg324 for your device part.
- Modify the ucf file you can download from Digilent using one of the other existing minsoc boards as a reference. Note that the Digilent ucf file uses gigabit GMII ethernet pin connections but minsoc requires 10/100 MII pin connections. The ethernet chip on the Atlys board supports the MII interface so you just need to check out the Atlys reference guide and ethernet chip data sheet to connect the right pins.
- In minsoc_defines.v, create a new device type (I called it SPARTAN6), use FPGA_CLOCK_DIVISION with a divisor of 2 and specify NEGATIVE_RESET.
3. Make the following modifications to or1200_defines.v:
- In the target FPGA memory section, define OR1200_XILINX_RAMB16.
- In the register file RAM section, define OR1200_RFRAM_DUALPORT (not OR1200_RFRAM_GENERIC).
4. In xilinx_dcm.v, you can allow the SPARTAN6 device to use the XILINX_DCM_SP define but you'll need to specify a value for CLKIN_PERIOD in the DCM_SP module (100 ns).
5. In xilinx_internal_jtag.v, create an instance of the BSCAN_SPARTAN6 module for the SPARTAN6 device.
6. In minsoc_onchip_ram.v, allow the SPARTAN6 device to use the MINSOC_XILINX_RAMB16 define.

With these modifications, adv_jtag_bridge can connect to the board using a xilinx USB jtag cable and the self test completes successfully. I can also upload software using or32-elf-gdb. I did all of this with the tools and minsoc code that was current as of December 2011.

Geoff

Hi Geoff,

I try the same with a different board and I get troubles with NgdBuild. It complaints
that logical block 'tap_top' with type 'minsoc_xilinx_internal_jtag' could not be resolved.

I tried to follow your instructions.

thx
mk