This is a reminder about tomorrow's teleconference.
The agenda is to discuss:
A) Semantics proposal (sent earlier by KenC).
B) Pragmas proposal (attached; from DougS)
- bhasker
----- Begin Included Message -----
X-Authentication-Warning: server.eda.org: majordom set sender to owner-vlog-synth@vhdl.org using -f
Date: Tue, 21 Jul 1998 16:29:04 -0400
From: owner-vlog-synth@vhdl.org
Orig-From: jbhasker@lucent.com
To: vlog-synth@eda.org
Subject: Re: Next 1364.1 WG meeting: Aug 4 teleconference
X-Sun-Charset: US-ASCII
Sender: owner-vlog-synth@eda.org
Content-Type: text
Content-Length: 668
Dear Working Group Member:
The next Verilog Synthesis Interoperability Working Group meeting has
been scheduled as a
teleconference for Aug 4 from 1:00pm EST till 2:30pm.
Bridge Telephone Number: 630-713-3333
Conference Code: 135485
-For trouble accessing your conference call, please call:
(888)252-7228 or (336)279-7399 to reach an operator.
Agenda will be posted later after we get updated drafts from the task leaders.
Regards,
- J. Bhasker, Lucent Technologies (610-712-3983, jbhasker@bell-labs.com )
Chair, IEEE 1364.1 Verilog Synthesis Interoperability Working Group
Email: vlog-synth@eda.org, URL: http://www.eda.org/vlog-synth
----- End Included Message -----
----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: pragma.proposal
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 110
Agenda for 1364.1 proposed pragmas - Doug Smith
-----------------------------------------------
Items to be discussed:
1. Direction for pragmas
========================
Do we want to make changes to the language itself
to use `define? Pros and cons of using in line comments
or so called real pragmas.
What is the timescale for 1364 revisions?
Pragmas under consideration:
map_to_mux
rtl_synthesis off
rtl_synthesis on
rtl_full_case
rtl_parallel_case
Extracted comments from Alain Raynaud
I don't really believe in the source code instructing the synthesizer of
which
algorithm is best. Source code is known so stay around much longer than
what
the original developer thought, and I'm afraid many pragmas would become
irrelevant in the process.
Basically, such pragmas tend to pollute the code with additional
information
that may or may not be used. And, as you pointed out, one could make up
hundreds more of these for all kinds of cases. Until a new mapping
algorithm
makes them all obsolete.
Extracted comments from Michael NcNamara
Verilog always simulates case statements as priority decoders, and so
the 'bug' of lying to design compiler about the mutual exclusivity of
the case items is not observed until gate simulation time, which is
often too late.
My fear with
`ifdef SYNTHESIS
rtl_parallel_case
`endif
is that this design information is hidden from the tools that could be
useful here - the lint tools, simulators, and so on, that could help
the user a fair amount.
So, what I am arguing for is a true pragma, that would be part of 1364
Verilog, that would have some defined keywords, some which are really
useful only to a subset of the tools (synthesis, simulation) and
others which are globally useful.
Extracted comments from Don Hejna
Most UDP's for mux cells pass known values (0 or 1)
to the output of a mux even though the select line may be "x"
provided both inputs are identical. This is not the case with a
"fractured" mux implementation using the nands/nors,aos, etc.
2. Use ifdef as a compiler directive instead of // rtl_synthesis off/on
=======================================================================
3. Other pragmas proposed by Ken Coffman
========================================
I agree with the above, perhaps we should add the spec version?
// 1164.1 pragma rtl_translate_off
other pragmas I'd like to see:
// Define pin assignment.
// Hierarchal assignment should be possible.
// Pin assignment example 1
// pragma signal_name pin_number nnn
// Pin assignment example 2
// pragma top_module_name1.lower_module_name2.signal_name pin_number nnn
I know we can sometimes infer the following, but I'd rather command the
hardware to synthesize a certain way.
// Assign signal to clock enable if supported by hardware.
// pragma signal_name clock_enable
// Assign signal to global clock resource if supported by hardware.
// pragma signal_name global_clock
// Assign signal to global reset resource if supported by hardware.
// pragma signal_name global_reset
// Assign signal to global preset resource if supported by hardware.
// pragma signal_name global_preset
// Don't collapse signal and use this signal name in place of any other
naming option.
// pragma signal_name preserve_signal
plus the following from Don Hejna
// pragma preserve_initial_instance_footprint