ISE tools not detecting IOSTANDARD conflicts within bank

Hello,

I'm running ISE 9.2.03i on a design for Spartan 3E (3s250e-4tq144).

For whoever wishes to skip the long description below, the idea is
simple: The tools should not agree to place pins with conflicting IO
standards, such as LVTTL and LVCMOS25, on the same bank. And suddenly
I caught the tools not noticing this. This clearly looks like a bug,
among others because slight tweaks with the source Verilog makes the
tools reject the conflict, as they should.

My question is if someone has had similar experience, and if there's a
way to be sure that the tools indeed detect collisions when they
occur.

And now to the long story, for those who want the details. A lot of
details, which I doubt if they're relevant. But anyhow.

Recently, I've been doing this pin placement back-and-forth with the
board designer. Since the logic isn't written yet, I've written dummy
logic for the I/O pins. So each time the board designer wants a
change, I make the change in the UCF file, run an implementation, and
see if there are complaints. If they do, I get an error like the
example at the bottom of this post (in case of an IO standard
violation), or errors about problems in clock routing. For a few
years, this has been my method to quickly approve pinouts, until this
method failed recently.

What I found out, is that the tools agreed to place LVTTL pins and
LVCMOS25 on the same bank, if they were defined as inouts (that is,
bidirectional). I verified this by looking at the pad report and with
FPGA editor. If I made both pins outputs, the tools refused, as they
should. Other irrelevant tweaks with the code (such as commenting out
irrelevant parts) also woke up the sleeping guard.

The method I use for checking is instantiating a module like at the
bottom of this message. The IOSTANDARD parameter is set at
instantiation to the desired standard. The module generates DDR flip-
flops for both input and output, so if placement and routing succeeds,
I know that the certain pin's placement is OK, and that IOB registers
with the given clock can be packed. Or so I thought.

I have, of course, other modules for input-only, output-only,
nonclocked IOs, differential IOs and such.

This looks like a bug in the tools. Unfortunately, I failed to make a
simple example which demonstrates the bug. It looks like the tools are
OK most of the time, but it's disturbing that they may fail on me even
once (and make me approve a faulty board design).

So has anyone encountered a similar problem?

Thanks in advance,
    Eli

---------------------------


Example of error from placer.
============================

ERROR:Place:864 - Incompatible IOB's are locked to the same bank 3
   Conflicting IO Standards are:
   IO Standard 1: Name = LVCMOS25, VREF = NR, VCCO = 2.50, TERM = NONE
   List of locked IOB's:
   	data<0>
   	data<1>

   IO Standard 2: Name = LVTTL, VREF = NR, VCCO = 3.30, TERM = NONE
   List of locked IOB's:
   	testpoints<1>
   	testpoints<3>

The test module
===============

module testiob #(parameter IOSTANDARD = "LVTTL")
   (inout pin,
    input clk);

   wire   in, out, T;
   wire   in_fall, in_rise;

   reg 	  in_fall_d, in_rise_d;

   always @(posedge clk)
     begin
	in_fall_d <= in_fall;
	in_rise_d <= in_rise;
     end

   // This is completely useless setting. It just puts the IOB in
