Design Notation VHDL or Verilog?

There are several nice features like interfaces (which are bi-directional unlike record bundles in VHDL). There's also enum's, always_comb, always_ff, always_latch to tell the synthesis tool what you're trying to do, $left, $right, etc. similar to 'left, 'right in VHDL.

I took a link at some of the links posted here previously, it looks nice and it's an improvement. But as far as I could tell it lacked polymorphism and inheritance. However, I have to study VVM further.

//Petter

Quite a few tools actually. DC, Synplify, and Quartus has pretty good SV support. XST does not, but hopefully that will change with Rodin¹.

//Petter ¹

Record bundles can be bi-directional in VHDL!

That's great news as I've always used one record type as input and another one as output. Care to share some examples? And how do you swap them like you do with modports in SV.

//Petter

Just declare the port as inout. Its simple as that.

glen herrmannsfeldt wrote: [snip]

You may as well ask why we're not using slide rules instead of calculators. Once you have floating point arithmetic with reasonable performance, fixed-point becomes of little value. If you really want to keep track of your binary point instead of letting the floating point package do it for you, you can always use integer types. Anyone who has worked on fixed point FFT logic knows just what a pain it can be to keep track of scaling. I don't know many C or Java programmers willing to take on that task. At my company, the only person who ever wrote fixed point code for processing had a background in microcoding and his whole job was just to create accellerated image processing libraries.

Obviously for hardware floating point is a huge resource hog, but when you're using a microprocessor that already has it built in there's no big incentive not to use it.

-- Gabor

That's the problem; every element of a VHDL bidirectional record port is bidirectional. You have to use resolved types for each element, and remember to assign benign driven values to elements you want to be input only. It can be done, but it gets ugly.

Sometimes (especially testbenches) it is worth the work, but it would be worth even more to be able to define custom record modes for record port types (e.g. master, slave, observer, etc modes for a record port representing a bus interface, each defining different individual in/ out/inout/etc modes on individual record elements).

Andy

Actually, being built around VHDL protected types, it has some amount of both. Not nearly as clean or capable as SV though.

Andy

I never had that problem when synthesizing for Xilinx devices.

Did you simulate your RTL using bidirectional ports? That's where the default driver problem arises, on inout ports that are only read (from the inside).

Synthesis can take a lot of liberty with your RTL description because of the static nature of the analysis of the code, and the fact that unknowns are don't cares in synthesis, which means the synthesis tool can do as it pleases, which is usually what pleases the most customers most of the time.

Andy

I didn't simulate that particular code. It was back in the days that simulation software wasn't available if you wanted to keep your arms and legs.

AFAIK: for RTL to synthesize each signal needs one driver. Even if it would drive the signal tristate. It probably depends on the tools. My experience is limited to Xilinx.

Most synthesis tools will convert multiple tri-state drivers on a signal into multiplexers, since most FPGAs do not support internal tri- state busses any more. They assume that the various tri-state enables are mutually exlusive (how else would the tri-state bus have worked?), so a prioritlyless multiplexer is constructed. This can be a handy way of specifying a distributed priorityless mux.

Most synthesis tools will convert default 'U' drivers to "undriven" (nothing), which is different behavior from the SL resolution function in simulation (they issue a warning about that).

Andy

That might cause some problems. I've seen some tool which did not like inouts other than at the top level (can't remember which, it might have been some LSI or IBM tool). This is many years ago and might not be the case in more recent versions. Also you'll miss the compile static check of only one driving the signal.

//Petter

The synthesizer will most likely complain about that.

I was thinking about simulator compile checks. Which typically can be checked quickly, e.g. can be done from the editor and prior to revision control commits etc. Synthesis usually takes longer.

//Petter