[Milkymist-devel] about LM32 onchip debug

[Sébastien Bourdeauducq]

Hi,

On Friday 18 September 2009 18:19:27 Jose Ignacio Villar wrote:
> > What boards are you using? If you need some help, just ask on this
> > mailing list...
> 
> I'm currently focused on the development of a ucLinux soc platform for
> "cheap" FPGA boards (spartan 3/3E/3A), now that it is for teaching
>  purposes. I want to use them for a SoC course at university where next
>  year I will be changing MB and other non-free tools with just Free
>  Hardware and and Free Software.

Cool!
In the same vein, I have been doing some (informal) FPGA workshops at 
/tmp/lab:
http://lekernel.net/presentations/FPGA_Workshops/
http://www.tmplab.org/wiki/index.php/Workshop_Introduction_aux_FPGA (French)
http://www.tmplab.org/wiki/index.php/FPGA:_la_suite (French)
http://www.tmplab.org/wiki/index.php/FPGA_Workshop (on Milkymist SoC)
Slides/tutorials are somewhat messy or nonexistent, and it would be nice if we 
had proper course material available :)

> Currently I've implemented wb_ddr core from Joerg on a S3E Starter Kit. How
> easy would be using hpdmc on a Spartan 3E that lacks IO primitives as
>  IDELAY and others?

You might get away without the IDELAYs. Actually, it turns out that they are 
not required on the ML401 (their delay is set to 0) - I was just keeping them 
to safe guard from potential issues. If you have read problems, you can try to 
adjust the DDRAM clock phase instead, using a DCM.
For the DDR registers, the Spartans use IDDR2 and ODDR2 instead of Virtex's 
IDDR and ODDR. They work roughly the same.
If you check out the Git repository, you will find an implementation for 
Spartan-6 that uses IDDR2 and ODDR2 that should be compatible with Spartan-3E. 
However, this implementation is not tested at all and even causes bitgen to 
fail (but this is supposedly because of an ISE bug).

A small tip: for debugging SDRAM electrical timing issues, it's very 
convenient to have the VGA output enabled. You can for instance tell at a 
glimpse whether read or write is failing: read errors produce dancing pixels, 
while write errors produce a constant defect on the image. Also, if you get a 
stable picture at all, it means that the command bus (address lines, CAS, RAS, 
etc.) is working.

I also recommend that you download the Verilog model for your particular SDRAM 
chip and simulate it along with HPDMC. It will immediately print error 
messages if some command timing is violated (tRCD, tRFC, etc.), while such 
errors can cause sporadic failure of the real hardware that can be very hard 
to track down.

Good luck,
Sébastien