FPGA Central

SRLen7 : SRL16
-- synthesis translate_off
generic map( INIT => x"0000")
-- synthesis translate_on
port map (Q => enadd5_d4,
A0 => '1', A1 => '1', A2 => '0', A3 => '0',
CLK => clock, D => enadd5);


PROCESS(clock,reset)
begin
if reset ='1' then
BITVECTOR4 <= (others => '0'); EVECTOR4 <= (others => '0');
elsif clock'event and clock ='1' then

if equal9='1' and enadd5_d4='1' then
BITVECTOR4 <= bitv; EVECTOR4 <= endvector;
else
BITVECTOR4 <= (others => '0'); EVECTOR4 <= (others => '0');
end if;
end if;
end process;

I had the above code synthesized by using synplify pro and it gave me
a negative slack :
Type Pin
Net Time Slack

SRLen7 SRL16 Q
enadd5_d4 2.772 -0.707
So I changed the code by moving the output of SRL16 into the process
and reducing the shift delay by one clock

in srl16 and the slack went away.

SRLen7 : SRL16
-- synthesis translate_off
generic map(
INIT => x"0000")
-- synthesis translate_on
port map (Q => enadd5_d3,
A0 => '0', -- changed from 1 to 0
A1 => '1', A2 => '0', A3 =>
'0', CLK => clock, D => enadd5);

PROCESS(clock,reset)
begin
if reset ='1' then
BITVECTOR4 <= (others => '0'); EVECTOR4 <= (others => '0');
enadd5_d4 <= '0'; ---- **********moved
into the process
elsif clock'event and clock ='1' then
enadd5_d4 <= enadd5_d3; ------ ******
if equal9='1' and enadd5_d4='1' then
BITVECTOR4 <= bitv; EVECTOR4 <= endvector;
else
BITVECTOR4 <= (others => '0'); EVECTOR4 <= (others
=> '0');
end if;
end if;
end process;

I had changed the code because of a suggestion in one of the notes to
get the signal inside into the process in case it doesnt meet the
timing. thats what I did and got the timing corrected.
What I dont understand is SRL16 is a simple shift reister and the
output of SRL16 is just like any other flipflop output with no
combinational logic at the output.
So why was it generating a negative slack since if u see the code the
signal enadd5_d4 is not at all critical but the synplify gives it a
critical status. I am digging into the synplify pro docs too in the
meantime.

"ni" <[email protected]> wrote in message
news:[email protected]...

> What I dont understand is SRL16 is a simple shift reister and the
> output of SRL16 is just like any other flipflop output with no
> combinational logic at the output.

Wrong.

An SRL16 *functions* just like a simple shift register, but physically it is
a special configuration of a LUT primitive. The setup time and clock-to-out
time is very different from a FF primitive in the fabric. When you are doing
a high-speed design, you should always try to make the last stage of your
shift register pipeline use a dedicated FF. Most synthesis tools will do
this for your automatically if you just write a straightforward shift
register in RTL. No need to go instantiating things.

-Ben-

On Apr 4, 7:28 am, "Ben Jones" <ben.jo...@xilinx.com> wrote:
> "ni" <nbg2...@gmail.com> wrote in message
>
> news:[email protected]...
>
> > What I dont understand is SRL16 is a simple shift reister and the
> > output of SRL16 is just like any other flipflop output with no
> > combinational logic at the output.
>
> Wrong.
>
> An SRL16 *functions* just like a simple shift register, but physically it is
> a special configuration of a LUT primitive. The setup time and clock-to-out
> time is very different from a FF primitive in the fabric. When you are doing
> a high-speed design, you should always try to make the last stage of your
> shift register pipeline use a dedicated FF. Most synthesis tools will do
> this for your automatically if you just write a straightforward shift
> register in RTL. No need to go instantiating things.
>
> -Ben-

So what your are implying is that its advisable to write the code in
the following way
---------------------------------------------------------------------------------------------------------------------------------------------
PROCESS(clock,reset)
begin
if reset = '1' then
en4 <= '0';
elsif clock'event and clock ='1' then
en4 <= en3;
end if;
end process;

SR : SRL16 generic map
(INIT => x"0000")
port map (Q => en3,
A0 => '0',
A1 => '1',
A2 => '0',
A3 => '0',
CLK => clock,
D => input);

---------------------------------------------------------------------------------------------
instead of



SR : SRL16 generic map
(INIT => x"0000")
port map (Q => en4,
A0 => '1',
A1 => '1',
A2 => '0',
A3 => '0',
CLK => clock,
D => input);
Is that right?

