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
6,753 Views
Registered: ‎12-16-2008

SOLVED!!! (Tho, not without some hair pulling :) XC9500XL...Strange behavior??

Jump to solution

Hi all,

 

  I ran into something that seems a bit odd in working on my design. In my circuit I have an LCD 8-bit graphics module, ROM and SRAM all connecting to a CPU databus (D0-D7). I have D0-D7 of the LCD and ROM tied together (ROM delivers data to the LCD module thru clocked gated logic). The databus for these 2 devices is then connected to the main D0-D7 (for direct CPU read/writes to the LCD module) thru a "home-made" 74245 (using buft buffers). I had the SRAM D0-D7 connected both directly to 8 ROM address lines, and buft-connected to the main databus for being able to write key data into the SRAM from the CPU. I've had this circuit up and running and all works perfectly.

 

  Never 1 to leave well-enough alone ;)  I decided that for some early cycles and some late cycles (in the total cyle of events) I need to be able to write data from the SRAM directly to the LCD display module. Sounds pretty straightforward, or so I thought.

 

  I took a simple and fairly obvious approach by adding (in the CPLD) an 8-bit wide tri-state buffer (again using buft) that would allow the SRAM D0-D7 to connect directly to the ROM/LCD D0-D7 bus. Of course I added the appropriate gating logic.

 

  Here's where it gets a bit "hinkey". The new circuit doesn't work when I have the added 8-bit buffer in. However, if I delete the lines that go from the buffer output to the LCD/ROM data lines (along with modifying the firmware to account for the change), the circuit works. To be sure this wasn't due to the firmware change, I disabled the logic so it would never be in anything but it's "z" state. Then, the only difference is whether the D0-D7 output lines of this added buffer are connected. Result - Connected: circuit doesn't work. Unconnected, circuit works just like I would expect. I did try disconnecting the input side of this buffer (the one that goes to the SRAM databus), but it had no effect at all (circuit still doesn't work).

 

   I could use some help. I think I've tried the obvious things, but maybe there's still something I'm missing. I thought it might be due to the number of buft devices I'm using (used vs. available). The software (Web version 10.1) makes no specific mention of that. I have tried both a XC9536xl and XC9572xl...no difference. I'm also wondering about loading issues, although, if it's truly a tristate device, when it's in tristate it shouldn't add much, if any, load. Again, no mention from the software.

 

  Thanks in advance....Steph

Message Edited by ipsbiz on 06-30-2009 04:06 PM
Message Edited by ipsbiz on 06-30-2009 04:27 PM
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Participant ipsbiz
Participant
7,835 Views
Registered: ‎12-16-2008

Re: SOLVED!!! (Tho, not without some hair pulling :) XC9500XL...Strange behavior??

Jump to solution

Hi all,

 

  OK, I figured this out. It has to do with "limitations" of the XC9500xl family. It also required me to redesign my circuit somewhat.

 

  I discovered a Xilinx page/document in my recent online searches that a buft (tri-state buffer, low enable), while supported in the XC9500xl family, is not supported for internal connection tri-state designs, which is somewhat of what I was trying to do...I had at least 2 buft outputs connected together between 2 I/O pads to isolate 2 circuits. Apparently, this is what was causing the "hinkey conflict". While  this internal connection "nono" was in 1 Xilinx doc, when I went back and looked at the doc that is linked with the Web software and lists CPLD functions (Help/Software Manuals/CPLD Functions), it said nothing about any limitations using this device. So, which to believe? ("A man with no watches doesn't know the time...a man with 2 watches is never sure"  ;) ...I wasn't really sure, so I decided to err on the conservative side..

 

  Question - If a buft device is only usable going to/from an I/O pin, how does that make it any different from an obuft?

 

  My first step was to break up my custom 74245 into an input buffer and an output buffer and see if the s/w would synthesize it differently. Someone somewhere made the comment that the s/w tries to reduce tri-states to muxes, where possible. Apparently, in my case, that didn't happen. Maybe this is just due to some settings I need to make in the properties.

 

  In the end, I redesigned the circuit by using an 8x2 mux to essentially replace the tri-state buft that seemed to be the cause. I still have some minor logic issues to work out, but the circuit is certainly wiggling again. My ultimate option would have been to put the tri-state external to the XC9500xl, but that was an option of only the last resort.

 

  The lesson here? If your circuit is behaving oddly (specifically in a XC9500xl device), check your logic, especially if you're doing tristates.

 

   Cheers....Steph

0 Kudos
4 Replies
Voyager
Voyager
6,741 Views
Registered: ‎08-30-2007

Re: XC9500XL...Strange behavior??

Jump to solution

OK, here's a dumb question - are you sure you've got the proper signal

sense driving the T input on the BUFT part?   A 1 sets tri-state.

 

I normally try to avoid instantiating primitives like a BUFT and simply

infer them in my Verilog code.

 

John Providenza

 

 

0 Kudos
Participant ipsbiz
Participant
6,734 Views
Registered: ‎12-16-2008

Re: XC9500XL...Strange behavior??

Jump to solution

