Subject: Re: Inferring FPGA Hardware Features?
From: Michael McNamara (mac@verisity.com)
Date: Mon Jul 16 2001 - 10:14:31 PDT
VhdlCohen@aol.com writes:
> [1 <text/plain; ISO-8859-1 (quoted-printable)>]
> 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).
I have no opinion on the above; except that we should leave room for
vendors to add things that we have not thought of.
> > 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.
My point is extremely pragmatic. If I insert into a module a pragma
that states something, like (* implement this in cell 14 *), then
when I instatiate this module more than once, I will have two cells
that are trying to use cell 14.
If I state in a module, (* optimize for time *), then _every_
instatiation of that module will be requesting timing optimization;
including instantiations that are not timing critical; hence I don't
get what I want.
>
> I'll write a new section of inferring RAMs and ROMs.
> ------------------------------------------------------------------------------
This archive was generated by hypermail 2b28 : Mon Jul 16 2001 - 10:25:58 PDT