So, they started synthesizing shared variables?

[Tricky]

Ive always been told categorically that "Shared variables cannot be
synthesized, Use signals for communication between processes"

But now it appears at least Quartus does. I have infered a ram using
one, plus also this interesting setup.

shared variable C : std_logic;

begin

process(clk)
begin
if rising_edge(clk) then
C := data_a;
end if;
end process;

process(clk)
begin
if rising_edge(clk) then
--c := data_b;

q_b <= C;
end if;
end process;

From synthesis, this gives me 2 registers, source from data_a. If I
uncomment the C assignment in the 2nd process, I only get 1 register
driven from data_b, with no warning about multiple constant drivers,
like you would if C was a signal.

So, is this an interesting and potentially dangerous precident Altera
are setting, or is this happening with other synthesisors too? would
shared variables actually have any use anywhere?

 

[Jonathan Bromley]

On Wed, 3 Jun 2009 01:17:15 -0700 (PDT), Tricky wrote:

Ive always been told categorically that "Shared variables cannot be
synthesized, Use signals for communication between processes"

yeah, I thought that too...

But now it appears at least Quartus does. I have infered a ram using
one,

I speculate that it's RAM inference that led them to support
shared variables. It provides a straightforward way to do
dual-port RAM with read-before-write, which is otherwise
rather hard to do in VHDL.

plus also this interesting setup.
[...]

Yes, I first saw this (unnecessary) use of shared
variables at a customer where I was doing some
design work - I nearly spilt my coffee over the
keyboard

So, is this an interesting and potentially dangerous precident Altera
are setting

I think it is, yes.

Unfortunately it's a precedent that has *already* been set
by Verilog, where shared variables are a (largely undesirable)
fact of life. So it is not a big step for a synthesis tool.
But it is a sure-fire way for VHDL programmers to get all
the same dreadful race conditions that plague careless
Verilog users.

Note that this form of shared variable is, properly speaking,
illegal now in VHDL; you should be using protected types.
However, all tools still support the VHDL-93 hooligan form
of shared variable (equivalent to Verilog's shared variables
using blocking assignment).

shared variables actually have any use anywhere?

To the best of my understanding, their only use in synthesisable
code would be the modeling of dual-port RAM with different write
clocks on the two ports. They have many interesting uses
in testbenches, of course.
--
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.

 

[Dave Farrance]

Tricky <Trickyhead@gmail.com> wrote:

Ive always been told categorically that "Shared variables cannot be
synthesized, Use signals for communication between processes"

But now it appears at least Quartus does. I have infered a ram using
one, plus also this interesting setup.
...

Maybe the synthesiser has grouped the processes together because they are
both triggered on the same rising_edge(clk), making C absorb unambiguously
into q_b? I don't know how other synthesisers would handle it.

--
Dave Farrance

 

[Dave Farrance]

Tricky <Trickyhead@gmail.com> wrote:

If it did that then the same would apply if C was a signal - when C is
declared as a signal, it throws an error saying multiple constant
drivers on C. If it combined the 2 processes, it wouldnt complain and
just take the last assignment to C.

I see. The shared variable assignments are computed sequentially within
the scope of the shared variable, so I guess that the behaviour that you
describe would be correct for simulation. I agree that allowing
synthesis, just because it can in this case, is very questionable.

--
Dave Farrance

 

[Tricky]

On 3 June, 10:56, Dave Farrance
<DaveFarra...@OMiTTHiSyahooANDTHiS.co.uk> wrote:

Tricky <Trickyh...@gmail.com> wrote:
Ive always been told categorically that "Shared variables cannot be
synthesized, Use signals for communication between processes"

But now it appears at least Quartus does. I have infered a ram using
one, plus also this interesting setup.
...

Maybe the synthesiser has grouped the processes together because they are
both triggered on the same rising_edge(clk), making C absorb unambiguously
into q_b?  I don't know how other synthesisers would handle it.

--
Dave Farrance

