Debugging SDRAM interfaces
in [FPGA]
|
From: Philip Pemberton on 21 May 2010 15:38 On Fri, 21 May 2010 19:48:42 +0100, Brian Drummond wrote: > What happens in simulation? I don't have a full simulation model of the CPU, SDRAM controller and so on. There is a testbench included with sdram_wb, but it uses a completely different chip (Micron MT48LC2M32B2, 512K*32*4banks) and I haven't managed to find a model of the ISSI SDRAM. Good ol' ISSI don't release Verilog models of their chips so I'm having to make do... :-/ The nearest I've found in Micron's portfolio is the MT48LC8M32B2, which matches for bank size but doesn't check the refresh timing. I've run the testbench with that model, and it passed all five test runs (it tests five times with different refresh timings). Do I need to set up any timing constraints in ISE for the SDRAM? If so, what do I need to set up? I've got a UCF that specifies the pin parameters (DRIGMORN2.UCF), but doesn't specify any timing requirements (not even the frequency of the input clock). The Xilinx documentation is as clear as mud on this, and I can't find any good application notes on the subject (but I found tons of DDR/DDR2 SDRAM appnotes)... -- Phil. usenet10(a)philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current year
From: Philip Pemberton on 21 May 2010 18:19 OK, this is nuts... With ISE Synthesizer set up like this: Optimisation Goal: AREA Optimisation Effort: NORMAL The core works fine (the timing is a little out, but not bad enough to pooch the whole thing). If I set it up like this: Optimisation Goal: SPEED Optimisation Effort: NORMAL Then the whole thing stops working -- it outright fails to read/write the SDRAM. I can access the SDRAM controller's cache (32 bytes of the current page), but accessing an out-of-page address returns garbage. If I do the same thing on Quartus? Well, the timing looks better in SPEED mode, but it still works fine on the DE1. What the *bleep* is going on? -- Phil. usenet10(a)philpem.me.uk http://www.philpem.me.uk/ If mail bounces, replace "10" with the last two digits of the current year
From: maxascent on 22 May 2010 03:48 The constraints you should have in the ucf are the input clock fequency, the pin constraints and the IO types you are using for those pins. If the design passes simulation and meets timing once you have run P&R then you should be ok. Jon --------------------------------------- Posted through http://www.FPGARelated.com
From: Nico Coesel on 22 May 2010 07:01 Philip Pemberton <usenet10(a)philpem.me.uk> wrote: >OK, this is nuts... > >With ISE Synthesizer set up like this: > Optimisation Goal: AREA > Optimisation Effort: NORMAL > >The core works fine (the timing is a little out, but not bad enough to >pooch the whole thing). If I set it up like this: > Optimisation Goal: SPEED > Optimisation Effort: NORMAL > >Then the whole thing stops working -- it outright fails to read/write the >SDRAM. I can access the SDRAM controller's cache (32 bytes of the current >page), but accessing an out-of-page address returns garbage. > >If I do the same thing on Quartus? Well, the timing looks better in SPEED >mode, but it still works fine on the DE1. > >What the *bleep* is going on? You probably have unconstrained paths which meet timing or not depending on the routing mode. It is crucial that all paths in an FPGA have timing constraints (including paths from the inputs to the flipflops and flipflops to the outputs). -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico(a)nctdevpuntnl (punt=.) --------------------------------------------------------------
From: Gabor on 22 May 2010 23:11
On May 21, 6:19 pm, Philip Pemberton <usene...(a)philpem.me.uk> wrote: > OK, this is nuts... > > With ISE Synthesizer set up like this: > Optimisation Goal: AREA > Optimisation Effort: NORMAL > > The core works fine (the timing is a little out, but not bad enough to > pooch the whole thing). If I set it up like this: > Optimisation Goal: SPEED > Optimisation Effort: NORMAL > > Then the whole thing stops working -- it outright fails to read/write the > SDRAM. I can access the SDRAM controller's cache (32 bytes of the current > page), but accessing an out-of-page address returns garbage. > > If I do the same thing on Quartus? Well, the timing looks better in SPEED > mode, but it still works fine on the DE1. > > What the *bleep* is going on? > > -- > Phil. > usene...(a)philpem.me.ukhttp://www.philpem.me.uk/ > If mail bounces, replace "10" with the last two digits of the current year As others have mentioned, you probably have some unconstrained paths causing timing violations. If you think you have enough constraints, but still have this problem, try setting up the post place&route static timing report for Verbose and enter a good size number like 100 in the option "report unconstrained paths". Then if you find an unconstrained path that probably should be constrained you will know what to add to your constraints. As for SPEED vs. AREA, in Xilinx FPGA's you very often get the best overall timing results using AREA optimization rather than speed. This is probably because the route portion of your total path delay is large. This shows up in larger designs and larger parts especially since the worst case routing delays grow with the design size. Regards, Gabor |