On 18/05/10 15:06, Sébastien Bourdeauducq wrote:
Is the error present on both the board and QEMU emulation (btw Michael's port
supports both Milkymist and the original Lattice environment)?
I'm not using the Milkymist hardware -- my "V2" SoC is an Enterpoint
Drigmorn2 development board with a Xilinx Spartan-3A XC3S700A FPGA. The
serial UART is a 16550 IP core, and the SDRAM "almost but doesn't quite
work" (the "0x4000_0000 bug" prevents the core from accessing the SDRAM).
This is all being tested under ISE 12.1 "M.53d".
> Can you submit your complete code?
http://www.philpem.me.uk/temp/firmware-20100518.tgz is the firmware
http://www.philpem.me.uk/temp/lm32-soc.tgz is the current SoC Verilog
code and Xilinx project files.
> Did you have a look at the disassembly?
OK, maybe it isn't a compiler bug:
18: 78 0b 40 00 mvhi r11,0x4000
1c: 78 0e 40 00 mvhi r14,0x4000
20: b9 60 08 00 mv r1,r11
24: b9 c0 10 00 mv r2,r14
28: 38 21 00 00 ori r1,r1,0x0
2c: 38 42 01 00 ori r2,r2,0x100
30: 58 21 00 00 sw (r1+0),r1
34: 34 21 00 04 addi r1,r1,4
38: 5c 22 ff fe bne r1,r2,30 <memtest+0x30>
So it's generating the correct code for the RAM test, but for some
reason the code isn't executing properly...
LM32 is an outstanding HW design (contrary to most other open source CPUs), it
would be quite a shame not to use it just because lm32-gcc is bad (and also
could cause you hardware development issues...).
It's not just that lm32-gcc is bad, it's that:
- the cache apparently doesn't work when the LM32 is synthesized for
Xilinx targets (or using the Xilinx synthesizer)
- the sign-extender won't enable on Xst -- you can uncomment the
`define, but the CCR still reports that the SX isn't present.
Did you have a look at LLVM?
I wasn't aware that LLVM had an LM32 backend...
--
Phil.
[email protected]
http://www.philpem.me.uk/
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkym...@freenode
Webchat: www.milkymist.org/irc.html
Wiki: www.milkymist.org/wiki
