FPGARelated.com
Forums

Design Notation VHDL or Verilog?

Started by vsh January 28, 2012
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 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 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
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.
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:

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