If it did that then the same would apply if C was a signal - when C is
declared as a signal, it throws an error saying multiple constant
drivers on C. If it combined the 2 processes, it wouldnt complain and
just take the last assignment to C.

 

[Dave Farrance]

Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk> wrote:

I see. The shared variable assignments are computed sequentially within
the scope of the shared variable, so I guess that the behaviour that you
describe would be correct for simulation.

Ah. I see that the Std 1076-1993 spec says it's not. Para 225: "... A
description is erroneous if it depends on whether or how an implementation
sequentializes access to shared variables."

--
Dave Farrance

 

[HT-Lab]

On Jun 3, 9:17 am, Tricky <Trickyh...@gmail.com> wrote:

"Tricky" <Trickyhead@gmail.com> wrote in message
news:d3545c34-d074-41b5-
b565-71da45810fae@j32g2000yqh.googlegroups.com...

Ive always been told categorically that "Shared variables cannot be
synthesized, Use signals for communication between processes"

But now it appears at least Quartus does.

Precision seems to support it as well although it does give a warning:

[43156]: Shared variables must be of a protected type.

It gives the same results as you describe below.

Hans
www.ht-lab.com

I have infered a ram using
one, plus also this interesting setup.

shared variable C : std_logic;

begin

process(clk)
begin
if rising_edge(clk) then
C := data_a;
end if;
end process;

process(clk)
begin
if rising_edge(clk) then
--c := data_b;

q_b <= C;
end if;
end process;

From synthesis, this gives me 2 registers, source from data_a. If I
uncomment the C assignment in the 2nd process, I only get 1 register
driven from data_b, with no warning about multiple constant drivers,
like you would if C was a signal.

So, is this an interesting and potentially dangerous precident Altera
are setting, or is this happening with other synthesisors too? would
shared variables actually have any use anywhere?

 

[Mike Treseler]

HT-Lab wrote:

Precision seems to support it as well although it does give a warning:
[43156]: Shared variables must be of a protected type.
It gives the same results as you describe below.

It might be possible to rewrite Tricky's
model using protected types.
That would eliminate the modelsim warnings,
but I don't know if quartus and precision
would still buy it.


-- Mike Treseler

 

[Jonathan Bromley]

On Wed, 03 Jun 2009 09:26:30 -0700, Mike Treseler
<mtreseler@gmail.com> wrote:

HT-Lab wrote:

Precision seems to support it as well although it does give a warning:
[43156]: Shared variables must be of a protected type.
It gives the same results as you describe below.

It might be possible to rewrite Tricky's
model using protected types.
That would eliminate the modelsim warnings,
but I don't know if quartus and precision
would still buy it.

I'm not entirely sure I understand what a protected
type method would look like in hardware, but I'm
happy to be educated if anyone can explain.

Note that some simulators are not yet supporting
VHDL protected types, so you need to be a little
circumspect when using shared variables.
--
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.

 

[Mike Treseler]

Jonathan Bromley wrote:

I'm not entirely sure I understand what a protected
type method would look like in hardware, but I'm
happy to be educated if anyone can explain.

It is not necessary to employ a shared variable
for a single port ram because a plain variable works fine.
http://mysite.verizon.net/miketreseler/block_ram.vhd
For a dual-port ram, two processes are needed to match
the given hardware.

I would declare the protected types/bodies in architecture
scope, rather than in a package, so that the procedures
have full access to the shared array.

-- Mike Treseler

 

[Matthew Hicks]

Unfortunately it's a precedent that has *already* been set
by Verilog, where shared variables are a (largely undesirable)
fact of life. So it is not a big step for a synthesis tool.
But it is a sure-fire way for VHDL programmers to get all
the same dreadful race conditions that plague careless
Verilog users.
Note that this form of shared variable is, properly speaking,
illegal now in VHDL; you should be using protected types.
However, all tools still support the VHDL-93 hooligan form
of shared variable (equivalent to Verilog's shared variables
using blocking assignment).

