verilog versus vhdl

As to which language will cause less issues with the Xilinx tools, I'm not sure, but my gut tells me that (if there is any difference) they may handle VHDL better because VHDL tends to be more used for FPGAs (at least in the past, but verilog may be catching up?). I remember a Mentor Graphics presentation at an HDL conference 4-5 years ago, and VHDL was the most used HDL for FPGA design, by a wide margin; Verilog was third, behind PALASM! Things have certainly changed since then, but I don't know by how much.

But if you don't already know VHDL and the traps within it, perhaps you'd be better off with verilog (depending on how well you know it)? Whether you use VHDL or Verilog, you are probably just as likely to encounter problems because of whichever one you choose!

Another thing to consider may be what IP you may be using, and what language it is written in (synthesis and/or simulation), if any. Most synthesis tools can handle mixed languages at the module level, but simulators that can do so may be more expensive.

Andy

Xesium wrote:

johnp schrieb:

yes, Xilinx verilog support has improved a great deal.

for ISE projects its almost no difference - for EDK systems its still a little easier to deal with VHDL - the way EDK propagates params down the hierachy seems to work better for VHDL, also if you are trying to create EDK peripherals where top-levels are in VHDL and those include modules below that are imported from other projects written in verilog, then if those verilog modules use some includes then the all thing doesnt want to compile so nicely any more.

the way EDK handles modules and directories - the all verilog define and include concept doesnt play nicely with it. If the EDK ip cores are written in verilog for EDK (and use no includes) then they work ok, also with parameter passing between VHDL and verilog modules

Antti

Most of the C based HDLs offer some means to assign arbitrary bit widths to objects, frequently in ways that break ANSI C compatability. Bit fields do however existing in the language, and in ways that are actually pretty useful for most applications. Still, one of my nits in doing FpgaC is to carry a proposal to the ANSI committee to allow bit fields that are larger than the native type, forcing the compiler to handle a 200 bit or 64 bit object the same on both an 8bit micro and a

128 bit super computer. In FpgaC, I'm not sure there is a limit on the width of an object, other than constants, which is something I'm already working toward fixing.

As for concurrency, that is something that hardware guys miss understand completely. Every compiler is free to shuffle/reschedule the code produced, as long as the results have the expected serial symantics. Out of order execution and multiple issue pipelines, ARE concurrency. As are threads, pipes, processes, and many other concurrent abstracts in what appears a sequential language.

In FpgaC everything in a statement group is completely concurrent. Other C based HDLs offer other concurrency rules, from statement level clock timing, to explict construction of parallelism using hardware HDL semantics.

Synthesis in FpgaC is becoming better, actually better than VHDL/Verilog, as I'm working on better technology mapping. My current development copy of FpgaC does optimizations effectively, that VHDL/Verilog can not do. The difference, is that with VHDL/Verilog you describe the circuits that must be built, and the HDL is pretty much obligated to build the circuits that are described. In high level languages, the programmer describes the result wanted, and the compiler is free to implement those results in the best way possible. In the old days, you wrote in assembler to get exactly the code you wanted executed, just as you write VHDL/Verilog to get exactly the hardware you want. While some folks think this is "advanced" over schematic designs, it's only advanced as assemblers are over programming directly in binary. Because of the extensive timing and instantiation control in the languages, the VHDL/Verilog synthesis tools are obligated to implement the circuits as described ... and this will forever be a handy cap.

With higher level languages, which avoid specific details about the instantiation, then the compiler becomes free to choose whatever hardware that will produce the described results, and optimize out everything else that doesn't matter. Vhdl/Verilog really lack that freedom, when the design description is as precise as what clock edge, and what logic level, every object is at.

In my testing some new tech mapping a few months back, I described a very very elaborate demo system that instantiated a very complex control system filter combining 60 inputs which produced a single bit output controlling a PWM driver. The synthesis result I thought was in error, as none of the multipliers, adders, comparitors, or feedback in the filter existed in the four term sum of products result .... four 30 variable AND terms OR'd togather, in just over 120 LUTs. However, the optimized circuit simulated to the expected test vecors, just as did the previous version of the design that was over 3,100 LUTs produced by the stock Beta-2 release. The combinatorial depth of the original synthesis was 47 LUTs deep which would have required extensive pipelining and retiming, and only 6 deep after optimization. Another crypto demonstration program is even better, which I will describe in a paper this fall, as the results shatter expectations about the strengths of certain cyphers, especially when large FPGA super computers are available. There are simplifications and optimizations available to bit structured machines, which are simply not possible for most sequential word machine architectures, and from that comes a different reality than "normally assumed" today.

