hamster Posted April 2, 2013 Report Share Posted April 2, 2013 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 More sharing options...
alex Posted April 2, 2013 Report Share Posted April 2, 2013 Do any of the error signals become asserted? Perhaps a screenshot of the simulation might help. Link to comment Share on other sites More sharing options...
hamster Posted April 3, 2013 Author Report Share Posted April 3, 2013 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 More sharing options...
hamster Posted April 3, 2013 Author Report Share Posted April 3, 2013 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 More sharing options...
alvieboy Posted April 4, 2013 Report Share Posted April 4, 2013 I might be able to simulate this with gdhl, most UNISIM primitives seem to work so far. Send me your design and test bench, and I'll try over here. Alvie Link to comment Share on other sites More sharing options...
hamster Posted April 4, 2013 Author Report Share Posted April 4, 2013 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 More sharing options...
hamster Posted April 5, 2013 Author Report Share Posted April 5, 2013 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... 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 More sharing options...
alex Posted April 6, 2013 Report Share Posted April 6, 2013 Well done, and well done figuring out the MCB block, it takes a little bit of getting used to, but it's also very handy to know how to drive it. Link to comment Share on other sites More sharing options...
hamster Posted April 7, 2013 Author Report Share Posted April 7, 2013 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 More sharing options...
alex Posted April 7, 2013 Report Share Posted April 7, 2013 Won't it be on your wiki as usual? That's where I go every time I need to refer to one of your choice projects. Link to comment Share on other sites More sharing options...
hamster Posted April 7, 2013 Author Report Share Posted April 7, 2013 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 More sharing options...
alex Posted April 7, 2013 Report Share Posted April 7, 2013 Oh OK, email it then please Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.