Synthesis in VHDL vs. Verilog

Greetings:

I am reading J Bhasker's "Verilog HDL Synthesis" along with "A Verilog Primer" in order to learn not only Verilog, but how to make sure I can model designs in a way that is synthesizable.

What I have just learned is that the synthesis system (such as if I am using Xilinx ISE Webpack and it's associated synthesis tools) dictates what style must be followed, because one system might be able to synthesize model 'A' and not 'B', whereas another system might be able to synthesize 'B' and not 'A', even though models 'A' and 'B' are functionally equivalent.

Thus, this leads to the question of how to I learn about what modeling style will be synthesizable for my particular tools?

The text won't be able to teach me this, since it is just dealing with the problem in general. Obviously this must be in the tooll documentation, so I would ask:

Is there good modeling style info in Xilinx tools so that one can learn how to make synthesizable models for Xilinx tools reliably?

Finally, how to VHDL and Verilog compare in terms of *inherent* synthesizability of models, or does the same problem essentially exist for both?

Thanks for input.

Good day!

--
____________________________________
Christopher R. Carlen
 Click to see the full signature
Reply to
Chris Carlen
Loading thread data ...

Chris Carlen wrote: ... : Is there good modeling style info in Xilinx tools so that one can learn : how to make synthesizable models for Xilinx tools reliably?

Look on the XILINX site fir xst.pdf amd lib.pdf

...

Bye

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

Chris Carlen wrote: ... : Is there good modeling style info in Xilinx tools so that one can learn : how to make synthesizable models for Xilinx tools reliably?

Look on the XILINX site for xst.pdf amd lib.pdf

...

Bye

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
 Click to see the full signature
Reply to
Uwe Bonnes

Both VHDL and Verilog were originally developed as simulation languages with synthesis coming along later. Both languages have stuff that is synthesizable and stuff that is not.

My experience using several VHDL synth tools is that 98% of the stuff that is synthesizable under one tool will also be synthesizable under another one. Of a much greater variability is how well each tool maps the models to the underlying fabric.

IMHO a good generic book about writing synthesizable code will prepare you for whatever tool you want to use. Also Xilinx has a guide to writing code for synthesis somewhere on their web site that will tell you pretty much the same thing. The xilinx docs should also tell you what special FPGA constructs like shifters and memory can be inferred from your generic code without having to explicitly instantiate them, which is good to know.

Jeff

Reply to
Jeff Cunningham

I've never run into anything that synthesized with Synplify and not with Precision or vice-versa. Synthesis directives are not standardized so they aren't generally portable although Precision secretly supports a small subset of Synplify directives. XST is a different story, there are lot's of things that didn't work the last time I tried it (I haven't tried the latest rev so it may have improved).

Synplify has a good user's guide. If you follow it's rules you won't have any problems with any decent synthesis tool.

Reply to
B. Joshua Rosen

I can't speak for Verilog, but in VHDL I've seen allready problems to migrate from Synopsys to Synplicity and vice versa. Further there are constructs that may synthesise, but fail in our tool for formal verification.

I would say, that's the difference between someone just learning the HDL and an experienced HW-Designer. A good book about synthesis will help. Experience or an experienced tutor will might be the other solution. As I bet there's somenone likely starting to bash on VHDL and telling me that will never happen with Verilog, I would bet anything, the same problem will rise when using Systemverilog (which is intended to replace Verilog in the next years).

bye Thomas Stanka

Reply to
Thomas Stanka

Use a synchronous template for all processes to minimize synthesis problems.

They are the same for register level design descriptions. VHDL allows synthesis using more complex data structures and algorithms.

-- Mike Treseler

Reply to
Mike Treseler

Verilog is a very simple language so it's easier for the tools guys to get it right. Personnally I stick strictly to Verilog 95, I'm not even considering using any Verilog 2001 constructs in synthesizable code for another year. As for things like System C, that's targeted at testbenches at the moment, I do think that there are any synthesis tools that can handle it.

Reply to
B. Joshua Rosen

Both VHDL and Verilog have a synthesis subset. Some aspects of the synthesis subset are intuitive, you can't synthesize access types.

Both have a separate standard that govern the synthesis subset. For VHDL this is 1076.6, for Verilog it is 1364.1. If you want to see vendors support portable coding styles, ask them to support these standards. You do need to ask because for EDA vendors supporting a standard is an investment. They expect to get something in return - like users buying their tools.

The VHDL synthesis standard is quite a bit broader than the Verilog standard, particularly with respect to registers. For example, VHDL supports dual edged registers (separate clocks or rising and falling edges). Some of this is representative of VHDL being more popular for FPGA design (and FPGA's supporting devices like this).

See also my follow up to the guy who stated: "Verilog is a very simple language so it's easier for the tools guys to get it right."

If you are making a saftey critical design, you would be better off using VHDL. There are lots of ways to hang yourself with Verilog (and none of them give you anything useful at the end of the day).

To sum this up in another way, "On a bad day coding VHDL, the compiler is going to abuse you (hence this explains why some hate VHDL), however, on a bad day coding Verilog, you can embed bugs that make it essential that you have a great testbench to find."

Cheers, Jim Lewis

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
 Click to see the full signature
Reply to
Jim Lewis

This is an incorrect assumption.

Verilog is a less consise language. If you don't follow some adhoc methodology for coding styles, you will not get it right. This fact has been proven time and time again by Verilog experts who have given numerous conference papers how they overcame yet another Verilog issue. And by the way, according to my sources (Cliff C.) this is not a feature that is being fixed in SystemVerilog.

VHDL is a very consise language. Code written and simulated in one simulator will behave exactly the same in another simulator.

So going back to simple. Verilog is simple to start producing code, however, if you fail to follow the adhoc rules of Verilog coding, it is very easy to get it wrong. Note, this happens to Verilog experts. If you want to get it right with Verilog, you would be best to invest in a Lint tool.

In VHDL many lint tool features are built into the language. As a result, you need to learn these rules from either a good book or from a good class. If you fail to learn these rules, getting started will be painful to get by the compiler. However, once you produce working code the likely hood of it being correct is much higher.

For example, at DVCon last year, a company who codes their IP in Verilog and translates to VHDL has imposed the strong typing rules of VHDL onto their Verilog designers (via a lint tool). 75% of the time a lint violation resulted in a real bug. It is certainly better to find these issues at compile/lint time rather than spending time simulating an incorrect design.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
 Click to see the full signature
Reply to
Jim Lewis

Jim -

Concise means succinct, i.e., the opposite of verbose. I've never heard anyone make that claim about VHDL. Maybe you meant precise?

Do you have a link to that DVCon paper? I'd like to read it. If not, can you briefly summarize some of the rules this company imposed?

Thanks,

Robert

Reply to
Robert Sefton

I'm hardly an expert in Verilog, yet I have no problems writing code that's easily and correctly synthesized.

There are perfectly good reasons for coding in VHDL, perhaps the most compelling of which to me is the ability to more easily include placement information, e.g., RLOCs (I'm going by what people I respect tell me, not personal experience). But writing synthesizeable Verilog is not an issue.

I think that Janick Bergeron, the verification guru, came up with the best answer to the which-is-better question. When asked which of the two languages he prefers, he said it's whichever one he isn't currently using.

Bob Perlman Cambrian Design Works

Reply to
Bob Perlman

Verilog 2001 supports attributes. However, even in this latest version of the language, it still isn't possible to have an attribute whose value is a string that is a function of e.g. a genvar.

Details here:

formatting link

[Sarcasm] Clearly the language committee understands the needs of users.

I dislike both VHDL and Verilog. Neither do what I want, although Verilog is much further away from the level of abstraction at which I wish to work. VHDL with some degree of OO would be nice. I await the results of the VHDL 200x committees.

Regards, Allan.

Reply to
Allan Herriman

Do such tools exist? Any of them free/cheap?

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
 Click to see the full signature
Reply to
Hal Murray

Thanks Bob and everyone else who responded to my inquiry.

I'm not going to get into another round of second guessing about my choice to use Verilog. Since I will be using it sporadically for things that are only a little too complicated to do with a schematic easily, I could even design at the gate instantiation level if I wanted to.

I doubt I will have too much trouble, and I intend to learn as much as I can about synthesizability in the process of learning the language.

Good day!

--
____________________________________
Christopher R. Carlen
 Click to see the full signature
Reply to
Chris Carlen

That's a very interesting thread; I missed it the first time around. Thanks for pointing it out.

Bob Perlman Cambrian Design Works

Reply to
Bob Perlman

But, there is only one type -- "wire"...

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
 Click to see the full signature
Reply to
Petter Gustad

Robert,

The paper is paper 6.1: AVOIDING ANOTHER VERILOG/VHDL WAR: GOOD CODING PRACTICES FOR SOFT IP VENDORS Dhanendra Jani, Tensilica Inc., Santa Clara, CA Alain Raynaud, Tensilica Inc., Santa Clara, CA

The quoted number came from the presentation and I could not find it in the paper. The paper is copyrighted, so I can't send you a copy. You may be able to find the paper on Tensilica's website. If you went to DVCon or have access to a disk, it is paper 6.1.

My brain just blew a fuse when with the ironic statement: "Verilog is a very simple language so it's easier for the tools guys to get it right."

Historically the problem with Verilog was that it executes differently on different platforms unless you follow some adhoc coding rules. How quick we forget.

VHDL never had race conditions and never will.

Cheers, Jim

Robert Seft>>VHDL is a very consise language. Code written and

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
 Click to see the full signature
Reply to
Jim Lewis

It's actually quite easy to make races in VHDL. Experience indicates that even simple examples may produce different results on different LRM compliant simulators.

signal clk1, clk2 : std_logic; signal sig1 : std_logic;

...

clk2

Reply to
Allan Herriman

Allan, > It's actually quite easy to make races in VHDL. I agree this is a clock to data race condition, however, it is also easy to avoid and easy to even forget the rule exists.

Are you suggesting that Verilog race conditions are as simple to solve as this? :) After reading Cliff's papers, I would conclude that it is not an insignificant issue in Verilog.

My read on the LRM and simulation cycle says that if two simulators execute your example differently, one of them is not compliant. Have you seen different results for a delta cycle situation like this that was not a simulator bug?

Regards, Jim

Allan Herriman wrote:

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
 Click to see the full signature
Reply to
Jim Lewis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.