- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
PB6 problem when fetching in the scratchpad
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-04-2012 02:58 PM
Hello!
I'm new to picoblaze, and I'm experiencing a problem which is giving me a hard time.
I'm trying to store and then retrieve a value from the scratchpad memory using the store and fetch instruction, but when I do so, I don't get the wanted value but FF. I've tried to simplify as much as possible my code to see where I could have done wrong, but here what I basically do:
CONSTANT DEBUG, FF main : LOAD s6, 00'd LOAD s7, 0A OUTPUT s6, DEBUG STORE s6, (s7) FETCH s6, (s7) OUTPUT s6, DEBUG LOAD s6, 02'd LOAD s7, 0B OUTPUT s6, DEBUG STORE s6, (s7) FETCH s6, (s7) OUTPUT s6, DEBUG LOAD s6, 04'd LOAD s7, 0C OUTPUT s6, DEBUG STORE s6, (s7) FETCH s6, (s7) OUTPUT s6, DEBUG LOAD s6, 06'd LOAD s7, 0D OUTPUT s6, DEBUG STORE s6, (s7) FETCH s6, (s7) OUTPUT s6, DEBUG LOAD s6, 08'd LOAD s7, 0E OUTPUT s6, DEBUG STORE s6, (s7) FETCH s6, (s7) OUTPUT s6, DEBUG JUMP main
And here what I get with Chipscope:
I absolutely don't see why I can't fetch the value back even when I try to get it just after storing it. Another strange behaviour, before noticing that the problem comes from my storing and fetching, I noticed that the value was either FF or 1E... And it was 1E after an interruption occurred.
Does someone have an idea of what could go wrong here ?
I am using ISE 12.3 and a Virtex6 fpga.
Re: PB6 problem when fetching in the scratchpad
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-06-2012 11:46 PM
Hi,
have you done some simulation too?
Where did you connect the Chipscope probe?
To out_port of the Picoblaze or to some real Port register, triggered by write_strobe?
Have a nice synthesis
Eilert
Re: PB6 problem when fetching in the scratchpad
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-07-2012 12:34 PM
Hi,
No, I haven't done a simulation, I directly tried it on the hardware. Should I try one to check a possible hardware problem ?
I connect the chipscope outside the picoblaze wrapper, so it shouldn't be a write_strobe problem I think. Here the picoblaze wrapper :
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use IEEE.std_logic_unsigned.all;
entity proc is
Port (
o_debug : out std_logic_vector (7 downto 0);
rst : in std_logic;
clk : in std_logic
);
end proc;
architecture RTL of proc is
--
-- Declaration of the default Program Memory recommended for development.
--
-- The name of this component should match the name of your PSM file.
--
component pico_proc
generic( C_FAMILY : string := "V6";
C_RAM_SIZE_KWORDS : integer := 1;
C_JTAG_LOADER_ENABLE : integer := 0);
Port ( address : in std_logic_vector(11 downto 0);
instruction : out std_logic_vector(17 downto 0);
enable : in std_logic;
rdl : out std_logic;
clk : in std_logic);
end component;
--
-- Signals for connection of KCPSM6 and Program Memory.
--
signal address : std_logic_vector(11 downto 0);
signal instruction : std_logic_vector(17 downto 0);
signal bram_enable : std_logic;
signal in_port : std_logic_vector(7 downto 0);
signal out_port : std_logic_vector(7 downto 0);
signal port_id : std_logic_vector(7 downto 0);
signal write_strobe : std_logic;
signal k_write_strobe : std_logic;
signal read_strobe : std_logic;
signal interrupt : std_logic;
signal interrupt_ack : std_logic;
signal rdl : std_logic;
-- Signals for interrupt generation
--
signal interrupt_count : integer range 0 to 255 :=0;
signal interrupt_event : std_logic;
begin
--
-------------------------------------------------- ---------------------------------------
-- Instantiate KCPSM6 and connect to Program Memory
-------------------------------------------------- ---------------------------------------
--
-- The KCPSM6 generics can be defined as required but the default values are shown below
-- and these would be adequate for most designs.
--
processor: kcpsm6
generic map ( hwbuild => X"36", -- 36 hex is ASCII Character "6"
interrupt_vector => X"3FF",
scratch_pad_memory_size => 64)
port map( address => address,
instruction => instruction,
bram_enable => bram_enable,
port_id => port_id,
write_strobe => write_strobe,
k_write_strobe => k_write_strobe,
out_port => out_port,
read_strobe => read_strobe,
in_port => in_port,
interrupt => interrupt,
interrupt_ack => interrupt_ack,
sleep => '0',
reset => rst,
clk => clk);
--
-- The default Program Memory recommended for development.
--
-- The generics should be set to define the family, program size and enable the JTAG
-- Loader. As described in the documentation the initial recommended values are.
-- 'S6', '1' and '1' for a Spartan-6 design.
-- 'V6', '2' and '1' for a Virtex-6 design.
-- '7S', '2' and '1' for a Artix-7, Kintex-7 or Virtex-7 design.
-- Note that all 12-bits of the address are connected regardless of the program size
-- specified by the generic. Within the program memory only the appropriate address bits
-- will be used (e.g. 10 bits for 1K memory). This means it that you only need to modify
-- the generic when changing the size of your program.
--
-- When JTAG Loader updates the contents of the program memory KCPSM6 should be reset
-- so that the new program executes from address zero. The Reset During Load port 'rdl'
-- is therefore connected to the reset input of KCPSM6.
--
program_rom: pico_proc --Name to match your PSM file
generic map( C_FAMILY => "V6", --Family 'S6', 'V6' or '7S'
C_RAM_SIZE_KWORDS => 1, --Program size '1', '2' or '4'
C_JTAG_LOADER_ENABLE => 0) --Include JTAG Loader when set to '1'
port map( address => address,
instruction => instruction,
enable => bram_enable,
rdl => rdl,
clk => clk);
--
-------------------------------------------------- ----------------------------------------
-- Interrupt
-------------------------------------------------- ----------------------------------------
--
interrupt_control: process(clk)
begin
if clk'event and clk='1' then
if interrupt_count = 250 then
interrupt_count <= 0;
interrupt_event <= '1';
else
interrupt_count <= interrupt_count + 1;
interrupt_event <= '0';
end if;
-- processor interrupt waits for an acknowledgement
if interrupt_ack='1' then
interrupt <= '0';
elsif interrupt_event='1' then
interrupt <= '1';
else
interrupt <= interrupt;
end if;
end if;
end process interrupt_control;
--
-------------------------------------------------- ---------------------------------------
-- General Purpose Input Ports.
-------------------------------------------------- ---------------------------------------
--
output_port: process (clk)
begin
if (clk'event and clk = '1') then
if (port_id = "11111111") then
o_debug <= out_port;
end if;
end if;
end process;
end RTL;
And here how the chipscope is connected, the signals sv_cs_control and sv_debug being previously declared and initialized to 0 :
icon_u0 : icon
port map
(
CONTROL0 => sv_cs_control
);
ila _u0: chip_ila
port map (
CONTROL => sv_cs_control,
CLK => clk50,
TRIG0 => strig0,
);
proc_u0 : proc port map ( rst => hard_reset_b, clk => clk50, o_debug => sv_debug, );
strig0 <= sv_debug;
Thank you very much for your help (and sorry for my poor english)
Re: PB6 problem when fetching in the scratchpad
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-07-2012 10:56 PM
Hi,
a simulation is always good, because it shows you what behavior you can expect from the design.
Also it's more flexible for analyzing the design. Access to all signals can be done instantly and the length of the waveform is limited mainly by the available storage space of your harddrice.
Chipscope has very limited capabilities compared to simulation, while it has its use to find true hardware problems (after design problems have been eliminated).
The output_port process of your design could need some improvement:
output_port: process (clk)
begin
if (clk'event and clk = '1') then
if write_strobe = '1' then -- uses CE of FFs this way, saving LUTs
if (port_id = "11111111" ) then
o_debug <= out_port;
end if;
end if;
end if;
end process;
It can happen that port ID is 0xFF even when no output command is active, this would cause wrong data to appear at the port. Only write_strobe ensures that port_id and out_port data are valid.
Check your design with a simulation first.
You can also compare the differences between your original design and the proposed change conveniently this way.
Have a nice synthesis
Eilert
Re: PB6 problem when fetching in the scratchpad
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
05-09-2012 08:12 AM
Hi !
I have added your improvement and tried a simulation. It worked on the ISim simulator, I retrieved my values as expected... Yet it still does the same FF problem once I put it on the hardware !
My code is part of a bigger design, so I guess the problem comes from somewhere else... But this is weird, I don't understand how it could possibly interfere.
Thanks a lot for your help, if I find a solution or the origin of the problem, I'll make a post here.
Re: PB6 problem when fetching in the scratchpad
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-02-2013 01:57 PM
Hi,
We are experiencing a similar issue. Could you please let us know if you found the cause of the problem?
Thanks
Re: PB6 problem when fetching in the scratchpad
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
04-03-2013 07:01 AM
@nkharth
As shown on pages 17, 18 and 74 of the KCPSM6 user documentation and in the templates and reference designs provided in the package, the ‘write_strobe’ must be used to qualify the ‘port_id’ when writing to an output port. I can see that Eilert pointed this out and you have reacted to it but as this was such a fundamental requirement it is worth taking the time to check everything else in your design to eliminate confusion.
By the way, your chipscope waveform did show the values 00, 02, 04, 06 and 08 between the FF’s and that suggest to me that everything is working correctly other than the fact that you didn’t define your output port correctly using ‘write_strobe’.
Principal Engineer, Xilinx UK











