Unused CPLD Pins

Thanks for confirming that.

Cheers,

Dave

I have a further question. Suppose one solders a brand new chip onto the PCB. What state would it's pins be in? I am, of course, asking before the chip is programmed at all.

I ask because one of the chip's pins are connected to pull up resistors. If the default state is an output then powering up a brand new chip might cause some I/O damage - but if that is the case, how is one supposed to program it?

--- Quote Start ---

I have a further question. Suppose one solders a brand new chip onto the PCB. What state would it's pins be in?

--- Quote End ---

You'll have to read the MAX V handbook.

They should be tri-stated, since their function has not been defined.

--- Quote Start ---

I ask because one of the chip's pins are connected to pull up resistors. If the default state is an output then powering up a brand new chip might cause some I/O damage - but if that is the case, how is one supposed to program it?

--- Quote End ---

Your pull-up will define the power-on state with a blank device.

You can also program the devices prior to assembly. There are TQFP and BGA sockets available.

For small numbers of boards, its easier just to use the JTAG to program the boards.

Cheers,

Dave

--- Quote Start ---

You'll have to read the MAX V handbook.

They should be tri-stated, since their function has not been defined.

Your pull-up will define the power-on state with a blank device.

You can also program the devices prior to assembly. There are TQFP and BGA sockets available.

For small numbers of boards, its easier just to use the JTAG to program the boards.

Cheers,

Dave

--- Quote End ---

Searching for the word "unprogrammed" in the databook lead me to this:

--- Quote Start ---

The programmable pull-up resistor is active during power-up, in-system programming (ISP), and if the device is unprogrammed

--- Quote End ---

So since the pull-up resistor is active it means the device must be tri-stated.

I'm a bit confused by what you mean by

--- Quote Start ---

Your pull-up will define the power-on state with a blank device.

--- Quote End ---

How would my pull up resistors define the default state of the device?

Ok, so the handbook indicates that the CPLD internal weak pull-ups are active in the unprogrammed state.

The signals connected to the CPLD pins will have a weak high applied to them. If an external device drives the signal on the CPLD, then it will over-ride the weak pull-up. If an external device is driven by the CPLD, then it will have a weak high applied, eg., an active low signal will be deasserted.

If you have a device signal that you would like a low on during power-on, then you need an external pull-down resistor on the signal, eg., 300-Ohms to ground. For example, the resetN signal on a controller that is controlled by the CPLD. If the CPLD is not programmed, then the external device will be held in reset.

I hope that is a little clearer.

Cheers,

Dave

--- Quote Start ---

The signals connected to the CPLD pins will have a weak high applied to them. If an external device drives the signal on the CPLD, then it will over-ride the weak pull-up.

--- Quote End ---

Thank you. And just to be sure - when an external signal overrides this weak pull up it will not damage the CPLD as the pins will be in tri-state?

--- Quote Start ---

Thank you. And just to be sure - when an external signal overrides this weak pull up it will not damage the CPLD as the pins will be in tri-state?

--- Quote End ---

That is correct.

Cheers,

Dave

Just to update you, Dave. The problem was indeed that the unused pins were set to "as outputs driving ground". When I changed it to "tristate inputs with weak pull up" the voltage went back to 3.3V.

I have the data transferring now and I've also modified the code to use the 8 MHz global clock instead of relying on SCK, as it was before in my old design.

begin
sync1: process(CLK)
variable resync: std_logic_vector(1 to 3);
begin
if rising_edge(CLK) then
rise	<= resync(2) and not resync(3);
fall	<=	resync(3) and not resync(2);
resync := SCK & resync(1 to 2);
end if;
end process;
process (CLK,nCS)
begin
if (nCS='1') then
tmp <= PI;
elsif rising_edge(CLK) then
if(fall = '1') then
tmp <= tmp(PI'high -1 downto PI'low) & '0';
end if;
end if;
end process;
SO <= tmp(PI'high) when nCS = '0' else 'Z';

Sorry about the non-indentation. The forum seems to be messing up my tabs.

--- Quote Start ---

Just to update you, Dave. The problem was indeed that the unused pins were set to "as outputs driving ground". When I changed it to "tristate inputs with weak pull up" the voltage went back to 3.3V.

--- Quote End ---

Great!

--- Quote Start ---

I have the data transferring now and I've also modified the code to use the 8 MHz global clock instead of relying on SCK, as it was before in my old design.

--- Quote End ---

If I was going to resynchronize an SPI clock to a local clock, I would instead write the code as:

1) SPI SCK goes through a dual DFF synchronizer. SPI select also needs to be synchronized. MISO and MOSI do not.

2) Generate a pulse on the rising or falling edges (or both since you want to read on rising and shift out on falling). The edge detector can be built by delaying the synchronizer output by one clock, and then using the delayed and non-delays signals (I'll let you figure it out).

3) Your SPI controller FSM can then be clocked at 8MHz, with inputs spi_sel, spi_sck_rising and spi_sck_falling to indicate edges.

You can then use those controls to determine whether your command shift register is shifted (on rising-edges), or your response is shifted (on falling-edges).

Write a testbench to generate the SPI input waveforms and you'll start to see what I mean.

Cheers,

Dave

When I look at the RTL schematic it seems that I do have two flip-flips (actually three) through which SCK is going. See below:

http://i.imgur.com/qWKkW.png

Do I gain anything from explicitly writing this with d-flip flops (like you did in your ByteBlaster code) instead of a vector? I must be missing something important.