In my verilog experience, no synthesizer will allow the type of behavior
you speak of. Can you give me an example that is synthesizable?

By the way, if you look at the synthesis standards for VHDL (IEEE 1076.6-2004)
it clearly says shared variables aren't supported. So a designer shouldn't
be using them even if tool support is there.

---Matthew Hicks

 

[Jonathan Bromley]

On Wed, 3 Jun 2009 21:26:06 +0000 (UTC), Matthew Hicks wrote:

However, all tools still support the VHDL-93 hooligan form
of shared variable (equivalent to Verilog's shared variables
using blocking assignment).

In my verilog experience, no synthesizer will allow the type of behavior
you speak of.

My bad; when I said "all tools" I intended to say "all simulators".
Apologies.

Can you give me an example that is synthesizable?

I agree that Verilog variables *written by more than one process*
are not generally synthesizable. However, synthesis tools DO
support this (very, very bad) Verilog:

reg q; // shared variable, because it's written by = assignment
reg r; // like a VHDL signal, because written by <=

always @(posedge clock)
q = d;

always @(posedge clock)
r <= q; // read/write race on q because it's a shared var

Of course, sensible Verilog users would immediately point out
that I should have used <= assignment to q. But the fact remains
that synthesis tools support what I wrote above, giving rise to
sim/synth mismatch just as you would get with a VHDL shared variable.

By the way, if you look at the synthesis standards for VHDL (IEEE 1076.6-2004)
it clearly says shared variables aren't supported. So a designer shouldn't
be using them even if tool support is there.

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

 

[HT-Lab]

"Tricky" <Trickyhead@gmail.com> wrote in message
news:924f64a6-74e4-44ec-b6f6-fa99e41cfe7a@q16g2000yqg.googlegroups.com...

On 3 June, 17:36, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:
On Wed, 03 Jun 2009 09:26:30 -0700, Mike Treseler

mtrese...@gmail.com> wrote:
HT-Lab wrote:

Precision seems to support it as well although it does give a warning:
[43156]: Shared variables must be of a protected type.
It gives the same results as you describe below.

It might be possible to rewrite Tricky's
model using protected types.
That would eliminate the modelsim warnings,
but I don't know if quartus and precision
would still buy it.

I'm not entirely sure I understand what a protected
type method would look like in hardware, but I'm
happy to be educated if anyone can explain.

Note that some simulators are not yet supporting
VHDL protected types, so you need to be a little
circumspect when using shared variables.
--
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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

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

Having a quick play, Quartus doesnt even want to know about protected
types, so I assume they havent gone beyond VHDL 93 (93/87 are the only
two settings). But what was iteresting was it said it was expecting
other stuff, including access, instead of protected.

So I tried infering a ram via an access type and shared variable.
Quartus just ploughed on, didnt throw a warning about access, but
seemed to ignore that it existed (therefore, just assumed everything
was connected to thin air - not really a surprise). Not even a warning
saying access types are not synthesizable.

Heres what I tried to synthesize(be interesting to see what other
synth tools do):

Not much luck in Precision either...

[40000]: vhdlorder, Release 2009a.15
[40000]: Files sorted successfully.
[40000]: hdl-analyze, Release RTLC-Precision 2009a.15
[42502]: Analyzing input file "D:/test/shared_var/test2.vhd" ...
[43156]: Shared variables must be of a protected type.
[651]: Top module of the design is set to: test_build.
[649]: Current working directory: <...>/shared_var/project_2_impl_1.
[40000]: RTLC-Driver, Release RTLC-Precision 2009a.15
[40000]: Last compiled on Mar 18 2009 18:40:36
[44512]: Initializing...
[44504]: Partitioning design ....
[40000]: RTLCompiler, Release RTLC-Precision 2009a.15
[40000]: Last compiled on Mar 18 2009 19:20:03
[44512]: Initializing...
[44522]: Root Module work.test_build(syn): Pre-processing...
[45258]: Object ram is of Non-Rtl type ram_t_p. Declaration wont be
compiled.
[46831]: Object ram of Non-Rtl type ram_t_p not handled. Continuing ...
[46292]: Module work.test_build(syn) cannot be compiled because it contains
non-rtl constructs. Please check the log for warnings or errors about
non-synthesizable constructs in this module.
[44536]: No modules were compiled in this run of RTLC, please check the logs
for blackboxes or non-rtl constructs in the design.
[44856]: Total lines of RTL compiled: 68.
[47002]: RTLCompiler error... aborting compilation.
[44513]: Overall running time 3.0 secs.
[46259]: Design compilation failed, unsupported or non-rtl constructs
detected in the following modules :
[40000]: work.test_build(syn)
[40000]: Please check the log for details pertaining to unsupported or
non-rtl construct(s)
[666]: Unable to elaborate design work.test_build in vhdl.

