Using the MCB


hamster

Recommended Posts

I'm feel that I'm really close to having a frame buffer in the SDRAM using the MCB,

* The MCB calibrates correctly

* All writes to the 1280x720 bytes of memory complete without issue.

 

However, all read commands seem to get stuck in the read port, and lock the memory controller up. Here's all the feedback I get from the MCB.

 

* p3_cmd_full is asserted

* p3_cmd_empty is not asserted

* p3_data_empty is asserted

* p3_data_count is not asserted

* p3_data_overflow is not asserted

 

I've changed my logic to only issue reads when read_cmd_empty is asserted - only one command is ever issued, and read_cmd_full is not asserted. I have also tested with fixing the read address at zeros to ensure that it isn't some addressing boundary crossing error.

 

Does anybody have any hints?

Link to comment
Share on other sites

Simulating the MCB is a pain. To quote http://tristesse.org/FPGA/XilinxMIGTutorial

 

"When running the simulation, be aware that calibration takes a long time - around 75821ns. With the WebPACK version of ISim, this may actually take a couple of days." 

 

Most of this is being done by simulating a partial system, with some very simple test bench models. What is really annoying is that writes work fine when run in hardware...

Link to comment
Share on other sites

I have done a bit more debugging.  If I don't empty the read data fifo then read_overflow is asserted, and there are 64 words waiting in the fifo (looking at read_count) - so at least four of the busts of 16 words are reading correctly.

 

 

However, if I keep the FIFO empty (or just leave "read_enable" asserted) then it jams up on the 48th read - I have now slowed the module down so that I'm only issuing on read every 1/60th of a second (one read per VGA frame), and the MCB runs for 8/10ths of a second before locking up.

 

I've reduced the burst length down to 8, and get a few extra commands issued - I'm going to play some more, and then expose some of the MCB's debugging signals...

Link to comment
Share on other sites

Alvie, Thanks for the offer! However I've got the problem fixed.

 

The error of my ways was to jump into the deep end and fiddle with the clocking before actually getting it working... Last night I threw in the towel and generated a new MCB, using only one port and without 'adjusting' the clocking. Hey presto! the design runs.

 

Now to adjust things slowly, and hopefully a 1280x720p frame buffer will be born...

Link to comment
Share on other sites

I've had success... a stable 8 bit 1280x720@60 test pattern, written to and displaying from the LPDDR to the LogicStart's analogue VGA .

 

Talk about an "experience building" exercise...

 

 

Mcb_test_pattern.jpg

 

I know the image isn't much, the the LPDDR is written with 


    colour <= std_logic_vector(x(8 downto 6) & y(8 downto 6) & (x(5 downto 4)+y(5 downto 4)));

 

Later on today I'll start updating the project page at  http://hamsterworks.co.nz/mediawiki/index.php/MCB_Frame_Buffer with the source.

 

There is still heaps of development that can be done on it, but for now I'm just happy to have an image!

 

 

Link to comment
Share on other sites

It has been a really good day. I've finally got MCB clocking completely clear in my head. I've got 1280x720 coming from RAM to an 8-bit analogue VGA output, and also generating the sample image using DVI-D of the HDMI port too.  If anybody wants a copy of the project, just ask!

Link to comment
Share on other sites

Code won't be on the Wiki. I had to do quite a bit of customization of the MCB generated code to implement the clocking, and the code is full of Xilinx headers & " © Copyright 2009 Xilinx, Inc. All rights reserved", so I can't really distribute it...  :(

 
Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.