tschaboo

Members
  • Content Count

    8
  • Joined

  • Last visited

About tschaboo

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The reference manual states Could someone please point me to the mentioned UCF/XDC file? The only one I could find doesn't include the DDR2 pins.
  2. In the reference manual Table 3.3.1 it says "Recommended clock period = 3077ps" and "650 Mbps data rate". I doubt this is correct. 1/3077 ps = 325 MHz. At a data width of 16 bits that's 2 Bytes per cycle. That would be 650 MBps. Actually, since it's DDR, shouldn't it be even twice that? 1300 MBps / 10.4 Gbps ?
  3. Hello Notarobot! Yes, that's what I found out yesterday. And indeed the command in question was such an assignment to a signal. Therefore it really should have been no different. Will do! Thanks!
  4. Yes, I'm careful. As far as I understand the RTL it looks like it's correct. It's just not that easy to decipher sometimes. Yes, I learned the difference between signal and variable the hard way. Took me half a day to find out. No, not yet. I yet have to learn how to simulate. That's on the agenda for this week. Luckily, since the RAM is static, the memory stays intact as long as the power is on. Therefore I could use the Digilent Adept 2 utility to fill the RAM with random data before my design runs [1], and read out the RAM afterwards. The result fascinates me: On the first run of writes address 0x1 doesn't get written. That's the 1 error the readback indicated. Now, if it would be 0x0 or 0xfff... I would know where to look. But 0x1?! Fascinating. And frustrating. But I learned a lot today. I think I'm going to put this aside for now. I will try to access the RAM synchronously. Let's see if similar/related bugs appear there ... or if I don't get it to work at all ... or if it just magically works. Thanks again! [1] a different, modified design - not the one I uploaded here.
  5. Thanks again for your help! I looked at the generated RTL Schematic and found nothing suspicious. As far as I understood it, the WE_clk_DFF_xx registers connect to the tri-state-BUFTs T-port. And it makes sense that those are all 16 the same, because I switch all 16 at once between 'Z' and output. Why there are first 16 flip-flops generated and only later combined into 1 - I don't know. The "Device Utilization Summary" says that there are 0 slice registers "used as Latches". It would be so helpful to see inside the FPGA. I guess if I had access to a logic analyzer I could route a few signals to output pins and watch them... I guess I could also somehow construct a simple model of the PSRAM so that I could simulate the whole thing. But I didn't look into simulation much yet. Is on my TODO list.
  6. Hello xc6lx45, thanks for your answer, I really appreciate it. I guess your suspicion that the problem is different is correct. I'm just so new to VHDL and FPGAs that I wanted to make sure, that my edit really should be equivalent. I did restructure the code several times now, and the problem (being that error_cnt gets incremented to 1) came and went. 😉 Currently it's gone. As a software engineer I'm used to +/-1 errors, but this is kind of different. Anyway, regarding your remarks: RAM timing: I have to check on the setup- and hold-constraints again. But in general it should be fine. I tried it slower - didn't make a difference. I tried it faster: there's quite some reserve. Spec says that the answer is guaranteed after 70ns but it worked fine down to 50ns. Any less and I got garbage. FPGA timing: The timing analysis always showed 145MHz or more. I'm running at 100MHz so that should be fine. Warnings: I understand all of them. They are about unused signals and they are correct. There is one NOTICE though that I don't understand: INFO:Xst:2261 - The FF/Latch <WE_clk_DFF_53> in Unit <PSRAM_nopage> is equivalent to the following 15 FFs/Latches, which will be removed : <WE_clk_DFF_56> <WE_clk_DFF_54> <WE_clk_DFF_55> <WE_clk_DFF_59> <WE_clk_DFF_57> <WE_clk_DFF_58> <WE_clk_DFF_62> <WE_clk_DFF_60> <WE_clk_DFF_61> <WE_clk_DFF_65> <WE_clk_DFF_63> <WE_clk_DFF_64> <WE_clk_DFF_68> <WE_clk_DFF_66> <WE_clk_DFF_67> I don't know what that means or where those flip-flops come from.
  7. I also attach my .ucf file in case someone wants to try this on a Nexys 3. The problem is absolutely reproducible on my end. I synthesized both variants severel times and programmed both variants several times to the FPGA. The result is always as described above. Nexys3_Master.ucf
  8. Hello, my design is made up of two files, which I both attached. I have the following problem, which I absolutely can't explain: If I move the statement "u_address <= u_address + 1;" from line 122 in top.vhd to line 128, the design behaves differently. In my eyes there should be no difference at all if I make this signal assignment before or after the "if"!?! What happens is, that with the first variant the Leds stay dark - as expected - but with the second variant Led(0) lights up after a second. Which means that u_error_cnt was incremented exaclty once! Is it possible that I hit a bug in ISE 14.7? Thanks PSRAM_nopage.vhd top.vhd