So, they started synthesizing shared variables?

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?

Tricky

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

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.

Tricky

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

"Tricky" <> wrote in message
news:d3545c34-d074-41b5-
b565-...
> 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?

HT-Lab

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

Dave Farrance

Dave Farrance <> 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

Dave Farrance

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

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

Mike Treseler

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

"Tricky" <> wrote in message
news:924f64a6-74e4-44ec-b6f6-...
> 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

HT-Lab