QII to QIISP2 Migration, Warning: Entity "xxx" contains only dangling pins

@roger,

--- Quote Start ---

Due to some issues during compilation, where the compiler declared that I could not connect an incoming clock signal to a logic device input, I decided to move to the Quartus II Version 9.0 Service Pack 2 Web Edition.

--- Quote End ---

It is in general no good design practice to use external clock signals for other applications than clocking registers and flip-flops (or as inputs to PLLs).

So the compiler is hinting you not to do this. Switching to other versions of the software is not a solution to the basic problem.

Hope this helps...

--- Quote Start ---

I had a (mostly) working system for MAX II using Quartus II Version 9.0 Web Edition. Due to some issues during compilation, where the compiler declared that I could not connect an incoming clock signal to a logic device input, I decided to move to the Quartus II Version 9.0 Service Pack 2 Web Edition. After installing QIIV9.0SP2, I got the "standard" warning that the databases were being deleted. I re-complied the function (.BDF format) that was giving problems earlier only to ultimately find a fluke caused by insertion of a component into a wire, then deletion of the center part of the wire spanning the component (I put in an inverter) that was previously causing my error. When the function was fixed, I tried compiling the top-level system, and was treated to a warning:

Warning: Entity "TestProject" contains only dangling pins.

The BDF for Test Project shows pin assignment boxes next to each IO port.

What has happened, and how is it fixed?

Thanks,

Roger Watkins

roger@pervalidus.com

--- Quote End ---

Hi,

could you post your BDF larger ????

Kind regards

GPK

--- Quote Start ---

@roger,

It is in general no good design practice to use external clock signals for other applications than clocking registers and flip-flops (or as inputs to PLLs).

So the compiler is hinting you not to do this. Switching to other versions of the software is not a solution to the basic problem.

Hope this helps...

--- Quote End ---

Thank you for the input, and it applies well for FPGA's (I have used the Cyclone III this way) that have PLL's. The MAX II series have no PLL's so our only choice is to use an external clock to drive at least some logic in the circuit... Further, QII has a bad habit of not following the documentation and optimising out buffers inserted in code to limit fanout for timing control purposes. As such you have further highlighted a "basic problem" that the compiler is not well versed on the capabilities of the device for which it is compiling. You are correct, however, about switching to the newer version of QII, which did not help.

After much effort, I have determined that the strange failure to compile was fixed simply by attempting to re-compile the exact same code. For some reason, the compiler did not properly place the results of its own first try enumeration and pin assignments where it could use them so was unable to complete the compilation (looks like a bug to me). It is also frustrating that the documentation with Quartus II or online nowhere describes the reason or meaning of the dangling pins error.

Hi Roger,

--- Quote Start ---

The MAX II series have no PLL's so our only choice is to use an external clock to drive at least some logic in the circuit...

--- Quote End ---

Even if no PLLs are available you should not drive logic by clock signals to make derived clocks. In this case the best thing to do is to use the clock available to clock your registers and flip-flops.

In case you need something like a "clock" at a lower speed, what you actually have to do is to use an enable signal or so. An example of this is as follows:

 
always @(posedge clock)
  if (reset)
    ... blah blah blah ...
  else begin
    if (enable) begin
       ... do here the things that you want to do under certain conditions
       ... or at a lower speed.
    end
  end

the enable signal can be generated from other always processes.

I do not see the need why you would need a derived clock or why you would be obliged to steer logic directly from a clock signal.

Hope this helps...

"I do not see the need why you would need a derived clock or why you would be obliged to steer logic directly from a clock signal."

Hi Sanmao,

Now I am really puzzled... The purposes of this circuit are:

1. Generate a series of time-sequenced pulses to control external analog and RF circuit operations. The sequencing of these operations enables the

operation of our circuit as a whole.

2. Generate synchronous and asynchronous serial interfaces for several different devices.

3. Translate to/from the asynchronous serial interface for communications with the synchronous serial interfaces.

For these purposes, operation of the CPLD as a state machine is not adequate. I must use a clock signal from somewhere to generate the sequencing and timing required. I understand there is likely a better way than I have chosen, and am very much open to learn what this might be.

One other request, as I am originally a C/C++ and hardware type, who is an extreme novice at VHDL and its kin: Is there a simple way to put your last reply into a .bdf form, or implement it using the Assignment IDE?

--- Quote Start ---

"I do not see the need why you would need a derived clock or why you would be obliged to steer logic directly from a clock signal."

Hi Sanmao,

Now I am really puzzled...

--- Quote End ---

What Sanmao is saying is that it is not considered good practice to use clock as data. If you connect a clock signal to the data input (and not the clock) of a register, you are using clock as data. This is why Quartus might give you a warning. You said Quartus didn't let you, but we assume it was just a warning because it does let you.

As every good practice, there are times when it might make sense to ignore it. But in most cases you should not.

As Pletz asked, try to repost your BDF complete and at higher resolution, otherwise we can't see what you are trying to do.

--- Quote Start ---

What Sanmao is saying is that it is not considered good practice to use clock as data. If you connect a clock signal to the data input (and not the clock) of a register, you are using clock as data. This is why Quartus might give you a warning. You said Quartus didn't let you, but we assume it was just a warning because it does let you.

As every good practice, there are times when it might make sense to ignore it. But in most cases you should not.

As Pletz asked, try to repost your BDF complete and at higher resolution, otherwise we can't see what you are trying to do.

--- Quote End ---

The reason for putting clock into logic in this case was to invert the signal in a NOT gate so I could use Clock and NotClock to more reliably control the timing of the circuit, knowing that the delay of the signal was sub-5us for the circuit before and using a NotClock after a Clock was used for the DFF gating for delay and one-shot purposes.

I am sorry about the post being poor resolution. The original I provided to the forum was an 184KB .gif file, which was decimated to an 11.9KB jpg when I tried again today to attach it. It is now OBE (overcome by events) as the base problem, as described above, was a bug in the .bdf editor that allows one to drop a NOT gate over a wire, merging the terminals of the NOT gate to the wire, then allowing deletion of the connection between NOT gate input and output, whilst keeping the wire declaration for either side of the NOT gate ***IDENTICAL***. This is huge, and has impacted several of my .bdf function blocks as I am used to schematic entry programs that properly handle this sequence of operations.