Subject: Re: How synthesize tools concern with size of the design?
Date: 15 May 1999 00:00:00 GMT
Newsgroups: comp.arch.fpga

Ray Andraka wrote in message <373B97D6.98A5BAE3@ids.net>...
>FPGA express is not currently as capable as SYnplicity and Exemplar, at
least
>from a standpoint of creating relatively placed macros.  I do alot of
structural
>instantiation with relative placement to get the performance and density I
>need.  I previously was constrained to schematics to do this, but with the
>capability to support and pass user attributes through to the EDIF output,
I
>know I can get the results I need from Synplicity, and while I haven't
tried it
>in exemplar, I understnd their tool will do it too.  FPGA express
definitely
>does not.


I recently downloaded the FPGA Express 3.1 upgrade to Xilinx Foundation
Express from the Xilinx website.  Attribute passing is described in
http://www.xilinx.com/techdocs/4392.htm.

Alas, my hopes for explicitly floorplanned datapaths, via structural
Verilog, via RLOC attributes on FMAP primitives, were dashed when I found
that my explicitly instantiated FMAPs were swallowed by FPGA Express and
were not copied into the output netlist.  This is explained in
http://www.xilinx.com/techdocs/4395.htm.

As a workaround, I created a schematic macro named FMAP_, which contains a
single FMAP primitive with an RLOC=R0C0 attribute, exported it as EDIF, and
instantiated those through structural Verilog, applying RLOC attributes to
my FMAP_ macros.  Express kindly passes these through to my output netlist.

With this technique, I was able to build a test section of a datapath with
the right relative placement.

However, if I recall correctly, when explicitly instantiating other device
primitives, like INV, Express would sometimes emit its own FMAPs which
covered the same nets as mine.  This led to map failure.  So, I defined and
used my own INV_ macro instead, and this suppressed the undesired FMAPs on
INVs.  But this way lies madness.

(If I am mistaken, or have overlooked something obvious, please let me
know!)

In other experiments, I tried something like an assign plus an FMAP
  assign o = ... a ... b ... c ... d ... ;
  FMAP_ fmo(.I1(a), .I2(b), .I3(c), .I4(d), .O(o)); //synopsys attribute
RLOC "R0C0"
but my fmo/fmap covered the same nets as the unattributed FMAP that Express
emits for the assign, and again map fails.  I briefly contemplated
post-processing Express output netlists to either 1) remove Express FMAPs
that covered my RLOC'd FMAPs, or 2) remove my FMAPs but propagate their
attributes to the equivalent Express generated FMAPs, but this way too lies
madness.

(Maybe it would be nice if, as with my custom netlist generator, an assign
which could be covered by a single FMAP could be attributed:
  assign o = ... a ... b ... c ... d ... ; // FMAP attribute RLOC "R0C0"
but maybe not.)

This is "pushing on a rope".  You know exactly what you want -- a particular
optimal, hand-mapped, hand-placed layout for your datapath -- but the tools
get in the way, and you spend hours trying to discover an incantation that
persuades the tools to emit the desired result.

Do Synplicity or Exemplar honor explicit instantiations of FMAPs, and enable
them to be attributed with RLOC constraints?


If you will indulge me, here are two desiderata for FPGA and synthesis tools
vendors to consider.

HDL Floorplanning Desiderata

1. there should be straightforward way to take a schematic and write an
equivalent structural HDL module.

(Corollaries:
1.a. If I can specify attributes on components and nets in the schematic,
then I can also attach them to the instances and nets in the structural HDL.
1.b. Just as with a schematic, if I DO instantiate a component, DO emit it
to the netlist.
1.c. Just as with a schematic, if I DON'T instantiate a component, DON'T
unhelpfully create one from whole cloth and emit it to the netlist.)

2. that way (1) should be standard across vendors

Somehow I doubt that '//synopsys attribute RLOC "R0C0"' is going to have the
desired effect when my design is built with Synplicity.  While I admire
synthesis vendor extensions which deliver new innovations, the issue of
passing attributes seems so fundamental to quality FPGA design that I hope
the FPGA and synthesis vendors can work together to define a common
notation.

Jan Gray



Subject: Re: Question: Does FPGA Express 3.2 support RPMs?
Newsgroups: comp.arch.fpga
Date: Mon, 21 Jun 1999 20:43:22 -0700

>I'm currently using the Metamor synthesis tool for targetting Xilnix
>XC4000-series devices, and I use the Xilinx system of
>relationally-placed macros (RPMs) to get good density results. I also
>use FPGA Express 3.0, which does not correctly support the generic
>attribute passing necessary - does anyone know if this has been fixed
>for version 3.2?

You can apply RLOC and RLOC_ORIGIN attributes in HDL to RPMs defined
elsewhere.  See http://www.xilinx.com/techdocs/4392.htm.

However (version 3.1) you can't *create* RPMs of FMAPs in structural HDL,
because it ignores explicit FMAPs.  See
http://www.xilinx.com/techdocs/4395.htm and my comments
http://deja.com/getdoc.xp?AN=478287358.

(Above comments refer to the FPGA Express 3.1 download available to Xilinx
Foundation Express customers.)

Jan Gray

Copyright © 2000, Gray Research LLC. All rights reserved.
Last updated: Feb 03 2001