Hi all,
I use synthesis pragmas (or synthesis directives/preprocessor) a lot. But my
current simulator doesn't support "simulation pragmas" though I wish they
would.
One reason for me to have to use synthesis and simulation pragmas is to work
around my simulation tool (and sometimes the synthesis tool).
Since synthesis tool vendors already natively support synthesis pragmas, my
current problem is with the simulation tool. Here's an example:
i_ipCore1: ipCore1 generic map (
--synthesis only.
/* synthesis translate_off */
i_ipCore1: entity vendorLibrary.ipCore1(rtl) generic map (
--simulation only.
/* synthesis translate_on */
...)
port map(...);
Currently, I have to manually comment out the line with "synthesis only" if
I want to simulate the design, since there are no simulation pragmas to
ignore synthesis-only code.
The "synthesis translate_off/on" pragma works only for my synthesis tool,
but not my simulation tool.
I notice also that this works around some entity binding problem for both my
simulation and synthesis tools. I don't seem to be able to just use a single
method for both.
I know there could be better ways to do this, such as using generate
statements, but due to the large number of generics and ports that need to
be mapped, I decided to go for the above method instead.
Otherwise I will clutter my design with a lot of "duplicated" code for the
generic maps and port maps, if I went to use something like:
if synthesisOnly then generate
i_ipCore1: ipCore generic map(...) port map(...);
end generate;
if simulationOnly then generate
i_ipCore1: entity vendorLibrary.ipCore1(rtl) generic map (...) port
map(...);
end generate;
Also, I hope that could be done in a single if-then generate-elsif-end
generate statement.
Regards,
Daniel
On Wed, Aug 17, 2011 at 10:19 PM, Scott Thibault <thibault@gmvhdl.com>wrote:
> It is not a proposal, just a discussion. I'm only pointing out that there
> are language based solutions that handle common conditional compilation use
> cases.
>
> As far as sequential if statements are concerned, there is no need for new
> keywords or semantics. You could merely define what a static if statement
> is, and require that static if's be collapsed.
>
> --Scott
>
>
> > -----Original Message-----
> > From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On
> > Behalf Of Evan Lavelle
> > Sent: Wednesday, August 17, 2011 9:31 AM
> > To: vhdl-200x@eda.org
> > Subject: Re: [vhdl-200x] conditional compilation proposal
> >
> > On 17/08/2011 13:33, Scott Thibault wrote:
> >
> > > No a sequential generate is not necessary. As you pointed out, the
> > > existing sequential if statement is suitable for that purpose. The
> > > only thing necessary for that is a defined function.
> >
> > I did *not* point out that an if statement is suitable for that purpose,
> and it is
> > not suitable, by any stretch of the imagination. A *new* "static if"
> might
> be
> > considered by some as suitable for that purpose, as I have pointed out in
> > detail elsewhere, with the issues that I have also pointed out in detail.
> Your 'if
> > defined()' construct could be construed to have the same semantic
> meaning,
> > but only if "if defined" or some equivalent becomes a reserved word, and
> > the argument is required to be static. Simply using 'defined' as a
> function
> > name doesn't do it.
> >
> > Your proposal - if it actually is a proposal - is that conditional
> compilation
> > should be handled by a combination of *3* features: the existing
> concurrent
> > generate, a new "declaration generate", and a new mechanism to test
> static
> > expressions inside sequential code.
> >
> > -Evan
> >
> > --
> > This message has been scanned for viruses and dangerous content by
> > MailScanner, and is believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Aug 19 06:49:47 2011
This archive was generated by hypermail 2.1.8 : Fri Aug 19 2011 - 06:50:22 PDT