GE ICS-1650 Updates

Setting the record straight

 

Hello, dear readers, as it turns out as few facts in the last blog were a little off. Namely because I was a few tools and homebrew elements that weren’t lining up with what Xilinx likes to see on it’s JTAG chain.

After some additional research and probing it turns out the chips on the particular card I’m probing were not as specified in the previous blog post. They are, in fact:

Virtex 5 XC5VLX30T (ID Code: c2a6e093)
Virtex 5 XC5VSX50T (ID Code: 52e9a093)

While this is a bit disappointing to me from the perspective of thinking I had a much beefier DSP FPGA, it’s still more than adequate to the tasks at hand. I decided to use the card that “didn’t work” to do the testing on (meaning it didn’t come up in the PCI bus enumeration on Linux or Windows), but it seems just fine from a JTAG and Chipscope perspective. Chipscope is Xilinx’s lovely tool to do active JTAG debugging on the chip, while the device is in use (or on your test bench, as the case may be).

Dumped Configuration

Next, I gathered the information that’s available without rewriting the FPGA’s configuration flash. The raw dumps are listed below for your reading pleasure.

An dump of the “Configuration Status” of the XC5VLX30T from the Chipscope tool follows:

COMMAND: show_config_status 0
INFO: 
Bits [31 ..0]:   0001  1110  1000  0000  0000  1010  0000  1100
Bit 31: 0    
Bit 30: 0 RBCRC_ERROR
Bit 29: 0 IPROG_EVENT
Bit 28: 1 WRAP_ERROR
Bit 27: 1
Bit 26: 1 BUS_WIDTH
Bit 25: 1 BUS_WIDTH
Bit 24: 0 FS
Bit 23: 1 FS
Bit 22: 0 FS
Bit 21: 0
Bit 20: 0 STARTUP_STATE
Bit 19: 0 STARTUP_STATE
Bit 18: 0 STARTUP_STATE
Bit 17: 0
Bit 16: 0 DEC_ERROR
Bit 15: 0 ID_ERROR
Bit 14: 0 DONE
Bit 13: 0 RELEASE_DONE
Bit 12: 0 INIT_B
Bit 11: 1 INIT_COMPLETE
Bit 10: 0 MODE M2
Bit 9: 1 MODE M1
Bit 8: 0 MODE M0
Bit 7: 0 GHIGH_B
Bit 6: 0 GWE
Bit 5: 0 GTS_CFG_B
Bit 4: 0 EOS
Bit 3: 1 DCI_MATCH
Bit 2: 1 DCM_LOCK
Bit 1: 0 PART_SECURED
Bit 0: 0 CRC_ERROR

An dump of the “Configuration Status” of the XC5VSX50T from the Chipscope tool follows:

COMMAND: show_config_status 1
INFO: 
Bits [31 ..0]:   0000  0000  0000  0000  0000  0000  0000  0000
Bit 31: 0    
Bit 30: 0 RBCRC_ERROR
Bit 29: 0 IPROG_EVENT
Bit 28: 0 WRAP_ERROR
Bit 27: 0
Bit 26: 0 BUS_WIDTH
Bit 25: 0 BUS_WIDTH
Bit 24: 0 FS
Bit 23: 0 FS
Bit 22: 0 FS
Bit 21: 0
Bit 20: 0 STARTUP_STATE
Bit 19: 0 STARTUP_STATE
Bit 18: 0 STARTUP_STATE
Bit 17: 0
Bit 16: 0 DEC_ERROR
Bit 15: 0 ID_ERROR
Bit 14: 0 DONE
Bit 13: 0 RELEASE_DONE
Bit 12: 0 INIT_B
Bit 11: 0 INIT_COMPLETE
Bit 10: 0 MODE M2
Bit 9: 0 MODE M1
Bit 8: 0 MODE M0
Bit 7: 0 GHIGH_B
Bit 6: 0 GWE
Bit 5: 0 GTS_CFG_B
Bit 4: 0 EOS
Bit 3: 0 DCI_MATCH
Bit 2: 0 DCM_LOCK
Bit 1: 0 PART_SECURED
Bit 0: 0 CRC_ERROR

