Skip to main content
Topic: Bus Blaster v2 (Read 31363 times) previous topic - next topic

Re: Bus Blaster v2

Reply #16
Here is a spreadsheet of the connections on the TI FT2232 + CPLD programmer. The goal is to snoop out any important connections now, instead of learning from mistakes in v1 :) We won't duplicate their connections because theres a few things I don't like, but it is a good reference.

It doesn't look like they use any of the app-specific pins for anything. ADBUS7 (usually RTCK) is connected to a global clock pin, but I think GCK pins are intended for input, not output, and RTCK will usually be very slow when it applies. Maybe we should flip the banks and use a GCK pin anyways?

Here's some more info on special pins:
http://www.xilinx.com/itp/xilinx10/iseh ... ts_gsr.htm
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #17
It's all about propagation time in the CPLD as such. TCK is the fastest clock in FT2232, RTCK is going to be far less. Unless you are using FT2232 in FIFO mode, then CLKOUT (60MHz) is the fastest clock. I would guess that simple logic in the CPLD will not suffer even if clock is fed from normal IO pin.

I should try to model something simple for the CPLD and see how it behaves (propagation times and such).

Re: Bus Blaster v2

Reply #18
I think CPLD are fun (at least that is what they say ;))

Would be nice to have a small, cheap CPLD system with programmer :)

Re: Bus Blaster v2

Reply #19
Quote
I should try to model something simple for the CPLD and see how it behaves (propagation times and such).

The TI programmer [s:]you linked[/s:] rsdio linked in the other thread comes with a complete ISE project you can test. It's in VHDL and not a schematic, but still pretty simple stuff:
http://processors.wiki.ti.com/index.php/XDS100
http://software-dl.ti.com/dsps/dsps_reg ... up_1_0.zip

I'm really sorry, now I see rsdio linked this, you just responded next that you liked the idea :)
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #20
Here's a schematic I've been playing with. It is just a test of the pin connections between the FT2232 and the CPLD.

Here are some highlights:
*TCK (AD0) and AC5 (LA clock out) are routed to GCK pins (there is one free if there is another clock signal)
*All 16bits of AD ad AC bus route to IO pins on the CPLD.
*The one CPLD input-only pin is used for target detect
*7 free vtarget CPLD pins to take to a breakout area

Here's some other notes:

GCK
This is optimized to fan out to the macrocells with little skew and is a sort of protected path.

While it says clock, I don't think that applies if the clock isn't driving the CPLD (as in the clock on a flip-flop in a macro cell). I don't think that's what we'll be doing (though maybe someone needs that for a hack?). We're just passing an external clock through to the other side of the chip. Can anyone chime in?

If it doesn't matter, then the routing is a lot simpler (everything to the closest pins). If we wanted some sort of CPLD processing on every clock tick (say blink a LED on every 100 ticks), then it would probably be really important to connect to a GCK pin. Does this sound right?

GSR
Global set-reset, again I think a dedicated signal for the flip-flops inside the CPLD? This is only used if you want a global reset of the macrocells in the CPLD. This is on the vtarget side, so it's not very useful.

GTS
Global tri-state. A signal to put all the pins on the CPLD hi-z. We probably never want this because even if there's no target attached we'll need to see that from the FT2232 using IO from the CPLD.

Further research needed:

Tri-state CPLD outputs with input? How does it work?
TSRST pin is tristate, and we need to read it. CPLD must go high, low, hi-z, as well as return the current value. The v1 uses three FT2232 pins (in/out/OE), and input buffer, and an output buffer with enable. We can use the JTAGkey-compilable interface on the FT2232 side, but is one CPLD pin able to do all these functions? Maybe it should be routed to two pins?

Resources
http://www.xilinx.com/support/answers/3122.htm
http://www.xilinx.com/support/answers/10453.htm
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #21
Need to add selectable voltage for VTARGET (power from board, or take power from target).

Could use some extra B port pins with pullups to the vtarget side, to change things int eh CPLD on the fly without uploading a new bitstream.

Also. LEDs.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #22
http://www.xilinx.com/support/documenta ... app382.pdf

Outputs can be high-low or hi-z-low, but not really tri-state. Maybe it can be combined.

Looking at the TI VHDL, they have a TSRST output and TSRST input on the FT2232 side, and only one TSRST output.

I think most systems use hi-z on TSRST, so this should be OK, or just provide your own pullup.

I'm tempted to get rid of the GCK clock routing too, though I can see where someone might like that for hacking.

At the very least, open-drain
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #23
Read this:
http://www.xilinx.com/support/documenta ... app378.pdf

Probably it's good to use teh GCK because it has dividers and (!) doublers :) If you want to do a little signal hacking, maybe trigger assist for the 60MHZ logic analyzer function it might be possible with this routing :)
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #24
looking into the 60mhz thing .. doing the 60MHz sync scan would actually only require CPLD to detect trigger condition and to lower the WR pin when that happens (and to keep it down).. so it should be fairly simple cpld design ..

now if one want to scan on some other freq then async FT245 can be used. In this mode there's nothing on CLKOUT and data is written to the 2232H on every WR high to low transition. This allows cpld to hit WR at any scanning frequency we like (up to 60MHz), we just in this case have to generate the clock on the CPLD.

Also, if we want to go below 30MHz we should be able to use both channels (now this I still have not tested)

Re: Bus Blaster v2

Reply #25
What about using small resistor packs (4 resistors each) for the 470 Ω and 10 kΩ resistors?

Re: Bus Blaster v2

Reply #26
Great suggestion. We're actually in the process of doing that :) We're also going to add some limiting resistors (50ohm or so) between the JTAG header and the [s:]FPGA[/s:] CPLD (in arrays).
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Blaster v2

Reply #27
[quote author="ian"]
Probably it's good to use teh GCK because it has dividers and (!) doublers :)
[/quote]

The coolrunner does not have doublers , but does have dualedge triggered registers - which is a bit different.
All the available primitives are here:
http://www.xilinx.com/itp/xilinx5/data/ ... 30_14.html

The design from TI does not generate any timing constrains, i will have to look at it a bit closer tomorrow.

BTW, finding from my previous project... 32macrocell cpld is a bit small to implement some serious logic, I have been able to put 13bit quadrature encoder decoder into 32macrocell cpld (13bit counter/decounter = 26cells + some output/input latches to debounce the signal). I would certainly pay 1 dollar more for the 64 macrocell version :-)

Also there is no clock generating primitive in the CPLD (just deviders) to generate clocking for the data lines.

Re: Bus Blaster v2

Reply #28
[quote author="robots"]
BTW, finding from my previous project... 32macrocell cpld is a bit small to implement some serious logic, I have been able to put 13bit quadrature encoder decoder into 32macrocell cpld (13bit counter/decounter = 26cells + some output/input latches to debounce the signal). I would certainly pay 1 dollar more for the 64 macrocell version :-)
[/quote]

Just  a stupid question, but is there a way to predict how many macrocells are needed? Or just put the functions into vhdl/verilog, compile, and read the number of macrocels from the screen?

Re: Bus Blaster v2

Reply #29
[quote author="Sjaak"]
Just  a stupid question, but is there a way to predict how many macrocells are needed? Or just put the functions into vhdl/verilog, compile, and read the number of macrocels from the screen?
[/quote]

Well its kinda easy for counters. You need to use 1 LUT for each "bit" and twice as much when the counter can decrement. It seems that each macrocell has one LUT. (at least on XC95xx it has)
I guess that easiest way is to write the code, and pick the best fit cpld :-)