FF with CE doesn't synthesize correctly by XST?

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.

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

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

MM wrote:

II).

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

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

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

flop

process?

Tried, it doesn't work.

Xilinx

library

I would like to avoid this.

wasn't

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

/Mikhail

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

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

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.

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 was connected to GND (doesn't matter what D is connected to), things would

Mikhail,

I see your point!

The following code will address the problem tested against F.31i

library ieee; use ieee.std_logic_1164.all;

entity ff_test is port (clk, sync_reset, clk_ena : in std_logic; outf : inout std_logic ); end entity ;

architecture test of ff_test is signal din : std_logic := '1' ; attribute keep : boolean ; attribute keep of din : signal is true ;

begin process(clk) begin if (clk'event and clk = '1') then if sync_reset='1' then outf I want the code below to synthesize as a FF with a sync reset and CE,

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

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

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

the

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!

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

Jake

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