Thanks for the reply. On Thu, Oct 27, 2011 at 2:17 AM, RussellMc wrote: > 1. Please trim most of old messages off when posting next message on > same subject . > GMail handles this well and I did not notice the prepended old > material until replying. But other browsers may not, and it wastes > bandwidth and possibly brain power. > My apologies. Will do. > 2. I have no experience whatsoever with the systems you are working > with so the comments are general. I'm utterly impressed with the games > you are now playing and the things you have learned and are learning, > especially so when looking back at your not always promising > beginnings on list (in 2008?). (That's not intended to be a backhanded > compliment). And I note that you were talking about FPGA starter kits > in April. Actually beginning to make headway with something 6 months > on from a 1st casual inquiry is a jump that all too many never make. > (I resemble that :-) ). > > The reported behaviour suggests > > 1. the possibility of an intermittent reset condition which normally > asserts often relative to display "events", or remains asserted, > such that the counter does not seem to be advancing because it is > fitting and starting around its reset point. A similat effect may > occur if logic is often but not always dropping into some illegal or > inconceived state due to a ogical error. Less likely here probably. > > 2. As it occurs in one language Same language, Verilog. Two different synthesis tools (XST and Synplify Pro). > and not the other it suggests it may > be due to a difference in boundary condition handling. (In my > experience the incorrect or incomplete handling of "boundary > conditions" is a major cause of programming errors but seems to get > less attention than one my expect). Here this could be register > initialisation, treatment of non explicitly defined bits or pins or eg > register connections to the world which are part of a larger register > which is being set up by the system but which are not expressly being > used here. > > If external undefined pin handling is an issue then literally waving a > hand (or a dead fish) near the IC or touching pins with an (only > mildly electrostaically charged) finger will often allow a problem to > be narrowed down. In lieu of a potentially unsafe (pun almost > intended) finger, a say 100k or 1 megohm resistor connected to Vdd > (and ground on a second pass) and touched to each pin in turn *may* > allow floating or unexpectedly active pins to be identified (by > locking them in a set logic state). Resistor value used should be high > enough that it will not affect a properly functioning pin. > I tried this, it doesn't seem to make any noticeable effect. > If the problem is internal undefined states this can sometimes succumb > to bloody minded brute force initialisation of everything that is used > in any way or associated with other material in any way. When writing > programs this can include zeroing or preloading all used RAM to known > states. expressly setting all ports and pins and registers to known > states during initialisation etc. Obviously this does not translate > directly into 'HDL coding but the principles are the same. > I have considered what you said. The following is true: - Synplify synthesis tool produces a synthesis that works the way I expect it (what I wrote my code to do). - XST sometimes seems to synthesize the way I expect it, and most of the time not with the code above. - I am running at -5 speed grade which is higher performance. I was running -4 before (did not notice initially), so I changed it to -5. This did not make any difference to the behaviour of XST. - In the -5 speed grade, the chip can run at up to 333MHz according to the datasheet (I believe). My input clock (on the board) is a 50MHz oscillator. I am instantiating a DCM to output a 300MHz clock via x6 multiplier. When I changed it to x5 multiplier (250MHz), it XST then *seems* to work the way I expect it to, but I'm still not sure what's going on. I am now simulating my design in ISIM. Due to the nature of my design and the size of my count register, I have to simulate for several seconds to actually get to the point where I can observe the *bug*. It will take a LON= G time to complete a few second simulation. timescale is 1ns / 1ps. Is there = a different timescale I can do to speed up the simulation? Can anyone provide any other guesses as to what could be wrong? --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .