Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

Structural and behavioral descriptions Verilog

Status
Not open for further replies.
D

David83

Advanced Member level 1
Joined
Jan 21, 2011
Messages
410
Helped
45
Reputation
92
Reaction score
45
Trophy points
1,308
Activity points
3,639
As an example, I will take and gate:

1- structural

Code: 
and(f,x,y);
2- behavioral: continuous assignment

Code: 
assign f=x&y;
3- behavioral: procedural assignment

Code: 
always @(x,y)
if(x==1 & y==1)
f=1'b1;
else
f=1'b0;

What is the difference between these descriptions, and why we use more than one description level? I would say that 1 and 2 are equivalent, but in 3 we defined the and gate itself from scratch.
 

Structural verilog is (or can be) a dead match to the physical
implementation (map to std cell library). It can be built from
schematics easily / automatically, and vice versa. Seems like
#3 is unnecessarily ornate with no benefit and likely longer
execution time for simulations.
 

David83 said:
What is the difference between these descriptions, and why we use more than one description level? I would say that 1 and 2 are equivalent, but in 3 we defined the and gate itself from scratch.
Click to expand...

You havent designed a gate at all, you've written a behavioural description.
Synthesis tools use these descriptions and try and place structural components to match your behavioural description.

In a real design, you're likely to use mostly behavioural code, with module instantiations to connect your code. No one writes code at a "structural" level.
 

TrickyDicky said:
...

In a real design, you're likely to use mostly behavioural code, with module instantiations to connect your code. No one writes code at a "structural" level.
Click to expand...

Why? What advantages are for using behavioral code over structural? I could've used and(f,x,y) instead of #3. It's already defined as a basic unit, right?
 

David83 said:
Why? What advantages are for using behavioral code over structural? I could've used and(f,x,y) instead of #3. It's already defined as a basic unit, right?
Click to expand...

If you're making a design with a handful of gates and flops, then maybe you can get away with it. But try writing a design with 200k gates and 200k flops in pure structural HDL (or far more on an asic), and you'll soon run home crying.
 

TrickyDicky said:
If you're making a design with a handful of gates and flops, then maybe you can get away with it. But try writing a design with 200k gates and 200k flops in pure structural HDL (or far more on an asic), and you'll soon run home crying.
Click to expand...

Again why? Could you please explain more?
 

because writing this:

Code: 
always @(posedge clk)
  if (a > b)
    c <= f + g;
  else
    c <= x + y;

is much more compact and easier to read than the structural equivalent (It would take me more than 5 minutes to figure out how to write it - and write it correctly).
Try it yourself as an exercise.
 

TrickyDicky said:
because writing this:

Code: 
always @(posedge clk)
  if (a > b)
    c <= f + g;
  else
    c <= x + y;

is much more compact and easier to read than the structural equivalent (It would take me more than 5 minutes to figure out how to write it - and write it correctly).
Try it yourself as an exercise.
Click to expand...

OK, I see. So, instead of converting mathematical expression into logic gates equivalent, you just write the behavioral description, and the simulator will find its structural equivalent, is that right?
 

The simulator just simulates the code as written.
The synthesisor will convert it to its structural equivalent.
 

David83 said:
Again why? Could you please explain more?
Click to expand...

Tricky has already alluded to the primary reason for not writing structural code.

You write behavioral code because it is at a higher level of abstraction. Higher levels of abstraction will allow you to be more efficient, concentrating on what you want to do and not on the details of hooking up individual gates.
 

Thanks all. It's more clear now. So the next step in the design is to synthesize the code, or it's not necessary?
 

David83 said:
Thanks all. It's more clear now. So the next step in the design is to synthesize the code, or it's not necessary?
Click to expand...
Unless you plan on writing your designs as EDIF netlists, then yes you will run your HDL description (VHDL/Verilog, structural/behavioral code) through a synthesis tool to produce an EDIF netlist or whatever vendor specific netlist is used.

- - - Updated - - -

That netlist will then be used by the place and route tools to implement the design.
 

TrickyDicky said:
In a real design, you're likely to use mostly behavioural code, with module instantiations to connect your code. No one writes code at a "structural" level.
Click to expand...

People doing mixed signal ICs, schematic style (however
unfashionable you may think it) will flow their schematics
into verilog or veriloga representations to gain larger-
assembly simulation speed. And this will be structural
because the source is. Maybe nobody (who you know)
"writes" structural. But the tools do when you "create
cellview from cellview" from schematic to verilog(a).
 

I was reading coding description styles in a book, and the author mentioned three styles: structural, behavioral, and sythesizable RTL coding styles. As I understood it:

1- Structural: You define the top-level functionality using lower level modules (you use simpler blocks until you reach to the leaf cell to build the top-level block).

2- Behavioral: You describe the functionality of the system directly from the truth table; if you have these inputs, you get this output.

3- Synthesizable RTL: uses logical expressions like ^ and &.

Is this correct?
 

Synthesizable RTL is the subset of the language (VHDL/Verilog/etc) that tools can actually infer hardware from.

VHDL/Verilog are primarily simulation languages. Synthesis is almost a happy-accident. There are features that could be synthesized, but tools don't support. There are also constructs that can be synthesized, but tend to result in bad results.

Because of these reasons, many developers use a more limited subset of the language than the tools actually support. As a result of this, the tool developers don't add more synthesis support.