Hans
www.ht-lab.com

 

[Tricky]

On 3 June, 17:36, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Wed, 03 Jun 2009 09:26:30 -0700, Mike Treseler

mtrese...@gmail.com> wrote:
HT-Lab wrote:

Precision seems to support it as well although it does give a warning:
[43156]: Shared variables must be of a protected type.
It gives the same results as you describe below.

It might be possible to rewrite Tricky's
model using protected types.
That would eliminate the modelsim warnings,
but I don't know if quartus and precision
would still buy it.

I'm not entirely sure I understand what a protected
type method would look like in hardware, but I'm
happy to be educated if anyone can explain.

Note that some simulators are not yet supporting
VHDL protected types, so you need to be a little
circumspect when using shared variables.
--
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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

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

Having a quick play, Quartus doesnt even want to know about protected
types, so I assume they havent gone beyond VHDL 93 (93/87 are the only
two settings). But what was iteresting was it said it was expecting
other stuff, including access, instead of protected.

So I tried infering a ram via an access type and shared variable.
Quartus just ploughed on, didnt throw a warning about access, but
seemed to ignore that it existed (therefore, just assumed everything
was connected to thin air - not really a surprise). Not even a warning
saying access types are not synthesizable.

Heres what I tried to synthesize(be interesting to see what other
synth tools do):

entity test_build is
port(

clk : in std_logic;

addr_a : in natural range 0 to 127;
addr_b : in natural range 0 to 127;

data_a : in std_logic_vector(7 downto 0);
q_b : out std_logic_vector(7 downto 0)


);
end entity test_build;

architecture syn of test_build is

type ram_t;
type ram_t_p is access ram_t;

type ram_t is array(0 to 127) of std_logic_vector(7 downto 0);


--type ram_t is protected
-- function read(a : natural) return std_logic_vector;
-- procedure write(a : natural; d : std_logic_vector);
--end protected type ram_t;
--
--type ram_t is protected body
-- type ram_array_t is array(0 to 127) of std_logic_vector(7 downto
0);
-- variable ram_array : ram_array_t;
--
-- function read(a : natural) return std_logic_vector is
-- begin
-- return ram_array(a);
-- end function read;
--
-- procedure write(a : natural; d : std_logic_vector) is
-- begin
-- ram_array(a) := d;
-- end procedure write;
--
--end protected type ram_t;

shared variable ram : ram_t_p := new ram_t;



signal addr_b_r : natural range 0 to 127;

begin


process(clk)
begin
if rising_edge(clk) then
ram(addr_a) := data_a;
end if;
end process;

process(clk)
begin
if rising_edge(clk) then
addr_b_r <= addr_b;
end if;
end process;


q_b <= ram(addr_b_r);

end architecture syn;

 

[Tricky]

On 4 June, 12:00, "HT-Lab" <han...@ht-lab.com> wrote:

"Tricky" <Trickyh...@gmail.com> wrote in message

news:924f64a6-74e4-44ec-b6f6-fa99e41cfe7a@q16g2000yqg.googlegroups.com...



On 3 June, 17:36, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:
On Wed, 03 Jun 2009 09:26:30 -0700, Mike Treseler

