So, they started synthesizing shared variables?

[Dave]

On Jun 4, 1:47 pm, Mike Treseler <mtrese...@gmail.com> wrote:

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

I've recently been having a back-and-forth with Xilinx about what XST
does when there's a top-level inout port with a VHDL init value of
'Z'. XST makes such a signal init to '0' - in other words, it doesn't
set the INIT value of the tristate-enable register correctly. When
they said they weren't going to fix it, I said that they should at
least throw a warning or error about a sim/synth mismatch. This was
the reply:

<snip>

I have reviewed the notes for case XXXXXX and understand the
situation. In regards to adding a "mismatch" warning in XST, here are
some thoughts:

1) Following synthesis, we expect customers to review the
functionality of the generated netlist by looking at the post-
synthesis netlist simulation, not the behavioral (RTL) simulation.
2) In several circumstances, XST already issues "potential simulation
mismatch" where the post-synthesis netlist simulation can potentially
show a mismatch on actual hardware behavior. As such, a "mismatch
warning" is only applicable against the post-synthesis simulation, not
the behavioral (RTL) simulation.

Please let me know if the information in this e-mail explains the
conclusion to this case.

<snip>

I guess their definition of a mismatch is different from mine.

Dave

 

[Mike Treseler]

Matthew Hicks wrote:

Speaking of which, does anyone know of an automated tool that will
equivalence check the behavior pre and post synthesis designs?

I rarely check post-synthesis, but when I do,
I just compile the gate architecture over the rtl
and rerun the testbench.

-- Mike Treseler

 

[Mike Treseler]

JimLewis wrote:

If a vendor implements an inferior alternative to what is in
1076.6-2004 (and do not implement what is in 1076.6-2004), I would
not call that advancing the state of the art. I would call it a bad
investment.

Nevertheless, the fact is interesting to a least
one reader of this newsgroup.

Please educate yourself on what is current and make sure your vendors
are implementing the parts you need. Vendors are market driven and
if you fail to do this, they will not implement it.

I hear what you are saying, but consider the designer's point of view.
I live in the moment with tightly budgeted time and money.
I would like like nothing better than to work on logic
description and synthesis all day, but that does not pay the bills.
A few lines of text in the newsgroup is all I can afford.

-- Mike Treseler

 

[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

 

[Jonathan Bromley]

On Thu, 4 Jun 2009 13:42:15 -0700 (PDT), JimLewis wrote:

Among other things, 1076.6-2004 has coding styles for implementing
dual port rams with different clocks.

I don't have access to the published standard just now, but I
do have draft 8 which does not explicitly specify a scheme for
multiple-clocked memory; instead, one can assume that the
multiple-clocked storage style could also be used for memory.

Unfortunately, I'm not aware of any synthesis tools that
support multiple-clock storage elements (with the single
exception of DDR flops clocked on both edges of the
same clock).

Consequently, the real practical situation today is that
if you want to model dual-clock dual-port RAM for synthesis
you must do one of the following:
- model the storage as a VHDL-93 shared variable
and have two clocked processes both writing to it -
this is supported by some but not all tools;
- model the storage as a signal and have two clocked
processes both writing to it; this is simply flat-out
wrong, and won't simulate correctly, but I've found
FPGA synthesis tools that not only accept it for
synthesis of DPRAM but actually recommend it as the
"correct" coding style!
- use Verilog, where you can do nonblocking assignment
(roughly, signal-like update) on a shared variable.

I share your frustration about lack of contribution to
standards efforts but, when the real situation on the ground
is so widely different from what the standard says, it's
hardly surprising that many people have given up or don't
even try. You and I have the luxury (and, indeed, the duty)
of trying to get these things right; many working engineers
must, as their first and only priority, get the results they
need with the tools and techniques they can get today.

I shall be filing bug reports against the tools that do
last-write-wins resolution of writes to VHDL signals from
multiple processes, a poisonous hack to make it possible
to get DPRAM from VHDL source code whilst using the same
algorithms they use to handle Verilog source. But there's
little else I can reasonably do to push things forward.
--
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.

 

[Jonathan Bromley]

On Thu, 4 Jun 2009 14:59:05 -0700 (PDT), JimLewis wrote:

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.

Yup, me too.

Tried any others recently? ;-)
--
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.

 

