Design Notation VHDL or Verilog?

VHDL

Yes, *both* languages have comments!

Traditionally, VHDL uses two dashes (--) to signify comments. The newer-fangled VHDL-2008 syntax also allows the use of C-style multi-line comments enclosed in /* */ pairs.

As in so many other ways, Verilog uses c style syntax - both /* */ and // are valid.

Does that help?

Cheers, Martin

Can't comment on VHDL other than to say it always strikes me as difficult to decipher and untidy looking. I'd be interested to know if there's anything useful that you can do in VHDL that you can't in Verilog.

I'm a Verilog user and like the straight-forward syntax. Like anything you can make a mess if you don't try hard enough not to.

A competent designer could use either to implement a digital logic system.

--------------------------------------- Posted through

With the 2008 fixed point package, VHDL allows synthesizable fixed point arithmetic of arbitrary precision and binary point location. The arithmetic operators and types are defined to automatically handle mixed precision/point arithmetic for you. To the best of my knowledge, the Verilog language in its current form cannot support this capability at all.

Similarly, VHDL also has a floating point package that handles arbitrary sizes of data and exponent.

The fixed and floating point packages were demonstrated prior to 2008 with no changes to the language required (that's the power of VHDL types and overloading), and the only 2008 features that the current packages use are package generics, to allow user specification of operator behaviors for rounding, saturation, guard bits, etc. This highlights VHDL's inherent extensible capabilities that are completely lacking in Verilog.

If all you use is std_logic, std_logic_vector, or arrays of same, there is negligible advantage to using VHDL over verilog. It is at higher levels of abstraction, where design productivity is maximized, that VHDL shines.

Untidy is in the eye of the beholder.

Andy

Andy wrote: (snip)

(snip)

An interesting idea, but note that, as far as I know, no computer hardware has support for this, so it seems strange that an HDL would need it.

Yes you can do fixed point with different positions of the radix point, PL/I and a small number of other languages do, but on hardware that doesn't keep track of the radix point.

For multiply, you do need to keep all the product digits, so that you can select the right ones based on the position of the product radix point.

And that is synthesizable by anyone?

I suppose higher level of abstraction is nice, but does it really help design real systems?

And maybe a slight disadvantage. It is a lot wordier to say the same thing, more places to get it wrong.

Probaby depends on what kind of systems you design.

Is it easier to design something like a pentium with a language that has support for floating point? For real floating point systems, it is usual to actually design the logic in the HDL.

-- glen

Whaaaatttt??? What does your computer capabilities have to do with your ASIC/FPGA designs? Mixed precision/radix point arithmetic can be very useful in an HDL design. If you are just passing data and controlling timing then maybe not. But signal processing often has to deal with the results of varying precision in operations.

You seem to be thinking only of CPU designs. HDL is used for a lot more than CPU designs.

Actually you need to keep the bits that are important to your application. That will vary.

I haven't looked at the floating point package, but if it is described in terms of basic operators in VHDL it should be synthesizable in every tool. That is the point of overloading. You can define a multiply operator for real data in terms of the basic building blocks and this is now a part of the language. VHDL is extensible that way.

Not if you refuse to consider it.

Yes, VHDL is definitely wordier. But then I never use std_logic_vector or std_logic. I use signed and unsigned which provide so much more functionality... also provided by the extensibility of VHDL I believe.

You seem to be very CPU focused. For every Pentium type design done in HDL there are what, thousands of other designs?

Rick

(snip, someone wrote)

(snip, I wrote)

If it is useful in ASIC/FPGA designs, wouldn't it also be even more useful in software running on commonly (or not so commonly) available processors? Yet none have bothered to implement it.

It could be done in software, but none of the popular languages have any support for fixed point non-integer arithmetic.

It was one of the fun things I did in PL/I so many years ago, though.

Well, more than CPU designs, I work on systolic arrays, but even there so, it doesn't seem likely to help much. Will it generate pipelined arithmetic units? Of all the things that I have to think about in logic design, the position of the binary point is one of the smallest.

And I don't expect the processor to help me figure out which ones those are.

Again, does it synthesize pipelined arithmetic units? If not, then they aren't much use to anything I would work on. If I do it in an FPGA that is because normal processors aren't fast enough.

But the big problem with floating point is that it takes too much logic. The barrel shifter for pre/post normalization for an adder is huge. (The actual addition, not so huge.)

(snip)

(snip)

Well, it was supposed to be an example....

-- glen

IMHO Verilog is about describing hardware and VHDL is about describing what it should do. VHDL has been good to me but it did take reading some books and experimenting for me to unleash its real power. If you overcome the stage where you describe hardware (thinking in 74' logic chips) and start describing what a piece of logic should do you can do a lot with just a few lines of VHDL by using functions, records, etc.

Glen,

The point of optimizing HW arithmetic to the task at hand is that avoiding excess precision saves resources (= $).

In SW, running on a majority of platforms that support double precision floating point (already paid for whether it is used or not) there is no incentive to optimize, so few computer programming languages support it. Many older programming languages, conceived before HW floating point support was ubiquitous, supported fixed point arithmetic because the SW could be optimized to provide only the precision required, thus consuming only the CPU cycles required.

CPUs have to be optimized for the universe of applications that may be run on them, so the flexibility of floating point is worth the cost, especially because only one or two floating point ALUs are typically required by a CPU core.

Most ASIC/FPGA designs are much more task specific, and do not need the flexibility of floating point, especially when considering how many arithmetic units (multiply/add) may be employed by a typical design, and thus how many times one would have to pay for the resources consumed by that unneeded flexibility.

Sure, you can design fixed point arithmetic HW in verilog, but you have to keep track of the binary point yourself, with no help from the compiler. These VHDL packages allow you to define the width and binary point at critical stages, and the compiler takes care of the rest.

Most synthesis tools support retiming, which can be used to pipeline arithmetic operators over a limited number of clock cycles by simply inserting empty clock cycles in RTL before or after the operator, and letting the retiming spread out the operator logic into those clock cycles. With most modern FPGA families, multiplies and multiply/adds are implemented using available DSP blocks anyway, so intra-operator pipelining is not often needed uness you have a really wide data path. And of course, just like verilog, you are in charge of pipelining multiple operations by the way you describe the behavior (number of clock cycles it takes to get from input to output). Note that I use the term clock cycles as opposed to registers. It's an abstraction...

And yes, both the floating and fixed point packages are completely synthesizable.

Andy

It depends of the Verilog version in question and the type of design. SystemVerilog has a much higher level of abstraction when it comes to verification and testbench code. Especially when using libraries like UVM etc.

//Petter

I don't really follow your reasoning here. The idea of the fixed point package is to allow a user to work with fixed point values in VHDL without having to manually deal with all the details. You seem to be saying that fixed point arithmetic is of no value because it is not implemented in software. I don't see how software has anything to do with it. Software is implemented on programmable hardware and for the most part is designed for the most common platforms and does not do a good job of utilizing unusual hardware effectively. I don't see how fixed point arithmetic would be of any value on conventional integer oriented hardware.

Asking about pipelining with fixed point numbers is like asking if boxes help your car. Sure, if you want to carry oranges in a car you can use boxes, but you don't have to. If your systolic arrays use fixed point arithmetic then the fixed point package will help your systolic arrays. If you don't care about the precision of your calculations then don't bother using the fixed point package.

What processor? You have lost me here. A multiply provides a result with as many bits as the sum of the bits in the inputs. But this many bits are seldom needed. The fixed point package makes it a little easier to work with the variety of formats that typically are used in a case like this. No, the package does not figure out what you want to do. You have to know that, but it does help hide some of the details.

Nope, the fixed point package does not design pipelines, it isn't a pipeline package. Yup, the barrel shifter is as large as a multiplier. So what is your point? The purpose of the package is to allow you to design floating point arithmetic without designing all the details of the logic. It isn't going to reduce the size of the logic.

An example of what? The fact that you can't find the utility of the fixed point package does not mean it is not useful. I really don't see your points.

Rick

AFAIK, the synthesizable subset of SV is pretty much plane old verilog, with all its warts.

For verification, SV is indeed really nice. However, a new open source VHDL Verification Methodology (VVM) library of VHDL packages has emerged that provides VHDL with some of the capabilities of SV with OVM/UVM.

Andy

(snip, I wrote)

The suggestion, which could be wrong, was that if scaled fixed point is useful in an HDL, it should also be useful in non-HDL applications.

The designers of PL/I believed that it would be, but designers of other languages don't seem to have believed in it enough to include. Personally, I liked PL/I 40 years ago, and believe that it should have done better than it did, and scaled fixed point was a feature that I liked to use.

Well, the designers of conventional hardware might argue that they support scaled fixed point as long as you keep track of the radix point yourself. It is, then, up to software to make it easier for programmers by helping them keep track of the radix point.

I believe that in addition to PL/I that there are some other less commonly used languages, maybe ADA, that support it.

It can be done in languages like Pascal and C, TeX and Metafont do it. Multiplication is complicated, though, because most HLL's don't supply the high half of the product in multiply, or allow a double length dividend in division. Knuth wrote the Pascal routines for TeX and MF to do it, and suggests that implementations rewrite them in assembler for higher performance.

In the past, the tools would not synthesize division with a non-constant divisor. If you generate the division logic yourself, you can add in any pipelining needed. (I did one once, and not for a systolic array.) With the hardware block multipliers in many FPGAs, it may not be necessary to generate pipelined multipliers, but many will want pipelined divide.

(snip)

Yes, multiply generates a wide product, and most processors with a multiply instruction supply all the bits. But most HLLs don't provide a way to get those bits. For scaled fixed point, you shift as appropriate to get the needed product bits out.

The point I didn't make very well was that floating point is still not very usable in FPGA designs, as it is still too big. If a design can be pipelined, then it has a chance to be fast enough to be useful.

Historically, FPGA based hardware to accelerate scientific programming has not done very well in the marketplace. People keep trying, though, and I would like to see someone succeed.

-- glen

Nope. SV synthesis is quite powerful. Arrays, and structs are first class citizens in SV and can be members of ports. Further most tools handle interfaces now pretty well in synthesis. There's quite a benefit to using these in your RTL.

Trying to resist making this a language war, but I see little advantage one or the other with regard to a "higher level of abstraction". You can probably achieve the same with either language.

--Mark

It is very useful in some applications, for example in DSP processing. There are DSP processors that support fixed point arithmetic. Also many "fixed" FPGA based DSP algorithms use different resolution fixed point numbers all around. Standard package to help that kind of design is very welcome. Previously they have been proprietary packages.

Floating point might be too heavy in many applications, but on the other hand if the number range and operators are limited to what is needed it is not that big anymore, when comparing to the leading edge FPGA sizes. For example leading edge FPGA can support ~2000 single precision floating point multipliers.

You are fixed to quite narrow band of FPGA applications. FPGAs are almost everywhere, for example they are very popular in mobile network basestations. And also telecom equipment use some forms of floating/fixed point arithmetic often in policing and shaping for example.

--Kim

I have no idea what bearing a forty year old computer language has to do with this issue.

Again, I don't know why you are dragging high level languages into this. What HLLs do has nothing to do with the utility of features of HDLs.

re

Oh, I see why you are talking about pipelining now. I don't think the package provides pipelining. But that does not eliminate the utility of the package. It may not be useful to you if it isn't pipelined, but many other apps can use non-pipelined arithmetic just fine.

lt

I have no interest in what HLLs do. I use HDLs to design hardware and I determine how the HDL shifts or rounds or whatever it is that I need.

ed

ay.

c.

to

Whether floating point is too big depends on your app. Pipelining does not reduce the size of a design and can only be used in apps that can tolerate the pipeline latency. You speak as if your needs are the same as everyone else's.

Scientific programming is not the only app for FPGAs and fixed or floating point arithmetic. Fixed point arithmetic is widely used in signal processing apps and floating point is often used when fixed point is too limiting.

Rick

On Feb 1, 11:38=A0am, snipped-for-privacy@sonic.net (Mark Curry) wrote:>

class

ing

an

Mark,

Sounds like SV synthesis has improved quite a bit, which is good to know, and good for the industry. Which tools support these features (I assume at least Synplify)? As soon as someone standardizes a library to do fixed point in SV, then it will be able to do what VHDL does :)

I'm not that familiar with SV or SV interfaces in particular. There's one thing I wish VHDL would do, and that is allow an interface (a record port with different directionality associated with each element of the record) on a component/entity/subprogram.

From the abstraction point of view, I think you are right, SV and VHDL synthesis are pretty close, with specific features being edges in each's favor.

However, I (and I believe the OP) was not considering SV as just a version of verilog though. Perhaps that is something that is beginning to change (the realization that there is another viable choice besides vanilla verilog and vhdl for synthesis.)

Andy

I've used Mentor Precision (for FPGAs), and am currently eval'ing Synplify. Synopsys has supported SV for a while now for ASICs.

I've followed this thread some with some confusion as to what this "fixed point library" is and/or does. I do all kinds of DSP math apps in verilog, with variable precision. Yes, you need to pay attention scaling along the data path. I'm unsure how a library can really help this.

Although I tend to want to be very precise - drawing out my data path with all truncation/rounding/etc specifically called out. I suppose if some library somehow standardized this... Hmm, need to think about it. Can't see how it'd offer much benefit.

--Mark