mtrese...@gmail.com> wrote:
HT-Lab wrote:

Precision seems to support it as well although it does give a warning:
[43156]: Shared variables must be of a protected type.
It gives the same results as you describe below.

It might be possible to rewrite Tricky's
model using protected types.
That would eliminate the modelsim warnings,
but I don't know if quartus and precision
would still buy it.

I'm not entirely sure I understand what a protected
type method would look like in hardware, but I'm
happy to be educated if anyone can explain.

Note that some simulators are not yet supporting
VHDL protected types, so you need to be a little
circumspect when using shared variables.
--
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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

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

Having a quick play, Quartus doesnt even want to know about protected
types, so I assume they havent gone beyond VHDL 93 (93/87 are the only
two settings). But what was iteresting was it said it was expecting
other stuff, including access, instead of protected.

So I tried infering a ram via an access type and shared variable.
Quartus just ploughed on, didnt throw a warning about access, but
seemed to ignore that it existed (therefore, just assumed everything
was connected to thin air - not really a surprise). Not even a warning
saying access types are not synthesizable.

Heres what I tried to synthesize(be interesting to see what other
synth tools do):

Not much luck in Precision either...

[40000]: vhdlorder, Release 2009a.15
[40000]: Files sorted successfully.
[40000]: hdl-analyze, Release RTLC-Precision 2009a.15
[42502]: Analyzing input file "D:/test/shared_var/test2.vhd" ...
[43156]: Shared variables must be of a protected type.
[651]: Top module of the design is set to: test_build.
[649]: Current working directory: <...>/shared_var/project_2_impl_1.
[40000]: RTLC-Driver, Release RTLC-Precision 2009a.15
[40000]: Last compiled on Mar 18 2009 18:40:36
[44512]: Initializing...
[44504]: Partitioning design ....
[40000]: RTLCompiler, Release RTLC-Precision 2009a.15
[40000]: Last compiled on Mar 18 2009 19:20:03
[44512]: Initializing...
[44522]: Root Module work.test_build(syn): Pre-processing...
[45258]: Object ram is of Non-Rtl type ram_t_p. Declaration wont be
compiled.
[46831]: Object ram of Non-Rtl type ram_t_p not handled. Continuing ...
[46292]: Module work.test_build(syn) cannot be compiled because it contains
non-rtl constructs. Please check the log for warnings or errors about
non-synthesizable constructs in this module.
[44536]: No modules were compiled in this run of RTLC, please check the logs
for blackboxes or non-rtl constructs in the design.
[44856]: Total lines of RTL compiled: 68.
[47002]: RTLCompiler error... aborting compilation.
[44513]: Overall running time 3.0 secs.
[46259]: Design compilation failed, unsupported or non-rtl constructs
detected in the following modules :
[40000]: work.test_build(syn)
[40000]: Please check the log for details pertaining to unsupported or
non-rtl construct(s)
[666]: Unable to elaborate design work.test_build in vhdl.

Hanswww.ht-lab.com

Well that is interesting, the fact that it recognises protected types.
Any chance you could take the code I posted and use the protected type
instead of the pointer? see what it does what that?

 

[Andy]

On Jun 4, 2:38 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Wed, 3 Jun 2009 21:26:06 +0000 (UTC), Matthew Hicks wrote:
By the way, if you look at the synthesis standards for VHDL (IEEE 1076.6-2004)
it clearly says shared variables aren't supported.  So a designer shouldn't
be using them even if tool support is there.

I agree.

It is my understanding (perhaps flawed) that the VHDL Synthesis
Standard sets the minimum set of the language to be supported by
synthesis. Shared variables are not required to be supported by a
compliant synthesis tool. If it sets limits on which VHDL constructs/
features CAN be supported, then it becomes a tremendous detriment to
the advancement of synthesis capabilities in general, since no vendor
will support it until it becomes part of the standard, and no vendor
will spend their money to develop a new capability if they cannot use
it any sooner than their competition.