ni wrote:
> On Apr 4, 7:28 am, "Ben Jones" <ben.jo...@xilinx.com> wrote:
>> "ni" <nbg2...@gmail.com> wrote in message
>>
>> news:[email protected]...
>>
>>> What I dont understand is SRL16 is a simple shift reister and the
>>> output of SRL16 is just like any other flipflop output with no
>>> combinational logic at the output.
>> Wrong.
>>
>> An SRL16 *functions* just like a simple shift register, but physically it is
>> a special configuration of a LUT primitive. The setup time and clock-to-out
>> time is very different from a FF primitive in the fabric. When you are doing
>> a high-speed design, you should always try to make the last stage of your
>> shift register pipeline use a dedicated FF. Most synthesis tools will do
>> this for your automatically if you just write a straightforward shift
>> register in RTL. No need to go instantiating things.
>>
>> -Ben-
>
> So what your are implying is that its advisable to write the code in
> the following way
> ---------------------------------------------------------------------------------------------------------------------------------------------
> PROCESS(clock,reset)
> begin
> if reset = '1' then
> en4 <= '0';
> elsif clock'event and clock ='1' then
> en4 <= en3;
> end if;
> end process;
>
> SR : SRL16 generic map
> (INIT => x"0000")
> port map (Q => en3,
> A0 => '0',
> A1 => '1',
> A2 => '0',
> A3 => '0',
> CLK => clock,
> D => input);
>
> ---------------------------------------------------------------------------------------------
> instead of
>
>
>
> SR : SRL16 generic map
> (INIT => x"0000")
> port map (Q => en4,
> A0 => '1',
> A1 => '1',
> A2 => '0',
> A3 => '0',
> CLK => clock,
> D => input);
> Is that right?
No, no--he's suggesting you write behavioral code, which infers the SRL
you would don't have to instantiate it. If you use Synplify, for
example, it will make the last stage of the delay line a packed flipflop
depending upon the timing requirements. So then you needn't worry about
what primitives are being used. You shouldn't instantiate primitives
unless completely necessary. It destroys clarity, maintainability, and
portability. This is an example from the Synplify help files that shows
how to make a byte-wide 4-cycle delay line:

entity srltest is
port ( inData: std_logic_vector(7 downto 0);
clk, en : in std_logic;
outStage : in integer range 3 downto 0;
outData: out std_logic_vector(7 downto 0)
);
end srltest;

architecture rtl of srltest is
type dataAryType is array(3 downto 0) of std_logic_vector(7 downto 0);
signal regBank : dataAryType;

begin
outData <= regBank(outStage);
process(clk, inData)
begin
if (clk'event and clk = '1') then
if (en='1') then
regBank <= (regBank(2 downto 0) & inData);
end if;
end if;
end process;
end rtl;

It's cleaner in Verilog, of course.
-Kevin

ni wrote:

> So what your are implying is that its advisable to write the code in
> the following way

If I were having trouble making timing,
I would use a generic shifter.
It is faster in nS and in work hours.
Registers are free on many fpga designs.

-- Mike Treseler

On Apr 4, 3:38 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
> ni wrote:
> > So what your are implying is that its advisable to write the code in
> > the following way
>
> If I were having trouble making timing,
> I would use a generic shifter.
> It is faster in nS and in work hours.
> Registers are free on many fpga designs.
>
> -- Mike Treseler

I have recently started(1 week) using Synplify pro. For two years in
my fpga designs I never used synplify pro. For most of the generic
component I used to use core generator and then instantiate those
component in my vhdl code. I was using xilinx XST extensivley and
hence never go these problems. Unfortunately before using synplify pro
for mycurrent design I have used core genrator in most of the
components. So now I am thingkin of cleaning up the code by changing
the cores for example adders , subtractors, SRL16s,
BRAMs, ROMS etc to vhdl statements.
Are ther any good documents for vhdl coding styles to infer the
various components in synplify pro?

Thanks for all the suggestions above.

ni wrote:

> I have recently started(1 week) using Synplify pro. For two years in
> my fpga designs I never used synplify pro. For most of the generic
> component I used to use core generator and then instantiate those
> component in my vhdl code.

Next time post to comp.lang.vhdl.

Start with the Synplify pro vhdl synthesis guide.
Most of the core generator blocks can be replaced by a few
lines of vhdl code, but there is a learning period.

Here's some brand A examples :
http://www.altera.com/support/examples/vhdl/vhdl.html

Here's some brand X examples :
http://www.xilinx.com/support/docume..._synthesis.htm

Here are my examples.
http://home.comcast.net/~mike_treseler/

Good luck.

-- Mike Treseler