cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
steberik
Visitor
Visitor
1,819 Views
Registered: ‎06-15-2018

IO_x_x_x_x_x_x_x

Jump to solution

Hi,

 

I managed to instantiate an IOBUFDS running bidirectional LVDS_33 but got warnings about turn-around timing requirements:

 

WARNING:Pack:2909 - The I/O component mvb_1_pos has an I/O standard value
   LVDS_33 and has a bi-directional differential usage. Please note that LVDS_33
   is a fixed impedance structure optimized to 100ohm differential. This is only
   intended to be used in point to point transmissions that do not have turn
   around timing requirements. If the intended usage is a bus structure, please
   use BLVDS instead.

 

For Spartan6 devices LVDS_33 seems to be acceptable as a solution for a bi-directional LVDS with 3.3V levels using IOBUFDS primitive.

 

Everything seems to be fine but when I check the PAD report I've got eight unlocated bi-directional pins with the following name and attributes:

 

C:\work\projects\cio_fw\CIO_GW_FW\impl>grep UNLOCATED gateway_top_pad.txt | cut -b-88 | grep -n .
1:|C15       |IO_x            |IOB      |IO_L33P_A15_M1A10_1          |BIDIR    |LVCMOS25*
2:|C16       |IO_x_x_x_x_x    |IOB      |IO_L33N_A14_M1A4_1           |BIDIR    |LVCMOS25*
3:|D14       |IO_x_x          |IOB      |IO_L31P_A19_M1CKE_1          |BIDIR    |LVCMOS25*
4:|E15       |IO_x_x_x_x      |IOB      |IO_L34P_A13_M1WE_1           |BIDIR    |LVCMOS25*
5:|E16       |IO_x_x_x_x_x_x  |IOB      |IO_L34N_A12_M1BA2_1          |BIDIR    |LVCMOS25*
6:|F13       |IO_x_x_x_x_x_x_x|IOB      |IO_L32P_A17_M1A8_1           |BIDIR    |LVCMOS25*
7:|F14       |IO              |IOB      |IO_L32N_A16_M1A9_1           |BIDIR    |LVCMOS25*
8:|F15       |IO_x_x_x        |IOB      |IO_L35P_A11_M1A7_1           |BIDIR    |LVCMOS25*

Can someone explain to me what these pins are for? Can I just ignore these pins?

0 Kudos
Reply
1 Solution

Accepted Solutions
steberik
Visitor
Visitor
2,195 Views
Registered: ‎06-15-2018

Hi drjohnsmith.

 

This issue was completly my fault, sorry.

 

During the creation of a test case to zip up I discovered a generated instance of 8 IOBUF deep down in the design causing those pins to appear.

 

Sorry for waisting your time but thanks to your comments I was able to discover the root cause of my problem.

 

Those pins wasn't created out from thin air after all.

View solution in original post

8 Replies
drjohnsmith
Teacher
Teacher
1,804 Views
Registered: ‎07-09-2009

As bi directional, you have two or more drivers on the bus,

 

How are you ensuring that only one LVDS driver is turned on at one time ?

       How are you switching the termination around ( termination at Rx in LVDS )

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Reply
jmcclusk
Mentor
Mentor
1,796 Views
Registered: ‎02-24-2014

These pins have strange names,  "IO_x_x..."    Are they in your source code?     ISE won't just create IO pins out of thin air.    If they are in your source, then it's up to you to assign locations and IO drivers to them.

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Reply
steberik
Visitor
Visitor
1,726 Views
Registered: ‎06-15-2018

Hi drjohnsmith and thank you for answering,

 

The FPGA is a slave only and the protocol is that the outside master writes a command in to the FPGA and then expect the FPGA, as a slave, to answer after some time. The FPGA will turn the bus around for the answer and then turn it back again. The turn-around timing requirement is not an issue due to a very relax protocol between the master and the slave.

 

I use the following primitive and ISE will only report mentioned warnings:

iobufds_primitive_for_spartan6.png

 

About the termination, I have 100 ohm at both ends externally and of course thats not an ideal case but it should work for us.

0 Kudos
Reply
steberik
Visitor
Visitor
1,725 Views
Registered: ‎06-15-2018
I have nothing obvious for ISE to generate those extra IO_x_x... pins. My opinion is that ISE has generate those pins out of thin air.
0 Kudos
Reply
drjohnsmith
Teacher
Teacher
1,699 Views
Registered: ‎07-09-2009

can you zip up the project and let us have look

 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Reply
drjohnsmith
Teacher
Teacher
1,698 Views
Registered: ‎07-09-2009

external termination, good,

 

100 ohms , unless you switch to bus lvds, , bad.

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Reply
steberik
Visitor
Visitor
2,196 Views
Registered: ‎06-15-2018

Hi drjohnsmith.

 

This issue was completly my fault, sorry.

 

During the creation of a test case to zip up I discovered a generated instance of 8 IOBUF deep down in the design causing those pins to appear.

 

Sorry for waisting your time but thanks to your comments I was able to discover the root cause of my problem.

 

Those pins wasn't created out from thin air after all.

View solution in original post

drjohnsmith
Teacher
Teacher
1,662 Views
Registered: ‎07-09-2009

well done for getting back, thank you for that..

 

A suggestion that I picked up years ago, is to always name something Im adding as an experiment / temp with a given sting.

 

In code, I use the comment +_+_+_+_+_+_+_   as its easy to type and find 

 

If I have something like a signal or file name , I tend to have 'fred' in the name.

   I don't know why fred, started decades ago and just kept it up

 

that way I know the automatic tools would not call something 'fred' , 

      and its very unlikely to be in the proper code , so easy to find...  and remove.....

 

ie if you inherit some terrible code with the _+_+_+  or the word fred in it, it was probably mine at some time in the last decades 

   ( I found some in some old Cobol a few years ago !! )

 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Reply