[Matthew Hicks]

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

I don't remember which tool I was using ModelSim or Active-HDL, but the problem
centered around concatenating two signals together and switching on the result.
I had to instead use an intermediate signal to hold the result of the operation,
then switch on it, otherwise the code was optimized away during synthesis.
This was a few years ago and may count as a bug, but I'm sure I have had
the fun of hunting mismatch bugs before, but can't remember the situation.
I just know that these bugs are the hardest (for me) to fix as I don't like
playing around with post-synthesis simulations.

Speaking of which, does anyone know of an automated tool that will equivalence
check the behavior pre and post synthesis designs?


---Matthew Hicks

 

[JimLewis]

Andy,

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

Your ignorance is both insulting and part of the problem with
getting the standards implemented.

Among other things, 1076.6-2004 has coding styles for implementing
dual port rams with different clocks. For a quick start on this
standard, see the paper or slides on "IEEE 1076.6-2004: VHDL
Synthesis
Coding Styles for the Future" that is at:
http://www.synthworks.com/papers/

If a vendor implements an inferior alternative to what is in
1076.6-2004 (and do not implement what is in 1076.6-2004), I would
not call that advancing the state of the art. I would call it a bad
investment.

Please educate yourself on what is current and make sure your vendors
are implementing the parts you need. Vendors are market driven and
if you fail to do this, they will not implement it.

If you need something that is not in 1076.6-2004, quit whining
and get involved. There are quite a few of you here
who are senior enough that you ought to be participating in standards
development - if not driving the standards development.
Participation is volunteer work. A typical committee
will let anyone with a vested interested participate - ie: a VHDL
user - after all free labor is free. Typically issues are resolved
by consensus. Only when the group is polarized does an official
membership vote come up. If you want to participate in those
you will need to be a member of the appropriate groups (typically
IEEE and DASC).

1076.6-1999 did as you said, listed a baseline set of existing
capabilities that intellectual property developers could depend
on all synthesis tools implementing. Its purpose was not to push
the state of the art - its intent is allow model developers to
claim compliance, and hence, if you purchased a compliant model
you could count an a synthesis tool creating a good implementation.

If not you then who?

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

 

[Andy]

On Jun 4, 3:42 pm, JimLewis <j...@synthworks.com> wrote:

Andy,

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

Your ignorance is both insulting and part of the problem with
getting the standards implemented.

Among other things, 1076.6-2004 has coding styles for implementing
dual port rams with different clocks.  For a quick start on this
standard, see the paper or slides on "IEEE 1076.6-2004: VHDL
Synthesis
Coding Styles for the Future" that is at:http://www.synthworks.com/papers/

If a vendor implements an inferior alternative to what is in
1076.6-2004 (and do not implement what is in 1076.6-2004), I would
not call that advancing the state of the art.  I would call it a bad
investment.

Please educate yourself on what is current and make sure your vendors
are implementing the parts you need.  Vendors are market driven and
if you fail to do this, they will not implement it.

If you need something that is not in 1076.6-2004, quit whining
and get involved.  There are quite a few of you here
who are senior enough that you ought to be participating in standards
development - if not driving the standards development.
Participation is volunteer work.  A typical committee
will let anyone with a vested interested participate - ie: a VHDL
user - after all free labor is free.  Typically issues are resolved
by consensus.  Only when the group is polarized does an official
membership vote come up.  If you want to participate in those
you will need to be a member of the appropriate groups (typically
IEEE and DASC).

1076.6-1999 did as you said, listed a baseline set of existing
capabilities that intellectual property developers could depend
on all synthesis tools implementing.  Its purpose was not to push
the state of the art - its intent is allow model developers to
claim compliance, and hence, if you purchased a compliant model
you could count an a synthesis tool creating a good implementation.

If not you then who?

Cheers,
Jim

I do not have access to the latest non-draft revision either, but
would add that there is a huge difference between a dual port ram that
operates with two independent, asynchronous clocks, and a dual-edge/
clock device such as a DDR flip-flop which requires constrained timing
between clocks for proper operation.

