cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
10,852 Views
Registered: ‎02-19-2009

associate pads with nets on low-level schematic

Hi

 

I've baught Digilent DL-BASYS FPGA board with XC3S100E, 8 switches, 4 buttons and 8 LEDs. I have to use these elements in different project every day so I can't every time use PACE - it takes a lot of time when you work on different projects. So my idea was to create a library with elements of my design board - LEDPACK, SWITCHPACK etc. The problem I've faced is that I can't find the way to associate pads with nets on LOW-LEVEL schematic in WebPack 10.1 and keep this association when I create a symbol.

 

I'am new to WebPack 10.1 - I've migrated from Foundatiuon F4.1i, where the solution was to simply use the IPAD symbol, so forgive me if my question seems like "why letters are black and so different?".

 

Thx for any help

 

-Timur

0 Kudos
7 Replies
Highlighted
Visitor
Visitor
10,785 Views
Registered: ‎02-19-2009

Re: associate pads with nets on low-level schematic

after some researches I've found the way to assign OUTPUT pins in low-level VHDL module, but I still can't assign INPUT pins. Here's a VHDL code for a symbol representing 8 switches:

 

 library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity SWPACK is
    Port ( SW0 : out STD_LOGIC;
           SW1 : out STD_LOGIC;
           SW2 : out STD_LOGIC;
           SW3 : out STD_LOGIC;
           SW4 : out STD_LOGIC;
           SW5 : out STD_LOGIC;
           SW6 : out STD_LOGIC;
           SW7 : out STD_LOGIC);
end SWPACK;

architecture Behavioral of SWPACK is


component IBUF
   port (O : out STD_ULOGIC;
         I : in STD_ULOGIC);
end component;


signal I0 : STD_LOGIC;
signal O0 : STD_LOGIC;
signal I1 : STD_LOGIC;
signal O1 : STD_LOGIC;
signal I2 : STD_LOGIC;
signal O2 : STD_LOGIC;
signal I3 : STD_LOGIC;
signal O3 : STD_LOGIC;
signal I4 : STD_LOGIC;
signal O4 : STD_LOGIC;
signal I5 : STD_LOGIC;
signal O5 : STD_LOGIC;
signal I6 : STD_LOGIC;
signal O6 : STD_LOGIC;
signal I7 : STD_LOGIC;
signal O7 : STD_LOGIC;

attribute LOC : string;

attribute LOC of I0 : signal is "P38";
attribute LOC of I1 : signal is "P36";
attribute LOC of I2 : signal is "P29";
attribute LOC of I3 : signal is "P24";
attribute LOC of I4 : signal is "P18";
attribute LOC of I5 : signal is "P12";
attribute LOC of I6 : signal is "P10";
attribute LOC of I7 : signal is "P6";

begin

ib0 : IBUF port map(I => I0, O => O0);
ib1 : IBUF port map(I => I1, O => O1);
ib2 : IBUF port map(I => I2, O => O2);
ib3 : IBUF port map(I => I3, O => O3);
ib4 : IBUF port map(I => I4, O => O4);
ib5 : IBUF port map(I => I5, O => O5);
ib6 : IBUF port map(I => I6, O => O6);
ib7 : IBUF port map(I => I7, O => O7);

SW0 <= O0;
SW1 <= O1;
SW2 <= O2;
SW3 <= O3;
SW4 <= O4;
SW5 <= O5;
SW6 <= O6;
SW7 <= O7;

end Behavioral;

 

and errors that I have

 

ERROR:Xst:2033 - Port I of Input buffer XLXI_4/ib7 is connected to GND
ERROR:Xst:2033 - Port I of Input buffer XLXI_4/ib6 is connected to GND
ERROR:Xst:2033 - Port I of Input buffer XLXI_4/ib5 is connected to GND
ERROR:Xst:2033 - Port I of Input buffer XLXI_4/ib4 is connected to GND
ERROR:Xst:2033 - Port I of Input buffer XLXI_4/ib3 is connected to GND
ERROR:Xst:2033 - Port I of Input buffer XLXI_4/ib2 is connected to GND
ERROR:Xst:2033 - Port I of Input buffer XLXI_4/ib1 is connected to GND
ERROR:Xst:2033 - Port I of Input buffer XLXI_4/ib0 is connected to GND

 

that's because signals I0-I7 are thought to be  sourceless. So the question is how to avoid it?

0 Kudos
Highlighted
Contributor
Contributor
10,772 Views
Registered: ‎01-06-2009

Re: associate pads with nets on low-level schematic

What I tend to do in cases like that is to have a single UCF file (I usually write them by hand rather than using PACE), that has LOC constraints for all components, using some standardized naming scheme.

For Digilent boards, I use the UCF from from the BIST. If you have the BASYS board that has a USB port (i.e. BASYS Rev E) then the ucf file can be found in this zip: http://www.digilentinc.com/Data/Products/BASYS/BASYS_E_bist.zip

 

