Hello everyone!

The last weeks I added a second clock domain to my minsoc system. The necessary synthesizer hardware is included and tested. A valid flag based on levels is passed to the second clk domain. Until the flag is not reported to the source clk domain, a busy signal is active.

The first tries were based on single TIG constraints for the syncronizer inputs.
After adding some more crossing signals, the bitfile changed alot and did not run after each synthesis (self test fails: cpu, sram or crc error).
As a first bugfix changing the xst and map flags torwards to standard, without global optimization helped. There are versions of my system where the minsoc system (25mhz) with second clock domain (50mhz) works fine!
But after adding more crossing signals, the same problem occured again:
either the sram selftest failed or the cpu stalls in the middle of the cpu selftest.

I thought the xst and map flags can't be the real cause - the just do some arbitrary changes which lead to success or not :/ ...

After studying some xilinx pdfs and forums I looked at the floorplanning with PlanAhead (analysis stage). The the openrisc cpu and the ethmac change their position after small changes of the clk domain crossing signals.

So I used the TIME GROUP constraint of the two clk source signals and specified TIG in both directions. This caused PAR not to show some hold score above 0 but the SoC was not able to be accessed via Advanced Debug Bridge (CRC error).

Adding a AREA GROUP constraint based on the new clk domain TIME GROUP and placing this group in a slice range near to the according output pads does not do some improvement :( .


My question now: how is possible the cpu/wishbone behaves *this* diffent when adding some signals which are marked to be TIG? There are no new warnings during the synthesis at map/par (only 3 ethernet signals, which occur out of the box with minsoc/dev). Maybe it is just my understanding but if there are NO setup/hold violations and the wishbone clk is constrained (25mhz due to 100mhz/4) WHY the system fails?

Details to my system: Digilent Atlys, Spartan6, about 65% slice utilisation. ethmac, i2c, uart and own wb-slave

Thanks alot for every helping word!!
Cheers
Flo

... after a small irc session I got some (for me) new facts:
- Advanced Debug Bridge HW is not syncron to wishbone --> check CDC behaviour/add constraints
- Advanced Debug Bridge SW sometimes throw CRC errors at correctly synthesized openrisc systems
- OpenOCD can be build to run with Advanced Debug Bridge hardware --> replace Advanced Debug Bridge software. This shall be a good way to improve CRC errors
... see http://www.elec4fun.fr/2011-03-30-10-16-30/2012-08-22-20-50-31/or1k-on-de1-openocd for howto
- openrisc is running sucessfully at 50mhz with ethmac on Digilent Atlys without timing violations. But as i understood without Advanced Debug Bridge (mohor debug system instead)

Now I have some new things to try.

Cheers
Flo

Hey guys!

Now I good some good news. I got openOCD for Advanced Debug System at the Atlys Board working.
I was able to reproduce the CRC error described in the IRC chat session. *One single* bitfile throws an error at Adv. Debug System like this:

 
	[root@toshiba minsoc]$ ./test_system.sh 
	Structs successfully initialized
	Initializing USB device
	Connected to libftdi driver.
	Initializing USB device
	Open MPSSE mode returned: OK
	Enumerating JTAG chain...

	Devices on JTAG chain:
	Index	Name		ID Code		IR Length
	----------------------------------------------------------------
	0: 	XC6SLX45 	0x34008093 	6

	Target device 0, JTAG ID = 0x34008093
	Xilinx IDCODE, assuming internal BSCAN mode
		(using USER1 instead of DEBUG TAP command)
	IDCODE sanity test passed, chain OK!
	*** Doing self-test ***
	Stall or1k - CPU(s) stalled.
	SRAM test: 
	expected 11112222, read 11112222
	expected 33334444, read 33334444
	expected 55556666, read 55556666
	expected 77778888, read 77778888
	expected 9999aaaa, read 9999aaaa
	expected bbbbcccc, read bbbbcccc
	expected ddddeeee, read ddddeeee
	expected ffff0000, read ffff0000
	expected dedababa, read dedababa
	SRAM test passed
	Testing CPU0 (or1k) - writing instructions
	Setting up CPU0
	Starting CPU0!
	CRC ERROR! Computed 0x8ea2777c, read CRC 0x767f3407
	Retry count exceeded!  Abort!

	or32_selftest.c:434: Jtag error 8 occured; exiting.	
 

My newly built openOCD with FT2232 ("enable-ftdi" configure option) outputs the following:

 
	[root@toshiba openOCD]$ openocd -f xilinx-dev.tcl 
	Open On-Chip Debugger 0.7.0-dev-gec21172-dirty (2013-11-22-14:29)
	Licensed under GNU GPL v2
	For bug reports, read
		http://openocd.sourceforge.net/doc/doxygen/bugs.html
	Info : only one transport option; autoselect 'jtag'
	adapter speed: 16 kHz
	jtag_ntrst_delay: 200
	adapter_nsrst_delay: 200
	Info : clock speed 16 kHz
	Info : JTAG tap: or1k.cpu tap/device found: 0x34008093 (mfg: 0x049, part: 0x4008, ver: 0x3)
	Halting processor
	Chip is or1k.cpu, Endian: big, type: or1k
 

(as I remember there is some output "cpu halted" ... but this paste origins from a wrong configured run)
Very strange but necessary is the IRLEN of 8 instead of 6 as described in "ise_14.6/14.6/ISE_DS/ISE/spartan6/data/xc6slx45_csg324.bds" boundary scan description file:

 attribute INSTRUCTION_LENGTH of XC6SLX45_CSG324 : entity is 6;
 

For connecting to minsoc I use the internal jtag TAP (FPGA_TAP). At first I didn't set the right IRLEN attribute and thought openOCD just supports Altera VJTAG and the generic TAP of openCores (tap_top). But the actual version does support xilinx BSCAN_SPARTAN6 TAP (2013-11-27).

The openOCD program now works from 16k to 3MHz adapter speed. An example of gdb:

 
	 [Flo@toshiba bin]$ or32-elf-gdb
	Building automata... done, num uncovered: 0/216.
	Parsing operands data... done.
	GNU gdb 6.8
	Copyright (C) 2008 Free Software Foundation, Inc.
	License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
	This is free software: you are free to change and redistribute it.
	There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
	and "show warranty" for details.
	This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=or32-elf".
	(gdb) file linc_soc 
	Reading symbols from ...bin/linc_soc...done.
	(gdb) tar rem :9999
	Remote debugging using :9999
	0x000051b4 in CommandInterpreter::getCommandByID (this=0x979a, id=18 '22')
	    at ...cpp:68
	68	    for ( ;i smaller COMINTERPRETER_MAX_CMD_COUNT;i++ ) {
	(gdb) load
	Loading section .reset, size 0x190 lma 0x0
	Loading section .vectors_minsoc, size 0xe1c lma 0x200
	Loading section .text, size 0x641c lma 0x1200
	Loading section .rodata, size 0x167 lma 0x761c
	Start address 0x1200, load size 29999
	Transfer rate: 106 KB/sec, 5999 bytes/write.
	(gdb) jump *0x100
	Line 0 is not in `CommandInterpreter::getCommandByID(unsigned char)'.  Jump anyway? (y or n) y

	Continuing at 0x100. 
 

Gdb supports set $pc, continue, jump and stepi. I didn't test further.

Now back to the *general* bitfiles which do not work - neither with adv.dbg.sys nor openOCD. Beside the single case described above there are a lot of minsoc bitfiles at which the CPU stalls after load and continue at 0x100. There are no timing violations in all bitfiles.
In most of the cases the pc values are:
0x000, 0x004, 0x200 _vec_start, 0x140 _reset_vector, 0x704 _except_700

The last file I synthesized now works. (In the past some small change of code let to working/non-working bitfile (cpu stall/not) ...)
Hopefully this is a lasting solution ... The main changes are:

 
 	NET "wb_clk" TNM_NET = "wb_clk";
				TIMESPEC TS_wb_clk = PERIOD "wb_clk" 25 MHz high 50%;

	NET "jtag_tck" 	TNM_NET = jtag_clk_pin;
				TIMESPEC TS_jtag_clk_pin = PERIOD jtag_clk_pin 3000 kHz HIGH 50% INPUT_JITTER 500 ps; 
	

The wb_clk constraint I saw at orpsocv2 Atlys constraint file.

Maybe someone as another idea what was the problem of the stalling cpu. I do not believe in a lasting solution yet ...
Otherwise this post may be a candidate for minsoc/advdbgsys wiki (openOCD alternative).

Cheers
Flo