I'd rather switch than fight!
in [FPGA]
|
From: Patrick Maupin on 22 Apr 2010 10:29 On Apr 22, 9:03 am, Patrick Maupin <pmau...(a)gmail.com> wrote: > On Apr 22, 3:44 am, Jan Decaluwe <j...(a)jandecaluwe.com> wrote: > .> Unfortunately, the source code is in Python :-) (MyHDL). > > > However, there is equivalent converted Verilog available > > in the article. > > > http://www.myhdl.org/doku.php/cookbook:jc2 > > Well, maybe it's so subtle I still don't get it. But it looks like > 'run' and 'dir' are what I would consider combinatorial variables, so > I would just stuff them in the combinatorial 'always @*' block. The > only register which would have a corresponding 'next_' is 'q'. In > fact, your whole sequential block could be converted to the > combinatorial block (with the exception of changing '<=' to '=', and > putting 'next_' in front of q on lhs), and the sequential block would > basically be 'q <= next_q'. > > Or is there something else you're trying to convey that I'm missing? > > Regards, > Pat BTW, your myhdl does something similar, in that you use 'q.next'. So, I really don't understand why you would think it's a terrible thing to use 'next_q' to mean the same thing. Regards, Pat
From: Jan Decaluwe on 22 Apr 2010 11:01 On Apr 22, 4:29 pm, Patrick Maupin <pmau...(a)gmail.com> wrote: > On Apr 22, 9:03 am, Patrick Maupin <pmau...(a)gmail.com> wrote: > > > > > On Apr 22, 3:44 am, Jan Decaluwe <j...(a)jandecaluwe.com> wrote: > > .> Unfortunately, the source code is in Python :-) (MyHDL). > > > > However, there is equivalent converted Verilog available > > > in the article. > > > > http://www.myhdl.org/doku.php/cookbook:jc2 > > > Well, maybe it's so subtle I still don't get it. But it looks like > > 'run' and 'dir' are what I would consider combinatorial variables, so > > I would just stuff them in the combinatorial 'always @*' block. The > > only register which would have a corresponding 'next_' is 'q'. In > > fact, your whole sequential block could be converted to the > > combinatorial block (with the exception of changing '<=' to '=', and > > putting 'next_' in front of q on lhs), and the sequential block would > > basically be 'q <= next_q'. > > > Or is there something else you're trying to convey that I'm missing? > > > Regards, > > Pat > > BTW, your myhdl does something similar, in that you use 'q.next'. So, > I really don't understand why you would think it's a terrible thing to > use 'next_q' to mean the same thing. The two are unrelated. q.next is MyHDL's way to do signal (non blocking) assignment ("<="). My critique is that you use 2 signals/regs per state register instead of 1. You could also do that in MyHDL, but I'm not doing that in the examples I showed you. BTW, it would look like: next_q.next = q Jan
From: Jan Decaluwe on 22 Apr 2010 11:08 On Apr 22, 4:03 pm, Patrick Maupin <pmau...(a)gmail.com> wrote: > On Apr 22, 3:44 am, Jan Decaluwe <j...(a)jandecaluwe.com> wrote: > .> Unfortunately, the source code is in Python :-) (MyHDL). > > > However, there is equivalent converted Verilog available > > in the article. > > > http://www.myhdl.org/doku.php/cookbook:jc2 > > Well, maybe it's so subtle I still don't get it. But it looks like > 'run' and 'dir' are what I would consider combinatorial variables, so > I would just stuff them in the combinatorial 'always @*' block. The > only register which would have a corresponding 'next_' is 'q'. In > fact, your whole sequential block could be converted to the > combinatorial block (with the exception of changing '<=' to '=', and > putting 'next_' in front of q on lhs), and the sequential block would > basically be 'q <= next_q'. > > Or is there something else you're trying to convey that I'm missing? Yes, the fact that 'run' and 'dir' are state variables. Therefore, your proposed approach wouldn't work. You have the test vectors, you can try it yourself. Quoting from the article: """ This example is more subtle and complex than it may seem at first sight. As said before, variables dir and run are state variables and will therefore require a flip-flop in an implementation. However, they are also used combinatorially: when they change, they may influence the counter operation in the same clock cycle, that is, before the flip-flop output changes. This is perfectly fine behavior and no problem for synthesis tools, but it tends to confuse a lot of designers. """ Jan
From: Patrick Maupin on 22 Apr 2010 15:11 On Apr 22, 10:08 am, Jan Decaluwe <j...(a)jandecaluwe.com> wrote: > > Or is there something else you're trying to convey that I'm missing? > > Yes, the fact that 'run' and 'dir' are state variables. Therefore, > your > proposed approach wouldn't work. You have the test vectors, you can > try it yourself. > > Quoting from the article: > """ > This example is more subtle and complex than it may seem at first > sight. As said before, variables dir and run are state variables and > will therefore require a flip-flop in an implementation. However, they > are also used combinatorially: when they change, they may influence > the counter operation in the same clock cycle, that is, before the > flip-flop output changes. This is perfectly fine behavior and no > problem for synthesis tools, but it tends to confuse a lot of > designers. > """ OK, I admit I didn't read that carefully enough; in fact, I just glanced at the actual code before my coffee this morning. But you know what? Where I come from, "subtle" that "tends to confuse a lot of designers" is just a synonym for "screwed up." The whole point of the coding style I was describing is to NOT write stuff that would confuse other designers. After all, in C I can write perfectly valid code like "0[x] = 3". But just because I can, doesn't mean it's a good idea. Regards, Pat
From: Muzaffer Kal on 22 Apr 2010 16:04
On Thu, 22 Apr 2010 08:08:59 -0700 (PDT), Jan Decaluwe <jan(a)jandecaluwe.com> wrote: >On Apr 22, 4:03�pm, Patrick Maupin <pmau...(a)gmail.com> wrote: >> On Apr 22, 3:44�am, Jan Decaluwe <j...(a)jandecaluwe.com> wrote: >> .> Unfortunately, the source code is in Python :-) (MyHDL). >> >> > However, there is equivalent converted Verilog available >> > in the article. >> >> > � �http://www.myhdl.org/doku.php/cookbook:jc2 >> >> Well, maybe it's so subtle I still don't get it. �But it looks like >> 'run' and 'dir' are what I would consider combinatorial variables, so >> I would just stuff them in the combinatorial 'always @*' �block. �The >> only register which would have a corresponding 'next_' is 'q'. �In >> fact, your whole sequential block could be converted to the >> combinatorial block (with the exception of changing '<=' to '=', and >> putting 'next_' in front of q on lhs), and the sequential block would >> basically be 'q <= next_q'. >> >> Or is there something else you're trying to convey that I'm missing? > >Yes, the fact that 'run' and 'dir' are state variables. Therefore, >your >proposed approach wouldn't work. You have the test vectors, you can >try it yourself. > >Quoting from the article: >""" >This example is more subtle and complex than it may seem at first >sight. As said before, variables dir and run are state variables and >will therefore require a flip-flop in an implementation. However, they >are also used �combinatorially�: when they change, they may influence >the counter operation �in the same clock cycle�, that is, before the >flip-flop output changes. This is perfectly fine behavior and no >problem for synthesis tools, but it tends to confuse a lot of >designers. >""" I am not sure who is really confused here. What is suggested in the above paragraph is not really feasible; assuming by 'dir' one refers to the output of a flop. It's not possible to use the output of a flop at the same clock when its input changes (without generating an intentional hold violation by playing with clock skews). What one can do is to have a combinational signal dir_d which gets computed by dir_q and other signals. This dir_d can be used in the same clock cycle but dir_q will not be available till next cycle: if (left or dir_q) dir_d = 1; if (right) dir_d = 0; if (dir_d) do_left; dir_q <= dir_d; The problem with the last verilog block shown is the dir and run are not flops anymore but combinational signals decoded from goleft and goright so the last direction will not be remembered. If last direction needs to be remembered, one needs to decode the 'instruction', use the decoded value and remember the decoded value as above. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.com |