Signal value clears for no reason [VHDL, ISE 10.1]
in [FPGA]
|
Prev: VHDL newbie- stuck just weeks before project submission :(..please help
Next: Multiple builds with different top-level generic
From: ColdStart on 9 Aug 2010 22:16 Hello, Well my code is huge... but the interesting part is.. lets say i have some 10 bit wide signal, and in my logic i clear it when it reaches value 768. Actually its not just signal, its a D flip-flop with a controlling mux, and i load new value or clear it using the Mux... When i was running and synthesizing this code in ISE 9.1 my logic was just fine... but now, with version 10.1 it compiles and synthesizes good... but during debug...i noticed that when that signal reaches value 13... it suddenly goes to 0... (actually it is my FSM which checks if its 768, the through the mux cleares it...and starts whole thing again...) But now, its NOT MY FSM who cleares it before 768...its reset by itself!... very weird... any ideas? p.s. im running same code which compiled and worked well from previous version, without any changes... --------------------------------------- Posted through http://www.FPGARelated.com
From: KJ on 9 Aug 2010 22:50 On Aug 9, 10:16 pm, "ColdStart" <teslashock(a)n_o_s_p_a_m.msn.com> wrote: > Hello, > > Well my code is huge... but the interesting part is.. lets say i have some > 10 bit wide signal, and in my logic i clear it when it reaches value 768. > My reading of what you wrote is that you *asynchronously* clear the 10 bits when those 10 bits happen to reach the value 768. If that's the case, then you're bound to have trouble. > Actually its not just signal, its a D flip-flop with a controlling mux, and > i load new value or clear it using the Mux... > To many uses of the word 'it' and nobody will be clear about just what 'it' is. Less description and more posting of the actual code snippet would be 10x more useful than what you're trying to describe. > When i was running and synthesizing this code in ISE 9.1 my logic was just > fine... but now, with version 10.1 it compiles and synthesizes good... but > during debug...i noticed that when that signal reaches value 13... it > suddenly goes to 0... > Not surprising at all if my first sentence regarding what I think you're describing is correct. > (actually it is my FSM which checks if its 768, the through the mux cleares > it...and starts whole thing again...) > Starts what whole thing? > But now, its NOT MY FSM who cleares it before 768...its reset by itself!.... > very weird... any ideas? > 1. If the logic defining the behavior of the 10 bit thing causes that 10 bit thing to be reset when it reaches a particular value, you've got some rewriting of the code to do. 2. Could be timing. Have you: - Setup the timing constraints and run static timing analysis? Did it pass? - Is there more than one clock domain in this design? > p.s. im running same code which compiled and worked well from previous > version, without any changes... > Some things to keep in mind... - You can't debug a working system. Don't waste time analyzing the working system, focus on the non-working one as if you didn't know about the older, working one. - Sometimes things 'work' although they have latent design issues still to be uncovered. Whether you should consider yourself 'lucky' that it was working or 'unfortunate' because you didn't uncover the problem sooner is up to you to decide. Feel free to post some actual snippets of code that demonstrate what you're saying that accurately represent what you're doing. (1) Kevin Jennings (1) An example of what I think you're describing (which would be a problem if it is what you have is) process(clk, clear) begin if (clear = '1') then big_sig <= (others => '0'); elsif rising_edge(clk) then big_sig <= big_sig + 1; end if; end process; clear <= '1' when (big_sig = 768) else '0';
From: Ed McGettigan on 9 Aug 2010 22:51 On Aug 9, 7:16 pm, "ColdStart" <teslashock(a)n_o_s_p_a_m.msn.com> wrote: > Hello, > > Well my code is huge... but the interesting part is.. lets say i have some > 10 bit wide signal, and in my logic i clear it when it reaches value 768. > > Actually its not just signal, its a D flip-flop with a controlling mux, and > i load new value or clear it using the Mux... > > When i was running and synthesizing this code in ISE 9.1 my logic was just > fine... but now, with version 10.1 it compiles and synthesizes good... but > during debug...i noticed that when that signal reaches value 13... it > suddenly goes to 0... > > (actually it is my FSM which checks if its 768, the through the mux cleares > it...and starts whole thing again...) > > But now, its NOT MY FSM who cleares it before 768...its reset by itself!.... > very weird... any ideas? > > p.s. im running same code which compiled and worked well from previous > version, without any changes... > > --------------------------------------- > Posted throughhttp://www.FPGARelated.com Have you reviewed all of the WARNING messages from the synthesizer? Which ISE version did you move to from 9.1? Ed McGettigan -- Xilinx Inc.
From: Gabor on 10 Aug 2010 10:02 On Aug 9, 10:50 pm, KJ <kkjenni...(a)sbcglobal.net> wrote: > On Aug 9, 10:16 pm, "ColdStart" <teslashock(a)n_o_s_p_a_m.msn.com> > wrote: > > > Hello, > > > Well my code is huge... but the interesting part is.. lets say i have some > > 10 bit wide signal, and in my logic i clear it when it reaches value 768. > > My reading of what you wrote is that you *asynchronously* clear the 10 > bits when those 10 bits happen to reach the value 768. If that's the > case, then you're bound to have trouble. > > > Actually its not just signal, its a D flip-flop with a controlling mux, and > > i load new value or clear it using the Mux... > > To many uses of the word 'it' and nobody will be clear about just what > 'it' is. Less description and more posting of the actual code snippet > would be 10x more useful than what you're trying to describe. > > > When i was running and synthesizing this code in ISE 9.1 my logic was just > > fine... but now, with version 10.1 it compiles and synthesizes good... but > > during debug...i noticed that when that signal reaches value 13... it > > suddenly goes to 0... > > Not surprising at all if my first sentence regarding what I think > you're describing is correct. > > > (actually it is my FSM which checks if its 768, the through the mux cleares > > it...and starts whole thing again...) > > Starts what whole thing? > > > But now, its NOT MY FSM who cleares it before 768...its reset by itself!... > > very weird... any ideas? > > 1. If the logic defining the behavior of the 10 bit thing causes that > 10 bit thing to be reset when it reaches a particular value, you've > got some rewriting of the code to do. > 2. Could be timing. Have you: > - Setup the timing constraints and run static timing analysis? > Did it pass? > - Is there more than one clock domain in this design? > > > p.s. im running same code which compiled and worked well from previous > > version, without any changes... > > Some things to keep in mind... > - You can't debug a working system. Don't waste time analyzing the > working system, focus on the non-working one as if you didn't know > about the older, working one. > - Sometimes things 'work' although they have latent design issues > still to be uncovered. Whether you should consider yourself 'lucky' > that it was working or 'unfortunate' because you didn't uncover the > problem sooner is up to you to decide. > > Feel free to post some actual snippets of code that demonstrate what > you're saying that accurately represent what you're doing. (1) > > Kevin Jennings > > (1) An example of what I think you're describing (which would be a > problem if it is what you have is) > > process(clk, clear) > begin > if (clear = '1') then > big_sig <= (others => '0'); > elsif rising_edge(clk) then > big_sig <= big_sig + 1; > end if; > end process; > > clear <= '1' when (big_sig = 768) else '0'; While I would agree that the above code is "broken" in the sense that you have a decoded output asynchronously resetting its source, I fail to see how it would have the symptom reported in the original post of resetting at value 13. 768 requires both high order bits to be high, which does not ever occur before state 768 in a normal up counter, glitches included. So if I saw the counter reset at state 13, I would suspect something else is horribly broken, perhaps my clock is not routed on a global resource, for example, causing the counter to have hold time errors. Automatic clock buffering is the sort of thing that can change between tool versions. Regards, Gabor
From: KJ on 10 Aug 2010 10:39
On Aug 10, 10:02 am, Gabor <ga...(a)alacron.com> wrote: > So if I saw the counter reset at state > 13, I would suspect something else is horribly broken Which is why I also suggested checking timing. KJ |