Mail Archives: geda-user/2012/02/20/01:07:08
Gene,
I think the greatest danger is that your synthesized code
behaves differently than your simulation. The evaluation
of verilog is tricky. I stick to some simple guidelines
that have always worked for me and they synthesize to
circuits that act exactly as the simulation does.
These are:
-When modeling sequential logic, use nonblocking assignments.
-When modeling latches, use nonblocking assignments.
-When modeling combo logic with an always block, use blocking
assignments.
-When modeling both sequential and combo logic within the same
always block, use nonblocking assignments.
-Do not mix blocking and nonblocking assignments in the same
always block.
-Do not make assignments to the same variable from more than one
always block.
These come from Cliff Cummings of Sunburst Design.
Roger
On Mon, Feb 20, 2012 at 12:42:48AM -0500, gene glick wrote:
> On 02/20/2012 12:17 AM, DJ Delorie wrote:
>
> >always @(posedge clk)
> > begin
> > /* edge happens here */
> > new_count = count + 1;
> > if (new_count == 0)
> > do_something
> > count = new_count;
> > end
> >
> >
> >always @(posedge clk)
> > begin
> > prev_count = count;
> > /* edge happens here */
> > count<= prev_count + 1; // non-blocking method
> > if (prev_count == 0)
> > do_something
> > end
> >
> >
> >My personal paradigm is to use '=' in an @always combinatoric state
> >machine that computes the next state from the current state, and '<='
> >in a separate edge-triggered @always that just copies the next state
> >to the current state.
> >
> >For example, see http://www.delorie.com/electronics/sdram/simple1.v
> >
> >The last two blocks are an "always @(negedge ram_wclock) begin" that
> >copies the next state to the current state, followed by a huge "always
> >@(...lots of things...)" that computes the next state.
> >
> >I've found that if I try to mix combinatoric and edge logic in the
> >same block, I end up doing something pessimal and the chip won't run
> >as fast as it should.
> >
>
> I suppose the "=" (blocking) makes the code sequential, like C - if that
> clarifies it some. But I was really wondering how the synthesis tools
> deal with this. I almost always avoid using the "=" form. It doesn't
> bother me that my states are off (delayed) by 1 clock tick. So in my
> 2nd example, during simulation do_something runs when the counter is 1
> not 0. Not really a big deal. In the first example, do_something runs
> when the counter is 0. Makes looking at the waveforms, and the counter,
> line up nice but what the heck does the synthesis tool build?
>
> Wouldn't your method of 'previous count' and 'count' use twice as many
> registers?
- Raw text -