While my interest in FpgaC is to build useful FPGA super computers in the future, it's a love of both hardware design, and software design, that enables that vision. That is not a reasonable vision, while the only tools to program fpga designs, and at the bit and clock edge level. I suspect, that just as assembler, and even 'low level" C is no longer in favor for complex designs today ... there will be an evolution where high level HDL tools move away from detailed hardware description at the clock and signal level detail, and move up so that system level specification which includes the interface descriptions and leaves the internal hardware description clearly to the tools to optimize and produce. I'm not the brighest tool designer on the planet ... actually just a wet eared newbie ... so if I can get FpgaC to do these things with a little magic, I'm certain the better guys on the planet that do this for a living will blow some socks off with system level C languages. I'm actually looking foward to a SystemC tool based on C++ sematics that has really good synthesis ... maybe a few years from now?

Actually, you can make your VHDL or Verilog description much more abstract than this. I've recently been working with some very abstract VHDL code, some of which was untimed, and some of which used functions and procedures rather than explicit hierarchy. It was also very dependent on passing around large records, and letting the synthesiser get rid of the unused bits. The untimed code relied on register retiming in DC (which I think XST supports).

Personally, I really hate this sort of code. It was synthesising to about 75 logic levels between clocks before I started hacking it.

Give it a go - try some abstract code on your favourite synthesiser. DC has a 'map_to_entity' pragma which allows you to write a behavioural function or procedure for simulation, and map it to an entity for synthesis. I tried running some example code that uses this pragma through Amplify recently, and it ignored the pragma, and synthesised the behavioural code correctly. Synplify would probably do exactly the same.

It'll never happen; already been tried, failed. Hacking low-level hardware semantics into existing C++ semantics just gives you a verbose and complex mess, which is nowhere near as concise and clear as a VHDL or Verilog description. Great for modelling, non-starter for real-world synthesis.

BTW, I google'd FpgaC and spent 10 minutes looking at the SourceForge site, before giving up. There's no obvious overview, FAQ, or documentation; you'll need to fix this if you want to get anyone interested.

Unrelated to your comments, but a couple of people elsewhere in this thread were comparing Verilog to C. I guess I've missed this - I've spent many years writing C, C++, and Verilog, and I've never noticed

*any* similarity between Verilog and C, apart from the most superficial. I'd really like to see someone produce a list of these similarities.

Evan

In summary: &&, ||, !, &, |, ^, ~, ==, !=. :-)

-Ben-

Thanks - I was going to say much the same. Case-sensitivity would be my strongest candidate - and, perhaps, the use of square brackets for array subscripts. Not much else.

I guess, though I don't know for sure, that the superficial similarities are because the original authors of Verilog very sensibly saved themselves some work by borrowing lex/yacc parsing technology.

[Ben Jones]

And even that is at the mercy of 4-state logic. (I spy a missed opportunity here. SystemVerilog has not yet assigned a meaning to the :-) operator.)

--
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.

How about:

1. if/else are the same.
2. Verilog "begin" and "end" maps to C's "{" and "}"
3. Verilog's case statement is similar to C's switch statement.
4. Comment characters are the same.
5. Verilog and C statements are both terminated with semicolon.
6. And last but not least, both Verilog and C have "integer" types. ;-)

Still, I'd rather type '&' than 'and' anyday. :)

I believe that happy smilies cannot exist within a standard C-syntax expression. The lexer requires them to be sad, viz:

r = a?b :-( d+e);

Ah, wait. Unless, of course, they have a big nose:

r = (a?b :0) ;

...or they are very very happy:

r = a?b :-D ;

There must be a standard reference somewhere for this stuff...

-Ben-

True, I guess the conditional statements have the same format. There aren't many different formats to choose from though. :)

So that's not very alike at all then...!

Nah, it's nothing like it! There's no equivalent of C's requirement for a 'break' statement at the end of each branch for a start.

True, good point.

But there the similarity ends; for example:

module foo; ... endmodule

WTF?!? Who thought *that* made sense?

ROFL! :-)

-Ben-

urrm, does the smiley apply to the whole post ?

C has a hard time with "if (1'bx)".

I'll grant you that one.

Apart from the facts that:

• each branch is a single statement in Verilog, whereas C switch is in fact a computed branch and execution continues through the switch block;

