Implementation

[hgleamon1]

Hello,

I have implemented an embedded processor design on a Spartan 6 using only XPS rather than Project Navigator in ISE12.4. The design mixes both Xilinx and proprietary IP connected using the PLB.

All seems OK so far. Running Bitgen produces the following warning in DRC:

WARNING:PhysDesignRules:372 - Gated clock. Clock net ][85314_919 is sourced by a
   combinatorial pin. This is not good design practice. Use the CE pin to
   control the loading of data into the flip-flop.

In principle, I understand this but the name of the net is not so informative. Checking the Clock report from the Design Summary shows this:

Clock Net

Routed

Resource

Locked

Fanout

Net Skew(ns)

Max Delay(ns)

][85314_919

ROUTED

Local

265

0.000000

1.952000

(Other clock nets removed)

I wanted to know where this clock net was coming from so that I could eliminate the offending combinatorial source, so I fired up FPGA Editor and searched for the net. The attachment shows a screenshot of the net attributes and the net source (I trust it is readable).

Now I am completely confused. The clock net source appears to be a signal embedded in the fifo_generator_6_2 instantiation (it even looks like a part of the reset block, if I interpret the names correctly).

The fifo instantiation looks like this:

fifo_inst : fifo_32x36
  port map (
   rst => fifoRst,
   wr_clk => clk,
   rd_clk => clk25MHz,
   din => fifoData,
   wr_en => fifoWrite,
   rd_en => RDREQ,
   dout => dataFromFifo,
   full => fifoFull,
   empty => RDEMPTY);

where fifoRst is fact the Bus2IP_Reset from the PLB. clk is a 50MHz PLB clock and clk25MHz is a local-side clock, generated from a DCM. The read and write control signals come from a state machine specifically designed to handle this fifo instantiation.

I don't really understand why this particular clock net signal is being sourced from here, why it is even being used as clock for other logic nor do I understand how I might solve the issue.

Experimentally, the design appears to work - by that I mean that all outputs from the FPGA are as expected and the overall system seems to be functioning without error or other anomalous behaviour, so in one sense, I could ignore it completely but I would like to know what is going on.

Thanks,

Howard

[eteam00]

I'm just guessing here...  The reset is an async reset, and is therefore edge-sensitive

It is entirely true that no edge-sensitive functions should be driven directly from the output of a LUT.  Try clocking the reset signal, or changing the FIFO reset type to synchronous.

-- Bob Elkind

[hgleamon1]

Hello Bob,

Thanks for the response.

Changing the FIFO to a synchronous reset is not possible as it is an independent clock FIFO (coregen states that synchronous resets are only available for common clock FIFOs). The FIFO is being used to cross clock domains and so must be independent in this sense.

I added a process to clock the reset thus:

RESET_PROCESS : PROCESS (Bus2IP_Clk)
begin
 if rising_edge(Bus2IP_Clk) then
  fifoRst  <= Bus2IP_Reset;
 end if;
end PROCESS RESET_PROCESS;

Excuse my ignorance if I misunderstood your suggestion.

The result is much the same - a warning from Bitgen DRC and a strange clock net name. However, the source (as I understand it) now seems to be a different block (see attachment) - the External Memory Controller IP! The actual clock usage pin is on a counter located in a proprietary IP block.

Grateful for any continued assistance.

Regards,

Howard

[eteam00]

The actual clock usage pin is on a counter located in a proprietary IP block.

Grateful for any continued assistance.

Hmmm... it will be quite difficult to provide "continued assistance" without details (source code) of the "proprietary IP".  So here's the non-specific assistance:

• do NOT use the unregistered output of a LUT (or any combinatorial logic function, except BUFGMUX) as a clock.

No doubt, you already knew as much, but it had to be said for the wider audience of readers.

-- Bob Elkind

[hgleamon1]

Hmmm... it will be quite difficult to provide "continued assistance" without details (source code) of the "proprietary IP". 

Yes, I appreciate that. A bit difficult for me to take those specifics further, too. I'll think about what I can post here for later.

So here's the non-specific assistance:

• do NOT use the unregistered output of a LUT (or any combinatorial logic function, except BUFGMUX) as a clock.

No doubt, you already knew as much, but it had to be said for the wider audience of readers.

This is the thing - I have no idea why this signal is being used and routed in this way. The "proprietary IP" uses a clock generated from a DCM and an asynchronous reset derived from the PLB reset. I do not understand why this signal is even being distributed for logic, let alone a clock.

I should perhaps state that I didn't write this IP, either. I shall try to convert the whole IP block to be a synchronously reset unit to see if that makes a difference. I am aware that the Xilinx general design guide recommends synchronous resets but this was originally a block targeting an Altera device and was written 10+ years ago. This is legacy support, I guess!

Thanks again.

Howard

[mcgett]

These thread seems to have gone off in a bad direction.  The warning message was about a clock pin, but this devolved in to a discussion about reset pin.  The FPGA Editor screen shot was not the entirety of the destinations for this net, if you look further you should see a .CLK load.

[eteam00]

These thread seems to have gone off in a bad direction.  The warning message was about a clock pin, but this devolved in to a discussion about reset pin.

I was thinking that the XST tools consider an asynchronouse set/reset equivalent to a clock (they are both edge-active functions), and the base problem might indeed be an async set/reset.  If they don't consider async s/r equivalent to a clock, they should (at least in this one implementation aspect).  Either case, the discussion of async set/reset and LUT outputs is still quite useful to the orginal poster.

The FPGA Editor screen shot was not the entirety of the destinations for this net, if you look further you should see a .CLK load.

There were a boatload of .SR pins visible in the list.  And there is a .CLK pin in the load list 3 rows below the signal source.

-- Bob Elkind

[eteam00]

I should perhaps state that I didn't write this IP, either. I shall try to convert the whole IP block to be a synchronously reset unit to see if that makes a difference.

You might also convert the clock loads (driven from an "amux" output) to clock enable loads, and use the conventional system clock for clocking the registers which were connected to the "amux" output.  Are you familiar with using clock enables?

-- Bob Elkind

[mcgett]

> And there is a .CLK pin in the load list 3 rows below the signal source.

Yes there is, I missed this on my first look.  The register located in SLICE_X34Y66 is at least one of the reasons behind the warning message.

> If they don't consider async s/r equivalent to a clock, they should

The reason behind the warning message on non-clock buffers driving clock pins of registers is that this can have very high skews that will create setup or hold problems, may have glitches due to combinatorial logic driving the clock creating a transition on each glitch, and are usually due to a mistake in the HDL code.  Note: there are cases where this is a perfectly acceptable design practice.

An asynchronous set/reset pin on the other hand is level sensitive.  High skews should not cause any issues as the signal should be asserted for multiple cycles, a glitch on the signal will likely cause no issues unless a clock edge came during the deassertion which will be fixed when it reasserts and a traditional driven by combinatorial logic (hopefully registered one or more times for a clean synchronous deassertion).  There is a required recovery time between the deassertion and the next clock edge and this would be handled by the timing tools.

[hgleamon1]

---

You might also convert the clock loads (driven from an "amux" output) to clock enable loads, and use the conventional system clock for clocking the registers which were connected to the "amux" output.  Are you familiar with using clock enables?

---

In short - no.

I will admit that I don't really understand how the clocks and resets are generated and distributed throughout the physical device. Referring to UG382, I had (rather naively) expected that once a clock is generated and output from a PLL or DCM that is automatically routed on the dedicated clock nets without additional input from me, the user (i.e. if I don't deliberately constrain the clock net in another way).