We should seriously consider the adverse effects on the development of
synthesis technology before we advise ourselves and others to avoid
anything not already documented in "the" synthesis standard. Various
individuals and their employers have differing needs WRT portability
across multiple synthesis tools.

As it is, we have an agreement that synthesis results' behavior must
be consistent with simulation (or else at least warnings are issued),
and market competitiveness drives innovation (e.g. multiple clock-edge
processes, handling of signal assignments after the clocked clause,
etc.)

In this case of shared variables, there are serious potential issues
with simulation mismatch, but none that could not be handled by
limiting the synthesizeable subset of shared variables such that
simulation and synthesis will agree. In the bargain, we get the
ability to store more abstract and/or efficient data types(enumerated
types, integers, records, etc.) in an inferred dual port memory than
is possible with instantiated primitives.

Andy

 

[Mike Treseler]

Matthew Hicks wrote:

I wish this were the case. I have had plenty of experiences with both
Verilog and VHDL where synthesis differed from simulation, but the tool
didn't care to inform me of the potential difference, when it could
have.

As a counterpoint, I have coded vhdl and verilog on the edge
for years using modelsim, quartus and ise.
I found only one such bug, and none since.
http://groups.google.com/groups/search?q=update_regs_bug

What did you find?

-- Mike Treseler

 

[Mike Treseler]

Mike Treseler wrote:

As a counterpoint, I have coded vhdl and verilog on the edge
for years using modelsim, quartus and ise.
I found only one such bug, and none since.
http://groups.google.com/groups/search?q=update_regs_bug

After rereading that thread, there was a synthesis
warning, so my total of cases breaking
Andy's rule is still zero.

-- Mike Treseler

 

[Matthew Hicks]

On Jun 4, 2:38 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:

On Wed, 3 Jun 2009 21:26:06 +0000 (UTC), Matthew Hicks wrote:

By the way, if you look at the synthesis standards for VHDL (IEEE
1076.6-2004)
it clearly says shared variables aren't supported. So a designer
shouldn't
be using them even if tool support is there.
I agree.

It is my understanding (perhaps flawed) that the VHDL Synthesis
Standard sets the minimum set of the language to be supported by
synthesis. Shared variables are not required to be supported by a
compliant synthesis tool.

IEEE 1076.6 states, "The intent of this version was to include a maximum
subset of VHDL that could be used to describe synthesizable RTL logic."
The standard does include MAY rules which leave open to interpretation how
certain constructs can be handled by synthesis tools. Shared is not one
of those.

If it sets limits on which VHDL constructs
features CAN be supported, then it becomes a tremendous detriment to
the advancement of synthesis capabilities in general, since no vendor
will support it until it becomes part of the standard, and no vendor
will spend their money to develop a new capability if they cannot use
it any sooner than their competition.

Since no synthesis tool currently meets the requirements, I don't think your
logic holds. It seems most vendors use the standards as a guide and make
language support decisions based upon what the majority of customers want.
Remember that vendors can do what they want, the IEEE isn't going to stop
them, they just can claim IEEE 1076.6 conformance.

We should seriously consider the adverse effects on the development of
synthesis technology before we advise ourselves and others to avoid
anything not already documented in "the" synthesis standard. Various
individuals and their employers have differing needs WRT portability
across multiple synthesis tools.

We should also think of the adverse affect of adding features and bloat to
the tools/language just to meet the needs of a few. But, this is a religious
argument akin to RISC vs CISC (<--- computer architectures).

As it is, we have an agreement that synthesis results' behavior must
be consistent with simulation (or else at least warnings are issued),
and market competitiveness drives innovation (e.g. multiple clock-edge
processes, handling of signal assignments after the clocked clause,
etc.)

I wish this were the case. I have had plenty of experiences with both Verilog
and VHDL where synthesis differed from simulation, but the tool didn't care
to inform me of the potential difference, when it could have. Maybe tool
vendors should work on perfecting features before adding new, possibly buggy,
ones.

