UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Participant ipsbiz
Participant
14,840 Views
Registered: ‎12-16-2008

Tri-state buffer conflict...

This should (hopefully) be an easy one for someone who's been there :)

 

Working w/10.1.03, I have a circuit that has multiple (3) tri-state connections to a databus D(0-7. One device is a 74245 look-alike submodule w/1 side connected to the d-bus (the other goes internal). The other 2 are simple tri-state buffers submodules whose outputs go to the d-bus. Each is controlled/enabled by a separate signal.

 

I have been getting the following error (8x, 1 for each data line):

 

ERROR:Xst:528 - Multi-source in Unit <DISPCNTL_GAL002> on signal <D0>; this signal is connected to multiple drivers.
Drivers are:
   Output signal of OBUFT instance <XLXI_5/XLXI_98>
   Output signal of OBUFT instance <XLXI_41/XLXI_5/I_36_40>
   Output signal of OBUFT instance <XLXI_42/XLXI_6/I_36_37>

 

XLXI_5 is my 245 doppleganger, XLXI_41 and 42 are the simple tri-state output buffers (1 4-bit, the other 8-bit)

 

(NOTE: Only 2 instances are listed for D4-7 since XLXI_41 is the 4-bit buffer connected only to the lower bits)

 

Originally I thought the problem was related to my using 'obufe' as the buffer device only to realize these devices are used specifically (and only) for connecting to an I/O pin on the device. OK, so I went back and changed the base device to 'obuft'. Based on the documentation, these appear to be the correct devices to use. However, they didn't fix the error as I thought it would.

 

Anyone have any suggestions or experience with this? Must be something obvious I'm missing.

 

  Thanks in advance...Steph

0 Kudos
8 Replies
Instructor
Instructor
14,818 Views
Registered: ‎08-14-2007

Re: Tri-state buffer conflict...

Basically you're only allowed to have one tristate driver poer pin.  So if you have multiple sources within

the FPGA, you need to mux them together and generate a common output enable for data going off-chip.

 

Regards,

Gabor

-- Gabor
0 Kudos
Participant ipsbiz
Participant
14,811 Views
Registered: ‎12-16-2008

Re: Tri-state buffer conflict...

Gabor,

 

 Thanks for your quick reply. It's not how I'd like to do it, but muxing was my next thought (hoping to avoid the xtra circuitry). I'll also have to go back and check if that's an issue for some of the other designs I am currently working on.

 

  So, while I know that the definitions of an obufe (used for tristate specifically to an I/O pin) and obuft (used for internal tri-state) are different in their intended use, how are they acutally used in particular implementations/applications.

 

One curious thought...I need to think this through, but is it OK to use obuft devices as I've done w/common outputs (d-bus lines) connected together and then run that combined output to the input of an obufe which would then be the single connection to the I/O pin? Sort of a tri-state mux....Otherwise, I would need to create up to an 8-bit, 5-input, 8-bit output mux for some of my other designs.

 

 Another thought..actually...question...did I read correctly somewhere that some sort of buffer/driver is required for any signal going to an output pin (I think this gets modified if the I/O pin is used in a bi-directional capacity (like a databus). I know there's an option to enable the software to place an ibuf device on any input pin. Is there such an option for an output pin?

 

  Again, thanks much for the help....Steph

 

Message Edited by ipsbiz on 03-23-2009 09:15 AM
Message Edited by ipsbiz on 03-23-2009 11:04 AM
0 Kudos
Instructor
Instructor
14,794 Views
Registered: ‎08-14-2007

Re: Tri-state buffer conflict...

If you are using internal tristates in anything newer than Spartan 2 or Virtex 1, you should realize that

the synthesis tools are converting them into LUT-based multiplexers anyway, so you really aren't

saving any logic resources.   In any case the internal tristates, even in the older parts, are not

intended to attach to I/O.  The IOB architecture does not include tristate connections to the

fabric, only to the pad.  So you get the conflict because at the pad only the IOB tristate buffer

can be used, and there is only one such buffer in the IOB.  By the way obuft and obufe are both

IOB structures.  The older parts with internal tristate buffers had buft for the fabric.

-- Gabor
0 Kudos
Participant ipsbiz
Participant
14,762 Views
Registered: ‎12-16-2008

Re: Tri-state buffer conflict...

Got it...Thanks.

 

 A clarification on this....should I be using OBUFT or OBUFE, or does it not matter at all (other than low vs high active)?

 

  On the inputs...I have the software set to automatically "insert" input buffer(s?)  Does this mean I don't have to worry about them? And how many input buffers can I have? Is this the same restriction as output, i.e. there is only 1 input buffer available per IO pad connection and, as a result, all of my internal "fabric" connections for that input port must be made to the output of the input buffer??Meaning...do I also have to create some form of muxingfor input signals to be distributed without loading issues?

 

  Apologies for the re-editing....one other concern (which prob'ly belogs elsewhere)...I have 4 designs for a specific project (2 for each of 2 functionals). I seem to have run into a problem with ISE in general...I can't seem to get past the Synthesize process (1 of my designs actually could up till yesterday). ISE now seems to exhibit the same non-functionality with all designs: Implement Design is x'ed (red circle with x....tho for 1 design there is a '-' in a red circle) with Synthesize showing a 'check' in a green circle. Translate also has the x in a red circle. However, while at one point in time I was able to get both a Synthesize and Translate report, I now can't get either. In the past, I think I remember the Synthesize Report would also be either checked or x'ed. I've also noticed that the time to process has been greatly reduced, almost as if the process opens the file and then crashes.

 

  I did some searching and cleared out my temp folder, and have tried restarts to my computer. Any ideas on what might be happening here? I'll also repost this last part in a more appropriate section of the forum

 

   Steph

Message Edited by ipsbiz on 03-24-2009 12:14 PM
Message Edited by ipsbiz on 03-24-2009 12:28 PM
0 Kudos
Instructor
Instructor
14,756 Views
Registered: ‎08-14-2007

Re: Tri-state buffer conflict...

OBUFT matches the actual IOB structure for most parts.  OBUFE  essentially inserts an inverter

before the tristate control.  Whether or not this makes a difference in logic usage depends on

whether the tools are smart enough to absorb the inverter somewhere else.  If you are trying

to ensure that I/O logic is pushed into the IOB, it is usually best to use OBUFT because you

could not have an inverter between the IOB tristate flip-flop and the tristate control of the output

buffer.  As I said before, if the tools see this and move the inverter to the input of the

flip-flop you may still get the same outcome, but I don't always rely on such smartness from

the tools.

 

Input buffers are one per pad as you guessed.  No real need for buffers inside the fabric.

 

As for your new "features", did you try "clean up project files" from the "Project" menu?

This is the universal cure for many such problems.

 

Regards,

Gabor

-- Gabor
0 Kudos
Historian
Historian
14,752 Views
Registered: ‎02-25-2008

Re: Tri-state buffer conflict...


ipsbiz wrote:

Got it...Thanks.

 

 A clarification on this....should I be using OBUFT or OBUFE, or does it not matter at all (other than low vs high active)?

 

  On the inputs...I have the software set to automatically "insert" input buffer(s?)  Does this mean I don't have to worry about them? And how many input buffers can I have? Is this the same restriction as output, i.e. there is only 1 input buffer available per IO pad connection and, as a result, all of my internal "fabric" connections for that input port must be made to the output of the input buffer??Meaning...do I also have to create some form of muxingfor input signals to be distributed without loading issues?

Message Edited by ipsbiz on 03-24-2009 12:28 PM

In general there is no need to instantiate any type of single-ended I/O buffer. The tools will infer what's needed.

 

And yes, there is only one input buffer at a pin, so that buffer's output feeds whatever inside the FPGA requires that signal. There's no need for any kind of muxing (dunno what you'd mux). If the signal output is loaded too much, the tools will tell you (you'll fail to meet timing constraints).

 

-a

----------------------------Yes, I do this for a living.
0 Kudos
Historian
Historian
14,751 Views
Registered: ‎02-25-2008

Re: Tri-state buffer conflict...


ipsbiz wrote:

  Apologies for the re-editing....one other concern (which prob'ly belogs elsewhere)...I have 4 designs for a specific project (2 for each of 2 functionals). I seem to have run into a problem with ISE in general...I can't seem to get past the Synthesize process (1 of my designs actually could up till yesterday). ISE now seems to exhibit the same non-functionality with all designs: Implement Design is x'ed (red circle with x....tho for 1 design there is a '-' in a red circle) with Synthesize showing a 'check' in a green circle. Translate also has the x in a red circle. However, while at one point in time I was able to get both a Synthesize and Translate report, I now can't get either. In the past, I think I remember the Synthesize Report would also be either checked or x'ed. I've also noticed that the time to process has been greatly reduced, almost as if the process opens the file and then crashes.

 

  I did some searching and cleared out my temp folder, and have tried restarts to my computer. Any ideas on what might be happening here? I'll also repost this last part in a more appropriate section of the forum

 

   Steph

Message Edited by ipsbiz on 03-24-2009 12:14 PM
Message Edited by ipsbiz on 03-24-2009 12:28 PM

Look at the reports generated by the stages that failed. The cause of the failure should be obvious.

 

-a

----------------------------Yes, I do this for a living.
0 Kudos
Participant ipsbiz
Participant
14,748 Views
Registered: ‎12-16-2008

Re: Tri-state buffer conflict...

Thanks much to both Gabor and "a" for the patience and persistence. I appear to have solved my problems and reached what seems to be a completed design (no failed processes) for one of the CPLDs.

 

For the ISE problems, I did try a "clean up" as suggested. Didn't seem to fix it. However, I found a path. I renamed my existing project (to an "A" version). Then I created a new project (.ise) and "reloaded" my files into it. Back to normal operation.

 

On the buffer issue...I own part of that problem....a's comment about not needing to mux was spot on. I was trying to use obufs internally and after rereading the docs, I realized that plain old "buf"s were what I needed. Changed all the instantiations of obufs to bufs and that's when everything compiled very nicely, exactly the way I had intednded the logic to work in the first place.I am curious about the messages I got.

 

WARNING:Xst:1348 - Unit <name> is merged (output interface has tristates)

 

I got 5 of these, 1 for each of the devices that has the tri-state-bufs in them. Should I be concerned? Or is this just the softare taking teh bufs and converting them to obufs (since the output of each buf goes to an IO pin/pad?

 

Again, thanks for the help. I feel I'm back on track.

 

BTW - 1 other thing I learned is to make sure that I clean up the project whenever I modify the schematics. Otherwise, devices I delete or changed may retain some persistence when the s/w does the processing :(

 

 

  Cheers...Steph

0 Kudos