So, they started synthesizing shared variables?
Tricky
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
>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...@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
>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
Tricky
<DaveFarra...@OMiTTHiSyahooANDTHiS.co.uk> 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.
HT-Lab
"Tricky" <Trick...@gmail.com> wrote in message
news:d3545c34-d074-41b5-
b565-71d...@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
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
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."
--
Dave Farrance
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
Jonathan Bromley
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.
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
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
>> 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.
Tricky
wrote:
> On Wed, 03 Jun 2009 09:26:30 -0700, 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.
>
> 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
>
> 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
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
> "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?
Andy
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
Matthew Hicks
> 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
> 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
Mike Treseler
> 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
> 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
Dave
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
JimLewis
> 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
>
> begin
> if rising_edge(clk) then
> C := data_a;
> end if;
> end process;
>
> 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
Matthew Hicks
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
> 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
Mike Treseler
> 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
> 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
> 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
Jonathan Bromley
>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...@MYCOMPANY.com
Jonathan Bromley
Yup, me too.
Tried any others recently? ;-)
Andy
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
> 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
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
> 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
Tricky
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
> On 6 June, 09:56, "HT-Lab" <han...@ht-lab.com> wrote:
>> "Tricky" <Trickyh...@gmail.com> wrote in message
>>
>> news:fb2b24a3-8eb3-41a9...@j18g2000yql.googlegroups.com...
>>
>> > On 4 June, 12:00, "HT-Lab" <han...@ht-lab.com> wrote:
>> >> "Tricky" <Trickyh...@gmail.com> wrote in message
..
>> > 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
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
> 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
On 8 June, 09:31, "HT-Lab" <han...@ht-lab.com> wrote:
> "Tricky" <Trickyh...@gmail.com> wrote in message
>
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
> 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.
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