Mike Tsao geeks out.

Son of ‘9572 is alive

A good night’s rest didn’t help the ‘9572. It remains destroyed. After talking it over with a few people, I believe any of the following is possible:

1. It was close to death already from having powered it from 5 volts for so long, and it simply gave out.
2. I was careless with a logic probe pin and briefly touched two opposing outputs.
3. While juggling pins on the UCF, I uploaded a new program that caused Possibility #2 to happen. I don’t think this was the case, because I think I would have noticed it when I rearranged the pins.
4. Or the chip just died, maybe from ESD, maybe from cosmic rays. It does happen.

No matter what the cause, I don’t think it was the VHDL, and I don’t think it was a currently-held misunderstanding on my part. So I’m back in the saddle with one of the Dorkbot PCBs.

As you can see, the latch clock is tied to the 1MHz Q clock. I managed to flick the latch button for less than a millionth of a second during the clock’s rising edge (it doesn’t look right on this graph, but I think this is sample error or else a difference in opinion between the Saleae and the ‘9572 about when the level fell again). The high value is latched into D0 on the next rising edge, then it’s shifted to D1 as D0 obtains the new low value, then it goes from D1 to D2, etc. Then about 21 clocks after that, we see it shift through A15. If I had more probe pins, we would have been able to see it go all the way from D0-D7, then A0-A15.

There is a bug in this code. The shift into D0 doesn’t happen until the rising edge after the one that should have latched it in. I will investigate. (Update: that was easy. I changed the REGISTER_TEMP vector from a signal to a variable so that it was evaluated in the order of the statements in the process block. There’s probably a better way.)

The ‘9572 is dead

I killed my CPLD Breakout Board. While taking pictures of the “successful” SRAM-loading VHDL I’d written and wired up, I noticed that the power LED on the board was off. I checked the connections, toggled the power a few times, tried re-running the logic analyzer, and eventually concluded that the board was dead. It draws 1.4 amps when I plug it in, and the CPLD itself gets pretty hot. As far as I can tell, everything else on the board is working (except for the power LED, which now appears to be inert).

Here’s my VHDL:

architecture Behavioral of SRAM_LOADER is
  signal REGISTER_TEMP : STD_LOGIC_VECTOR(23 downto 0);
begin
  process (CLK)
  begin
    if (rising_edge(CLK)) then
      REGISTER_TEMP <= REGISTER_TEMP(22 downto 0) & LATCH;
      if OE = '1' then
        ADDRESS <= REGISTER_TEMP(23 downto 8);
        DATA <= REGISTER_TEMP(7 downto 0);
      else
        ADDRESS <= "ZZZZZZZZZZZZZZZZ";
        DATA <= "ZZZZZZZZ";
      end if;
    end if;
  end process;
end Behavioral;

I think the tri-stated address and data pins are the problem. None of them were connected to anything (except four data pins hooked to my logic analyzer). But I’m not at all sure why that would be a problem. The only reason I think it’s related is that one of the last things I did was testing OE disabled (grounded), but it wasn’t the last thing (which was one more OE-high run to take a picture of the registers shifting), so even that evidence is questionable. If I’d obviously shorted something external to the chip, then I doubt I’d have been able to spend the half-hour or so when I successfully tested it. That’s why I believe I did something wrong with the tri-stating.

If you know a way that one could destroy an XC9572XL CPLD by programming it incorrectly, I’d appreciate a tip. 

5.0 != 3.3

I just realized that the XC9572XL’s “5-volt tolerant I/O pins” do not mean that the device itself can be powered with 5 volts. It’s a 3.3-volt device. I’ve been running it from the Arduino’s 5-volt supply.

Sigh.

With this newly understood information, I hope to discover that the JTAG Whisperer is working correctly, and that the incorrect voltage was preventing the CPLD from programming itself. Other possibilities are (1) my code is still buggy but the CPLD is happy to be finally running at the right voltage, and (2) I’ve fried my poor little ‘9572.

JTAG TCK: active-low?

Why does it seem like the JTAG clock signal is active low? Consider this snippet from Xilinx’s XAPP058 source code.

/* toggle tck LH.  No need to modify this code.  It is output via setPort. */
void pulseClock()
{
    setPort(TCK,0);  /* set the TCK port to low  */
    setPort(TCK,1);  /* set the TCK port to high */
}

This means that when the clock isn’t being pulsed, it’s high. Right? If so, why don’t any descriptions of JTAG’s electrical characteristics say it’s active low?

The JTAG Whisperer

Available here on GitHub. The JTAG Whisperer turns your Arduino into a JTAG cable. Wow, sounds great! Here are the caveats:

• It’s actually just an XSVF player. This is a tiny subset of what JTAG does. The current architecture has the desktop load the XSVF file, then send it over serial to the Arduino. Since serial is going to be limited to the kilobits-per-second range of speed, it’s unlikely it’ll be suitable for more ambitious interactive JTAG operations. But it’d be interesting to see what could be accomplished with the newer Arduinos that have replaced the FTDI chip with the more flexible ATmega U-series chips.
• It has been tested only on a Xilinx XC9572XL breakout board from Dangerous Prototypes, and the only function it has performed so far is asking the chip its device ID (spoiler: it’s 0xf9604093). I would have happily used the Bus Pirate’s XSVF Player firmware, but it hasn’t yet been ported to my BPv4 hardware, and I wasn’t willing to invest in learning PIC development.
• It doesn’t work very well yet. The serial communication between the desktop and the PC frequently gets logjammed, and the Arduino sometimes has to ask repeatedly for the ID.

I have high hopes for this project. Its immediate use will be to program the ‘9572 so that I can start experimenting with replacing discrete logic 74xx chips. Eventually I hope it’ll become a robust, reliable XSVF player for the Arduino.

Please give it a try. I look forward to your pull requests!

Linux on Nexys2?

All the search results for [linux nexys2] discuss how the heck you run that djtgtgtgjdsasdfghjkcfg Digilent tool on Linux. In other words, how do you program the Nexys2 on Linux?

But what would it take to run Linux on the Nexys2, or a similar medium-sized FPGA? Can you just download an http://opencores.org/ processor that has a gcc toolchain for it, throw in some I/O controllers, and get the kernel booted up? I am so new to FPGA that I can’t even do a back-of-the-envelope calculation whether a Linux-capable core, plus glue, would fit. But it would be a fun project to find out!

Arduino XSVF Player?

I want to program a Xilinx XC9572XL and refuse to buy a $50 dongle to do so. Keywords in my research so far: xapp058, XSVF, SVF, JTAG, arduiggler. There is an FT232-based version that seems very close to what I want, but it’s written in Visual Basic, of all things, and probably won’t work on a modern non-FTDI Arduino.

If you’re reading this and do contract programming in exchange for karma, please write it in Python to avoid cross-platform issues!