place.
   // It may drive the lines crazy if used for real

   IOBUF  #(.IOSTANDARD(IOSTANDARD)) iobuf
     (.IO(pin), .I(out), .O(in), .T(T));

   ODDR2 #(.SRTYPE("ASYNC")) out_ddr
     (.Q (out),
      .C0   (clk),
      .C1   (!clk),
      .CE (1'b1),
      .R (1'b0),
      .D0 (in_rise_d),
      .D1 (in_fall_d),
      .S (1'b0));

   ODDR2 #(.SRTYPE("ASYNC")) T_ddr
     (.Q (T),
      .C0   (clk),
      .C1   (!clk),
      .CE (1'b1),
      .R (1'b0),
      .D0 (in_rise_d),
      .D1 (in_fall_d),
      .S (1'b0));

   IDDR2 #(.SRTYPE("ASYNC")) in_ddr
     (
      .Q0   (in_rise),
      .Q1   (in_fall),
      .C0   (clk),
      .C1   (!clk),
      .CE   (1'b1),
      .D    (in),
      .R    (1'b0),
      .S (1'b0));

endmodule

On Apr 26, 1:59=A0pm, Eli <eli.billa...@gmail.com> wrote:
> Hello,
>
> I'm running ISE 9.2.03i on a design for Spartan 3E (3s250e-4tq144).
>
> For whoever wishes to skip the long description below, the idea is
> simple: The tools should not agree to place pins with conflicting IO
> standards, such as LVTTL and LVCMOS25, on the same bank. And suddenly
> I caught the tools not noticing this. This clearly looks like a bug,
> among others because slight tweaks with the source Verilog makes the
> tools reject the conflict, as they should.
>
> My question is if someone has had similar experience, and if there's a
> way to be sure that the tools indeed detect collisions when they
> occur.
>
> And now to the long story, for those who want the details. A lot of
> details, which I doubt if they're relevant. But anyhow.
>
> Recently, I've been doing this pin placement back-and-forth with the
> board designer. Since the logic isn't written yet, I've written dummy
> logic for the I/O pins. So each time the board designer wants a
> change, I make the change in the UCF file, run an implementation, and
> see if there are complaints. If they do, I get an error like the
> example at the bottom of this post (in case of an IO standard
> violation), or errors about problems in clock routing. For a few
> years, this has been my method to quickly approve pinouts, until this
> method failed recently.
>
> What I found out, is that the tools agreed to place LVTTL pins and
> LVCMOS25 on the same bank, if they were defined as inouts (that is,
> bidirectional). I verified this by looking at the pad report and with
> FPGA editor. If I made both pins outputs, the tools refused, as they
> should. Other irrelevant tweaks with the code (such as commenting out
> irrelevant parts) also woke up the sleeping guard.
>
> The method I use for checking is instantiating a module like at the
> bottom of this message. The IOSTANDARD parameter is set at
> instantiation to the desired standard. The module generates DDR flip-
> flops for both input and output, so if placement and routing succeeds,
> I know that the certain pin's placement is OK, and that IOB registers
> with the given clock can be packed. Or so I thought.
>
> I have, of course, other modules for input-only, output-only,
> nonclocked IOs, differential IOs and such.
>
> This looks like a bug in the tools. Unfortunately, I failed to make a
> simple example which demonstrates the bug. It looks like the tools are
> OK most of the time, but it's disturbing that they may fail on me even
> once (and make me approve a faulty board design).
>
> So has anyone encountered a similar problem?
>
> Thanks in advance,
> =A0 =A0 Eli
>
> ---------------------------
>
> Example of error from placer.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>
> ERROR:Place:864 - Incompatible IOB's are locked to the same bank 3
> =A0 =A0Conflicting IO Standards are:
> =A0 =A0IO Standard 1: Name =3D LVCMOS25, VREF =3D NR, VCCO =3D 2.50, TERM=
 =3D NONE
> =A0 =A0List of locked IOB's:
> =A0 =A0 =A0 =A0 data<0>
> =A0 =A0 =A0 =A0 data<1>
>
> =A0 =A0IO Standard 2: Name =3D LVTTL, VREF =3D NR, VCCO =3D 3.30, TERM =
=3D NONE
> =A0 =A0List of locked IOB's:
> =A0 =A0 =A0 =A0 testpoints<1>
> =A0 =A0 =A0 =A0 testpoints<3>
>
> The test module
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> module testiob #(parameter IOSTANDARD =3D "LVTTL")
> =A0 =A0(inout pin,
> =A0 =A0 input clk);
>
> =A0 =A0wire =A0 in, out, T;
> =A0 =A0wire =A0 in_fall, in_rise;
>
> =A0 =A0reg =A0 =A0in_fall_d, in_rise_d;
>
> =A0 =A0always @(posedge clk)
> =A0 =A0 =A0begin
> =A0 =A0 =A0 =A0 in_fall_d <=3D in_fall;
> =A0 =A0 =A0 =A0 in_rise_d <=3D in_rise;
> =A0 =A0 =A0end
>
> =A0 =A0// This is completely useless setting. It just puts the IOB in
> place.
> =A0 =A0// It may drive the lines crazy if used for real
>
> =A0 =A0IOBUF =A0#(.IOSTANDARD(IOSTANDARD)) iobuf
> =A0 =A0 =A0(.IO(pin), .I(out), .O(in), .T(T));
>
> =A0 =A0ODDR2 #(.SRTYPE("ASYNC")) out_ddr
> =A0 =A0 =A0(.Q (out),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE (1'b1),
> =A0 =A0 =A0 .R (1'b0),
> =A0 =A0 =A0 .D0 (in_rise_d),
> =A0 =A0 =A0 .D1 (in_fall_d),
> =A0 =A0 =A0 .S (1'b0));
>
> =A0 =A0ODDR2 #(.SRTYPE("ASYNC")) T_ddr
> =A0 =A0 =A0(.Q (T),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE (1'b1),
> =A0 =A0 =A0 .R (1'b0),
> =A0 =A0 =A0 .D0 (in_rise_d),
> =A0 =A0 =A0 .D1 (in_fall_d),
> =A0 =A0 =A0 .S (1'b0));
>
> =A0 =A0IDDR2 #(.SRTYPE("ASYNC")) in_ddr
> =A0 =A0 =A0(
> =A0 =A0 =A0 .Q0 =A0 (in_rise),
> =A0 =A0 =A0 .Q1 =A0 (in_fall),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE =A0 (1'b1),
> =A0 =A0 =A0 .D =A0 =A0(in),
> =A0 =A0 =A0 .R =A0 =A0(1'b0),
> =A0 =A0 =A0 .S (1'b0));
>
> endmodule

Similar problem, yes.  It is possible to specify an invalid IOTYPE
when instantiating an IOBUF.  Not a single step in the chain detects
it - it goes all the way -through- bitgen without a single warning.

"Version 12 will fix it"  (And it will pick winning lotto numbers
too!)

RK

On Apr 26, 11:14=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote:

> Similar problem, yes. =A0It is possible to specify an invalid IOTYPE
> when instantiating an IOBUF. =A0Not a single step in the chain detects
> it - it goes all the way -through- bitgen without a single warning.
>

At least it sounds like this issue is consistent. What I encountered
is more like voodoo.

On 30 Apr, 10:04, Eli <eli.billa...@gmail.com> wrote:
> On Apr 26, 11:14=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote:
>
> > Similar problem, yes. =A0It is possible to specify an invalid IOTYPE
> > when instantiating an IOBUF. =A0Not a single step in the chain detects
> > it - it goes all the way -through- bitgen without a single warning.
>
> At least it sounds like this issue is consistent. What I encountered
> is more like voodoo.

I've just discovered that "DCI CASCADE" can be applied in the wrong
order for a VIRTEX5 I'm working with. The whole problem is that XILINX
does its regression testing on its software using DESIGNS THAT ARE
CORRECT. Whereas the vast majority of compilations that users do are
on designs that are wrong.

Colin
.

On Apr 26, 3:59=A0pm, Eli <eli.billa...@gmail.com> wrote:
> Hello,
>
> I'm running ISE 9.2.03i on a design for Spartan 3E (3s250e-4tq144).
>
> For whoever wishes to skip the long description below, the idea is
> simple: The tools should not agree to place pins with conflicting IO
> standards, such as LVTTL and LVCMOS25, on the same bank. And suddenly
> I caught the tools not noticing this. This clearly looks like a bug,
> among others because slight tweaks with the source Verilog makes the
> tools reject the conflict, as they should.
>
> My question is if someone has had similar experience, and if there's a
> way to be sure that the tools indeed detect collisions when they
> occur.
>
> And now to the long story, for those who want the details. A lot of
> details, which I doubt if they're relevant. But anyhow.
>
> Recently, I've been doing this pin placement back-and-forth with the
> board designer. Since the logic isn't written yet, I've written dummy
> logic for the I/O pins. So each time the board designer wants a
> change, I make the change in the UCF file, run an implementation, and
> see if there are complaints. If they do, I get an error like the
> example at the bottom of this post (in case of an IO standard
> violation), or errors about problems in clock routing. For a few
> years, this has been my method to quickly approve pinouts, until this
> method failed recently.
>
> What I found out, is that the tools agreed to place LVTTL pins and
> LVCMOS25 on the same bank, if they were defined as inouts (that is,
> bidirectional). I verified this by looking at the pad report and with
> FPGA editor. If I made both pins outputs, the tools refused, as they
> should. Other irrelevant tweaks with the code (such as commenting out
> irrelevant parts) also woke up the sleeping guard.
>
> The method I use for checking is instantiating a module like at the
> bottom of this message. The IOSTANDARD parameter is set at
> instantiation to the desired standard. The module generates DDR flip-
> flops for both input and output, so if placement and routing succeeds,
> I know that the certain pin's placement is OK, and that IOB registers
> with the given clock can be packed. Or so I thought.
>
> I have, of course, other modules for input-only, output-only,
> nonclocked IOs, differential IOs and such.
>
> This looks like a bug in the tools. Unfortunately, I failed to make a
> simple example which demonstrates the bug. It looks like the tools are
> OK most of the time, but it's disturbing that they may fail on me even
> once (and make me approve a faulty board design).
>
> So has anyone encountered a similar problem?
>
> Thanks in advance,
> =A0 =A0 Eli
>
> ---------------------------
>
> Example of error from placer.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>
> ERROR:Place:864 - Incompatible IOB's are locked to the same bank 3
> =A0 =A0Conflicting IO Standards are:
> =A0 =A0IO Standard 1: Name =3D LVCMOS25, VREF =3D NR, VCCO =3D 2.50, TERM=
 =3D NONE
> =A0 =A0List of locked IOB's:
> =A0 =A0 =A0 =A0 data<0>
> =A0 =A0 =A0 =A0 data<1>
>
> =A0 =A0IO Standard 2: Name =3D LVTTL, VREF =3D NR, VCCO =3D 3.30, TERM =
=3D NONE
> =A0 =A0List of locked IOB's:
> =A0 =A0 =A0 =A0 testpoints<1>
> =A0 =A0 =A0 =A0 testpoints<3>
>
> The test module
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> module testiob #(parameter IOSTANDARD =3D "LVTTL")
> =A0 =A0(inout pin,
> =A0 =A0 input clk);
>
> =A0 =A0wire =A0 in, out, T;
> =A0 =A0wire =A0 in_fall, in_rise;
>
> =A0 =A0reg =A0 =A0in_fall_d, in_rise_d;
>
> =A0 =A0always @(posedge clk)
> =A0 =A0 =A0begin
> =A0 =A0 =A0 =A0 in_fall_d <=3D in_fall;
> =A0 =A0 =A0 =A0 in_rise_d <=3D in_rise;
> =A0 =A0 =A0end
>
> =A0 =A0// This is completely useless setting. It just puts the IOB in
> place.
> =A0 =A0// It may drive the lines crazy if used for real
>
> =A0 =A0IOBUF =A0#(.IOSTANDARD(IOSTANDARD)) iobuf
> =A0 =A0 =A0(.IO(pin), .I(out), .O(in), .T(T));
>
> =A0 =A0ODDR2 #(.SRTYPE("ASYNC")) out_ddr
> =A0 =A0 =A0(.Q (out),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE (1'b1),
> =A0 =A0 =A0 .R (1'b0),
> =A0 =A0 =A0 .D0 (in_rise_d),
> =A0 =A0 =A0 .D1 (in_fall_d),
> =A0 =A0 =A0 .S (1'b0));
>
> =A0 =A0ODDR2 #(.SRTYPE("ASYNC")) T_ddr
> =A0 =A0 =A0(.Q (T),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE (1'b1),
> =A0 =A0 =A0 .R (1'b0),
> =A0 =A0 =A0 .D0 (in_rise_d),
> =A0 =A0 =A0 .D1 (in_fall_d),
> =A0 =A0 =A0 .S (1'b0));
>
> =A0 =A0IDDR2 #(.SRTYPE("ASYNC")) in_ddr
> =A0 =A0 =A0(
> =A0 =A0 =A0 .Q0 =A0 (in_rise),
> =A0 =A0 =A0 .Q1 =A0 (in_fall),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE =A0 (1'b1),
> =A0 =A0 =A0 .D =A0 =A0(in),
> =A0 =A0 =A0 .R =A0 =A0(1'b0),
> =A0 =A0 =A0 .S (1'b0));
>
> endmodule

Xilinx pin configuration has been brain-dead forever.  It is slightly
better now, but not enough that it could be classified as "good."

I haven't manually generated UCF files in over a decade.  Back then,
the Xilinx tools would do *exactly* the wrong thing (from my
perspective):  if your top-level design had a net that wasn't in the
UCF, the tools would blithely assign the net to some random pin on the
package (bad), and if your UCF had a pin that wasn't in your top-level
design (perhaps because you were defensively coding your UCF in
advance of your design because of the other issue), the tools would
abort and complain about not having the pin in the design.

The tools are a bit better now, giving you some options on these
things, but I still don't trust them.

ALSO, with the different I/O standards, you have to realize that you
are inviting issues if you don't carefully control the UCF to match
the board design.

The only right answer is a script that reads in the top level HDL, the
schematic netlist, and the Xilinx package file, and spits out a UCF
file.  (Because I'm paranoid, I put "PROHIBIT" on all pins on the part
that aren't in the netlist; then if the design is built with changes
without rerunning the UCF script, it will barf.)

Regards,
Pat