Matthew Hagerty

Members
  • Content count

    17
  • Joined

  • Last visited

  • Days Won

    1

Community Reputation

1 Neutral

About Matthew Hagerty

  • Rank
    Member

Profile Information

  • Gender Male
  1. SDRAM controller with consistent access time?

    Jack, thanks for the showcase posting! However, the timing diagrams you put up are not mine, they are from Alex's tests with the Xilix SDRAM controller I believe. Here are read, write, and refresh timing diagrams from my controller in case anyone finds them useful.
  2. vhdl problem with testbench

    I can't quite tell what your problem might be, and I really don't understand what you are doing with the Cin signal as if it were a clock? Unless you are making a Kogge-Stone adder for education purposes, I would suggest just using VHDL's addition operator and let the tool synthesize an adder. I wrote a quick adder and used the Xilinx ISE tool to make a default testbench. It worked as expected. Here is the code and timing diagram. Hope this helps. Adder: Testbench:
  3. In addition to what Hamster said, what do you have done so far? Do you have your FPGA generating VGA video (probably one of the easier tasks) or any other parts working?
  4. SDRAM controller with consistent access time?

    I would rate SDRAM a 5 *if* you already understand modern SDRAM (which includes variants like DDR, etc.) For a long time I simply did not want to learn the details, but once I committed it took me about two weeks, some questions here, and two references to understand all the timing and such. Once that was done, making a basic controller was not too difficult and I wrote most of the HDL in a few hours. Very similar to SPI memory actually, but I still don't like "command based" memory. If you have to learn everything about SDRAM, and you are trying to work with all the details of multiple banks, long burst sizes, multiple chips, etc. then I would rate SDRAM at a 10. Squeezing maximum bandwidth from an SDRAM can be very complicated. Alvieboy, it is curious you had trouble with the SRAM. I have always found SRAM to be very easy to work with and give it a 3 based on previous experience. SRAM is just like working with the internal FPGA BRAM, except you might have a longer access time depending on the external SRAM and the clock you are working with.
  5. Good looking video: flat screen vs CRT

    Getting the frequency right is not really my problem. In my first design the original resolution of the system was 256x192 pixels. I ran the monitor at 640x480 and just doubled the pixels for a 512x384 display with 64-pixel borders left/right and 48-pixel borders top/bottom. While the pixels look fine, this does not maximize the screen area (and people asked how they could get the display to fill the screen). When I did a later design I decided to just change pixel colors at the original resolution during the horizontal trace. On a CRT this filled the screen nicely and the pixels look very nice. However, on an LCD (or LED) display I'm getting artifacts since a pixel color may change halfway through an LCD's element. The horz/vert scan rates are spot on, but I was treating the horizontal sweep as a true analog raster as it really is on a CRT. I can't come up with a good way to address the problem on an LCD and I was wondering if anyone else had done anything similar or solved this problem? This is one case where a CRT is still superior to an LCD/LED display.
  6. SDRAM controller with consistent access time?

    Thanks for the camaraderie! As requested here is the code. I need to do a write-up if I can get some spare time. Hamster, thanks for the wiki offer, I might take you up on that in the near future. In the mean time, feel free to put it up if you are so inclined. I do need to mention that the rw_i request and done_o response / handshake is combinatorial and needs to respond in 5ns on both sides. This is because I used the falling edge for my register transfer and all my other HDL uses the rising edge. This post has been promoted to an article
  7. Simple SDRAM controller in VHDL

    Thanks for the camaraderie! As requested here is the code. I need to do a write-up if I can get some spare time. Hamster, thanks for the wiki offer, I might take you up on that in the near future. In the mean time, feel free to put it up if you are so inclined. I do need to mention that the rw_i request and done_o response / handshake is combinatorial and needs to respond in 5ns on both sides. This is because I used the falling edge for my register transfer and all my other HDL uses the rising edge.
  8. Does anyone have ideas, suggestions, opinions, etc. on getting good video from a flat screen vs. a CRT? In this case I'm talking about driving a VGA signal from an FPGA (which is rather easy). Since flat screens have fixed pixels sizes and resolution, I find I can't expand the display to the borders like I can with a CRT. I end up with "pixel noise" on the flat screens, but on the CTR the display is beautiful. I can correct this by adding borders to the display and ensuring the horizontal timing falls on a multiple of the flat screen's resolution, but that does not maximize the display area, i.e. like watching a movie with letter-box. The native video resolutions I'm working with will always be low compared to modern systems, i.e. 340x280, etc. and probably never over 640x480. However, using modern monitors is desirable since they are cheap and available. Thoughts?
  9. SDRAM controller with consistent access time?

    Thank you everyone for the feedback and information. Once I had most of pieces in place I tested my SDRAM controller in simulation to verify and tweak the timing. I implemented my register-transfer on the falling edge of the clock and it really worked out nicely for the SDRAM at 100MHz. After things looked good in simulation I wired it in to the rest of the system, generated the bit stream, loaded it into the FPGA, and... It worked the first time!! I was beside myself. I could not believe it. It was a lonely triumph though, no one to high-five, or call on the phone, or have a small celebration with. That seems to be the way it is in the hobby FPGA scene though. My design lets me read or write a word (16-bits in this case) every 70ns, guaranteed. The host is responsible for issuing refresh cycles though, which also take 70ns, but having control of when those refresh cycles happen allows me to keep them from interfering with the other accesses (which is what I needed). Since the host is running at 1MHz in this case, I just issue a refresh after the CPU has had its access, and just prior to the video circuits. So one refresh every microsecond, which is well below the SDRAM minimum of one refresh every 7.8us (i.e. 8192 refreshes needed every 64ms). I also now realize that SDRAM is not so bad once you get over the mystique and decouple the interface from the data access patterns. Controlling the I/O and commands to use SDRAM is not so bad, designing an efficient "memory controller" to give maximum bandwidth to SDRAM is the hard part IMO. I think most SDRAM controllers try to smash those two components together which makes them complicated. In my case I did not need maximum bandwidth so I traded it for simplicity.
  10. FPC Open LDI Display on FPGA

    Jack, Do you have any links to some docs or technical info? I have not looked a TFT LCD, or touch, but I'm wondering if the hard part is driving the display or doing the touch part, or both?
  11. SDRAM controller with consistent access time?

    As I'm getting close to trying my controller out on the real SDRAM, I noticed that the two controllers I was using as a guide (hamster's being one of them) always do the register transfer on the rising edge of the clock. While this is typically normal in HDL, this is the same clock that the SDRAM is using and the SDRAM *samples* the inputs on the rising edge of the clock. That says to me that the HDL controller should be doing its register transfers on the falling edge of the clock so the signals to the SDRAM are nice and stable during the rising edge. The other controllers work, but maybe just barely? The setup and hold times for the SDRAM I'm using are 1.5ns and 1.0ns respectively, which is fast, but might not always be fast enough as the FPGA clock speed increases. I changed my design to work with the falling edge of the clock, and the registers are now nice and stable during the rising edge and the simulation timing diagrams look much more like the datasheet's timing. Am I missing something?
  12. SDRAM controller with consistent access time?

    Alex, thanks for the research! Very good information. Hopefully I can get a little better results with a simple controller dedicated to the task. I'm working with an SDRAM, i.e. not DDR and a 100MHz clock. Based on the datasheet the Trc (Active to Active command on the same bank) is 65ns min, so in theory I can get 70ns access per read or write. I'm going to control when the auto-refresh command is issued so it won't get in the way of a read or write.
  13. SDRAM controller with consistent access time?

    Nice resources! SDRAM can certainly be used to great affect when you need a lot of bulk data, but in situations where you are working with random access 8-bit (or even 16-bit) data, SDRAM is going to be difficult. Knowing your data and access patterns can help improve bandwidth, but you don't always have that information. I remember reading somewhere that if you are thinking about something or have an idea, there are at least ten other people somewhere having similar thoughts. I don't know if that is true, but it would not surprise me it it were.
  14. SDRAM controller with consistent access time?

    I just moved from the Spartan3 500K to the Spartan6 LX25, so BRAM was not an option on my previous devboard. I typically like to get external RAM working since there won't always be enough BRAM, and I've committed too much time on the SDRAM solution to back out now. ;-)
  15. SDRAM controller with consistent access time?

    Hmm, that seems pretty doable. Now I just have to *do it*. ;-) Having each 16K bank in a separate page would be possible, but it becomes a hassle due to the way the CPU accesses that memory vs the video circuits. In this case it would be more trouble than it is worth and I don't need the efficiency, 240ns is well within the 600ns or so that I have for that part of the design.