cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
tim00
Visitor
Visitor
6,780 Views
Registered: ‎06-01-2014

KCPSM3 and JUMP issue

Jump to solution

Hello,

 

I have an issue with the JUMP instruction on the kcpsm3, and I suppose I misunderstood this instruction, maybe someone can help me ? 

 

Here are the lines :

 

12C  04002       recBFlag: INPUT s0[tempReg], 02[I2C_STATUS]          ; I2C : Read status
12D  12002                 TEST s0[tempReg], 02                       ; test busy flag
12E  3592C                 JUMP C, 12C[recBFlag]                      ; 
12F  2A000                 RETURN                                     ; 

 

This is supposed to work as a "while(busy_flag)" to wait for the busy flag to be at '0', and RETURN when it is (the recBFlag is CALLed before).. So I want a loop waiting for the busy flag to be dwon. 

 

 

My problem is that after the jump instruction, as I should come back to the recBFlag label, the program counter increments and the next instruction is "RETURN".This can be seen on this picture : 

 

jumpIssue.png

This can't be seen on this picture but the busy_flag bit of the I2C_Status is at '1' all the time here. 

 

 

Thanks for the PicoBlaze and your answers,

 

Timothée Fivaz

Student at the HE-Arc (Switzerland)

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
chapman
Xilinx Employee
Xilinx Employee
8,325 Views
Registered: ‎09-05-2007

I would like to see exactly what you have connected to ‘in_port(7:0)’ of KCPSM3. Actually, I want to see what value is read into register ‘s0’ during your INPUT instruction. As described in the KCPSM3 Manual there are simulation variables that show the contents of registers that you can display in a simulator. That said, not all simulators provide the ability to display variables so for a really quick debugging test try putting  ‘OUTPUT s0,FF’ immediately after your INPUT instruction and displaying ‘port_id’, ‘out_port’ and ‘write_strobe’ in your simulator to see what the contents of ‘s0’ are before the TEST instruction is executed.   

 

The decoding you have shown us is mainly involved with output ports. At some point you need to use ‘write_strobe’ to qualify your OUTPUT instructions but we can’t see that either. You have mixed some input decoding in there as well but that confused me for a while too! We still don't have a full picture of what is being presented to 'in_port'. I wonder if you have more pipeline stages in that path.

 

Ken Chapman
Principal Engineer, Xilinx UK

View solution in original post

0 Kudos
7 Replies
gbredthauer
Explorer
Explorer
6,766 Views
Registered: ‎02-27-2008
Your instructions look correct. Can you post the logic you're using to decode the port address and register the inputs to Picoblaze?

-Greg
0 Kudos
tim00
Visitor
Visitor
6,763 Views
Registered: ‎06-01-2014

Thank you for your answer.

 

Here is the structure around the PicoBlaze : i2cstructure.png

 

There are an I2C IP (selfmade), an UART module (the macros from Xilinx), some registers, and a RTC (PCF8563).

 

Here is the code of the address_decoder : 

 

-- EASE/HDL begin --------------------------------------------------------------
-- 
-- Architecture 'rtl' of entity 'decodage_adresse'.
-- 
--------------------------------------------------------------------------------
-- 
-- Copy of the interface declaration:
-- 
--   port (
--     Data_out_I2C       : in     std_logic_vector(7 downto 0);
--     Data_out_registres : in     std_logic_vector(7 downto 0);
--     address_in         : in     std_logic_vector(7 downto 0);
--     clk                : in     std_logic;
--     data_out_UART      : in     std_logic_vector(7 downto 0);
--     ebl_I2C            : out    std_logic;
--     ebl_UART           : out    std_logic;
--     ebl_reg            : out    std_logic;
--     ebl_status_bus     : out    std_logic;
--     in_port            : out    std_logic_vector(7 downto 0);
--     reset_n            : in     std_logic);
-- 
-- EASE/HDL end ----------------------------------------------------------------

architecture rtl of decodage_adresse is

begin
            
	p1:PROCESS (clk, reset_n) BEGIN
		IF reset_n = '0' THEN --reset asynchrone actif bas
			ebl_reg 		<= '0';
			ebl_UART 		<= '0';