John,

 

  Thanks for the help. I wish I could slap my head and say "D'oh!, Of course. How could I be so dumb!". However, been there, done that ;) (see my 2nd to the last paragraph above where I mention about hardwiring the problem buffer's "T" input to a "1" so I could eliminate that as a possibility...meaning the output of the buffer could be connected to the circuit, but held in a supposedly hi-impedance state). Then I ran my circuit with the same code, both with and w/out the buffer output lines connected (this connection consists of the junction of the "B" side of my 74245 equivalent, ROM D0-D7, LCD D0-D7 and, of course, the problem tristate buffer). The only change I make that appears to affect the circuit's functioning is the problem buffer's outputs are either connected or not connected - not connected: the circuit works; connected: dead in the water. It doesn't matter whether I have the inputs of this buffer connected. The problem seems to reside in something to do with the outputs. It almost seems to be a loading issue, but I can't seem to find anything that would help me understand if that might be so.

 

  A little more insight on the circuit. There are 2 states the circuit can be in. First is simple CPU (80C51) access to the LCD display. This is used to set up and configure the display. The only thing "enabled" on the LCD D0-D7 lines in this state is the 74245 (for providing isolation during auto operation, which is the other state). In auto operation, the CPLD provides timing and control for tranferring data from the ROM into the LCD display. It's during this state where the problem occurs.

 

    I will still look for something obvious (I have a 250MHz 4-channel scope at my disposal), but I'm getting the sense this is some odd anomaly either with how the s/w builds the design (I'm using shcematic input) or how it's implemented. Actually, now that I think about it, I need to re-investigate a little deeper if the problem occurs only during auto operation. I thought I verified that, but I maybe should do more research. You just might be right, but in an odd sort of way (just like this problem :)  It may not be so much as to where to look for the problem, but rather "when" to look for it. I'll post back if I find anything new. I am still open to any ideas anyone might have.

 

 

  BTW - the ROM is a 29C010 and the LCD uses the Toshiba T6963C controller as its interface.

 

   Thanks again and cheers....Steph

0 Kudos
Participant ipsbiz
Participant
6,713 Views
Registered: ‎12-16-2008

Re: XC9500XL...Strange behavior??

Jump to solution

OK, I did a bit of backtracking on my problem-solving on this, and while I realized something new, I'm no closer to sorting this out. Still seems a bit odd.

 

I went back to confirm that disabling the "problem" tristate buffer didn't help. However, I must have missed something last time. The T line of the buft is connected to a 3-input OR gate, so all 3 inputs have to be low before the buffer is enabled (T=0). 1 input is a pretty solid state line: either on or off (LCD update or not). 1 line is a RD line, so that wiggles a bit and the 3rd line goes to a gated line that qualifies further when the 8-bit buffer is enabled. Thinking the RD line might be glitchy, I pulled that line to a "1". Lo and behold, the circuit worked (with the outputs of the buft connected..something I didn't think I was able to do before). So, my initial reaction was that I do have a glitchy line going to the T line of the buffer. However, there must be something else.

 

In my target circuit (with the RD line reconnected), when the CPU has access to the LCD module, the 1 pretty solid state line I mention above that goes to the 3-input OR gate is held at a very solid 1. This should completely disable the buffer so none of the other 2 lines should have any effect (as I would expect it to), but it still seems to interfere with access to the LCD module (D0-D7). It seems commands that the CPU tries to write to the LCD are getting scrambled because when the CPU tries to read the right status (there are 4 different ones), the LCD module is never ready for that status (Hope this makes sense). If I plug back in the CPLD with the 1 line pulled high, it works.

 

In simple terms (and this is what I now see as the "hinkey" part), why would a "1" from a f/f (actually an inverter) which seems to cause problems be any different than hardwiring an input to Vcc (3.3VDC in this case), in which case the circuit works?. 

 

Unless I'm missing something that might not be as obvious as I would hope, this still seems like a pretty odd problem. I guess I'll have to go ferret out loading data, pull-up considerations, etc.

 

  Anyway, I appreciate any insight anyone might have.

 

   Cheers...Steph

Message Edited by ipsbiz on 06-29-2009 07:10 AM
0 Kudos
Highlighted
Participant ipsbiz
Participant
7,836 Views
Registered: ‎12-16-2008

Re: SOLVED!!! (Tho, not without some hair pulling :) XC9500XL...Strange behavior??

Jump to solution

Hi all,

 

  OK, I figured this out. It has to do with "limitations" of the XC9500xl family. It also required me to redesign my circuit somewhat.

 

  I discovered a Xilinx page/document in my recent online searches that a buft (tri-state buffer, low enable), while supported in the XC9500xl family, is not supported for internal connection tri-state designs, which is somewhat of what I was trying to do...I had at least 2 buft outputs connected together between 2 I/O pads to isolate 2 circuits. Apparently, this is what was causing the "hinkey conflict". While  this internal connection "nono" was in 1 Xilinx doc, when I went back and looked at the doc that is linked with the Web software and lists CPLD functions (Help/Software Manuals/CPLD Functions), it said nothing about any limitations using this device. So, which to believe? ("A man with no watches doesn't know the time...a man with 2 watches is never sure"  ;) ...I wasn't really sure, so I decided to err on the conservative side..

 

  Question - If a buft device is only usable going to/from an I/O pin, how does that make it any different from an obuft?

 

  My first step was to break up my custom 74245 into an input buffer and an output buffer and see if the s/w would synthesize it differently. Someone somewhere made the comment that the s/w tries to reduce tri-states to muxes, where possible. Apparently, in my case, that didn't happen. Maybe this is just due to some settings I need to make in the properties.

 

  In the end, I redesigned the circuit by using an 8x2 mux to essentially replace the tri-state buft that seemed to be the cause. I still have some minor logic issues to work out, but the circuit is certainly wiggling again. My ultimate option would have been to put the tri-state external to the XC9500xl, but that was an option of only the last resort.

 

  The lesson here? If your circuit is behaving oddly (specifically in a XC9500xl device), check your logic, especially if you're doing tristates.

 

   Cheers....Steph

0 Kudos