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?

 

[Dave Farrance]

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.

 

[Tricky]

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.

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.

 

[HT-Lab]

(e-mail address removed)...

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

 

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

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]

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

 

[Mike Treseler]

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

 

[Mike Treseler]

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

 

[Tricky]

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
(e-mail address removed)://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;

 

[HT-Lab]

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
(e-mail address removed)://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]

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
(e-mail address removed)://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?

 

[JimLewis]

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

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

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

Usage of shared variables in this example - independent of using
either a
protected type (only correct usage in 1076-2002 and beyond) or
regular
types (as temporarily defined in 1076-1993) - is always going to lead
to
quirky behavior in simulation. Either process can be executed
first.
If Proc2 runs first, there are two registers. If Proc1 runs first,
there
is only one register. Adding protected types only ensures that the
access
to the object is not interrupted in the middle - which really does not
help
or hurt this pair of processes.

To be correct, synthesis results must match RTL simulation results.
Since the RTL simulation is ambiguous for this example, there is no
correct synthesis result for this problem.

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?

I agree with your assessment and would consider it a bad investment on
their part - unless they got it for free. Even then it is still a
liability.

I primarily use shared variables in testbenches where they are great
for
data structures and randomization. See http://www.synthworks.com/downloads/
for the randomziation packages we use.

Cheers,
Jim

 

[JimLewis]

Jon,

Note that some simulators are not yet supporting
VHDL protected types, so you need to be a little
circumspect when using shared variables.

Care to name names?

I have used protected types on both ModelSim and
Aldec for quite some time now.

Cheers,
Jim

 

[Tricky]

Tricky,









Usage of shared variables in this example - independent of using
either a
protected type (only correct usage in 1076-2002 and beyond) or
regular
types (as temporarily defined in 1076-1993) - is always going to lead
to
quirky behavior in simulation.  Either process can be executed
first.
If Proc2 runs first, there are two registers. If Proc1 runs first,
there
is only one register.  Adding protected types only ensures that the
access
to the object is not interrupted in the middle - which really does not
help
or hurt this pair of processes.

To be correct, synthesis results must match RTL simulation results.
Since the RTL simulation is ambiguous for this example, there is no
correct synthesis result for this problem.


I agree with your assessment and would consider it a bad investment on
their part - unless they got it for free.  Even then it is still a
liability.

I primarily use shared variables in testbenches where they are great
for
data structures and randomization.  Seehttp://www.synthworks.com/downloads/
for the randomziation packages we use.

Cheers,
Jim

Thanks Jim. I am not really interested in simulation results - I was
just surprised such features were supported by at least 1 synth tool
(I only have access to Quartus), not something I intend to use at all
for synth. Like you, I only use shared variables in testbenches (as
should anyones else, IMO, though being able to get the correct
behaviour for a Dual-port ram may be considered a bonus). I just dont
want people falling into traps, like I think I have demonstrated,
because synth tools allow shared variables but dont warn against their
use. Who knows what a VHDL beginner might do when he finds out about
this magical device that is updated instantly across many processes.

 

[HT-Lab]

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

Sure, send/or post a version that doesn't annoy Modelsim and I will run it
through Precision,

Hans
www.ht-lab.com

 

[Tricky]

"Tricky" <[email protected]> wrote in message

..

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

Sure, send/or post a version that doesn't annoy Modelsim and I will run it
through Precision,

Hanswww.ht-lab.com

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;



signal addr_b_r : natural range 0 to 127;

begin


