Prev: ICTP Regional Course on FPGA Design in South and Southeast Asia
Next: Signal value clears for no reason [VHDL, ISE 10.1]
From: lastminutepanic on 7 Aug 2010 13:14
Hello,

For my Masters project, I'm trying to implement a multiplier, and a
MAC where the outputs are calculated per clock cycle and stored in a
text file which can then be used for further processing.

However, both these designs are giving out partial products(I guess
they are partial products) at the output too, before they give the
final result..I've tried changing the codes, changing clock frequency
in testbench etc. but nothing seems to work...

Is there any way to implement a output_ready signal for multipliers/
adders?(I saw a few codes using shifter for rdy, but could not
understand the logic behind it)

I'm using the embedded Mult18X18 in Spartan 3..but do not want to use
the Core generator for MAC(which has a RDY signal) as the code has to
be kept portable.


Code for multiplier is--

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.NUMERIC_STD.ALL;

entity Single_Mul is
Port ( Clk : in STD_LOGIC;
Mul1 : in STD_LOGIC_VECTOR (17 downto 0);
Mul2 : in STD_LOGIC_VECTOR(17 downto 0);
Mul_Res : out STD_LOGIC_VECTOR(35 downto 0));
end Single_Mul;

architecture Behavioral of Single_Mul is
Signal Prod : Signed( 35 downto
0):="000000000000000000000000000000000000";

begin
process(clk)is
begin

if rising_edge(Clk) then
Prod<=signed(Mul1)*signed(Mul2);
end if;
end process;

Prod_Process:Process(prod)
begin

Mul_Res<=STD_LOGIC_VECTOR(Prod);--here I was hoping this process is
invoked only when the --clocked process above is complete...

end process;

end Behavioral;


Code for MAC--

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_STD.all;


entity Mul_Adder is
Port ( MulA : in STD_LOGIC_VECTOR (17 downto 0);
MulB : in STD_LOGIC_VECTOR(17 downto 0);
Multi_Res : in STD_LOGIC_VECTOR(35 downto 0);
MulAdd_Res : out STD_LOGIC_VECTOR(35 downto 0);
Clk : in STD_LOGIC);
end Mul_Adder;

architecture Behavioral of Mul_Adder is
shared variable temp :SIGNED(35 downto
0);--:="000000000000000000000000000000000000";
Signal temp1:SIGNED(35 downto
0):="000000000000000000000000000000000000";


begin
Process(Clk) is
BEGIN

If rising_edge(Clk)
then
temp:=signed(MulA)*signed(MulB);
temp1<=signed(Multi_Res)+temp;
end if;

End Process;

MulAdd_Res_process: Process(temp1)
begin
MulAdd_Res<=STD_LOGIC_VECTOR(temp1);
end Process;


end Behavioral;


Am I doing anything wrong here? Any help in this direction would be
useful
From: Thomas Stanka on 9 Aug 2010 11:15
On 7 Aug., 19:14, lastminutepanic <sheetalgandhi...(a)gmail.com> wrote:

> For my Masters project, I'm trying to implement a multiplier, and a
> MAC where the outputs are calculated per clock cycle and stored in a
> text file which can then be used for further processing.

Calculation per clock cycle and storing in file means unnecessary mix
of RTL and behavioral in most cases.
Per cycle is used for HW, storing in files is pure SW. Are you sure
you intend this?

> However, both these designs are giving out partial products(I guess
> they are partial products) at the output too, before they give the
> final result..I've tried changing the codes, changing clock frequency
> in testbench etc. but nothing seems to work...

Partial products for 12*34 would be 340 and 68.
You see intermediate results when not every bit is settled. This means
you need to wait until the output is settled.
normally you do combinatoric between two register stages and your
timing analysis ensures the output is settled before the next clock
cycle.
But in real hardware you will see some intermediate results even on
the output register when having more then one bit. You just need to
ensure, that the output settling between first and last bit is small
enough for your requirements (often within less than 1 ns).

> Is there any way to implement a output_ready signal for multipliers/
> adders?(I saw a few codes using shifter for rdy, but could not
> understand the logic behind it)

Yes. But I doubt I can teach you this in 2 lines, when you didn't
learn this up to now.

> library IEEE;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> use IEEE.NUMERIC_STD.ALL;

Never mix those two packages without very good reason. It is like
left foot on brake an right foot on gas at the same time.

> architecture Behavioral of Single_Mul is
> Signal Prod : Signed( 35 downto
> 0):="000000000000000000000000000000000000";

Initialisations of signals shall be used only with good reason. It
masks potential errors. If needed, use (others=>'0') instead of
"00..00"

> if rising_edge(Clk) then
> Prod<=signed(Mul1)*signed(Mul2);
> end if;
> end process;
>
> Prod_Process:Process(prod)
> begin
>
> Mul_Res<=STD_LOGIC_VECTOR(Prod);--here I was hoping this process is
> invoked only when the --clocked process above is complete...

Hopeless. If you move this line between rising_edge(Clk) and end if,
you get something like you intended (but one clock cycle latency)

regards Thomas

From: Kolja Sulimma on 9 Aug 2010 15:16
On 9 Aug., 17:15, Thomas Stanka <usenet_nospam_va...(a)stanka-web.de>
wrote:

> > use IEEE.STD_LOGIC_UNSIGNED.ALL;
> > use IEEE.NUMERIC_STD.ALL;
>
> Never mix those two packages without very good reason.  It is like
> left foot on brake an right foot on gas at the same time.

Indeed. Use numeric_std only.
>
> > architecture Behavioral of Single_Mul is
> > Signal Prod : Signed( 35 downto
> > 0):="000000000000000000000000000000000000";
>
> Initialisations of signals shall be used only with good reason.
I don't agree.
The initialization should match the hardware.
So if you have one of these old fashioned ASIC registers that come
up at a random state you initialize them to "U" (which is the default
for VHDL)
but in modern FPGAs and many ASIC libraries registers have a defined
power on
state and simulation should reflect that.

XST honors the initialization values during synthesis and I expect
other tools to do the same.

Kolja
From: KJ on 9 Aug 2010 16:19
On Aug 9, 3:16 pm, Kolja Sulimma <ksuli...(a)googlemail.com> wrote:

>
> > Initialisations of signals shall be used only with good reason.
>
> I don't agree.
> The initialization should match the hardware.
> So if you have one of these old fashioned ASIC registers that come
> up at a random state you initialize them to "U" (which is the default
> for VHDL)
> but in modern FPGAs and many ASIC libraries registers have a defined
> power on
> state and simulation should reflect that.
>

Do you think it's still a good idea to have signal initializations to
'match the hardware' in the following contexts as well?
- Free running oscillator on the board is input to the FPGA which
implies there is no control of the setup/hold time of anything for
that very first rising edge of the clock (which then overwrites that
initialization anyway)?
- Unskilled designer that does not provide any form of hardware reset
to their logic.

KJ
From: Thomas Stanka on 10 Aug 2010 03:39
Hi,

On 9 Aug., 21:16, Kolja Sulimma <ksuli...(a)googlemail.com> wrote:
> XST honors the initialization values during synthesis and I expect
> other tools to do the same.

You either limit the number of tools you are using to a small degree
or expecting in vain.

Nevertheless using initialisations in signal declaration is sometimes
necessary but is more likely masking design errors during simulation.
So I suggest to use them not without justification.

bye Thomas
 |  Next  |  Last
Pages: 1 2
Prev: ICTP Regional Course on FPGA Design in South and Southeast Asia
Next: Signal value clears for no reason [VHDL, ISE 10.1]