Something interesting here. It appears as if the second chip (the XC5VSX50T), is NOT even powered up here, or has some other type of error that prevents it from telling the JTAG chain what’s wrong with it. This seems a little odd to me, and coupled with the fact that there were two TDO outputs, it made me attempt a dump of the configuration from the TDO2 output. No difference in the results were observed when the TDO2 output was used to examine the chain. I must conclude that the two TDO outputs are either identical, or serve a purpose currently unknown to me.

Additionally, it appears that the first FPGA in the JTAG chain (the 30T) does not FIND a configuration when it goes looking for one on the flash chip. This is likely the reason it doesn’t show up in the PCIe bus enumeration, either. It also opens up an opportunity for me to test the unit by programming the 30T with the PCIe IP hard endpoint logic, and then observing the pin inputs from a raw perspective. This is a non-trivial task, to say the least and will require another full blog entry or two to explain the process (assuming I can figure it out myself).

Strategy Change

While all this information is well and good, I couldn’t help wondering about the power being supplied to the board. There were inputs for 5v that I am not using, and the board is designed to be powered by the PCIe bus. With this in mind, I setup another test case. I plugged the board into a PCIe slot (in a ThunderBolt to PCIe external chassis as seen in Figure 1 below), and powered the unit up. When I reattached the JTAG chain to the device, there were a few more entries in the Chipscope, and the configuration information for both FPGAs had changed.

In addition, there were the two new “MyILA0” and “MyILA1” elements on the JTAG chain! Very exciting, indeed! Could it be that GE had left Integrated Logic Analyzer components in the production bitstream?! Well, it certainly appears that they have done exactly that (assuming that what I know about the ILA module is correct).

Figure 1. Powered in a ThunderBolt Chassis, with JTAG attached and working.
Figure 1. Powered in a ThunderBolt Chassis, with JTAG attached and working.

A screenshot of the ChipScope Pro tool while the ILAs are visible

ChipScope Pro with ILAs

Conclusions for tonight

So I have to conclude that this card is likely to be functional, but having some firmware issues that prevent it from being recognized. It also gives me a “nothing to lose opportunity” to insert my OWN firmware into the device and start doing things like pin-to-pin mapping on the FPGAs!

So, stay tuned and we’ll see what we can discover next time! I see the next steps as:

  • Generating a PCIe Hard IP Block bitstream that listens on all pins (on the 30T)
  • Generating a Bitstream that simply turns all the pins into outputs and sends timed pulses (on the 50T)
  • Getting the flash programmed with the images
  • Getting some idea of a pin to pin mapping for the FPGAs (to determine what kind of bus we can use to program the devices to speak to each other).
  • Figuring out which pins are bound to the Mini DB9 connector (I’ve already got two Mini DB9 male to RJ45 cables here!  Photos next time.)
  • Figuring out which pins are bound to the analog input circuitry and how to adjust gain, etc.
  • Publishing it all, and putting a boilerplate configuration for BOTH FPGAs out there for all of you who want to use it, without GE’s expensive SDK/HDK!

Cheers!

 

mm
About

Phorkus is just this guy...