I also read your related paper. Your model in section 6.1 of the
behavior of a dual edged flop is flawed. An asynchronous reset should
be the highest priority (not an elsif to the clock conditions), as is
correctly mentioned in section 2.1. Also, with two simultaneous
clocks, it is a bit pessimistic. The output should not assume 'X'
unless the two data inputs are different and reset is not asserted.
Just like set and hold violations, RTL models need not faithfully
describe clock skew related behavior either.

But relax, I'm not insulted by your ignorance... :^) Seriously, I
truly enjoy and respect your fervent advocation of VHDL, whether I
agree with all of it or not.

I believe the 1999 approach (not the content) of the standard is more
useful than apparently that of the 2004 standard. By implementing a
minimum set of common capabilities, the 1999 standard allows both
model writers, consumers, and tool vendors to ascertain compatibility,
while not restricting progress in the state of the art until the next
version of the standard is published. You seem to believe it is the
standard that sets the state of the art, yet I know there were
synthesis vendors that implemented some if not all of the features in
your paper prior to 2004. Had the 1999 standard prohibited
capabilities in excess of the standards, those vendors would have had
to choose between providing the advanced capabilities desired by their
customers, or claiming compliance with the standard in order to ensure
compatibility with their users. Thankfully, the 1999 standard let them
do both.

Andy

 

[Tricky]

On 4 June, 20:39, JimLewis <j...@synthworks.com> wrote:

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

 

[Brian Drummond]

On Thu, 04 Jun 2009 10:35:35 -0700, Mike Treseler <mtreseler@gmail.com> wrote:

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?

I have seen XST using variable assignment rules (immediate not postponed) on
signals, when the assignments were in a procedure, with the signal passed as an
inout parameter. Eventually acknowledged as a bug; I don't know if it's fixed in
ISE11.

- Brian

 

[HT-Lab]

"Tricky" <Trickyhead@gmail.com> wrote in message
news:fb2b24a3-8eb3-41a9-88ce-debe737a4c0c@j18g2000yql.googlegroups.com...

On 4 June, 12:00, "HT-Lab" <han...@ht-lab.com> wrote:
"Tricky" <Trickyh...@gmail.com> 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,

Hans
www.ht-lab.com

 

[HT-Lab]

"Tricky" <Trickyhead@gmail.com> wrote in message
news:8ef9c5cf-faa1-4741-b54c-64d1acf05862@e21g2000yqb.googlegroups.com...

On 6 June, 09:56, "HT-Lab" <han...@ht-lab.com> wrote:
"Tricky" <Trickyh...@gmail.com> wrote in message

news:fb2b24a3-8eb3-41a9-88ce-debe737a4c0c@j18g2000yql.googlegroups.com...

On 4 June, 12:00, "HT-Lab" <han...@ht-lab.com> wrote:
"Tricky" <Trickyh...@gmail.com> wrote in message
...
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

...

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]

On 6 June, 09:56, "HT-Lab" <han...@ht-lab.com> wrote:

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

news:fb2b24a3-8eb3-41a9-88ce-debe737a4c0c@j18g2000yql.googlegroups.com...



On 4 June, 12:00, "HT-Lab" <han...@ht-lab.com> wrote:
"Tricky" <Trickyh...@gmail.com> 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;

 

[Tricky]

On 8 June, 09:31, "HT-Lab" <han...@ht-lab.com> wrote:

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

news:8ef9c5cf-faa1-4741-b54c-64d1acf05862@e21g2000yqb.googlegroups.com...



On 6 June, 09:56, "HT-Lab" <han...@ht-lab.com> wrote:
"Tricky" <Trickyh...@gmail.com> wrote in message

news:fb2b24a3-8eb3-41a9-88ce-debe737a4c0c@j18g2000yql.googlegroups.com....

On 4 June, 12:00, "HT-Lab" <han...@ht-lab.com> wrote:
"Tricky" <Trickyh...@gmail.com> wrote in message
..
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

..

 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.

 

[Mike Treseler]

Brian Drummond wrote:

I have seen XST using variable assignment rules (immediate not postponed) on
signals, when the assignments were in a procedure, with the signal passed as an
inout parameter. Eventually acknowledged as a bug; I don't know if it's fixed in
ISE11.