here is an example:
Code: 
always @ (posedge clk) begin
  // Tools should be able to create a priority encoder from a for loop.  This works in VHDL, I've never tried 
  // Verilog.
  priorityEncoder <= 0;
  for (i = 0; i < 8; i = i + 1) begin
    if (value[i]) begin
      priorityEncoder <= i;
    end
  end

  // this also creates a priority encoder.  The tools certainly will work with this.
  case (1'b1)
    value[7]: priorityEncoder2 <= 7;
    value[6]: priorityEncoder2 <= 6;
    value[5]: priorityEncoder2 <= 5;
    value[4]: priorityEncoder2 <= 4;
    value[3]: priorityEncoder2 <= 3;
    value[2]: priorityEncoder2 <= 2;
    value[1]: priorityEncoder2 <= 1;
    default: priorityEncoder2 <= 0;
  endcase

  // there are also other ways to write a priority encoder

end

In my example, the first style can be extended easily, and could be parameterized. The second style can be extended by copy/paste. The first uses a for-loop. for-loops are less used in synthesizable code. the second uses a switch statement, which is a safe construct. The encoder can also be written as a large if-elseif-else block. There are a few other ways.

I suggest making small "sandbox" designs to see how the synthesis tools handle different constructs.
 

vGoodtimes said:
Synthesizable RTL is the subset of the language (VHDL/Verilog/etc) that tools can actually infer hardware from.

VHDL/Verilog are primarily simulation languages. Synthesis is almost a happy-accident. There are features that could be synthesized, but tools don't support. There are also constructs that can be synthesized, but tend to result in bad results.

Because of these reasons, many developers use a more limited subset of the language than the tools actually support. As a result of this, the tool developers don't add more synthesis support.


here is an example:
Code: 
always @ (posedge clk) begin
  // Tools should be able to create a priority encoder from a for loop.  This works in VHDL, I've never tried 
  // Verilog.
  priorityEncoder <= 0;
  for (i = 0; i < 8; i = i + 1) begin
    if (value[i]) begin
      priorityEncoder <= i;
    end
  end

  // this also creates a priority encoder.  The tools certainly will work with this.
  case (1'b1)
    value[7]: priorityEncoder2 <= 7;
    value[6]: priorityEncoder2 <= 6;
    value[5]: priorityEncoder2 <= 5;
    value[4]: priorityEncoder2 <= 4;
    value[3]: priorityEncoder2 <= 3;
    value[2]: priorityEncoder2 <= 2;
    value[1]: priorityEncoder2 <= 1;
    default: priorityEncoder2 <= 0;
  endcase

  // there are also other ways to write a priority encoder

end

In my example, the first style can be extended easily, and could be parameterized. The second style can be extended by copy/paste. The first uses a for-loop. for-loops are less used in synthesizable code. the second uses a switch statement, which is a safe construct. The encoder can also be written as a large if-elseif-else block. There are a few other ways.

I suggest making small "sandbox" designs to see how the synthesis tools handle different constructs.
Click to expand...

I'm sorry, I'm new to Verilog and digital design, so, I didn't understand everything. Are you saying that structural and behavioral descriptions cannot be synthesized to gate level netlist?
 

They both could be synthesized. Synthesizable is not related to something being structural or behavioral.

Specifically, not all coding styles can be synthesized or synthesized with good results. It isn't that these coding styles can't be synthesized or couldn't produce good results -- it is that the tools don't currently support them.

Structural vs Behavioral is mostly boring. Structural defines exact implementations by using lots of modules. It is mostly just used by tools that generate HDL -- things like post-synthesis simulations. Behavioral is what people actually use.

But within behavioral there are many ways to describe the implementation. Some of these methods work well, some of these methods are a good fit to the problem. Ideally, code constructs will both match the problem and lead to good results. However, this doesn't always work out. At that point, you need to use workarounds with safer constructs. Or you'll need to take more extreme steps.
 

vGoodtimes said:
They both could be synthesized. Synthesizable is not related to something being structural or behavioral.

Specifically, not all coding styles can be synthesized or synthesized with good results. It isn't that these coding styles can't be synthesized or couldn't produce good results -- it is that the tools don't currently support them.

Structural vs Behavioral is mostly boring. Structural defines exact implementations by using lots of modules. It is mostly just used by tools that generate HDL -- things like post-synthesis simulations. Behavioral is what people actually use.

But within behavioral there are many ways to describe the implementation. Some of these methods work well, some of these methods are a good fit to the problem. Ideally, code constructs will both match the problem and lead to good results. However, this doesn't always work out. At that point, you need to use workarounds with safer constructs. Or you'll need to take more extreme steps.
Click to expand...

Is it the role of the designer then to make sure that the code is synthesizable, or there would be someone else who would optimize the code to be sythesizable later on? Because it seems that synthesizable codes are more difficult to write (it's like assembly language versus high-level programming languages), like in your example, although theoretically both give the same result!!
 

I suspect most places require the developer to write synthesizable code. Possibly this person wouldn't need to write the simulation. That would be more ideal as it makes it less likely the same mistake will be made in the design and sim.

There is a difference between code that fundamentally cannot be synthesized, code that technically could be synthesized, and code that is currently synthesizable.
 

vGoodtimes said:
I suspect most places require the developer to write synthesizable code. Possibly this person wouldn't need to write the simulation. That would be more ideal as it makes it less likely the same mistake will be made in the design and sim.

There is a difference between code that fundamentally cannot be synthesized, code that technically could be synthesized, and code that is currently synthesizable.
Click to expand...

You made a distinction between developer and the person who writes simulation. Who does write the simulation? Is he/she the designer?
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top