ebl_status_bus <= '0'; ebl_I2C <= '0'; in_port <= (OTHERS => '0'); ELSIF (clk'EVENT AND clk = '1') THEN --flanc montant du signal clk CASE address_in(7 downto 5) IS WHEN "000" => ebl_I2C <= '1'; ebl_reg <= '0'; ebl_UART <= '0'; ebl_status_bus <= '0'; in_port <= Data_out_I2C; WHEN "010" => ebl_I2C <= '0'; ebl_reg <= '1'; ebl_UART <= '0'; ebl_status_bus <= '0'; in_port <= Data_out_registres; WHEN "100" => ebl_I2C <= '0'; ebl_reg <= '0'; ebl_UART <= '1'; ebl_status_bus <= '0'; in_port <= data_out_UART; WHEN "101" => ebl_I2C <= '0'; ebl_reg <= '0'; ebl_UART <= '0'; ebl_status_bus <= '1'; in_port <= data_out_UART; WHEN OTHERS => ebl_I2C <= '0'; ebl_reg <= '0'; ebl_UART <= '0'; ebl_status_bus <= '0'; in_port <= (OTHERS => '0'); END CASE; END IF; END PROCESS; end architecture rtl ; -- of decodage_adresse

 

I forgot to precise this but after the "TEST" instruction the carry flag of the PicoBlaze is at '1' and doesn't go down before a while, so the "JUMP C" instruction should really jump back to recBFlag.

0 Kudos
gbredthauer
Explorer
Explorer
6,759 Views
Registered: ‎02-27-2008
I'm a bit confused - in your code, you do an INPUT from address 0x02 for your I2C module, but in your decoder, you appear to be watching for 0x00 for the I2C module?
0 Kudos
tim00
Visitor
Visitor
6,758 Views
Registered: ‎06-01-2014
This is because the relevant bits for the decoder are the bits 7 downto 5. 0x02 has "000" in the 7 downto 5 bits, which enables the I2C IP.

Then in the I2C registers we have 5-bits addressable registers which take the bits 4 downto 0, in this case : "00010", which is our status register's address.
0 Kudos
chapman
Xilinx Employee
Xilinx Employee
8,326 Views
Registered: ‎09-05-2007

I would like to see exactly what you have connected to ‘in_port(7:0)’ of KCPSM3. Actually, I want to see what value is read into register ‘s0’ during your INPUT instruction. As described in the KCPSM3 Manual there are simulation variables that show the contents of registers that you can display in a simulator. That said, not all simulators provide the ability to display variables so for a really quick debugging test try putting  ‘OUTPUT s0,FF’ immediately after your INPUT instruction and displaying ‘port_id’, ‘out_port’ and ‘write_strobe’ in your simulator to see what the contents of ‘s0’ are before the TEST instruction is executed.   

 

The decoding you have shown us is mainly involved with output ports. At some point you need to use ‘write_strobe’ to qualify your OUTPUT instructions but we can’t see that either. You have mixed some input decoding in there as well but that confused me for a while too! We still don't have a full picture of what is being presented to 'in_port'. I wonder if you have more pipeline stages in that path.

 

Ken Chapman
Principal Engineer, Xilinx UK

View solution in original post

0 Kudos
tim00
Visitor
Visitor
6,747 Views
Registered: ‎06-01-2014

Thank you for your answer. Here is a more complete simulation.

 

i2coverallview.png

 

I can't include the s0 register in the simulation, nor can I include the kcpsm3_opcode. Too bad ISim (or at least the version my school uses) doesn't support the tracing of VHDL variables. 

 

I see now that unlike what I thought, the carry flag is down, which explains why the JUMP isn't made. I thought that the JUMP had to be made because his instruction was there, but of course if the carry flag is down, the program counter will just incremens. 

 

Anyway, I don't understand why the carry flag doesn't get high when I test the s0 register, which should take the value of the input, 0x02. I read in your document that the carry bit is set high when, as I test a single bit, the bit tested is high. Is it right that if the value of s0 is 0x02, the instruction "TEST s0,02" should set the carry flag high ? 

 

Thank you very much for your help

Timothée Fivaz

0 Kudos
tim00
Visitor
Visitor
6,739 Views
Registered: ‎06-01-2014

While searching further on this forum, I found how to include the s0-sF registers in the simulation. Here's the simulation with the s0 vector added : 

 

i2csims0.png

 

This was helpful but I could've seen my problem before, the in_port takes the value 0x02 right after the INPUT instruction (opcode 04002), which was caused by a mistake in a register I had made in my I2C IP. Now that this one is solved I'll be able to go on debugging my application. 

 

Thank you for your help, and for your amazing work on the kcpsm3 which is a real pleasure to use. 

 

Best regards

 

Timothée fivaz

0 Kudos