FF with CE doesn't synthesize correctly by XST?

M

MM

Hi all,

I want the code below to synthesize as a FF with a sync reset and CE,
however XST does something quite different (target technology is Virtex II).
It routes my clk_ena signal to the REV pin and ties D and CE to VCC. The
sync_reset is recognized OK and gets routed correctly to the SR pin. I
realize that if I had a "regular" input signal instead of '1' under the
clock enable statement it would have worked fine, but what should I do if I
need to tie it to VCC?

process(clk)
begin
if rising_edge (clk) then
if sync_reset='1' then
outf <= '0';
elsif clk_ena='1' then
outf <= '1';
end if;
end if;
end process;

Thanks,
/Mikhail
 
M

Mike Treseler

MM said:
Hi all,

I want the code below to synthesize as a FF with a sync reset and CE,
however XST does something quite different (target technology is Virtex II).
It routes my clk_ena signal to the REV pin and ties D and CE to VCC.

XST is just doing its job, making a valid netlist per your description.
A synth will often do unexpected things, but it will work just fine.
The
sync_reset is recognized OK and gets routed correctly to the SR pin. I
realize that if I had a "regular" input signal instead of '1' under the
clock enable statement it would have worked fine,

Both are "fine".
You write the description, the synth makes the netlist.

-- Mike Treseler


-- makes an fdre module on Virtex:
library ieee;
use ieee.std_logic_1164.all;

entity sreset_ce is
port (
clk : in std_ulogic;
clk_ena : in std_ulogic;
sync_reset : in std_ulogic;
inf : in std_ulogic;
outf : out std_ulogic);

end entity sreset_ce;

architecture synth of sreset_ce is
begin
process(clk) is
begin
if rising_edge (clk) then
if sync_reset = '1' then
outf <= '0';
elsif clk_ena = '1' then
outf <= inf;
end if;
end if;
end process;
end architecture synth;
 
C

Chris Ebeling

Mikhail,
Your last statement suggests a solution.
Have you tried creating signal and assigning that to one outside of the process?

I this may (or may not) work.

If you absolutely want some particular interconnect configuration of a Xilinx
Basic Element you can always instantiate any component in the the unisim library

(unisim_VCOMP.vhd) FDRE in this case

I'll also just mention XST implementation is logically correct even if it wasn't
what
you wanted.

Chris
 
M

MM

Mike Treseler said:
XST is just doing its job, making a valid netlist per your description.
A synth will often do unexpected things, but it will work just fine.

I don't think the netlist is valid. With D and CE both tied to VCC the flop
reverts to '1' on every clock regardless of my clk_ena signal. This is a
part of a bigger design that used to work on Spartan II. I only found the
problem when I moved it to Virtex II.... Any other ideas?

Thanks,
/Mikhail
 
M

Mike Treseler

MM said:
I don't think the netlist is valid. With D and CE both tied to VCC the flop
reverts to '1' on every clock regardless of my clk_ena signal.

Your description says outf is low for reset, high otherwise.
The only way to get a low with that description
is to reset and immediately disble the clock.

-- Mike Treseler
 
M

MM

OK, so how should I describe a D flip-flop with a synchronous reset and a
clock enable with the D input tied to VCC?

/Mikhail
 
M

MM

Chris Ebeling said:
Mikhail,
Your last statement suggests a solution.
Have you tried creating signal and assigning that to one outside of the process?

I this may (or may not) work.

Tried, it doesn't work.
If you absolutely want some particular interconnect configuration of a Xilinx
Basic Element you can always instantiate any component in the the unisim library

(unisim_VCOMP.vhd) FDRE in this case

I would like to avoid this.
I'll also just mention XST implementation is logically correct even if it wasn't
what
you wanted.

So, is there a way to describe what I want in VHDL so that XST will
understand it?

/Mikhail
 
V

Vinh Pham

You could try to break your process into two seperate ones. Sometimes
"rewording" your code has an effect on the synthesizer:

process(clk,inf)
begin
if rising_edge(clk) then
outf <= inf;
end if;
end process;

process(sync_reset,clk_ena,outf)
begin
if sync_reset = '1' then
inf <= '0';
elsif clk_ena = '1' then
inf <= '1';
else
inf <= outf;
end if;
end process;

If you get desperate, you can manually instantiate a FF. It won't be as
portable, of course.

