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!

 

 

  • Like 1
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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.