process(clk)
begin
if rising_edge(clk) then
ram.write(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.read(addr_b_r);

end architecture syn;

 

[HT-Lab]

...

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;

mmmm, not sure which version of Modelsim you are using but my 6.5b version
complained bitterly and told me to get some more coffee..

After some quick hacking I changed the code into:

type ram_t is protected -- Error in PS
impure function read(a : natural) return std_logic_vector;
procedure write(a : natural; d : std_logic_vector);
end protected 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;

impure 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 body ram_t;

Unfortunately it didn't go through Precision although this might be due to
me screwing up the code.

[40000]: vhdlorder, Release 2009a.15
[40000]: Syntax error at or near "protected"
[40000]: VHDL file ordering failed.

Hans
www.ht-lab.com

 

[Tricky]

..

 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;

mmmm, not sure which version of Modelsim you are using but my 6.5b version
complained bitterly and told me to get some more coffee..

After some quick hacking I changed the code into:

type ram_t is protected -- Error in PS
impure function read(a : natural) return std_logic_vector;
procedure write(a : natural; d : std_logic_vector);
end protected 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;

impure 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 body ram_t;

Unfortunately it didn't go through Precision although this might be due to
me screwing up the code.

[40000]: vhdlorder, Release 2009a.15
[40000]: Syntax error at or near "protected"
[40000]: VHDL file ordering failed.

Hanswww.ht-lab.com

You need to compile with the -2000 option, not -93. Protected types
were not introduced until VHDL 2000

As for the protected type - I just realised I probably meant to find
out what other synthesisors do with access types.

So, in the origional code (without protected types), replace the type/
shared variable declaration with this:

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);

shared variable ram : ram_t_p := new ram_t;

Then run it through precision and see what it makes of it all - as I
said quartus just ignored it - not even a warning that it's a bad idea.

 

[HT-Lab]

...

..

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;

mmmm, not sure which version of Modelsim you are using but my 6.5b version
complained bitterly and told me to get some more coffee..

After some quick hacking I changed the code into:

type ram_t is protected -- Error in PS
impure function read(a : natural) return std_logic_vector;
procedure write(a : natural; d : std_logic_vector);
end protected 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;

impure 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 body ram_t;

Unfortunately it didn't go through Precision although this might be due to
me screwing up the code.

[40000]: vhdlorder, Release 2009a.15
[40000]: Syntax error at or near "protected"
[40000]: VHDL file ordering failed.

Hanswww.ht-lab.com

You need to compile with the -2000 option, not -93. Protected types
were not introduced until VHDL 2000

I did and I get:

D:\test\shared_var>vcom shared_tricky.vhd -2002
Model Technology ModelSim SE vcom 6.5b Compiler 2009.05 May 21 2009
-- Loading package standard
-- Loading package std_logic_1164
-- Compiling entity test_build
-- Compiling architecture syn of test_build
** Error: shared_tricky.vhd(28): near "type": expecting ';'
** Error: shared_tricky.vhd(30): Subprogram "read" parameter name
"_impliedOperand_ram_t" does not conform bet
ween subprogram declaration and subprogram body (declaration has "a").
** Error: shared_tricky.vhd(30): Subprogram "read" parameter
"_impliedOperand_ram_t" class does not conform be
tween subprogram declaration and subprogram body.
** Error: shared_tricky.vhd(30): Subprogram "read" parameter
"_impliedOperand_ram_t" mode INOUT does not confo
rm between subprogram declaration and subprogram body (declaration has IN).
** Error: shared_tricky.vhd(30): Subprogram "read" parameter
"_impliedOperand_ram_t" type does not conform bet
ween subprogram declaration and subprogram body.
** Error: shared_tricky.vhd(34): VHDL Compiler exiting

As for the protected type - I just realised I probably meant to find
out what other synthesisors do with access types.
So, in the origional code (without protected types), replace the type/
shared variable declaration with this:

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);
shared variable ram : ram_t_p := new ram_t;
Then run it through precision and see what it makes of it all - as I
said quartus just ignored it - not even a warning that it's a bad idea.

Precision doesn't seem to like it and reports:

[40000]: vhdlorder, Release 2009a.15
[40000]: Files sorted successfully.
[40000]: hdl-analyze, Release RTLC-Precision 2009a.15
[42502]: Analyzing input file "D:/hdl_designs/test/shared_var/shared_var3.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_5_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: 70.
[47002]: RTLCompiler error... aborting compilation.
[44513]: Overall running time 1.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.

Regards,
Hans.
www.ht-lab.com