|
|
|
|
|
Xilinx User Community Forums :
Embedded Solutions :
PicoBlaze :
Re: Pointers
|
|
|
|
|
|
|
Pointers
|
|
digital_mind
Contributor
Posts: 39
Registered: 09-03-2007
Message 1 of 11
Viewed 12,835 times
|
|
|
Dear Ken, How are you? I have a question, what will happen if I tried to access the scratch pad memory in PicoBlaze with a pointer greater than its maximum depth? Thanks in advance |
|
|
|
09-10-2007 01:02 PM
|
|
|
|
|
|
Re: Pointers
|
|
 kcmman
Xilinx Employee
Posts: 155
Registered: 09-05-2007
Message 2 of 11
Viewed 12,817 times
|
|
As you know, the scratch pad memory is 64-bytes and this is accessed using the following instructions.
STORE sX, ss
STORE sX, (sY)
FETCH sX, ss
FETCH sX, (sY)
In each case it is the value held in the ‘sX’ register which is data being written (stored) or read (fetched) from the scratch pad memory. The memory location is either the absolute address specified by a constant value ‘ss’ or the contents of a second register ‘sY’.
In the case of specifying an absolute value ‘ss’ in your program the KCPSM3 assembler will only accept a two digit hexadecimal value in the range 00 to 3F (0 to 63 decimal).
When you use a pointer ‘(sY)’ then you do have the potential to specify a location anywhere in the range 00 to FF (0 to 255 decimal) but only the values 00 to 3F are really valid and your PicoBlaze program should be the one to ensure the scratch pad address remains in the valid range.
However you raise a valid question and the answer is very simple. PicoBlaze totally ignores the most significant 2-bits of the pointer specified by ‘(sY)’ and therefore all values exceeding 3F will alias back to the normal range. There is no error trapping.
For example, if ‘sY’ contains 25 hex, 65, hex , A5 hex or E5 then in all cases the use of ‘sY’ as a scratch pad memory pointer will always result in the use of scratch pad memory location 25 hex because the least significant 6-bits are identical.……
25 hex = 00 10 0101
65 hex = 01 10 0101
A5 hex = 10 10 0101
E5 hex = 11 10 0101
KCPSM3 has a 64-byte memory as this is the largest depth supported by distributed RAM in Spartan-3 Generation devices. For the more adventurous (and experienced) it is possible to edit the ‘kcpsm3.vhd’ or ‘kcpsm3.v’ file and replace the 64-byte scratch pad memory with a 256-byte memory (probably using a BRAM) because the all 8-bits are available to connect to address the memory. In which case the 00 to FF range of your ‘sY’ pointer would be fully used.
Regards,
Ken Chapman
Ken Chapman
Senior Staff Engineer, Applications Specialist, Xilinx UK
|
|
|
|
09-11-2007 08:36 AM
|
|
|
|
|
|
Re: Pointers
|
|
digital_mind
Contributor
Posts: 39
Registered: 09-03-2007
Message 3 of 11
Viewed 12,805 times
|
|
|
Dear Ken
Thanks for your valuable answers. I would like to ask if you have a KCPSM3 design which utilize a 256bytes BRAM instead of 64bytes Distributed RAM?
If yes, can you please send it to me?
Thanks and best regards
|
|
|
|
09-12-2007 04:23 AM
|
|
|
|
|
|
Re: Pointers
|
|
kcmman
Xilinx Employee
Posts: 155
Registered: 09-05-2007
Message 4 of 11
Viewed 12,778 times
|
|
|
I do not have a version of KCPSM3 which has 256-bytes of scratch pad memory because it would not be self contained. As I mentioned previously, BRAM is probably the best idea for this much memory. The issue is that 256 bytes is then only 12.5% of the capacity of a BRAM and it makes a lot of sense to utilise the remaining 1792-bytes for something else.
Since BRAM is dual port you can access the remaining memory via the second port. For some people that is the main PicoBlaze program and for others it is another PicoBlaze or other logic. The efficient and creative use of the BRAM is going to be highly dependent on your design and your situation.
By the way, the section of code you need to replace or modify in 'kcspm3.vhd' in the generate loop called 'store_loop'.
Regards,
Ken
Ken Chapman
Senior Staff Engineer, Applications Specialist, Xilinx UK
|
|
|
|
09-17-2007 06:00 AM
|
|
|
|
|
|
Re: Pointers
|
|
feichtinger
Visitor
Posts: 4
Registered: 12-13-2007
Message 5 of 11
Viewed 12,488 times
|
|
|
Right now I can define constants and it takes me an instruction line to move the constant to a register or to the scratch pad memory.
The scratch pad memory is initialized to zero. Could it be an future option to make the initialization accessible to store "start up" constants into the scratch pad memory?
Regards,
Richard
|
|
|
|
12-13-2007 01:34 AM
|
|
|
|
|
|
Re: Pointers
|
|
kcmman
Xilinx Employee
Posts: 155
Registered: 09-05-2007
Message 6 of 11
Viewed 12,475 times
|
|
Dear Richard,
I had initially planned to implement preloading of both
scratch pad memory and registers but I decided not to in the end for two
reasons. The first being that a hard reset would not re-initialise the values
and the second being that program development would require a lot more re-synthesis rather
than the use of JTAG_loader or DATA2MEM.
Of course there is nothing to stop you implementing manual preloading
in your own design because if you look in the KCPSM3.VHD or KCPSM3.V you can
find the distributed memory forming the registers and scratch pad memory and apply
your own non-zero INIT values. I appreciate that is not ‘ease of use’ so I
think this is only worth doing if you have a lot of constants. I said it before
but I’ll say it again; hard reset does not restore the values.
I think the easier way is to connect an initialised ROM to
a PicoBlaze input port. You can even use the second
port of the instruction BRAM and that is why the INST directive is provided in the
assembler.
Regards,
Ken
Ken Chapman
Senior Staff Engineer, Applications Specialist, Xilinx UK
|
|
|
|
12-14-2007 02:06 PM
|
|
|
|
|
|
Re: Pointers
|
|
feichtinger
Visitor
Posts: 4
Registered: 12-13-2007
Message 7 of 11
Viewed 12,451 times
|
|
|
Dear Ken,
thanks for your instant reply.
I'm aware of the hard reset argument but I think it's still worth thinking about preloading. I guess there are quite a lot of applications that don't consume anything ot the available scratch pad memory and sX registers. So it would be possible to use these leftovers as ROM cells for predefined constants. If it would be possible to do the initialisation inline similar to the INST directive the assambler could check if there is any write access to these "ROM cells" - reporting a warning or even an error. Ok, more re-synthesis could be a fact but if I would use that predefining option I would use it for constants that are more or less well defined from the project start. So, if predefining would exit - it is still up to the user to use it or not! But right now I don't have the option besides of creating my own solution as you described.
Experimenting with your recommended alternatives didn't work out straightforward. I thought PicoBlaze is easy to use within the System Generator Tool as I simulate and implement other parts of my design with sysgen. The Dual Port RAM of the Xilinx Blockset has the restriction that data width of port B as to be greater or eval to data width of port A. That means that I have to use port B as instruction memory path and port A as constant ROM path when I choose width A = 9 (8), depth A = 2048 and width B = 18. Running xlpb_as.p generates a file called fill_pico_code_program_store.m that won't fit to this DPRAM topology. Next problem is that xlpb_as.p invokes assembler version KCPSM3 v1.12 even after updating the system to the latest releases (DSP tools 9.2.1, ISE 9.2.4, ISE IP 2) and so the INST directive is not available.
On the other hand - the alternatives recommended will cost extra logic resources. A little bit of an antagonism to the lean PicoBlaze concept?!
Regards,
Richard
|
|
|
|
12-17-2007 12:18 AM
|
|
|
|
|
|
|
|
Re: Pointers
|
|
shayping
Newbie
Posts: 2
Registered: 12-19-2007
Message 9 of 11
Viewed 12,403 times
|
|
Hi Richard,
You are quite right that the current version of
System Generator makes use of version 1.12 of the PicoBlaze assembler.
We will move up to the latest 1.30 version in the next release of
System Generator. In the mean time, there is a very simple work around.
Download the 1.30 version of the assembler from
www.xilinx.com/picoblaze and simply copy the executable "kcpsm3.exe"
into the System Generator bin directory, %SYSGEN_ROOT/bin
There
has not been an update to the HDL of the PicoBlaze since version 1.12
of the assembler, so you should be good to go after changing the
assembler.
Cheers,
shay
|
|
|
|
12-19-2007 10:56 AM
|
|
|
|
|
|
Re: Pointers
|
|
feichtinger
Visitor
Posts: 4
Registered: 12-13-2007
Message 10 of 11
Viewed 12,381 times
|
|
|
Hi Shay,
thanks for your info.
System Generator causes another trouble to the user of the PicoBlaze block - it doesn't support Spartan 3A and Spartan 3A DSP though these members of the Spartan 3 family have been released for a while. So I guess I have to live with another work around. I'm just experimenting with calling Pico Blaze by means of a Black Box block. Is there another - better - solution?
Cheers,
Richard
|
|
|
|
12-20-2007 06:11 AM
|
|
|
|
|
|
|
|
|
|
