jagboy

Members
  • Content count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jagboy

  • Rank
    Newbie

Profile Information

  • Gender
    Not Telling
  1. jagboy

    Real Hardware Does Not Match Simulation

    Yes, the off-chip signals are synchronized, other than ones, like the data bus, that have enormous setup/hold times. The frustrating thing is it's now all working perfectly, even though I didn't change anything.... Regards, Ray L.
  2. jagboy

    Real Hardware Does Not Match Simulation

    I don't really see a problem there. The first is the asynchronous reset signal which is only asserted when the logic is essentially quiescent. After it's released, nothing happens until the CPU comes along and writes some registers. While I agree reset should (and will) be synchronized, I' can't explain the problems I'm seeing. The other four are the first stages of the synchronizers on the Wr and RD inputs. Regards, Ray L.
  3. jagboy

    Real Hardware Does Not Match Simulation

    This thing is going to be the death of me! In the process of trying to debug and figure out exactly WHAT was broken, I added some debug logic. It didn't give me any useful information, so I removed it, and re-built. Everything is now working properly, even though, in theory, nothing has changed. That would seem to me to support my theory that there is some bizarre synthesis error happening. Due to the Monte Carlo methods used in generating the logic and mapping, it is entirely possible for different builds of the same source code to generate different gates and mappings for functionally equivalent logic. I can't see any other explanation for what's happening to me here. It doesn't give me a warm and fuzzy feeling about the Xilinx tools.... Are others using Win 8.1 with ISE? I had a really hard time getting a working install, so I have to wonder if there is some Win8 problem with the tools. Regards, Ray L.
  4. jagboy

    Real Hardware Does Not Match Simulation

    Synthesis report is attached. I don't see anything unexpected in there, certainly nothing that would explain the flaky behavior. I'll see if I can zip up the whole design. Regards, Ray L. synthesis report.txt
  5. jagboy

    Real Hardware Does Not Match Simulation

    No motors or any other noise sources right now - just the FPGA, an Arduino, and the encoders. Noise would be more random. This is a very consistent, hard failure. The Encoder 0, 2, and 3 logic works perfectly, only Encoder 1 is funky. The logic is identical - a single module instantiated 4 times. The decoding is also identical, except foe two address bits. Regards, Ray L.
  6. I've got a very simple design running on a PapilioOne 500K, implementing multiple quadrature encoder interfaces and PWMs. It all works flawlessly in simulation, but in the actual hardware it is flaky. For a given build, the flakiness will manifest in a very consistent manner. I can make some inane change to the logic, and the flakiness will move to a completely different part of the circuit. I've examined the generated gate-level logic, and it is exactly what I would expect (I've been doing chip design for 25+ years). At first, I thought I just got a bad FPGA, so I got a replacement board, but I get the exact same results. I can do synthesis at 2X the target clock rate, and still have LOTS of margin on all paths. As an example, I've had two quadrature encoders and two PWMs operating for over a week now without a single problem. Yesterday, I added two more PWMs, and now just one of the quadrature encoder interfaces is working - it's completely ignoring the encoder inputs - or, likely more correctly, I can no longer read the encoder counter. But, that same interface has worked perfectly for the last week and I have made NO changes to the RTL, except adding the two additional PWMs. All the PWMs work fine, as does the other identical encoder interface. I'm quite confident the RTL is correct, and it ALWAYS simulates correctly, so about all I can figure is I am doing something wrong in the configuration of the tools, and it's perhaps not building for the right chip or something like that. I have it configured for a xc3s500e-4vq100, and 32MHz clock at LOC P89. The clock is defined in the UCF file as: NET "CLK" TNM_NET = CLK;TIMESPEC TS_CLKSPEC = PERIOD "CLK" 31.25ns HIGH 15.125 ns; That is correct, right? Is there anything else I could be doing wrong that could explain this odd behavior? I did have one helluva time getting the Xilinx tools to install properly, as I'm running Win 8.1, but except for this problem, they now seem to be working fine. Regards, Ray L.