Thanks for the tip!
I would not have seen this since I only
use signals in structural entities.

-- Mike Treseler

 

[HT-Lab]

"Tricky" <Trickyhead@gmail.com> wrote in message
news:1adc2767-9f3b-47b4-9e85-9ec6df2501dd@k8g2000yqn.googlegroups.com...
On 8 June, 09:31, "HT-Lab" <han...@ht-lab.com> wrote:

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

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

..

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

 

[JimLewis]

Andy,

I also read your related paper. Your model in section 6.1 of the
behavior of a dual edged flop is flawed. An asynchronous reset should
be the highest priority (not an elsif to the clock conditions), as is
correctly mentioned in section 2.1.
The implementation you expected is in the slides. The one from the

paper
is still correct as it uses nReset as inactive as a condition to the
clock
statements - which is permitted in 1076.6-2004 - looking back I have
no
idea why I would have written the paper that way.

Also, with two simultaneous
clocks, it is a bit pessimistic. The output should not assume 'X'
unless the two data inputs are different and reset is not asserted.
The example was intended to show that one can detect and flag

simultaneous changes if it is problematic for the circuit being
created, however, one is not obliged to do this.

But relax, I'm not insulted by your ignorance... :^) Seriously, I
truly enjoy and respect your fervent advocation of VHDL, whether I
agree with all of it or not.
The standard gives users something to ask your vendor to implement.

If you ignore it, then we get stuff that may solve the issue, however,
in this case is not VHDL compliant. Not great, but like
Mike T noted, one does have to get a job done.

I believe the 1999 approach (not the content) of the standard is more
useful than apparently that of the 2004 standard. ...
WRT support and not support, the 2004 approach is identical to the

1999 approach. I think the selective quoting and confusion introduced
since the standard is for both writing compliant
models and writing compliant tools.

The quote from, Matthew Hicks, which states:

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

This is correct, however, it was in the introduction which was noted
as
"not part of IEEE Std 1076.6-2004". Meaning it is non-binding.

I find the word maximum easy to misunderstand here. I think the
working
group was trying to say that the goal was to maximize the variations
of
coding styles that would be accepted by a compliant synthesis tool.
To do this, the 1999 templates for flip-flops were replaced by rules
that included the templates and more.

To further clarify this, the Scope of the 2004 specification states:
---------------------------------- Start of Quote of 2004
specification --------------------------
1.1 Scope
This standard defines a subset of very high-speed integrated circuit
hardware description language (VHDL)
that ensures portability of VHDL descriptions between register
transfer level synthesis tools. Synthesis tools
may be compliant and yet have features beyond those required by this
standard. This standard defines how
the semantics of VHDL shall be used, for example, to model level-
sensitive and edge-sensitive logic. It also
describes the syntax of the language with reference to what shall be
supported and what shall not be supported
for interoperability.
---------------------------------- End of Quote of 2004 specification
--------------------------
My interpretation is that a synthesis vendor is permitted to do more
than the standard states.

We also need to address what not supported means, so
moving on to the next quote also from Matthew:

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.

While this is true, one has to review what "not supported" means:
---------------------------------- Start of Quote of 2004
specification --------------------------
Not Supported: RTL synthesis does not support the construct. RTL
synthesis does not expect to
encounter the construct, and the failure mode shall be undefined. RTL
synthesis may fail upon
encountering such a construct. Failure is not mandatory; more
specifically, RTL synthesis is allowed
to treat such a construct as ignored.
NOTE—A synthesis tool may interpret constructs that are identified as
not supported in this standard. However a model
that contains such unsupported constructs is not compliant with this
standard.
---------------------------------- End of Quote of 2004 specification
--------------------------
My interpretation is that a synthesis tool vendor is permitted to
support anything
it likes that is labeled as not supported and still be compliant, but
a model that
uses constructs marked as not supported is not compliant with the
standard.


Although I worked on both the 1999 and 2004 committees, this is not an
official
interpretation of the standard. If you need an official
interpretation, you can
request this by contacting the chair of the sponsoring committee of
standard. The
sponsoring committee for both 1076.6 and most IEEE EDA standards is
DASC. You can
find DASC on the web at: http://www.dasc.org/

Cheers,
Jim