From what code you have shown us, I can't see why the XST is doing what it's
doing, unless the logic generating sync_reset and clk_ena is somehow causing
you problems. You could run a quick experiment and synthesize only that
piece of FF code, in your post, making sync_reset and clk_ena into ports, to
see what the synthesizer does.

Best of luck.


Regards,
Vinh
 
M

MM

I've just tried synthesizing the same code for Spartan II. The result is
similar in terms of using REV pin, however in this case the D and CE are
(correctly in my opinion) tied to GND!

So, at the very least the synthesis results are not consistent and I still
think the netlist for Virtex II is not valid.

/Mikhail
 
V

Vinh Pham

I agree with Mikhail. The real problem is CE being connected to VCC. If it
was connected to GND (doesn't matter what D is connected to), things would
be fine.
 
M

MM

Thanks, Vinh. Just to clarify, I am using ISE 5.2.03i. Can anyone with 6.1
check this out? Here is the code:

entity weirdff is
Port ( clk : in std_logic;
clk_ena : in std_logic;
sync_reset : in std_logic;
outf : out std_logic);
end weirdff;

architecture rtl of weirdff is

begin

process(clk)
begin
if rising_edge (clk) then
if sync_reset ='1' then
outf <= '0';
elsif clk_ena ='1' then
outf <= '1';
end if;
end if;
end process;

end rtl;

Synthesize it for Spartan II and Virtex II and see the results in the FPGA
Editor....


/Mikhail
 
M

MM

Folks,

It seems that I owe Xilinx an apology... I overlooked little muxes with
invertors enabled at the CE and D inputs for Virtex II architecture. So, the
CE and D are not really tied to VCC and I have nobody to blame for my
problem:(

/Mikhail
 
A

Andy Peters

MM said:
Hi all,

I want the code below to synthesize as a FF with a sync reset and CE,
however XST does something quite different (target technology is Virtex II).
It routes my clk_ena signal to the REV pin and ties D and CE to VCC. The
sync_reset is recognized OK and gets routed correctly to the SR pin. I
realize that if I had a "regular" input signal instead of '1' under the
clock enable statement it would have worked fine, but what should I do if I
need to tie it to VCC?

process(clk)
begin
if rising_edge (clk) then
if sync_reset='1' then
outf <= '0';
elsif clk_ena='1' then
outf <= '1';
end if;
end if;
end process;

This is interesting. Carefully re-read the data sheet. Page 12 of
the "Virtex II Platform FPGAs: Detailed Description" data sheet says
that, "if SR is used, the BY input is used to force the storage
element into the opposite state."

In your case, SR is used as the sync reset. And you're not using
clk_ena as a clock enable, really, you're just using it as a
synchronous set, which the tool correctly recognizes and puts on REV
(through BY).

However, the odd thing is that both CE and D are set high in the flop,
which should result in the output of the flop _always_ high (except
when sync_reset) asserted. What are your pre- and post-route
simulations telling you?

=a
 
M

MM

However, the odd thing is that both CE and D are set high in the flop,
which should result in the output of the flop _always_ high (except
when sync_reset) asserted. What are your pre- and post-route
simulations telling you?

I will repeat my apology to Xilinx and that I was wrong as I overlooked
little muxes with invertors enabled at the CE and D inputs for Virtex II
architecture.

/Mikhail
 
V

Vinh Pham

It seems that I owe Xilinx an apology... I overlooked little muxes with
invertors enabled at the CE and D inputs for Virtex II architecture. So, the
CE and D are not really tied to VCC and I have nobody to blame for my
problem:(

Heh heh honest mistake. It's very easy for humans to overlook small
details. Or sometimes we spend so much time staring at a problem, we can't
see the "obvious." Finally the mystery is solved!
 
J

Jake Janovetz

What about the case where sync_reset=0 and clk_ena=0? Your code
doesn't describe the desired behavior for this case.

Jake
 
M

MM

Jake Janovetz said:
What about the case where sync_reset=0 and clk_ena=0? Your code
doesn't describe the desired behavior for this case.

Compare to the standard DFF description below. It is not required to
explicitly specify what to do when CE='0'...

process(clk)
begin
if rising_edge (CLK) then
if CE='1' then
Q <= D;
end if;
end if;
end process;

/Mikhail
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,042
Latest member
icassiem

Latest Threads

Top