ISE tools not detecting IOSTANDARD conflicts within bank
in [FPGA]
|
Prev: Booting Linux from my own bootloader
Next: Fpga Board detection on INTEL motherboard S5000XVN and S3210SHLC
From: Eli on 26 Apr 2010 16:59 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
From: d_s_klein on 26 Apr 2010 17:14 On Apr 26, 1:59 pm, Eli <eli.billa...(a)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, > 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 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
From: Eli on 30 Apr 2010 05:04 On Apr 26, 11:14 pm, d_s_klein <d_s_kl...(a)yahoo.com> wrote: > 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. > At least it sounds like this issue is consistent. What I encountered is more like voodoo.
From: colin on 30 Apr 2010 05:49 On 30 Apr, 10:04, Eli <eli.billa...(a)gmail.com> wrote: > On Apr 26, 11:14 pm, d_s_klein <d_s_kl...(a)yahoo.com> wrote: > > > 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. > > 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 ..
From: Patrick Maupin on 1 May 2010 02:00
On Apr 26, 3:59 pm, Eli <eli.billa...(a)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, > 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 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 |