( ESNUG 273 Item 3 ) --------------------------------------------- [12/5/97]
Subject: ( ESNUG 272 #9 ) Floating DW Inputs, Weird Stuff, & Module Compiler
> I am using Design Compiler for my synthesis in VHDL. I have a matrix
> multiplication in my design. It is a 3 by 3 matrix. My coefficients as
> well as the inputs are signed. For one sum of partial products I use:
>
> a <= signed(c1) * signed(in1) +
> signed(c2) * signed(in2) +
> signed(c3) * signed(in3);
>
> Q1) DC does not recognize "signed" and thus when it uses designware for
> the mutlipliers, it does'nt connect the "TC" (two's complement) to high
> -- it just lets it float. (Floating inputs??!!!) The way I got around
> it is to instantiate the DW02_mult and "force" the TC bit high. Is
> there any other, more automatic way to solve this problem beyond hand
> instantiating & baby-sitting DW parts?
>
> Q2) When I use the above equation, I break it into partial products, i.e.
>
> wait until clk'event and clk='1';
> a1 <= signed(c1) * signed(in1);
> a2 <= signed(c2) * signed(in2);
> a3 <= signed(c3) * signed(in3);
> a <= a1 + a2 + a3;
>
> And I don't meet my timing.
>
> Although if I take the sum of the partial products ( a1, a2, a3) and
> optimize them seperately in another file, I seem to achieve my timing:
>
> VHDL file_1:
>
> wait until clk'event and clk='1';
> a1 <= signed(c1) * signed(in1);
> a2 <= signed(c2) * signed(in2);
> a3 <= signed(c3) * signed(in3);
>
> VHDL file_2:
> wait until clk'event and clk='1';
> a <= a1 + a2 + a3;
>
> Why is Design Compiler croaking on such a small magnitude design ??
>
> - Xerxes Wania
> Xentec Inc., Canada
From: charles@efficient.com (Charles Shelor)
John,
When you have it in 2 files, it has become pipelined. You will get a set
of registers for the partial products and then those registers will get
passed to the adders in the "second stage".
No multiplier is a "small magnitude design" being proportional to m * n,
where m and n are the bit lengths of the two inputs.
- Charles F. Shelor
Efficient Networks
---- ---- ---- ---- ---- ---- ----
From: Hesham El Adly <hesham@cae.ca>
Hi John,
Replying to Xerxes post in ESNUG 272; As an alternative to using DC's
somewhat limited datapath optimizations, matrix multiplications can be
targeted with either of Synopsys's datapath tools - BC's BOA/BRT engine
or Module Compiler.
With BC, I suggest using BOA with BRT. BOA, behavioral optimization of
arithmetic functions, can transform a datapath into a faster datapath based
mainly on carry save adder trees.
Carry save adders calculate partial sums. CSAs have no carry propagation
delay with the area of a standard adder. So, delay is independant of bit
width. A standard full adder, however, is still required at the bottom of
the tree to produce a single value.
BOA can be applied to any design that can be deconstructed into adder
trees. This is done through a single command, transform_csa, after
elaboration - no scheduling required.
If the design does not require data to be produced on every clock (ie. not
every resource is used on every clock) then you can try BC's scheduler. The
scheduler will try to share resources and may reduce area further.
BRT can be used after the design has been BOAed and compiled to move any
registers in the design to meet timing goals.
The usage model of BOA/BRT is interesting in that the design can be an RTL
design. We do not have to change our coding styles, as we do with BC's
scheduler, to use BOA/BRT. In fact, we just need to code our datapath and
instantiate some registers (or use the pipeline_design command to add
registers to a combinational design) and let BOA/BRT perform timing and
register optimization.
We're using BOA/BRT as a fairly standard approach to get our very high
performance datapaths to meet timing and area.
MC can be also be used and will eat the matrix operations for lunch. If you
use MC, I suggest that register placement be optimized with BRT instead of
MC's pipeline retiming capability. We've found that BRT reduces sequential
area somewhat better than MC.
Note that MC (Module Compiler) is a datapath "expert" design tool. You have
to be very experienced and understand exactly the datapath you want to
achieve to get the best results with MC. Conversely, BOA/BRT is really easy
to use but designers still need some datapath knowledge to make the best
use of BOA.
- Hesham El-Adly
CAE Electronics, Ltd. Quebec, Canada
---- ---- ---- ---- ---- ---- ----
From: tom@iota.com (Iu-Meng Tom Ho)
Hi John,
In our DCT/IDCT modules, we have over 16 Multipliers with a constant. Since
we need to go 100Mhz, we created our own two's complement Wallace tree for
multipling a constant.
In your application, we could use 3 of those trees and a 6 input adder for
the final add. The size is going to be larger than Synopsys. It is just a
lot faster.
DC is great. We want to use it as much as we can. In some of our special
cases, we just have to do things by hand. In most of the multiplier
applications, we insert our own netlists while synthesizing the rest with
Synopsys.
- Tom Ho
Iota
---- ---- ---- ---- ---- ---- ----
From: Xerxes Wania <xerxes_wania@xentec-inc.com>
John,
Here's a follow-up to my problems.
Synopsys did start to look at the problem. It seems that when you do use
DesignWare components with a TC pin, the logic generated is correct (of
course) but after optimizing, the TC pin inside the module may seem
unconnected. What it actually does is to optimize the TC pin internally to
logic 0 or 1 thus not requiring the TC pin to be connected external to the
component. Visiually this looks like an error, but internally it is all
working fine.
Regarding the matrix multiplication, Synopsys is still looking into
regenerating the design on their premises. They will get back to me soon.
Thanks ESNUG, it really got things going.
- Xerxes Wania
Xentec, Inc. Ontario, Canada
|
|
