nico@puntnl.niks (Nico Coesel) writes:

>>be the case in more recent versions. Also you'll miss the compile
>>static check of only one driving the signal.
>
> 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

-- 
.sig removed by request. 

Petter Gustad <newsmailcomp6@gustad.com> wrote:

>nico@puntnl.niks (Nico Coesel) writes:
>
>> Petter Gustad <newsmailcomp6@gustad.com> wrote:
>>
>>>nico@puntnl.niks (Nico Coesel) writes:
>>>
>>>>>There are several nice features like interfaces (which are
>>>>>bi-directional unlike record bundles in VHDL). There's also enum's,
>>>>
>>>> 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.
>>
>> Just declare the port as inout. Its simple as that.
>
>be the case in more recent versions. Also you'll miss the compile
>static check of only one driving the signal.

The synthesizer will most likely complain about that.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

nico@puntnl.niks (Nico Coesel) writes:

> Petter Gustad <newsmailcomp6@gustad.com> wrote:
>
>>nico@puntnl.niks (Nico Coesel) writes:
>>
>>>>There are several nice features like interfaces (which are
>>>>bi-directional unlike record bundles in VHDL). There's also enum's,
>>>
>>> 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.
>
> Just declare the port as inout. Its simple as that.

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


-- 
.sig removed by request. 

On Feb 9, 3:32=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
> Andy <jonesa...@comcast.net> wrote:
> >On Feb 7, 3:14=3DA0pm, n...@puntnl.niks (Nico Coesel) wrote:
> >> 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).
>
> 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.
>
> >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.
>
> 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.
>
> --
> Failure does not prove something is impossible, failure simply
> indicates you are not using the right tools...
> nico@nctdevpuntnl (punt=3D.)
> --------------------------------------------------------------

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

Andy <jonesandy@comcast.net> wrote:

>On Feb 7, 3:14=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
>> 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).

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.

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

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.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

On Feb 7, 3:14=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
> 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

Andy <jonesandy@comcast.net> wrote:

>On Feb 3, 5:43=A0am, n...@puntnl.niks (Nico Coesel) wrote:
>> Record bundles can be bi-directional in VHDL!
>
>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.

I never had that problem when synthesizing for Xilinx devices.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

On Feb 3, 4:37=A0am, Petter Gustad <newsmailco...@gustad.com> wrote:
> Andy <jonesa...@comcast.net> writes:
> > 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.
>
> 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.

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

Andy

On Feb 3, 5:43=A0am, n...@puntnl.niks (Nico Coesel) wrote:
> Record bundles can be bi-directional in VHDL!

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

glen herrmannsfeldt wrote:
[snip]
> As far as I know, currently if something can be done either with
> an FPGA or a small microcontroller, or even DSP processor,
> the choice is often for the processor. With the price of smaller
> FPGAs coming down, that might change, but also there are more
> people who know how to program such processors than HDL design.
> 
> Given that, I would expect some overlap between FPGA/HDL
> applications and processor/software applications, depending
> on the speed required at the time. Some applications might 
> initially be developed in software, debugged and tested, before
> moving to an FPGA/HDL implementation. 
> 
> Maybe the question isn't whether scaled fixed point is useful
> in HDL, but why isn't it useful, enough that people ask for
> it in an HLL, in software! Why no scaled fixed point datatype
> in C or Java? 

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