A High Impedence Shift Register

--- Quote Start ---

Regarding what's the active state - I already wrote the code for an active state of High. Let's go with 0 this time so that I know the code both cases.

--- Quote End ---

You're confusing the active state of the output-enable with the active state of your output. Use a more obvious name for tmp, and you'll see what I mean, i.e.,

library ieee; 
use ieee.std_logic_1164.all; 
entity SerialInParallelOut is
    port(CLK, SI, Reset : in std_logic;
                        POut : out std_logic_vector(29 downto 0));
end SerialInParallelOut;
architecture shift of SerialInParallelOut is
    constant WIDTH : integer := 30;
    signal oe: std_logic_vector(WIDTH-1 downto 0);
begin
      process(CLK,Reset)
            begin
            if Reset = '1' then
                oe <= (others => '0');
            elsif rising_edge(CLK) then
                oe <= oe(WIDTH - 2 downto 0) & SI;
            end if;
        end process;
        
    process(oe)
    begin
        for i in 0 to WIDTH-1 loop
            if oe(i) = '0' then
                -- tri-state and allow the external pull-up to generate high
                POut(i) <= 'Z';
            else
                -- drive low when enabled
                POut(i) <= '0';
            end if;
        end loop;
    end process;
end shift;

--- Quote Start ---

I'm not using an FPGA, exactly. I'm using the Max V CPLD.

--- Quote End ---

That's fine. It should still have the weak pull-ups, and you can check the data sheet for their value.

Cheers,

Dave

