Will Synopsys synthesis infre the feedback or...

[Marty]

will this code infer a latch?

Always @(posedge clk or negedge rst)
if (!rst)
x <= 1'b0;
else if (load_en)
x <= x_in;

I don't like this code, but, that's the way the VHDL is written that
I'm converting to Verilog - no else for the load_en "if" statement.
In the VHDL version, I guess synthesis infers the feedback from x (q)
to x (d) via a MUX (I've not seen any latches in these cases). I
ASSUME it will do the same for the Verilog version. Will it? I plan
to perform a little experiment, but can't get to that at the moment
because somebody broke our synthesis scripts. It's always something!

To be complete, here is the VHDL:

process (clk, rst)
begin
if (rst = '0') then
x <= '0';
elsif (clk'event and clk = '1') then
if (load_en = '1') then
x <= x_in;
end if;
end if;
end process;

Thanks.

 

[Jonathan Bromley]

On Fri, 25 Jan 2008 10:43:12 -0800 (PST), Marty <m_piet@yahoo.com>
wrote:

will this code infer a latch?

Always @(posedge clk or negedge rst)
if (!rst)
x <= 1'b0;
else if (load_en)
x <= x_in;

I don't like this code,

Why not? Surely you agree that 'x' will imply a flip-flop.
Flip-flops are quite good at storing values. You're simply
asking the FF to continue storing its current value across
any clock edge for which load_en is false.

but, that's the way the VHDL is written

Same as I would do it - and plenty others like me.

no else for the load_en "if" statement.

What would you put in the 'else' branch?
x <= x;
That would be utterly pointless, although I can just
about imagine a scenario in which you might write such
a thing to express design intent.

In the VHDL version, I guess synthesis infers the feedback from x (q)
to x (d) via a MUX (I've not seen any latches in these cases). I
ASSUME it will do the same for the Verilog version.

The example you give is just fine. It will synthesise to a
FF with its synchronous enable connected to load_en, or (if
your target device's FFs have no synchronous enable) the
mux arrangement you describe. No problems. No need for
redundant 'else' branches in the code. Definitely no latch.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Mike Treseler]

Marty wrote:

To be complete, here is the VHDL:

process (clk, rst)
begin
if (rst = '0') then
x <= '0';
elsif (clk'event and clk = '1') then
if (load_en = '1') then
x <= x_in;
end if;
end if;
end process;

That's a clock-enabled register,
not a latch.

-- Mike Treseler

 

[Marty]

On Jan 25, 11:50 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Fri, 25 Jan 2008 10:43:12 -0800 (PST), Marty <m_p...@yahoo.com
wrote:

will this code infer a latch?

Always @(posedge clk or negedge rst)
 if (!rst)
   x <= 1'b0;
 else if (load_en)
   x <= x_in;

I don't like this code,

Why not?  Surely you agree that 'x' will imply a flip-flop.
Flip-flops are quite good at storing values.  You're simply
asking the FF to continue storing its current value across
any clock edge for which load_en is false.

That's the answer I was looking for. If load_en is false, then d gets
q via a mux with with load_en as the selector.

but, that's the way the VHDL is written

Same as I would do it - and plenty others like me.

The "load_en" is really a reg specific load_en for each reg in the
design. So, each register needs a separate clocked always process.

I like to keep the combinational and sequential logic separate. That
way, I can have ONE clocked always process to infer ALL the flops in
one place for that particular clock. I don't infer the mux, I code
it. The design intent is very clear.

So, it's just different from the way I normally code things and I
wanted to make sure that it was cool and it is.

Thanks very much.
--
Marty

 

[gabor]

On Jan 25, 2:55 pm, Marty <m_p...@yahoo.com> wrote:

On Jan 25, 11:50 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:



On Fri, 25 Jan 2008 10:43:12 -0800 (PST), Marty <m_p...@yahoo.com
wrote:

will this code infer a latch?

Always @(posedge clk or negedge rst)
if (!rst)
x <= 1'b0;
else if (load_en)
x <= x_in;

I don't like this code,

Why not? Surely you agree that 'x' will imply a flip-flop.
Flip-flops are quite good at storing values. You're simply
asking the FF to continue storing its current value across
any clock edge for which load_en is false.

That's the answer I was looking for. If load_en is false, then d gets
q via a mux with with load_en as the selector.

but, that's the way the VHDL is written

Same as I would do it - and plenty others like me.

The "load_en" is really a reg specific load_en for each reg in the
design. So, each register needs a separate clocked always process.

I like to keep the combinational and sequential logic separate. That
way, I can have ONE clocked always process to infer ALL the flops in
one place for that particular clock. I don't infer the mux, I code
it. The design intent is very clear.

So, it's just different from the way I normally code things and I
wanted to make sure that it was cool and it is.

Thanks very much.
--
Marty

You don't need an always block for each register as long as the async
reset term is the same. For example:

always @ (posedge clk or negedge rst)
if (!rst)
x <= 0;
y <= 0;
z <= 0;
else
begin
if (load_x) x <= x_in;
if (load_y) y <= y_in;
if (load_z) z <= z_in;
end

Regards,
Gabor

 

[Jonathan Bromley]

On Fri, 25 Jan 2008 11:55:07 -0800 (PST),
Marty <m_piet@yahoo.com> wrote:

That's the answer I was looking for. If load_en is false, then d gets
q via a mux with with load_en as the selector.

Or a clock enable on the FF. Most FF cells have 'em.
If you refuse to use them, you are wasting performance
and silicon area.

The "load_en" is really a reg specific load_en for each reg in the
design. So, each register needs a separate clocked always process.

As gabor said, that is emphatically *not* the case.
For example:

reg [2:0] address;
...
always @(posedge clock)
casez (address)
3'b000: reg_0 <= data;
3'b001: reg_1 <= data;
3'b01?: reg_23 <= data; // write to address 2 or 3
3'b1??: // writing any address 4..7 clears all registers
begin
reg_0 <= 0;
reg_1 <= 0;
reg_23 <= 0;
end
default:
$display("Some idiot used an address with X values in it");
endcase

I like to keep the combinational and sequential logic separate. That
way, I can have ONE clocked always process to infer ALL the flops in
one place for that particular clock. I don't infer the mux, I code
it. The design intent is very clear.

I understand what you're saying, and I know you are not
alone in this stance, but I very profoundly disagree.
Your *implementation* intent is clear. Your *design*
intent, I suggest, is horribly fogged by this artificial
split between registers and combinational logic,
and is obscured by needless implementation detail that
may even be completely inappropriate for some specific
target technology. I put it to you that the code snippet
I gave above is a good expression of *design* intent,
leaving *implementation* detail to the synth tool - which
I can trust to make a good job of utilizing whatever features
the FF cells in my target may have, such as synchronous clear
inputs, clock enables or whatever. Building the combinational
logic to implement the same thing would be an opaque mess.

I haven't designed clocked logic with a schematic for
about twelve years now, and I'm not planning to start again
any time soon.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Mike Treseler]

Jonathan Bromley wrote:

I haven't designed clocked logic with a schematic for
about twelve years now, and I'm not planning to start again
any time soon.

Nor have I felt the urge to write a program using toggle switches
http://www.fortunecity.com/marina/reach/435/altair8800.jpg

-- Mike Treseler

 

[Dwayne Dilbeck]

Just a note to clarify. The clock enable on the FF that your synthesizer
could be using instead of the multiplexor and selector line. Is NOT to be
confused with a gated clock, which operates differently,obviously.

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:b1ump3lm71sqrsv3ft6t9dducl1lgc7dub@4ax.com...

On Fri, 25 Jan 2008 11:55:07 -0800 (PST),
Marty <m_piet@yahoo.com> wrote:

That's the answer I was looking for. If load_en is false, then d gets
q via a mux with with load_en as the selector.

Or a clock enable on the FF. Most FF cells have 'em.
If you refuse to use them, you are wasting performance
and silicon area.

The "load_en" is really a reg specific load_en for each reg in the
design. So, each register needs a separate clocked always process.

As gabor said, that is emphatically *not* the case.
For example:

reg [2:0] address;
...
always @(posedge clock)
casez (address)
3'b000: reg_0 <= data;
3'b001: reg_1 <= data;
3'b01?: reg_23 <= data; // write to address 2 or 3
3'b1??: // writing any address 4..7 clears all registers
begin
reg_0 <= 0;
reg_1 <= 0;
reg_23 <= 0;
end
default:
$display("Some idiot used an address with X values in it");
endcase

I like to keep the combinational and sequential logic separate. That
way, I can have ONE clocked always process to infer ALL the flops in
one place for that particular clock. I don't infer the mux, I code
it. The design intent is very clear.

I understand what you're saying, and I know you are not
alone in this stance, but I very profoundly disagree.
Your *implementation* intent is clear. Your *design*
intent, I suggest, is horribly fogged by this artificial
split between registers and combinational logic,
and is obscured by needless implementation detail that
may even be completely inappropriate for some specific
target technology. I put it to you that the code snippet
I gave above is a good expression of *design* intent,
leaving *implementation* detail to the synth tool - which
I can trust to make a good job of utilizing whatever features
the FF cells in my target may have, such as synchronous clear
inputs, clock enables or whatever. Building the combinational
logic to implement the same thing would be an opaque mess.

I haven't designed clocked logic with a schematic for
about twelve years now, and I'm not planning to start again
any time soon.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Marty]

On Jan 26, 9:53 am, gabor <ga...@alacron.com> wrote:

On Jan 25, 2:55 pm, Marty <m_p...@yahoo.com> wrote:





On Jan 25, 11:50 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:

On Fri, 25 Jan 2008 10:43:12 -0800 (PST), Marty <m_p...@yahoo.com
wrote:

will this code infer a latch?

Always @(posedge clk or negedge rst)
 if (!rst)
   x <= 1'b0;
 else if (load_en)
   x <= x_in;

I don't like this code,

Why not?  Surely you agree that 'x' will imply a flip-flop.
Flip-flops are quite good at storing values.  You're simply
asking the FF to continue storing its current value across
any clock edge for which load_en is false.

That's the answer I was looking for.  If load_en is false, then d gets
q via a mux with with load_en as the selector.

but, that's the way the VHDL is written

Same as I would do it - and plenty others like me.

The "load_en" is really a reg specific load_en for each reg in the
design.  So, each register needs a separate clocked always process.

I like to keep the combinational and sequential logic separate.  That
way, I can have ONE clocked always process to infer ALL the flops in
one place for that particular clock.  I don't infer the mux, I code
it.  The design intent is very clear.

So, it's just different from the way I normally code things and I
wanted to make sure that it was cool and it is.

Thanks very much.
--
Marty

You don't need an always block for each register as long as the async
reset term is the same.  For example:

always @ (posedge clk or negedge rst)
if (!rst)
  x <= 0;
  y <= 0;
  z <= 0;
else
  begin
    if (load_x) x <= x_in;
    if (load_y) y <= y_in;
    if (load_z) z <= z_in;
  end

Regards,
Gabor- Hide quoted text -

- Show quoted text -

Cool. Thanks!
--
Marty

 

[Marty]

On Jan 26, 11:15 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

I understand what you're saying, and I know you are not
alone in this stance, but I very profoundly disagree.  
Your *implementation* intent is clear.  Your *design*
intent, I suggest, is horribly fogged by this artificial
split between registers and combinational logic,
and is obscured by needless implementation detail that
may even be completely inappropriate for some specific
target technology.  I put it to you that the code snippet
I gave above is a good expression of *design* intent,
leaving *implementation* detail to the synth tool - which
I can trust to make a good job of utilizing whatever features
the FF cells in my target may have, such as synchronous clear
inputs, clock enables or whatever.  Building the combinational
logic to implement the same thing would be an opaque mess.

Hmmm, I pride myself on writing clear and concise code. I've never
had anybody say that my style was unclear. I've had some adopt it and
this after they read it - not by me pushing it. But, there is always
room to change and improve by learning new things and by examining
other styles. I will do a self examination to look for ways to let go
and let synthesis and hopfully improve my ways and knowledge.

I haven't designed clocked logic with a schematic for
about twelve years now, and I'm not planning to start again
any time soon.

I never did. Well, okay, maybe in school.

Thanks for the great feedback.
--
Marty

 

[unfrostedpoptart]

On Jan 25, 10:43 am, Marty <m_p...@yahoo.com> wrote:

will this code infer a latch?

Always @(posedge clk or negedge rst)
  if (!rst)
    x <= 1'b0;
  else if (load_en)
    x <= x_in;

I don't like this code, but, that's the way the VHDL is written that
I'm converting to Verilog - no else for the load_en "if" statement.
In the VHDL version, I guess synthesis infers the feedback from x (q)
to x (d) via a MUX (I've not seen any latches in these cases).  I
ASSUME it will do the same for the Verilog version.  Will it?  I plan
to perform a little experiment, but can't get to that at the moment
because somebody broke our synthesis scripts.  It's always something!

To be complete, here is the VHDL:

process (clk, rst)
begin
  if (rst = '0') then
    x <= '0';
  elsif (clk'event and clk = '1') then
    if (load_en = '1') then
      x <= x_in;
    end if;
  end if;
end process;

This is a D flip-flop with negative-true, asynch reset and an enable.
In Verilog this it would be:

always @ (posedge clk or negedge rst)
if (rst == 1'b0) // could be "if !rst"
x <= 1'b0;
else
if (load_en == 1'b1) // could be "if (load_en)"
x <= x_in;

Some people like to add the following to the second if clause:
if (load_en == 1'b1)
x <= x_in;
else
x <= x; // this is pointless code

This is technically legal, but completely useless. To me it shows the
designer isn't comfortable with Verilog and it trying to make
everything look like a schematic. I hate code with this in it since
it's just lots of extra lines that get in the way of me reading and
understanding the code that's actually doing something.

I've never seen any book or technical paper that showed the "x <= x"
style, much less suggested its use.

David

 

[alan]

On Jan 26, 3:55 am, Marty <m_p...@yahoo.com> wrote:

On Jan 25, 11:50 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:



On Fri, 25 Jan 2008 10:43:12 -0800 (PST), Marty <m_p...@yahoo.com
wrote:

will this code infer a latch?

Always @(posedge clk or negedge rst)
 if (!rst)
   x <= 1'b0;
 else if (load_en)
   x <= x_in;

I don't like this code,

Why not?  Surely you agree that 'x' will imply a flip-flop.
Flip-flops are quite good at storing values.  You're simply
asking the FF to continue storing its current value across
any clock edge for which load_en is false.

That's the answer I was looking for.  If load_en is false, then d gets
q via a mux with with load_en as the selector.

but, that's the way the VHDL is written

Same as I would do it - and plenty others like me.

The "load_en" is really a reg specific load_en for each reg in the
design.  So, each register needs a separate clocked always process.

I like to keep the combinational and sequential logic separate.  That
way, I can have ONE clocked always process to infer ALL the flops in
one place for that particular clock.  I don't infer the mux, I code
it.  The design intent is very clear.
Regarding coding style, there's one splitting of combinational and

sequential logic that I particularly find disgusting. Basically, some
guy decided that it would be better to "organize" their ******* code
such that all declarations were together, then all assign statements,
then all always blocks. One time I needed to debug some other
company's code, and very nicely enough they had that style. It was
frustrating (!maledicion frustrating!) trying to trace a signal from
one block to another - I had to keep flipping back and forth between
the always section and the assign section, and often lost my thread of
logic in the process. No wonder their design had so many bugs; we
have recently re-implemented their core and thrown away theirs.

For this reason, I tend to put code in an "input-to-output" order,
with the input stage (regardless of whether it's combinational or
sequential) first, then various middle stages, until the output
stage. Just to be complete I even ensure that declarations are most
emphatically *not* on the top of the module, but just prior to first
use. Feedback nodes are declared in statement blocks on their
lonesome just prior to the blocks which use them. Something like
this...
module rotator(
input load,
input [2:0] i,
input rotate,
output [2:0] o,

input clk,
input reset_n
);

/*demonstration of coding style only; obviously you should use a [2:0]
register*/

reg three; //fed back from last member of bucket brigade

/*first member of bucket brigade*/
reg one;
always @(posedge clk, negedge reset_n) if(!reset_n) one <= 0; else
begin
if(load) one <= i[2];
else if(rotate) one <= three; end

/*second member of bucket brigade*/
reg two;
always @(posedge clk, negedge reset_n) if(!reset_n) two <= 0; else
begin
if(load) two <= i[1];
else if(rotate) two <= one; end

/*last member of bucket brigade*/
//reg three; //fed back
always @(posedge clk, negedge reset_n) if(!reset_n) three <= 0; else
begin
if(load) three <= i[0];
else if(rotate) three <= two; end

/*-----------------------------------------
Output stage
-----------------------------------------*/

/*rearrange the outputs*/
assign o {
one,
two,
three};

endmodule

So, it's just different from the way I normally code things and I
wanted to make sure that it was cool and it is.

Thanks very much.
--
Marty

 

[Andy]

On Jan 26, 12:15 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Fri, 25 Jan 2008 11:55:07 -0800 (PST),

Marty <m_p...@yahoo.com> wrote:
That's the answer I was looking for. If load_en is false, then d gets
q via a mux with with load_en as the selector.

Or a clock enable on the FF. Most FF cells have 'em.
If you refuse to use them, you are wasting performance
and silicon area.

The "load_en" is really a reg specific load_en for each reg in the
design. So, each register needs a separate clocked always process.

As gabor said, that is emphatically *not* the case.
For example:

reg [2:0] address;
...
always @(posedge clock)
casez (address)
3'b000: reg_0 <= data;
3'b001: reg_1 <= data;
3'b01?: reg_23 <= data; // write to address 2 or 3
3'b1??: // writing any address 4..7 clears all registers
begin
reg_0 <= 0;
reg_1 <= 0;
reg_23 <= 0;
end
default:
$display("Some idiot used an address with X values in it");
endcase

I like to keep the combinational and sequential logic separate. That
way, I can have ONE clocked always process to infer ALL the flops in
one place for that particular clock. I don't infer the mux, I code
it. The design intent is very clear.

I understand what you're saying, and I know you are not
alone in this stance, but I very profoundly disagree.
Your *implementation* intent is clear. Your *design*
intent, I suggest, is horribly fogged by this artificial
split between registers and combinational logic,
and is obscured by needless implementation detail that
may even be completely inappropriate for some specific
target technology. I put it to you that the code snippet
I gave above is a good expression of *design* intent,
leaving *implementation* detail to the synth tool - which
I can trust to make a good job of utilizing whatever features
the FF cells in my target may have, such as synchronous clear
inputs, clock enables or whatever. Building the combinational
logic to implement the same thing would be an opaque mess.

I haven't designed clocked logic with a schematic for
about twelve years now, and I'm not planning to start again
any time soon.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

I agree wholeheartedly with Jonathan on this. Especially when we have
tools with optimizations such as pipelining and retiming, where the
final distribution of logic and registers can be much different that
what was implied by the RTL, it makes little sense to use a coding
style whose main positive attribute is identification of registers and
combinatorial logic.

I take it a step further (in VHDL) and use variables in clocked
processes for just this reason: they allow me to focus on cycle by
cycle behavior, instead of structure (which the tool will chew up
anyway).

IINM, the separate combinatorial and register style of code dates back
to the earliest synthesis tools that could not infer registers, so the
registers had to be instantiated anyway. The most straight forward
path to inferring registers was to simply replace instantiations of
registers with code that inferred just registers, leaving the
combinatorial logic separate.

Andy

 

[Mike Treseler]

Andy wrote:

I take it a step further (in VHDL) and use variables in clocked
processes for just this reason: they allow me to focus on cycle by
cycle behavior, instead of structure (which the tool will chew up
anyway).

Well said.
This works in verilog also in a named block.
http://home.comcast.net/~mike_treseler/barrel.v
http://home.comcast.net/~mike_treseler/barrel_v.pdf

-- Mike Treseler

 

[Marty]

On Feb 4, 11:54 am, Mike Treseler <mike_trese...@comcast.net> wrote:

Andy wrote:
I take it a step further (in VHDL) and use variables in clocked
processes for just this reason: they allow me to focus on cycle by
cycle behavior, instead of structure (which the tool will chew up
anyway).

Well said.
This works in verilog also in a named block.http://home.comcast.net/~mike_treseler/barrel.vhttp://home.comcast.net/~mike_treseler/barrel_v.pdf

       -- Mike Treseler

Andy and Mike, your timing is fantastic!

I'm in the process of converting more VHDL to Verilog and in this
particular entity/architecture pair, there is state machine logic.
I'm not trying to modify the style of what exists because I know it
runs through synthesis just fine and the functionality is correct.
However, the next state logic is all within a clocked process. Okay,
to me that is just not as easy to follow as having the next state
logic be combinational. Anyway, within this sequential next state
logic, there are variable assignments that are updated in a state and
used to update a register within that state. I was going to remove
these variables and create the associated combinational logic whose
output would load this same register. But, if I'm reading this
correctly, all I have to do is declare local regs within this process
and use them the same way. Right? Does the process have to be named
for this to work?

Thanks!
--
Marty

BTW - when I got out of school and into ASIC design, my 1st job was
with an early adopter of VHDL. They did indeed declare and
instantiate ALL of the regs used in the design (and used "macro" VHDL
that was run through an expander). They even coded in the test logic
(I think they still do this). So, I learned to code at a fairly low
level. I've gotten away from many of those practices, but, as you can
tell from my original post, I still maintain some of them.

 

[Mike Treseler]

Marty wrote:

Andy and Mike, your timing is fantastic!

It always seems like right now to me

I'm in the process of converting more VHDL to Verilog and in this
particular entity/architecture pair, there is state machine logic.
I'm not trying to modify the style of what exists because I know it
runs through synthesis just fine and the functionality is correct.

In that case, why touch it?
Most synthesis tools can handle
mixed vhdl and verilog modules.

However, the next state logic is all within a clocked process. Okay,
to me that is just not as easy to follow as having the next state
logic be combinational.

I do everything in a clocked process.
It's very easy to trace on a simulator.

Anyway, within this sequential next state
logic, there are variable assignments that are updated in a state and
used to update a register within that state. I was going to remove
these variables and create the associated combinational logic whose
output would load this same register.

That sounds like starting over to me.

But, if I'm reading this
correctly, all I have to do is declare local regs within this process
and use them the same way. Right?

That's what I do to emulate the process scope of vhdl variables.
It's called a block in verilog.
I name it 'process' because I still
think in vhdl.

Here's the vhdl version of the example for your reference:
http://home.comcast.net/~mike_treseler/barrel.vhd

Does the process have to be named
for this to work?

I can't declare local registers otherwise.
Good luck.

-- Mike Treseler

 

[Mike Treseler]

Marty wrote:

And, the assignment to these local regs (variables) should be blocking
assignments?

It doesn't work like vhdl variables otherwise.
I would use <= if I were wiring blocks together,
but I prefer to use one (big) block per module
and wire modules together.

-- Mike Treseler

 

[Marty]

On Feb 4, 1:35 pm, Marty <m_p...@yahoo.com> wrote:

On Feb 4, 11:54 am, Mike Treseler <mike_trese...@comcast.net> wrote:

Andy wrote:
I take it a step further (in VHDL) and use variables in clocked
processes for just this reason: they allow me to focus on cycle by
cycle behavior, instead of structure (which the tool will chew up
anyway).

Well said.
This works in verilog also in a named block.http://home.comcast.net/~mike_treseler/barrel.vhttp://home.comcast.ne...

       -- Mike Treseler

Andy and Mike, your timing is fantastic!

I'm in the process of converting more VHDL to Verilog and in this
particular entity/architecture pair, there is state machine logic.
I'm not trying to modify the style of what exists because I know it
runs through synthesis just fine and the functionality is correct.
However, the next state logic is all within a clocked process.  Okay,
to me that is just not as easy to follow as having the next state
logic be combinational.  Anyway, within this sequential next state
logic, there are variable assignments that are updated in a state and
used to update a register within that state.  I was going to remove
these variables and create the associated combinational logic whose
output would load this same register.  But, if I'm reading this
correctly, all I have to do is declare local regs within this process
and use them the same way.  Right?  Does the process have to be named
for this to work?

And, the assignment to these local regs (variables) should be blocking
assignments?

Thanks again.
--
Marty

 

[Marty]

On Feb 4, 2:24 pm, Mike Treseler <mike_trese...@comcast.net> wrote:

Marty wrote:
Andy and Mike, your timing is fantastic!

It always seems like right now to me

I'm in the process of converting more VHDL to Verilog and in this
particular entity/architecture pair, there is state machine logic.
I'm not trying to modify the style of what exists because I know it
runs through synthesis just fine and the functionality is correct.

In that case, why touch it?
Most synthesis tools can handle
mixed vhdl and verilog modules.

However, the next state logic is all within a clocked process.  Okay,
to me that is just not as easy to follow as having the next state
logic be combinational.

I do everything in a clocked process.
It's very easy to trace on a simulator.

 Anyway, within this sequential next state
logic, there are variable assignments that are updated in a state and
used to update a register within that state.  I was going to remove
these variables and create the associated combinational logic whose
output would load this same register.

That sounds like starting over to me.

But, if I'm reading this
correctly, all I have to do is declare local regs within this process
and use them the same way.  Right?

That's what I do to emulate the process scope of vhdl variables.
It's called a block in verilog.
I name it 'process' because I still
think in vhdl.

Here's the vhdl version of the example for your reference:http://home.comcast.net/~mike_treseler/barrel.vhd

 Does the process have to be named
for this to work?

I can't declare local registers otherwise.
Good luck.

          -- Mike Treseler

Done and it compiles. So far, so good.

Thanks!
--
Marty