Then I just have top level ports with the correct names, and everything works well, with one small catch. I must tell translate to ignore unmatched LOC constraints. That is easy enough. Just right-click on the translate process in Processes tab in ISE and choose properties. (The Translate command is inside the Implement command in ISE's processes tab.) There should be an option to ignore unmatched LOC constraints. Check it, and click OK.

 

Of course, one could avoid that step by creating several smaller UCF files, relating to one component each (i.e. a swiches.ucf, an leds.ucf, buttons.ucf, sevenseg.ucf, etc.), andkeeping them someplace, adding just the ones you need into each project. 

0 Kudos
Highlighted
Visitor
Visitor
10,747 Views
Registered: ‎02-19-2009

Re: associate pads with nets on low-level schematic

Thanks for your answer kcathcar. Indeed, that's the only way of using external components of test board fast, that I know in ISE 10.1. I already use .ucf file from test project, but still have a hope to do a beautifull library)

 

I've found this thread Assigning FPGA pins in a VHDL submodule

But they discuss only input pins.

 

Now i can  reformulate my question: "How to avoid grounding of a sourceless signal?"

0 Kudos
Highlighted
Participant
Participant
10,674 Views
Registered: ‎12-30-2008

Re: associate pads with nets on low-level schematic

Hello!

If I may intervene here. :) I'm the starter of the mentioned other thread, and we've been discussing OUTput pins there so far. Or rather, I've only tested a LED output pin and had hoped that the method with instantiating an OBUF would work the same way with IBUFs.

But now I've run into the exact same problem. XST ties the unassigned input of the IBUF to "0" and then complains that its input is grounded.

So far I found no solution. I'll watch this thread too, hoping that someone comes around with a new idea.
Message Edited by ti-uni-bonn on 02-24-2009 06:22 AM
0 Kudos
Highlighted
Historian
Historian
10,635 Views
Registered: ‎02-25-2008

Re: associate pads with nets on low-level schematic


kergan wrote:

Now i can  reformulate my question: "How to avoid grounding of a sourceless signal?"


This answer might seem flippant, but it's not: a sourceless signal must have a driver. If your design does not explicitly provide one, the tools do it for you by grounding the signal.

 

You usually see this warning when you use an IP core. A lot of the Xilinx cores have a whole bunch of configuration options, and in some configurations some signals simply aren't used. But since there's no way to completely remove them from an entity's port list (this is an HDL limitation), they remain. So the tools are basically saying, "Your entity has an unused input port, and this port can't float, so we are grounding it for you and warning you of same."

 

-a

----------------------------Yes, I do this for a living.
0 Kudos
Highlighted
Visitor
Visitor
10,489 Views
Registered: ‎02-19-2009

Re: associate pads with nets on low-level schematic


bassman59 wrote:

This answer might seem flippant, but it's not: a sourceless signal must have a driver. If your design does not explicitly provide one, the tools do it for you by grounding the signal.

 

-a


Yeah, grounding of sourceless signals is important, but in my situation it's obvious that a special attribute is needed to prevent the grounding because the signal is not really sourceless (or pin is not a source anymore???). A simple example: what if someone has an external component connected with 20...100 pins of FPGA. He uses it in different projects (he may be a scientist, or a student, or scientist-student) every day. What do you suggest to him? Use the User Constraints File? And he will need to name nets every time. Or, maybe, use a template schematic with all nets already named? But he has a tool that meets all his needs, and was designed to do it - libraries, but... unfortunately, he can't use it, because he can't control the grounding process.

 

So, the IPADs are the one thing that I miss so much.

 

- Timur, still looking for solution

0 Kudos
Highlighted
Historian
Historian
10,481 Views
Registered: ‎02-25-2008

Re: associate pads with nets on low-level schematic


kergan wrote:

bassman59 wrote:

This answer might seem flippant, but it's not: a sourceless signal must have a driver. If your design does not explicitly provide one, the tools do it for you by grounding the signal.

 

-a


Yeah, grounding of sourceless signals is important, but in my situation it's obvious that a special attribute is needed to prevent the grounding because the signal is not really sourceless (or pin is not a source anymore???). A simple example: what if someone has an external component connected with 20...100 pins of FPGA. He uses it in different projects (he may be a scientist, or a student, or scientist-student) every day. What do you suggest to him? Use the User Constraints File? And he will need to name nets every time. Or, maybe, use a template schematic with all nets already named? But he has a tool that meets all his needs, and was designed to do it - libraries, but... unfortunately, he can't use it, because he can't control the grounding process.

 

So, the IPADs are the one thing that I miss so much.

 

- Timur, still looking for solution


OK, I went back and looked at your second post in this thread, and I understand why you get the error.

 

You declared an entity that has only output ports. Then you instantiate a bunch of IBUFs, and you declare a bunch of signals to connect to those IBUFs' ports. You place LOCs on the IBUF input signals. But these signals are not driven by anything, so ERROR:Xst:2033 is thrown. Of course, in typical Xilinx fashion, there's no specific help topic for this error message, but it's fairly obvious what it means: all entity INPUTS must be driven (have a source).

 

Since your code does not provide a source for those IBUF inputs, you get an error.

 

Now I've seen plenty of code that throws the WARNING:Xst:653 - Signal <foo> is used by never assigned. This sourceless signal will be automatically connected to value 0. When I do it in my code, it's a mistake. But it's in a lot of EDK code ... Point being here is that signals that are not assigned get a warning and a default.

 

If I had time or inclination, I would do some tests ... simply create an entity, instantiate it in a higher-level entity, connect up the signals but don't assign anything to one of the input ports, and see what the tools say. It might be that for most code, you'll get a warning and note that the signal was connected to GND. However, in the specific case of an IBUF, because of its special nature (being a chip input pin), it cannot be driven by anything from within the chip. So the tools say, "Port I of Input buffer foo is connected to GND," but that's physically impossible, hence the ERROR.

 

If these signals are truly meant to be inputs, and if it's part of some code that you might not use for one application, that's OK. You still have to bring the IBUF inputs to the FPGA top level. It's OK if they're not actually driven, but I would play it safe by putting a PULLDOWN constraint in the UCF on each of those pins.

 

--a

 

 

Message Edited by bassman59 on 03-06-2009 04:47 PM
Message Edited by bassman59 on 03-06-2009 04:48 PM
----------------------------Yes, I do this for a living.
0 Kudos