11 Comments on “GE ICS-1650 Updates

  1. Thanks for posting your work. I am considering purchasing one of these boards.

    I already contacted GE but they refuse to help. They actually told me there had to be a possible buisness opportunity for them to even think about supplying me with documentation. Even if I introduce them to people that are actually likely to buy their products, which I can do, they cannot gaurantee me the support for this card. Given the small customer base for something like this and their NI competition their position seems irrational.

    Anyway, I am not that experienced with FPGAs. I would like to follow your work regardless. Are you confident that you can come up with something like an SDK for this? Do you think at minimum , without GE support, the card can be made to sample and save to an SSD or something like that?

    Would love to hear your thought/comments.

    • I think that we can definitely get at least the PCIe endpoint working, and with a little effort, we should also be able to map the FPGA-to-FPGA pins so we can channel data in or out of the DSP Virtex-5. Exactly how we will set the channel input gain, and other off FPGA elements, I’m not 100% certain on yet. It should be possible, but the mapping will take some effort, I suspect. I would very much like to be able to sample and record, as well as output to a linear amplifier. Not sure if that’s in the card’s specifications, or not, however. Output may need to be through a seperate channel (at least for SDR purposes). The nice thing is that there’s a high speed digital output port (in a mini DB-9 form factor which is one odd duck and hard to get connectors for at a decent price) that could be used with a simple A/D converter of some sort to synthesize the output channel. There might need to be some diode trickery on order to use the same antennea, but I think it might be viable.

  2. Hello!

    I was going to buy this board, but given the circumstances, I thought that even a 100$ investment for a piece of metal is a waste… Now I see that we can work something out… Beautiful! I am there to help, I will get one ASAP. As long as we can map the I/O and push a bitstream, we are good to go ! Actually, I wanted to implement a SDR using this board and perhaps another board to use as logic analyzer or oscilloscope 🙂 … with a nice front end. Any updates?

    • I love the idea of using this as a Oscilloscope! It’s got enough bandwidth to read 4 probes concurrently at almost 200MHz each! That’s a $4,000 scope for a midrange scope, if memory serves! We’ll likely need to do some voltage scaling on the inputs, however, to keep from blowing up the FPGAs :-). The input range on their analog (from memory, I could be wrong) only goes to 5v at most (might be 3.3v). That’s not insurmountable, and could even be automated with a little SPI Verilog. You could use the mini-DB9 to sample up to 9 pins of logic (1.0-5.0v) at the 200 MHz rate, also. Good project idea!!!

  3. If I remember right, there are a few chips missing on this board right?
    If you compare to the one sold… like the QDR (memory) and maybe the front end ADC’s ?? Please advise.

    • I’m not completely certain. There are several modles of card like this, some have on-card buffering, some don’t. Now, an interesting thought here, for the cards that DON’T have the memeory, those pins are freed up on the FPGA, but are still bound to the chip’s BGA. It could be possible to actually use the memory mounting pads to gain a large number of digital logic analyzer probes without a lot of effort or money! Combine that with the FPGAs ability to re-write it’s encoders/decoders dynamically, and you could quickly have a bus sniffer that’s unparalleled in the marketplace today. I think all the 1650s have the A/D conversion stuff. It’s just under the cage. I assume there are pins on the second Virtex-5 wired to gain control of some sort, but I’ve not found anything on it yet.

  4. Next best board which shares similarities on *bay… ICS ICS-554E-4-MN

    Not as powerful in many aspects, but complete or not, I don’t know how GE manages to keep their clients with the latest SDK/HDK’s ??

    • Hi Bart, the ISC-1650 is the “big brother” of the ICS-554E-4 series cards. The bus was upgraded from PIC-X to PCIe and thus allowed for a *lot* more bandwidth in terms of the sampling rate. I’m not sure which FPGA(s?) the PCI-X card is using, but they certainly look viable if you have a motherboard with that kind of slot about. I DO spot a nice looking single inline set of pins that are most likely the programming interface on it (JTAG probably). Six pins means Xilinx most likely! On GE keeping clients, well, sometimes things go sideways despite the best efforts and intentions. Like a tower of mashed potatoes going over….

  5. Just wanted to say thank you for all the information you have published so far on these cards… looking forward to further follow ups. keep up the good work.

    • My pleasure! Sorry I’ve been so focused on work lately, or there would be more :-). I anticipate more R&D time in June, and being able to get at least the PCIe bus interface hard IP working right. If not getting the upper FPGA (or DSP as you like it) bridge connections and the inputs from the digital raw inputs, too!

Leave a Reply

Your email address will not be published. Required fields are marked *

*