Post by thread:[EE] VHDL questions

Honestly, no. However, I'm not looking for a lengthy tutoring service. I have several books on VHDL and I have about 5 specific questions which I have not been able to find an answer to and I'd like to ask them of an expert. Sean On Nov 9, 2007 6:58 PM, Vitaliy <spam_OUTspamTakeThisOuTmaksimov.org> wrote: > Sean Breheny wrote: > > If there is anyone here who knows VHDL well and is willing to answer a > > few questions, please email me offlist (shb7 at cornell.edu). > > > > Most importantly, I'm interested in race conditions and the effects of > > routing delays on them and how to write VHDL to avoid them. > > Are you prepared to pay for such advice? :) > -

Sean Breheny wrote: >> > If there is anyone here who knows VHDL well and is willing to answer a >> > few questions, please email me offlist (shb7 at cornell.edu). >> > >> > Most importantly, I'm interested in race conditions and the effects of >> > routing delays on them and how to write VHDL to avoid them. >> >> Are you prepared to pay for such advice? :) > > Honestly, no. However, I'm not looking for a lengthy tutoring service. > I have several books on VHDL and I have about 5 specific questions > which I have not been able to find an answer to and I'd like to ask > them of an expert. Then you should probably ask your questions "on the air".

Hi Peter, Vitaliy, and all, Yeah, I guess you are right, I will just ask my questions here. I said "offlist" because I thought that it might take a few exchanges of messages back and forth but that's typical for this list anyway :) Here's my first question: See the following example code: signal a: integer range 0 to 7; signal b: std_logic; process is begin if rising_edge(clk) then a<=a+1; wait for 1 ns; if a=4 then b<='1'; else b<='0'; end if; else null; end if; wait on clk; end process; Assuming that a=0 to start, then this snippet sets b to 1, after the fourth rising clock edge (no matter how much time I put in the wait statement, even a picosecond - in the simulator of course). However, if I remove the wait statement, then b doesn't go high until the fifth rising edge. The book I have (by Peter Ashenden) states that signals are not resolved until the end of the process. Did they perhaps mean to say that they are resolved at every wait statement? I know that delays of specific time are not synthesizable, I added this to simulate clock skew, and I was alarmed that even a tiny delay caused totally different behavior. Am I over-thinking this and there is an easier way to check for clock skew and race conditions? In other words, I'm concerned that in the implementation, "a" might be compared to 4 either while it is changing or depending on the delays, the comparison might happen before the new "a" value propagates to the comparator. Thanks, Sean On 11/10/07, Vitaliy <.....spamKILLspam@spam@maksimov.org> wrote: {Quote hidden}> Sean Breheny wrote: > >> > If there is anyone here who knows VHDL well and is willing to answer a > >> > few questions, please email me offlist (shb7 at cornell.edu). > >> > > >> > Most importantly, I'm interested in race conditions and the effects of > >> > routing delays on them and how to write VHDL to avoid them. > >> > >> Are you prepared to pay for such advice? :) > > > > Honestly, no. However, I'm not looking for a lengthy tutoring service. > > I have several books on VHDL and I have about 5 specific questions > > which I have not been able to find an answer to and I'd like to ask > > them of an expert. > > Then you should probably ask your questions "on the air". > -

Hi Sean, > I know that delays of specific time are not synthesizable, I added > this to simulate clock skew, and I was alarmed that even a tiny delay > caused totally different behavior. Am I over-thinking this and there > is an easier way to check for clock skew and race conditions? In other > words, I'm concerned that in the implementation, "a" might be compared > to 4 either while it is changing or depending on the delays, the > comparison might happen before the new "a" value propagates to the > comparator. The first thing that I would recommend that you do to learn HDL is to read a lot of example code. You should also understand that HDL is _not_ like software programming. It helps to think of things in terms of hardware. It also helps to learn how your HDL code is is translated into hardware. The trouble with your code isn't race conditions. Also, inserting "delays" for simulation is perfectly okay. But, if you want to do a counter followed by a comparator, do it properly. 1) stick your counter in a synchronous process that increments on each posedge clock. 2) stick your comparator in an asynchronous process. Try not to mix the two. Either way, do not forget your sensitivity list! Cheers. -- with metta, Shawn Tan Aeste Works (M) Sdn Bhd - Engineering Elegance http://www.aeste.net

Sean Breheny wrote: > Hi Peter, Vitaliy, and all, > > Yeah, I guess you are right, I will just ask my questions here. I said > "offlist" because I thought that it might take a few exchanges of > messages back and forth but that's typical for this list anyway :) > > :) {Quote hidden}> Here's my first question: > > See the following example code: > > signal a: integer range 0 to 7; > signal b: std_logic; > > process is > begin > if rising_edge(clk) then > a<=a+1; > wait for 1 ns; > if a=4 then > b<='1'; > else > b<='0'; > end if; > else null; > end if; > wait on clk; > end process; > > Assuming that a=0 to start, then this snippet sets b to 1, after the > fourth rising clock edge (no matter how much time I put in the wait > statement, even a picosecond - in the simulator of course). However, > if I remove the wait statement, then b doesn't go high until the fifth > rising edge. > > The book I have (by Peter Ashenden) states that signals are not > resolved until the end of the process. Did they perhaps mean to say > that they are resolved at every wait statement? > > Probablly, but since wait statements are not synthisisable anyway. > I know that delays of specific time are not synthesizable, I added > this to simulate clock skew, and I was alarmed that even a tiny delay > caused totally different behavior. If clock skew exeeeds clock to output delay minus hold time a synchronous circuit will misbehave. Simulating a model with no delays is essentially simulating a model with infinitely fast flip flops so introducing any clock skew will make the system misbehave. > Am I over-thinking this and there > is an easier way to check for clock skew and race conditions? You don't generally handle that yourself, you tell the synthisiser the characteristics of your clock and it works everything out from there. > In other > words, I'm concerned that in the implementation, "a" might be compared > to 4 either while it is changing or depending on the delays, the > comparison might happen before the new "a" value propagates to the > comparator. > you have written your code in a confusing way. process is begin if rising_edge(clk) then a<=a+1; if a=4 then b<='1'; else b<='0'; end if; else null; end if; wait on clk; end process; is equivilent to process is begin if rising_edge(clk) then if a=4 then b<='1'; else b<='0'; end if; a<=a+1; else null; end if; wait on clk; end process; but the second version is far more readable. Either way it is the value of A before the clock edge that affects B and it is the value of A after the clock edge that is set by the process. Making sure that clock skew is low enough for correct synchronous behaviour with the flip flops used and making sure that outputs have settled before the next clock is the synthisis tools problem not yours. Don't try to get too clever with your VHDL timing or you may confuse the synthisis tools in bad ways. For code that is synthised stick to the pattern of a process that does stuff on a clock edge using the information from the previous clock edge and then ends. when writing register transfer level VHDL code like this

> The book I have (by Peter Ashenden) states that signals are not > resolved until the end of the process. Did they perhaps mean to say > that they are resolved at every wait statement? > Further to my previous reply I would like to mention that neither "end of process" or "every wait statement" is a very accurate description. Changes happen after an infinitesimally small delay (known as a delta delay). This means that any changes triggered by a clock edge will only take effect after everything triggered by that clock has been processed. That is what lets you model synchronous logic with VHDL proceses without having to build clock to output delay into your model.