• choices must be prefixed with the keyword "case" in C;

• the syntax for mapping more than one choice to the same action is different;

• Verilog has two wildcard-matching variants of "case";

• case labels (choices) in Verilog don't need to be constants.

In other respects, yes, they're similar....

OK, I concede.

with different names and different semantics :-)

--
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.

Personally, I'd rather read 'and' than '&'. The old Ada argument is that code is read far more often than it is written. I guess that's why Ada-inspired VHDL ended up as it did. IMHO the world needs both, Verilog for hacking together things at low-level very quickly and easily, VHDL for larger projects, particularly those being written by a large team. There's also plenty of room for personal preference of course...

-- Peter

I will agree that bad synthesis prevent abstract use, and that given enough time a human can normally find a better solution. On the otherhand, large designs, and fixed market windows, force tradeoffs. And as the complexity of designs grow to take advantage of FPGAs which grow in size with Moore's Law, we probably are not going to see either the number of skilled FPGA hackers (err hardware designers) salary shrink to maintain the same costs or see market windows increasing in length with Moore's Law. So that says, the tools must improve, as must the coding efficiency of hardware hackers.

I love people quoting other failures as proof of impossibiity.

I'm sure the experience set in this forum is rife with examples of designs that "would never happen", because a few teams failed, and over time other people learn new skills, tricks, tools and find the solutions to previously difficult problems. It wasn't that long ago that the DEC systems engineers defended writing in assembly long after the industry moved past that poor practice. Of course, the industry moved past DEC too. And a couple of my "favorite" hardware companies that swore large TTL design where cheaper, that have long since bit the dust too.

it's not prime time yet, still has about two more major changes to be release as Beta's this year. There hasn't been a need yet for an FAQ, but everything else in your list is in the Source Forge archive in all the expected spots.

and the current development snapshot gets checked into the publicly accessable svn archive as changes are integrated into the main development tree, including doc updates. I have my own development tree of major hacks and work in progress ideas, that get pushed up to the svn archive as they are nearing a point in development that they ready for others to play with.

As a work in progress, it's certainly far from complete today, and probaby would have been a lot farther complete, except for the drowning death of my 11 year old daughter at a friends house in May. As close as I can tell, there are a good few using it, from the periodic emails. Mostly students that are comfortable with the work in progress state of the project, and are willing to spend a small amount of time to hack the tools into a working state for their development environment.

Clean, plug and play release which are married well to Altera and Xilinx tools, will probably not happen till Beta-4 around Christmas. At which point FpgaC will go pretty close to production, with some maturity and ease of use work.

Even for these operators, the usage semantics (as you know) are very different from C's. Sections 4.4/4.5 of the LRM are fantastically complicated (to me, anyway). To quote Steven Sharp from an old c.l.v post on the subject: "I agree that this is not intuitive to someone used to most other programming languages". Too right.

Damn... I was going to say that :-)

That reminds me. C++ has 'and', 'or', 'xor', and 'not' operators. Now, this could just be a bizarre coincidence, but I think not. A more reasonable explanation, I contend, is that Mr. Stroustrup actually based C++ on VHDL.

Evan

Certainly not ... as one expression per post can be horribly boring :(

Ummm ... Why is that construct difficult for C?

Something that makes switch statements "interesting" for FpgaC at the moment because of the current "one-hot" notion about flow control. That abstraction however, isn't pure, and will certainly get less pure soon, when switch/case/break/continue are implemented using a mapped set of enables (rather than a pure mux tree).

Historically, in the evolution of languages, C defined a number of departures in syntax that have been adopted in new languages rather than the more verbose 1970's styles found in Pascal, ADA, PL/1 predicessors.

Hmm ... C++ was presented initially released as part of the programmers workbench sometime in the spring of 1975 if I remember right. Verilog was a decade later in 1985. When was VHDL?

hmm ... so much for memory ... googling seems place it early 1980's too.

[bitwise logic]

We must be grateful for small mercies. At least it's written down in the LRM now. Until V-2001, the only place to go for real understanding of Verilog's bit width rules was Steven Sharp's consistently informative and precise postings on c.l.v.

And don't even ask about short-circuit evaluation of boolean expressions... another non-similarity between C and Verilog.

--
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.

[C++]

I had understood that Stroustrup was working on "C with Classes" (using a preprocessor to map from CwC to pure C) from around 1978. Methinks Evan was being whimsical about VHDL...

-- 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 snipped-for-privacy@MYCOMPANY.com

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