In this case of shared variables, there are serious potential issues
with simulation mismatch, but none that could not be handled by
limiting the synthesizeable subset of shared variables such that
simulation and synthesis will agree. In the bargain, we get the
ability to store more abstract and/or efficient data types(enumerated
types, integers, records, etc.) in an inferred dual port memory than
is possible with instantiated primitives.

Andy

In this thread, I've seen no mention/proof of some unique utility provided
by shared variables, but lots of problems. Dual-port ram isn't a good example
as it is just a case of using search-and-replace on a highly constrained
version of shared variables.


---Matthew Hicks

 

[Andy]

On Jun 4, 11:38 am, Matthew Hicks <mdhic...@uiuc.edu> wrote:

IEEE 1076.6 states, "The intent of this version was to include a maximum
subset of VHDL that could be used to describe synthesizable RTL logic."  
The standard does include MAY rules which leave open to interpretation how
certain constructs can be handled by synthesis tools.  Shared is not one
of those.

Like I said, my understanding of the intent of the standard could be
flawed...

If it sets limits on which VHDL constructs
features CAN be supported, then it becomes a tremendous detriment to
the advancement of synthesis capabilities in general, since no vendor
will support it until it becomes part of the standard, and no vendor
will spend their money to develop a new capability if they cannot use
it any sooner than their competition.

Since no synthesis tool currently meets the requirements, I don't think your
logic holds.  It seems most vendors use the standards as a guide and make
language support decisions based upon what the majority of customers want..
 Remember that vendors can do what they want, the IEEE isn't going to stop
them, they just can claim IEEE 1076.6 conformance.

So we have a standard that no tool can or does correctly claim
compliance to?

How good a standard is that?

My logic is that because the standard is what it is, no one follows it
verbatim. In turn, because no one follows it verbatim, the standard
must be flawed.

We should seriously consider the adverse effects on the development of
synthesis technology before we advise ourselves and others to avoid
anything not already documented in "the" synthesis standard. Various
individuals and their employers have differing needs WRT portability
across multiple synthesis tools.

We should also think of the adverse affect of adding features and bloat to
the tools/language just to meet the needs of a few.  But, this is a religious
argument akin to RISC vs CISC (<--- computer architectures).

Features sell, but bloat does not (usually); let the market decide.
Standards are there to coax interoperability to the maximum extent
practical. Vendors support and adhere to standards to the extent that
those standards create/support a market, but in the end, the vendors
support the market, as it should be.

What discerns features from bloat in the standard?

As it is, we have an agreement that synthesis results' behavior must
be consistent with simulation (or else at least warnings are issued),
and market competitiveness drives innovation (e.g. multiple clock-edge
processes, handling of signal assignments after the clocked clause,
etc.)

I wish this were the case.  I have had plenty of experiences with both Verilog
and VHDL where synthesis differed from simulation, but the tool didn't care
to inform me of the potential difference, when it could have.  Maybe tool
vendors should work on perfecting features before adding new, possibly buggy,
ones.

Bugs exist, and most synthesis vendors will fix bugs related to
simulation mismatch (except in traditional "accepted" ways like
sensitivity lists, etc.) when they are brought to their attention.

I think we can agree on perfecting existing features for sure!

In this thread, I've seen no mention/proof of some unique utility provided
by shared variables, but lots of problems.  Dual-port ram isn't a good example
as it is just a case of using search-and-replace on a highly constrained
version of shared variables.

Shared variables allow inferring dual port rams with different clocks
from arrays of any data type you want. Inferred memories allow storage
of data not easily (if at all) described by SLV, and in a target-
independent manner. Just because you say it is not a good example does
not make it so. There may be flaws in the allowed use of shared
variables (e.g. unprotected access), but the proof of unique utility
is there nevertheless.

I applaud vendors that try to advance the state of the art in
synthesis. It is certainly more than the synthesis standard has
accomplished lately (merely listing the existing capabilities that
vendors had already come up with on their own).

Andy