Subject: Re: Inferring FPGA Hardware Features?
From: VhdlCohen@aol.com
Date: Mon Jul 16 2001 - 10:05:01 PDT
In a message dated 7/16/01 8:56:37 AM Pacific Daylight Time, mac@verisity.com
writes:
> >> So the question really is: Do we want to sort out a "common" set of
> >> attributes that are useful for FPGA? This is not an easy task.
> >> Will it ever be complete? Vendors may also wish to provide
> >> specific tailorability into their tools (thru pragmas/attributes)
> >> to be competitive. Is it our job to define this set?
>
> <It is our job to come up with a system that will work, a framework for
> the industry to use. We should define clear winners like parallel
> case, and define a framework for the implementation of more.>
If we add features to infer hardware optimization, then we need to modify
section 1.1 of IEEE P1364.1 / D1.6
Draft Standard for Verilog® Register Transfer Level Synthesis, which
currently reads:
1.1 Scope
This standard defines a set of modeling rules for writing Verilog HDL
descriptions. Adherence to these rules guaran-tee
the interoperability of Verilog HDL descriptions between register-transfer
level synthesis tools that comply to this
standard. The standard defines how the semantics of Verilog HDL is used, for
example, to describe level- 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.
Use of this standard will enhance the portability of Verilog HDL based
designs across synthesis tools conforming to
this standard. In addition, it will minimize the potential for functional
mismatch that may occur between the RTL
model and the synthesized netlist.
This would be something like:
This standard defines a set of modeling rules for writing Verilog HDL
descriptions. This standard also defines a set of attributes for hardware
optimization as a guidance for the compiler, but not necessarily as an
implementation requirement.
I argue that, per the current scope of the spec, if vendor "A" synthesizes
RTL code
such that the resulting gate level model operates like the RTL, but at speed
X, and if vendor "B" also synthesizes the same code with additional vendor
"B" specific pragma/comments/GUI stuff, but at speed 3X, then vendor "A" and
vendor "B" are both compliant to our RTL spec.
My argument here is that the attributes that represent directives for
optimization do NOT impact interoperability. I also argue that these
optimization attributes could be endless becuase of changes in technology and
the mechanisms used in the synthesis process.
Bottom line, if as group we think that we need to add these optimization
attributes, then we should also change the scope of the spec (section 1.1).
> Note that a classic problem is reuse: Probably a particular
> case/endcase is once and for all parallel case; but a particular bit
> of logic may not be always 'altera_implement_in_eab' in every
> instatiation in a particular design, or even if so, then in a
> subsequent design where the logic is reused in a larger structure.>
Optimization does not equal "reuse". Take for example the ROM or RAM
built-in features of some FPGAs. The ROMs could be built with special
hardware elements or with combinational logic. Also the RAM could be built
with either registers or built-in RAM cells. On that topic, since ROM and
RAMs are hardware primitives, like FFs, we need to at least meet the spec
reuirement "The standard defines how the semantics of Verilog HDL is used".
Because RAMs and ROMs are primitive elements, I believe that attributes are
neded here ONLY TO GUIDE the synthesis process. But it would NOT be a
violation if the attribute infers a RAM, and the implementation uses
registers.
I'll write a new section of inferring RAMs and ROMs.
------------------------------------------------------------------------------
--------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdlcohen@aol.com
Author of following textbooks:
* Component Design by Example ... a Step-by-Step Process Using
VHDL with UART as Vehicle", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------
--------------------------------------
This archive was generated by hypermail 2b28 : Mon Jul 16 2001 - 10:17:20 PDT