Hmm, I may have trouble understanding the concept behind output_enable. As I understand, I need to have a buffer because internally the signals cannot be tri-stated. So we use a buffer to hold our signal and then substitute Z in place of a '1' (let's just stick with a '1' for now).

This is why we have two separate processes - one is essentially a shift register that works on the buffer and the other is a process that places the buffer at the output but tri-states the output where the buffer held a '1' - in other words, 10111111, which was "held" internally, becomes Z0ZZZZZZ at the output.

Isn't that pretty much it or am I missing something? Sorry to be so thick! Please know I appreciate your help immensely. And thank you for the code as well.

--- Quote Start ---

I may have trouble understanding the concept behind output_enable. As I understand, I need to have a buffer because internally the signals cannot be tri-stated. So we use a buffer to hold our signal and then substitute Z in place of a '1' (let's just stick with a '1' for now).

--- Quote End ---

Synthesize the logic and look at the RTL view; Tools->Netlist viewer->RTL viewer.

Your logic corresponds to a shift-register. Every bit of that shift-register is an 'output-enable' control to an equivalent number of tri-state buffers. Those signals control the output-enable port of the tri-state buffers. All of the inputs to the tri-states are connected to '0'. When an output-enable bit is 0 (disabled), the buffer output is 'Z', when the output-enable bit is 1 (enabled), the buffer is on, and it drives its input onto the output, i.e., the output is 0.

--- Quote Start ---

This is why we have two separate processes - one is essentially a shift register that works on the buffer and the other is a process that places the buffer at the output but tri-states the output where the buffer held a '1' - in other words, 10111111, which was "held" internally, becomes Z0ZZZZZZ at the output.

--- Quote End ---

Yes. The two processes correspond to the two types of logic you are creating; the shift register and the tri-state buffers with static inputs.

However, I'm concerned that you don't realize that as you shift, the output-enables will be enabling and disabling buffers. What you might need to consider is that you need an output register. In a JTAG boundary scan application, you have a capture state, shift state, and update state. In your case, you probably need to have the shift-register, a parallel output register, and a load control. When running a test, you would shift the new output-enable bits into the shift register, pulse the load control to copy the shift-register contents into the parallel output register, and that output register would control the tri-states. All outputs would then simultaneously change.

Cheers,

Dave

im sorry im really new to this and i cant find a post a new thread button anyways i have a code i cant seem to compile it! any helps

"

library ieee;

use ieee.std_logic_1164.all;

use ieee.std_logic_arith.all;

use ieee.std_logic_unsigned.all;

entity up_counter is

port(pb0, pb1, clk : in std_logic;

Q, q_out, clk_out: out std_logic_vector (3 downto 0));

end up_counter;

architecture sequential of up_counter is

signal count: std_logic_vector(3 downto 0);

begin

process (pb1, clk)

begin

if (pb1 = '1') then

count <= "0000";

elsif (CLK'event and (CLK = '1'))

then

count <= count + "0001";

end if;

end process;

Q <= count;

end sequential;

architecture Behavioral of up_counter is

signal clk_sig : std_logic;

begin

process(pb1,clk)

variable cnt : integer;

begin

if (pb1='0') then

clk_sig<='0';

cnt:=0;

elsif rising_edge(clk) then

if (cnt=24999999) then

clk_sig<=NOT(clk_sig);

cnt:=0;

else

cnt:=cnt+1;

end if;

end if;

end process;

clk_out <= clk_sig;"""

thanks alot and sorry again

end Behavioral;

--- Quote Start ---

Synthesize the logic and look at the RTL view; Tools->Netlist viewer->RTL viewer.

Your logic corresponds to a shift-register. Every bit of that shift-register is an 'output-enable' control to an equivalent number of tri-state buffers. Those signals control the output-enable port of the tri-state buffers. All of the inputs to the tri-states are connected to '0'. When an output-enable bit is 0 (disabled), the buffer output is 'Z', when the output-enable bit is 1 (enabled), the buffer is on, and it drives its input onto the output, i.e., the output is 0.

--- Quote End ---

OK, I think I understand upto this point. By looking at the rtl view (http://i.imgur.com/exxym.png) of the code, I see it a bit better. I can see the IO buffers being connected to the register (OE enable).

I think I also understand that the OE logic will actually be opposite to the output. Suppose output-enable(7) is enabled (is 1). This implies that the IO_Buffer(7) is also enabled which then drives the output which is 0. And this is exactly what the code implies:

if oe(i) = '0' then
                -- tri-state and allow the external pull-up to generate high
                POut(i) <= 'Z';
            else
                -- drive low when enabled
                POut(i) <= '0';
            end if;

To my understanding now, this code states that if the output_enable bit is disabled, then our respective output is also disabled (but an external pull up resistor will pull it to 1). But if we set our output_enable, then our output is 0. Correct?

The register controls the IO Buffers which in turn control the output.

--- Quote Start ---

However, I'm concerned that you don't realize that as you shift, the output-enables will be enabling and disabling buffers.

--- Quote End ---

Unfortunately, I get a bit confused here. Isn't it supposed to do that? When the buffer is on, it will drive our output to '0'. When it's off, it will tri-state the output. It sounds like what I need...

--- Quote Start ---

What you might need to consider is that you need an output register. In a JTAG boundary scan application, you have a capture state, shift state, and update state. In your case, you probably need to have the shift-register, a parallel output register, and a load control. When running a test, you would shift the new output-enable bits into the shift register, pulse the load control to copy the shift-register contents into the parallel output register, and that output register would control the tri-states. All outputs would then simultaneously change.

--- Quote End ---

I see. Does my current code not incorporate this? If not, how can I go about putting this in? As I understand, we have the shift register. We also have the parallel out register. I believe the load control is the new bit, isn't it?

Here's a picture from the simulation. It behaved exactly as I expected: I loaded a '1' via Serial In (SI) and immediately a 0 appeared at the output.

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

By clocking the register, I could see the '0' move through the outputs.

--- Quote Start ---

Here's a picture from the simulation. It behaved exactly as I expected: I loaded a '1' via Serial In (SI) and immediately a 0 appeared at the output.

By clocking the register, I could see the '0' move through the outputs.

--- Quote End ---

But do you really want it to move through the outputs, or do you want it to update all outputs in one clock? I wrote you a testbench to help explain things.

The testbench contains your component and a new-and-improved version :)

Since your component does not have a shift-enable and a load pulse, the component will 'keep going' when the clock is running. Its quite possible that you do not have a free running clock, and so this warning might not apply. But regardless, you might want to add this feature so that all the output bits update on a single clock; otherwise your wires are going to be bouncing around when you shift your test patterns.

Click on the JPG and look at the waveforms. 'Original' is your logic. 'Improved' is mine. With a free running clock, your component 'forgets' the pin state, since it keeps on shifting SI on every clock (and in this case SI was low).

Unzip the attached, start modelsim, change directory to the unzipped folder and type 'source sim.tcl' and it'll run the testbench.

Cheers,

Dave

Ah, now I understand! See, my "clock" is comes from the microcontroller. And it's really not a regulator clock, the uC just sends a pulse whenever it wants to shift the register. I don't have any crystal on the board.

The other thing is, I don't think I need to have a "load" bit. The reason is, I don't load different test patterns. It's always a walking '0'. Once the first '0' is loaded via SI, thats it. I know that if I send a pulse 30 times, the '0' will have fallen off.

So it's a bit like

1) Reset Shift Register.

2) Set SI to '0'.

3) Send a pulse.

4) Set SI to '1'

Continue shifting till the register has been pulsed 30 times.

Ignoring the free running clock and the enable bit, your approach would be as follows (for 8-bit register)

1) Reset shift register.

2) Load '1' and send a pulse 7 times. Then set SI to '0'. This will effectively load 11111110. But until the load bit is set, these will not appear the output. This is good because otherwise the outputs would rapidly change as the data is shifted in.

When we want to load 11111101, we can either send a pulse or clear load and clock the data in like I described above. The advantage that I see is that the uC will always know the position of '0' because it will form this data inside as a byte or a series of bytes. For my approach, it will have to keep track of the number of pulses that have been sent to the shift register.

This is a good approach, but do I need it if I only intend to load a single test vector?

In fact, for what it's worth, the other end of the wires have a Parallel In Serial Out shift register. That has a Load bit. The MCU sets Load and then clears it. It then transfers the data quickly via SPI.

--- Quote Start ---

Ah, now I understand! See, my "clock" is comes from the microcontroller. And it's really not a regulator clock, the uC just sends a pulse whenever it wants to shift the register. I don't have any crystal on the board.

--- Quote End ---

I would argue that this is bad solution. What if your external SPI clock from the microcontroller has ringing or noise? You will then get your test vector shifted incorrectly.

A more robust solution is to synchronize the SPI interface to the CPLD clock (and perhaps check a checksum if you want it really robust), i.e., use logic to detect rising-edges of the clock, and to check that there are no glitches that would cause double clocking. The detected clock edges are then used as enable pulses to the shift register.

--- Quote Start ---

The other thing is, I don't think I need to have a "load" bit. The reason is, I don't load different test patterns. It's always a walking '0'. Once the first '0' is loaded via SI, thats it. I know that if I send a pulse 30 times, the '0' will have fallen off.

--- Quote End ---

Right, but when you shift a 1, as it moves along the shift register, it will enable the first output, then the second, then the third, etc. This does not sound like the right solution to me, as you are supposed to be sending specific tests along the wires. With the loabable scheme you have more control.

--- Quote Start ---

So it's a bit like

1) Reset Shift Register.

2) Set SI to '0'.

3) Send a pulse.

4) Set SI to '1'

Continue shifting till the register has been pulsed 30 times.

--- Quote End ---

So you have the first output disabled, and then start enabling the other outputs. That does not make sense. If you invert the logic, then you have one output enabled and the others not. But even then, its hardly an exhaustive test.

--- Quote Start ---

Ignoring the free running clock and the enable bit, your approach would be as follows (for 8-bit register)

--- Quote End ---

Its not an 8-bit register. Its generic VHDL you set the WIDTH parameter to the width you want. I set it to 8 so you could compare the two implementations.

--- Quote Start ---

1) Reset shift register.

2) Load '1' and send a pulse 7 times. Then set SI to '0'. This will effectively load 11111110. But until the load bit is set, these will not appear the output. This is good because otherwise the outputs would rapidly change as the data is shifted in.

--- Quote End ---

No, there is no reset required each time you want to change the output, and no, you don't pulse load and then shift. Look at the code. The shift-register shifts in the value you want, and then you pulse load to load the parallel output register.

--- Quote Start ---

When we want to load 11111101, we can either send a pulse or clear load and clock the data in like I described above.

--- Quote End ---

You've got your logic inverted again. If you want the output 11111101, then you want to load the output-enable shift register with 00000010.

--- Quote Start ---

In fact, for what it's worth, the other end of the wires have a Parallel In Serial Out shift register. That has a Load bit. The MCU sets Load and then clears it. It then transfers the data quickly via SPI.

--- Quote End ---

If you are using SPI, then there should be an chip-select bit, you can use that to control the loading, i.e., the micro asserts chip-select, then sends as many bytes as you deem appropriate, and a state machine at the other end receives them, loading them into internal registers. When you deassert chip-select to indicate the command is complete. The state machine checks the bytes are valid and then updates the parallel output-enable register.

The difference here is making a system that your users will not have trouble with.

How fast is your SPI clock on the microcontroller? You really do not have an oscillator on your board? That was a poor design choice, you should always have an oscillator footprint on a board, and just not load it if you do not use it. The MAX V CPLDs probably have an on-chip oscillator (the MAX IIs do), so I could write an example showing what I am proposing to you.

And never never never create write-only registers. Your micro should be able to read back the output-enable register.

Cheers,

Dave

--- Quote Start ---

I would argue that this is bad solution. What if your external SPI clock from the microcontroller has ringing or noise? You will then get your test vector shifted incorrectly.

A more robust solution is to synchronize the SPI interface to the CPLD clock (and perhaps check a checksum if you want it really robust), i.e., use logic to detect rising-edges of the clock, and to check that there are no glitches that would cause double clocking. The detected clock edges are then used as enable pulses to the shift register.

--- Quote End ---

Understood. I'll include a crystal in the next revision of the board. Not quite sure how to sync. the the clocks, though.

--- Quote Start ---

Right, but when you shift a 1, as it moves along the shift register, it will enable the first output, then the second, then the third, etc. This does not sound like the right solution to me, as you are supposed to be sending specific tests along the wires. With the loabable scheme you have more control.

So you have the first output disabled, and then start enabling the other outputs. That does not make sense. If you invert the logic, then you have one output enabled and the others not. But even then, its hardly an exhaustive test.

--- Quote End ---

I'll try to describe the test. I'll ignore tri-states and things like that for now. I'll assume that we have a normal IO and no tri-state. So if we load 00000001 into the shift register, that's what appears at the output.

Now suppose we have 8 wires to test and there is a short circuit between wire 1 and 2. The shift register is loaded with 00000001. The shift register thats connected at the other end of the wires (parallel in serial out) loads these values and then shifts them out to the uC. Because there is a short circuit between wire 1 and 2, the shift register will read 00000011 - the expected output was 00000001 and it would have been this if the wires were OK.

We note this down and pulse the shift register. The shift register contents now read 00000010. At the other end, the values read at 00000011. Again, we know we have a short and this is just another confirmation. We then send another pulse. The register reads 00000100 and at the other end it's 00000100. Wire 3 is OK, its not short circuited anywhere.

Now the register is 00001000. If we read 00000000 we know that we have a broken wire. How does uC 'know' weather the output is OK or not? It maps out the wires. This is essentially a wiring harness tester for automobiles. As the harness is different for every model, the microcontroller first maps out a "reference" harness and stores it. When the outputs don't match, it knows there's an error. I'm sure you knew this but I wanted to explain further. I felt this was an exhaustive test - but if you feel I can do more, let me know. For what it's worth, I know specific test vectors could be generated that would test the harness much more quickly but time isn't a big factor. The harness is still connected manually onto jigs and then tested. As it is, the electronics are not the limiting factor.

This is obviously a simple example, but I hope you can see that it also takes into account junctions and such. But what I hope I showed was that there was no need to load the shift register again and again, when it could just be 'pulsed'. I know your approach has advantages but I just felt because I will always have a walking one/zero test vector, there's no need to a loading mechanism. But perhaps I'm still missing something here... you've been very patient with me and I appreciate that. I've learned a lot from this thread. And indeed, now I do understand that because of noise or ringing, the register could end up being shifted more than intended. As mentioned, I will definitely include a crystal on the next revision. But is a free running clock still necessary?

--- Quote Start ---

Its not an 8-bit register. Its generic VHDL you set the WIDTH parameter to the width you want. I set it to 8 so you could compare the two implementations.

--- Quote End ---

I know this. I said it's 8-bit register so we could discuss 8 values and not 30 or however much. The actual final circuit will need to test harnesses containing upto 300 wires so a 300 bit register will be needed and I know I can easily change a few variables to achieve that.

--- Quote Start ---

You've got your logic inverted again. If you want the output 11111101, then you want to load the output-enable shift register with 00000010.

--- Quote End ---

Sorry, still trying to get my head wrapped around this.

--- Quote Start ---

If you are using SPI, then there should be an chip-select bit, you can use that to control the loading, i.e., the micro asserts chip-select, then sends as many bytes as you deem appropriate, and a state machine at the other end receives them, loading them into internal registers. When you deassert chip-select to indicate the command is complete. The state machine checks the bytes are valid and then updates the parallel output-enable register.

--- Quote End ---

Only one shift register is connected via SPI - the parallel in serial out is connected via SPI as it allows me to shift out whole contents very easily.

The parallel out serial in is connected via general purpose IO pins and thats controlled like I described in my previous post.

--- Quote Start ---

How fast is your SPI clock on the microcontroller? You really do not have an oscillator on your board? That was a poor design choice, you should always have an oscillator footprint on a board, and just not load it if you do not use it. The MAX V CPLDs probably have an on-chip oscillator (the MAX IIs do), so I could write an example showing what I am proposing to you.

--- Quote End ---

The SPI clock is at 62.5KHz. It's so slow because speed isn't necessary - as mentioned, the limiting factor isn't the electronics.

--- Quote Start ---

And never never never create write-only registers. Your micro should be able to read back the output-enable register.

--- Quote End ---

Understood. I'll make sure the next revision of the board (the current board is just a prototype) has a crystal and that the uC is able to read back the contents. This will provide valuble feedback weather data was loaded correctly or not.

EDIT: Reading the document on max v architecture (http://www.altera.com/literature/hb/max-v/mv51002.pdf), page 2-21 and 2-22 talk about the internal oscillator. Is this the oscillator you were talking about? If so, how can I use this to synchronize my shift register and uC? As mentioned, only one of the shift registers is connected via SPI. But if required, I'll connect both of them via SPI on the next revision.

--- Quote Start ---

Understood. I'll include a crystal in the next revision of the board. Not quite sure how to sync. the the clocks, though.

--- Quote End ---

When you get to that point I can show you.

--- Quote Start ---

I'll try to describe the test ...

--- Quote End ---

Thanks for the explanation.

You are focused on the shift-register as being a key part of your design. I'm trying to encourage you to see the bigger picture.

You have a CPLD. This is a very powerful device. Its way more than a shift register. It could in fact perform the walking 1's test automatically.

I'm just trying to expand your horizons. What you have proposed would work, but it won't help you solve the next problem.

Consider the following system;

1) Microcontroller to CPLD interface implementing using SPI. The bytes over SPI define a protocol, something like a command byte, address byte(s), and data bytes(s). Your CPLD is then an addressable memory map.

2) Within the CPLD memory map are the registers that control the test-harness tester. The test harness interface involves a tri-state buffer, output enable registers, and pin readback registers.

3) You can manually generate shift patterns to the registers, or later you could generate patterns automatically.

--- Quote Start ---

Reading the document on max v architecture (http://www.altera.com/literature/hb/max-v/mv51002.pdf), page 2-21 and 2-22 talk about the internal oscillator. Is this the oscillator you were talking about? If so, how can I use this to synchronize my shift register and uC? As mentioned, only one of the shift registers is connected via SPI. But if required, I'll connect both of them via SPI on the next revision.

--- Quote End ---

The SPI signals from your microcontroller would be passed through a synchronizer; a cascade of D-flip-flops (generally two is sufficient) clocked by the oscillator (external or internal). The rising-edge of the clock can be detected by delaying the clock by one more clock (using a DFF) and then NANDing that with the undelayed version (draw a picture, it'll make sense).

The SPI chip-select and rising-edge can be an input to a state machine that is clocked in the oscillator clock domain, and that state machine can be used to parse the bits coming into the CPLD.

If you look in the Embedded Peripheral IP Users Guide, they probably have something like this in there.

But like I said, what you are proposing is not wrong. But you're potentially limiting yourself. If you make sure you have an oscillator and the full SPI interface wired into your CPLD (SPI clk, sel, mosi, miso), then you can work on this alternative design later.

Cheers,

Dave