Thus, when I write the code that states if rising_edge(dcm_clk_output_1) (or similar), then it is exactly that clock from the global resource. I digress slightly.

Looking at the offending clock net properties again, the .CLK input is always the same and the name (once I have traced it through in FPGA Editor) implies it is a part of a 72 bit signal used as a counter. Having just written that, the "signal", is infact, a variable within a VHDL process. I'll give a pseudo code snippet here:

process (clk, rstn)

  variable bit_number : integer range 72 downto 1; 

if (rstn = '0')

 -- pseudo code

 reset other signals in the state machine process

 note: bit_number is NOT assigned here

elsif (clk'event and clk = '1') then

<< snip of start of case statement >>

when certain_condition =>

  bit_number := 1;

when next_condition =>

  if (bit_number = 72) then

    do something with it

  else

    bit_number := bit_number + 1;

  end if;

-- end of pseudo code

I hope that severely edited fragment is enough to give an idea. In summary, perhaps, a variable is defined but never given a reset value at any time. It is then assigned during part of the FSM process and then incremented as the FSM progresses.

So, two things stick out in my mind. 1. The process is reset asynchronously. 2. The defined variable is never reset within the process.

This is how I intend to approach this.

I have never liked using variables in this way, so I shall change the variable to a global signal, to be assigned an initial value, e.g. signal bit_number : integer range 72 downto 1 := 1;

Change the process to be reset synchronously (it is actually my intention to change the whole legacy design to be fully synchronous, but I will worry about this later).

Your guidance and suggestions are much appreciated.

Regards,

Howard