mirror of
https://github.com/pConst/basic_verilog.git
synced 2025-01-14 06:42:54 +08:00
600 lines
32 KiB
Plaintext
600 lines
32 KiB
Plaintext
|
||
<EFBFBD> Copyright 2010-2014, Xilinx, Inc. All rights reserved.
|
||
This file contains confidential and proprietary information of Xilinx, Inc. and is
|
||
protected under U.S. and international copyright and other intellectual property laws.
|
||
|
||
Disclaimer:
|
||
This disclaimer is not a license and does not grant any rights to the materials
|
||
distributed herewith. Except as otherwise provided in a valid license issued to you
|
||
by Xilinx, and to the maximum extent permitted by applicable law: (1) THESE MATERIALS
|
||
ARE MADE AVAILABLE "AS IS" AND WITH ALL FAULTS, AND XILINX HEREBY DISCLAIMS ALL
|
||
WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED
|
||
TO WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR
|
||
PURPOSE; and (2) Xilinx shall not be liable (whether in contract or tort, including
|
||
negligence, or under any other theory of liability) for any loss or damage of any
|
||
kind or nature related to, arising under or in connection with these materials,
|
||
including for any direct, or any indirect, special, incidental, or consequential
|
||
loss or damage (including loss of data, profits, goodwill, or any type of loss or
|
||
damage suffered as a result of any action brought by a third party) even if such
|
||
damage or loss was reasonably foreseeable or Xilinx had been advised of the
|
||
possibility of the same.
|
||
|
||
CRITICAL APPLICATIONS
|
||
Xilinx products are not designed or intended to be fail-safe, or for use in any
|
||
application requiring fail-safe performance, such as life-support or safety devices
|
||
or systems, Class III medical devices, nuclear facilities, applications related to
|
||
the deployment of airbags, or any other applications that could lead to death,
|
||
personal injury, or severe property or environmental damage (individually and
|
||
collectively, "Critical Applications"). Customer assumes the sole risk and
|
||
liability of any use of Xilinx products in Critical Applications, subject only to
|
||
applicable laws and regulations governing limitations on product liability.
|
||
|
||
THIS COPYRIGHT NOTICE AND DISCLAIMER MUST BE RETAINED AS PART OF THIS FILE AT ALL TIMES.
|
||
|
||
|
||
|
||
-------------------------------------------------------------------------------------------------
|
||
KCPSM6 : Known Issues and Workarounds
|
||
-------------------------------------------------------------------------------------------------
|
||
|
||
This file was included with KCPSM6 Release 9 - 30th September 2014.
|
||
|
||
Ken Chapman - Xilinx Ltd - 30th September 2014
|
||
|
||
|
||
This document contains known issues and workarounds with PicoBlaze or when using PicoBlaze in an
|
||
ISE or Vivado design environment. For more general discussion and to share ideas and experiences
|
||
please visit the PicoBlaze forum. It is likely that commonly asked questions will be discussed
|
||
here and threads provide a resource for everyone to be able to read.
|
||
|
||
http://forums.xilinx.com/t5/PicoBlaze/bd-p/PicoBlaze
|
||
|
||
Xilinx Technical support is also available to answer your questions. However it is recommended
|
||
that you take the time to consider exactly what your issue is before asking any questions. Just
|
||
because your design contains a PicoBlaze processor doesn't mean you actually have a problem
|
||
with PicoBlaze! If you are a Xilinx novice and encounter difficulties then make sure you can
|
||
get a simple HDL design through ISE or Verilog before including PicoBlaze.
|
||
|
||
http://www.xilinx.com/support/clearexpress/websupport.htm
|
||
|
||
|
||
|
||
-------------------------------------------------------------------------------------------------
|
||
Contents
|
||
-------------------------------------------------------------------------------------------------
|
||
|
||
Potential issues when using ISE 12.x
|
||
|
||
JTAG Loader requires ISE/ChipScope when using Vivado
|
||
|
||
'The XILINX environment variable is not set or is empty'
|
||
'The program can't start because libCsdFpga.dll is missing...'
|
||
|
||
'PCMSVCR100.dll' or 'MSVCR100.dll' is missing or could not be found
|
||
|
||
KCPSM6 program memory can be corrupted when configuring device with Vivado 'Hardware Manager'.
|
||
|
||
KCPSM6 size may vary when using Vivado
|
||
|
||
WARNING:Xst:647 - Input <instruction<0:11>> is never used
|
||
|
||
INFO:Xst:2261 or WARNING:Xst:1710 messages relating to Unit <jtag_loader_6>
|
||
|
||
JTAG Loader not working
|
||
|
||
JTAG Loader may take ~25 seconds to load a new program when using an ATLYS board
|
||
|
||
Designs containing multiple KCPSM6 processors
|
||
|
||
'global_opt' may result in incorrect implementation
|
||
|
||
'Pack:2811' errors in MAP when using ChipScope
|
||
|
||
'Pack:2811' errors in MAP when using 'Keep Hierarchy' and design contains multiple KCPSM6.
|
||
|
||
'Pack:2811' errors in MAP when using a low 'Max Fanout' value in XST.
|
||
|
||
'PhysDesignRules:1422' errors reported by BITGEN
|
||
|
||
JTAG Loader and BSCAN Users
|
||
|
||
KCPSM6 program memory can be corrupted when using ChipScope Analyser
|
||
|
||
KCPSM6 program memory can be corrupted when using Vivado Hardware Manager
|
||
|
||
Poor Display of Strings in ISE Simulator
|
||
|
||
KCPSM6 Assembler window takes a long time to appear on screen
|
||
|
||
-------------------------------------------------------------------------------------------------
|
||
Descriptions
|
||
-------------------------------------------------------------------------------------------------
|
||
|
||
|
||
Potential issues when using ISE 12.x
|
||
------------------------------------
|
||
|
||
Using ISE v12.x may result in XST generating errors similar to the following...
|
||
|
||
HDLCompiler:1314 - "<program_ROM_filename>.vhd" Line 390:
|
||
Formal port/generic <rdaddr_collision_hwconfig> is not declared in <ramb18e1>
|
||
|
||
The logic primitives including BRAM are defined in libraries that XST reads as it elaborates
|
||
your design. Not surprisingly these libraries change with each release of the ISE tools. In
|
||
particular the ISE v13.x tools introduced support for the 7-Series devices a obviously this
|
||
required quite significant additions and alterations to the underlying libraries.
|
||
|
||
The ROM_form templates have been prepared to match with the libraries provided with ISE v13.x
|
||
and therefore the potential exists for a something to be absent from an older library
|
||
resulting in a error similar to that shown above.
|
||
|
||
It is recommended that you use ISE v13.2 or later with KCPSM6 but if this is not convenient
|
||
then simply replace the default 'ROM_form.vhd' or 'ROM_form.v' template with a copy of an
|
||
older template that was supplied with 'Release 2' of KCPSM6 and included in this package
|
||
for your convenience.
|
||
|
||
Provided for use with ISE v13.x or later
|
||
|
||
ROM_form_JTAGLoader_14March13.vhd
|
||
ROM_form_JTAGLoader_14March13.v
|
||
|
||
Provided for use with ISE v12.x only
|
||
|
||
ROM_form_JTAGLoader_3Mar11.vhd
|
||
ROM_form_JTAGLoader_3Mar11.v
|
||
|
||
|
||
JTAG Loader requires ISE/ChipScope when using Vivado
|
||
----------------------------------------------------
|
||
|
||
In order to use JTAG loader the drivers associated with ChipScope must be present. These
|
||
drivers provide access the Platform Cable USB or the equivalent Digilent circuit. It is
|
||
therefore necessary to also have an installation of ChipScope which is part of the ISE
|
||
tools. Please see page 25 of 'PicoBlaze_Design_in_Vivado.pdf' which presents a simple
|
||
batch file that will set environment variables that specify the location of ISE on you
|
||
PC so that JTAG Loader will be able to work.
|
||
|
||
|
||
'The XILINX environment variable is not set or is empty'
|
||
'The program can't start because libCsdFpga.dll is missing...'
|
||
--------------------------------------------------------------
|
||
|
||
The 'PATH' and 'XILINX' environment variables must be correctly set to the location of
|
||
an ISE installation. Please see one or more of the following for further details...
|
||
|
||
'READ_ME_FIRST.txt' - 'System Requirements' section.
|
||
'KCPSM6_User_Guide_30Sept14.pdf' - Page 25.
|
||
'PicoBlaze_Design_in_Vivado.pdf' - Page 25.
|
||
|
||
|
||
'PCMSVCR100.dll' or 'MSVCR100.dll' is missing or could not be found
|
||
-------------------------------------------------------------------
|
||
|
||
The following description is also to be found in the 'System Requirements' section of the
|
||
'READ_ME_FIRST.txt' file.
|
||
|
||
JTAG Loader must also be able to access some system level DLL files. In the case of a Windows-XP
|
||
environment then it is normal for the PATH to contain 'C:\WINDOWS\system32;' or similar. So if
|
||
you receive a system error indicating that 'PCMSVCR100.dll' is missing or could not be found then
|
||
add the appropriate definition to your PATH. When using a Windows-7 environment it is more likely
|
||
that 'MSVCR100.dll' will become the subject of a system error message. 'MSVCR100.dll' is not part
|
||
of a default Windows-7 installation but is a often present as a result of a Microsoft Visual C++
|
||
application. If you do encounter this issue then the quickest solution is to place a copy of
|
||
'msvcr100.dll' provided in the 'JTAG_Loader' directory of this package in to the same directory
|
||
as the JTAG Loader executable you are invoking.
|
||
|
||
|
||
|
||
KCPSM6 program memory can be corrupted when configuring device with Vivado 'Hardware Manager'.
|
||
----------------------------------------------------------------------------------------------
|
||
|
||
Vivado 'Hardware Manager' results in the same memory corruption issue as described in
|
||
'KCPSM6 program memory can be corrupted when using ChipScope Analyser'. In this case the only
|
||
workarounds are either to use iMPACT to configure your device or to write your program in a way
|
||
that avoids address 003. For example, placing the following at the start of a program will ensure
|
||
that the corrupted location is not executed at all.
|
||
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> JUMP cold_start ;Avoid address 003 on start up
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> JUMP cold_start
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> JUMP cold_start
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> JUMP cold_start ;Address 003
|
||
<20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>;
|
||
cold_start: <normal program code starts here>
|
||
|
||
|
||
KCPSM6 size may vary when using Vivado
|
||
--------------------------------------
|
||
|
||
When using Vivado to implement a design, KCPSM6 will probably occupy more than the 26-32
|
||
Slices predictably achieved when using the ISE tools and quoted in the documentation. The
|
||
maximum performance may also be lower. Vivado (at least up to 2014.2), ignores the Slice
|
||
packing directives (i.e. HBLKNM attributes) contained in the source VHDL and Verilog files
|
||
and this tends to result in KCPSM6 being distributed across a larger number of Slices. Vivado
|
||
packs designs more tightly the more a design fills a given device so this is not a significant
|
||
issue. However, the size reports can be misleadingly large when implementing a simple test case.
|
||
|
||
The architecture of UltraScale devices is somewhat different in that every Slice has 8 LUTs
|
||
rather than the 4 LUTs in the Slices of Spartan-6, Virtex-6 and 7-Series devices. It is
|
||
therefore expected that KCPSM6 would appear to occupy less Slices in an UltraScale device
|
||
but that is really just a difference in architecture.
|
||
|
||
|
||
Unrecognised 'RAMB18E2' Primitives in Program Memory when using ISE
|
||
-------------------------------------------------------------------
|
||
|
||
This will happen if you assembled your program whilst using the 'ROM_form' template intended
|
||
for use with Vivado (e.g. 'ROM_form_JTAGLoader_Vivado_2June14.vhd'). When using ISE you should
|
||
assemble your programs using a copy of 'ROM_form_JTAGLoader_14March13.vhd' which is the original
|
||
template compatible with ISE. Alternatively, assemble your program using one of the 'production
|
||
templates' consistent with the target device and memory size required.
|
||
|
||
|
||
WARNING:Xst:647 - Input <instruction<0:11>> is never used
|
||
---------------------------------------------------------
|
||
|
||
XST in ISE v12.x and ISE v13.x incorrectly reports the following warning message....
|
||
|
||
WARNING:Xst:647 - Input <instruction<0:11>> is never used.
|
||
|
||
This warning can safely be ignored. However, it should be recognised that if a similar warning
|
||
message reports that all 18-bits of instruction (instruction<0:17>) are never used then it
|
||
probably means that you really didn't connect the program memory to KCPSM6 correctly.
|
||
|
||
This issue was fixed in ISE version 14.1.
|
||
|
||
|
||
INFO:Xst:2261 or WARNING:Xst:1710 messages relating to Unit <jtag_loader_6>
|
||
---------------------------------------------------------------------------
|
||
|
||
XST typically issues two or three messages concerning 'FF/Latch <control_dout_int_2>' or
|
||
similar when the design has JTAG Loader enabled. These messages can be safely ignored because
|
||
they reflect the way in which certain signals have been assigned the same constant values
|
||
which the JTAG Loader utility will later use to understand your PicoBlaze design (e.g. a value
|
||
defining the size of your program memory).
|
||
|
||
Once JTAG Loader is disabled or a production 'ROM_form' template is used there should be no
|
||
messages of this kind.
|
||
|
||
Note that XST issues 'INFO' messages when the program memory file is VHDL and 'WARNING' messages
|
||
when the program memory file is Verilog. Hence, if you use a VHDL file to define your program
|
||
memory the messages will become 'INFO' even if the remainder of your project is Verilog.
|
||
|
||
|
||
JTAG Loader not working
|
||
-----------------------
|
||
|
||
If you experience any issues related to not being able to find a DLL then please check the
|
||
'Requirements' section above to ensure that your environment variables are set appropriately.
|
||
|
||
Vivado users must install ChipScope provided with ISE (see 'Requirements')
|
||
|
||
JTAG Loader may not work correctly if you have more that Platform Cable USB connected to your
|
||
PC at the same time so the obvious workaround is only to connect the cable associated with
|
||
the chain in which your target device is located. Please note that many development boards and
|
||
evaluation kits such as ATLYS or ML605 boards have Platform Cable USB circuit or Digilent
|
||
equivalent included on them so the most common reason for appearing to have multiple cables
|
||
connected is when one or more of these boards are connected (or one of these boards and a real
|
||
Platform Cable USB).
|
||
|
||
|
||
JTAG Loader may take ~25 seconds to load a new program when using an ATLYS board
|
||
--------------------------------------------------------------------------------
|
||
|
||
Loading a KCPSM6 program normally takes about 5 seconds so this issue is under investigation.
|
||
However, it is only a case of being slower than expected; operation is correct and reliable.
|
||
|
||
|
||
Designs containing multiple KCPSM6 processors
|
||
---------------------------------------------
|
||
|
||
It is common practice for designs to contain multiple instances of PicoBlaze with each typically
|
||
acting as an independent 'state machine'. There are also some designs in which hundreds, or even
|
||
thousands, are used to implement amazing structures and algorithms. Regardless of how many
|
||
KCPSM6 processors are included, the use model and design method is really the same for each
|
||
instance so there is really very little to consider just because there is more than one. That
|
||
said, the following points may be helpful in making your multi-KCPSM6 enjoyable.
|
||
|
||
When using the default 'ROM_form' template your assembled program file provides you with the
|
||
option to enable the JTAG Loader circuit. However, you do need to remember that only one program
|
||
memory can have this feature enabled at any time. Hence, only one instance can have
|
||
'C_JTAG_LOADER_ENABLE' assigned the value '1' and all other instances must be assigned '0'.
|
||
|
||
Although compliance with the fundamental limitation described above should result in a design
|
||
that will successfully pass through the ISE tools you will find that WARNING messages are
|
||
generated for each instance or program memory assembled using the default 'ROM_form' template.
|
||
This is because the default 'ROM_form' template includes the definition of the JTAG Loader
|
||
circuit and this means that synthesis observes a repeated definition of the JTAG Loader circuit
|
||
(and a function) in each instance irrespective of the loader being enabled or not. These warnings
|
||
can be safely ignored but if you are looking for more elegance (and why shouldn<64>t you?), then
|
||
here are two techniques for you to consider.
|
||
|
||
a) Replace the default 'ROM_form' template with the appropriate 'Production Memory' template.
|
||
These are described on page 47 of the KCPSM6 user guide and in 'kcpsm6_assembler_readme.txt'.
|
||
Once a program is assembled using a production template then the memory definition file
|
||
only contains the specific BRAM(s) necessary for your application. JTAG Loader is no longer
|
||
included and hence replicated definition is avoided. Use of 'Production Memory' does require
|
||
small changes to your design (i.e. the instantiation no longer includes generics or the 'rdl'
|
||
port) but this is a recommended step before release of a product anyway and suitable once
|
||
any program has become stable.
|
||
|
||
b) If you still want to maintain the ability to enable the JTAG Loader on a program instance
|
||
in the design (obviously you can only enable one at a time) then you have to keep the
|
||
JTAG Loader option available within each instance. To avoid those warning messages you
|
||
need to ensure that the JTAG Loader is only defined once in overall design. This ultimately
|
||
means separating the definition of JTAG Loader from the definition of the program memory.
|
||
|
||
Start by making a copy of the default template ('ROM_form_JTAGLoader_16Aug11.vhd') and remove
|
||
all items defining JTAG Loader. Locate and delete the code near the top that defines a function
|
||
called 'addr_width_calc' and all the code towards the end following the 'JTAG Loader' comment
|
||
banner that defines the actual JTAG Loader circuit. In the 'Miscellaneous' directory you can
|
||
find 'ROM_form_for_multiple_instances.vhd' which has already had these items removed from the
|
||
default template and ready for you to use.
|
||
|
||
You must (only) assemble one program using the default template which will include the definition
|
||
of JTAG Loader. All other programs must be assembled using the modified template which only
|
||
define the program memory (hint - assemble programs in different directories containing the
|
||
'ROM_form' template required).
|
||
|
||
|
||
'global_opt' may result in incorrect implementation
|
||
---------------------------------------------------
|
||
|
||
Setting 'global_opt' to anything other than 'off' (the default) in MAP when using ISE v13.1 or
|
||
ISE 13.2 may result in incorrect implementation of the KCPSM6 logic and therefore a failure to
|
||
execute code in the way expected (e.g. shift and rotate operations may not work properly). The
|
||
'area' setting may even prevent your design from passing through MAP at all. This issue had
|
||
not been observed when using ISE v12.4 and there are no issues as long as 'global_opt' is set
|
||
to 'off'. Note that when using ISE v13.2 to target a 7-Series device the 'global_opt' option
|
||
is not available and therefore this issue can only occur when targeting Spartan-6 or Virtex-6.
|
||
|
||
The cause of this issue was located and then fixed in ISE v13.4 so you should use ISE v13.4
|
||
or later when 'global_opt' needs to be set to anything other than 'off' in order to process
|
||
other parts of your design. However, a user of ISE v13.4 did still appear to have a similar
|
||
issue when ChipScope was also being used to probe inside KCPSM6.
|
||
|
||
|
||
'Pack:2811' errors in MAP when using ChipScope
|
||
----------------------------------------------
|
||
|
||
Connection of ChipScope can generate 'Pack:2811' errors in MAP. This mainly appears to happen
|
||
when connecting 'out_port' or 'port_id' directly to ChipScope. It has also been known to
|
||
happen when connecting ChipScope directly to the 'address' or 'instruction' ports.
|
||
|
||
There are four potential workarounds for this issue.
|
||
a) To insert a pipeline register between KCPSM6 and ChipScope.
|
||
b) Set the 'Keep Hierarchy' option in XST to 'Yes' (default is 'No').
|
||
However this may not work if there are more than one KCPSM6 (see below).
|
||
c) Set the following system environment variable: XIL_MAP_OLD_SAVE=1.
|
||
Close ISE.
|
||
Right click on 'My Computer' and select 'Properties'.
|
||
Go to the 'Advanced' tab and choose 'Environment Variables'.
|
||
Use 'New' or 'Edit' as necessary.
|
||
Open and run ISE again.
|
||
d) Remove or comment out all the Slice packing directives (HBLKNM attributes) in the KCPSM6
|
||
source file. The 'kcpsm6_without_slice_packing_attributes.vhd' located on the 'Miscellaneous'
|
||
directory already has these attributes commented out. Using this workaround will result in
|
||
KCPSM6 occupying more Slices and having a lower peak performance and therefore it is
|
||
better to only resort to using it if the other methods cannot be used or are unsuccessful.
|
||
|
||
|
||
'Pack:2811' errors in MAP when using 'Keep Hierarchy' and design contains multiple KCPSM6.
|
||
------------------------------------------------------------------------------------------
|
||
|
||
This error has been observed when a design contains multiple instances of KCPSM6 and
|
||
the 'Keep Hierarchy' option in XST has been set to 'Yes'. Therefore the obvious solution is
|
||
to revert to the default setting of 'No'. Alternatively the 'Allow Logic Optimization Across
|
||
Hierarchy' option in MAP can be enabled (tick box in Project navigator or apply the
|
||
-ignore_keep_hierarchy switch on the command line).
|
||
|
||
If it is undesirable to adjust your implementation settings then please see 'c' and 'd'
|
||
workarounds in the issue above.
|
||
|
||
|
||
'Pack:2811' errors in MAP when using a low 'Max Fanout' value in XST.
|
||
---------------------------------------------------------------------
|
||
|
||
The 'Max Fanout' parameter is a 'Xilinx Specific Option' for XST and has the default value
|
||
of 100000 for the devices used with KCPSM6. It has been known for very low values (e.g. <20)
|
||
to result in a subsequent error in MAP. Should this occur, please increase the value. If
|
||
you have a particular reason to use such a low value then synthesize KCPSM6 separately and
|
||
include it in your design as a 'black box'.
|
||
|
||
|
||
'PhysDesignRules:1422' errors reported by BITGEN
|
||
------------------------------------------------
|
||
|
||
Should this error report occur then it will probably look something like this....
|
||
|
||
ERROR:PhysDesignRules:1385 - Issue with pin connections and/or configuration on
|
||
block:<instance_name>/stack_ram_high_RAMD_D1>:<LUT_OR_MEM6>. For RAMMODE programming
|
||
set with DPRAM32 or SPRAM32 or SRL16 the DI2 input pin must be connected.
|
||
|
||
This error has only occurred in designs where the user has not connected all 12-bits of the
|
||
address bus to a program memory. Hence the simple and obvious solution is to ensure that
|
||
all address bits are connected to something.
|
||
|
||
Regardless of the memory size, all the supplied 'ROM_form' templates connect all address bits
|
||
to something so that these signals and associated logic are preserved. This makes it easier to
|
||
increase or decrease the memory size and avoids warning messages (as well as this error). As
|
||
such, if you have encountered this error you are probably using your own 'ROM_form' template
|
||
in which one or more of the (most significant) address bits are not required and have not been
|
||
connected to something in order to preserve them.
|
||
|
||
Whilst it is generally a good idea for unused logic to be trimmed, KCPSM6 is so optimised
|
||
to the architecture and so tightly packed into the logic Slices that any logic trimming is
|
||
insignificant. Furthermore, any trimming only leads to the formation of unusable 'holes' in
|
||
otherwise used Slices so there is nothing to be gained. This is particularly true of what
|
||
happens to the memory used to implement the program counter stack when any of the address
|
||
bits are unused and leads to the error being generated. Obviously it would be better if the
|
||
tool chain could handle this better but it just happens to be one of those cases that is
|
||
more challenging than it first appears to be!
|
||
|
||
|
||
JTAG Loader and BSCAN Users
|
||
---------------------------
|
||
|
||
The JTAG Loader utility employs a BSCAN primitive within the device to form a bridge to the
|
||
KCPSM6 program memory. Other applications may also exploit a BSCAN primitive such as ChipScope
|
||
which implements a bridge between ChipScope Analyser and an associated ICON core. The good news
|
||
is that there are four BSCAN primitives in each device so it is unlikely that you will not have
|
||
enough of them. Clearly, if you do exceed the number available then your only recourse is to
|
||
reduce the number required; possibly disabling JTAG Loader so that the rest of your design can
|
||
fit will be the easiest solution.
|
||
|
||
However, since there are normally enough BSCAN primitives available, the more common issue
|
||
relates to the allocation of the 'USER' address to each BSCAN primitive. As provided, the JTAG
|
||
Loader is assigned to 'USER2'. When generating an ICON core for ChipScope there is an option to
|
||
set the 'boundary scan' value to USER1, USER2, USER3 or USER4 but this is normally set to 'USER1'
|
||
so in most cases ChipScope and JTAG Loader happily co-exist.
|
||
|
||
If you find it necessary to assign JTAG Loader to a different 'USER' then you will need to
|
||
make a small adjustment to hardware and use JTAG Loader with the '-i' option as shown below.
|
||
|
||
To modify the hardare, open the default 'ROM_form' template and locate the line shown below and
|
||
adjust the number '2' to '1', '3' or '4' as desired...
|
||
|
||
'ROM_form.vhd' (approximately line 256 and part of 'component jtag_loader_6')
|
||
|
||
C_JTAG_CHAIN : integer := 2;
|
||
|
||
'ROM_form.v' (approximately line 295 and part of 'module jtag_loader_6')
|
||
|
||
parameter integer C_JTAG_CHAIN = 2;
|
||
|
||
You will then need to assemble your PSM file such that the new assignment is transferred into
|
||
your actual design file. Obviously, since this is a change to the hardware definition you must
|
||
also process the whole design, generate a BIT file and configure the device with it too.
|
||
|
||
When you run the JTAG Loader utility it assumes the default USER number is '2' so you will now
|
||
need to use the '-i' option to specify the same USER number that you defined in your template.
|
||
For example, if the line in the VHDL template was changed to 'C_JTAG_CHAIN : integer := 4;'
|
||
then to update the KCPSM6 program using JTAG Loader the command will be...
|
||
|
||
jtagloader -i4 -l your_program.hex
|
||
|
||
(where 'jtagloader' is the required executable for your operating system).
|
||
|
||
|
||
KCPSM6 program memory can be corrupted when using ChipScope Analyser.
|
||
---------------------------------------------------------------------
|
||
|
||
If your PicoBlaze design has JTAG Loader enabled and the device is configured with the BIT
|
||
file using ChipScope Analyser (rather than iMPACT) then this can result in corruption to one
|
||
location of the program memory. Other uses of ChipScope may also result in the same corruption
|
||
which will almost certainly be to the 4th instruction in the program memory (address 003) and
|
||
result in that location being cleared to 00000 Hex. This value is equivalent to a 'LOAD s0, s0'
|
||
instruction which will do nothing but obviously that still means that your intended instruction
|
||
is missing and effect the execution of your program.
|
||
|
||
Note that there does not need to be a ChipScope Core in the design, it is purely the act of
|
||
using ChipScope Analyser that has this effect even if it is only used to configure the device.
|
||
The issue is related to the way ChipScope Analyser searches for a ChipScope core in your design
|
||
and that process interfering with JTAG Loader which makes use of a BSCAN primitive in a very
|
||
similar way to that of a ChipScope core.
|
||
|
||
If you suspect that this is happening then JTAG Loader can be used to confirm it using its
|
||
read back facility. First read back the contents of the memory into a temporary hex file...
|
||
|
||
jtagloader -r temp.hex
|
||
|
||
Then compare the contents of this hex file with the hex file generated by the KCPSM6 assembler
|
||
for your program. It should be easy to see the '00000' value near the top of the file if
|
||
corruption has taken place.
|
||
|
||
Fortunately there are several workarounds:-
|
||
|
||
a) Use iMPACT rather than ChipScope to configure the device with your BIT file.
|
||
b) Following configuration by ChipScope Analyser, use JTAG Loader to refresh the program
|
||
memory with a valid image (you will do this naturally if using JTAG Loader during
|
||
program development).
|
||
c) Disable JTAG Loader if you don't need to use it.
|
||
d) Start your PSM program with directive 'ADDRESS 004' such that your code begins at
|
||
address 004. In this way the first four locations of memory will default to 00000 hex
|
||
('LOAD s0, s0' has no effect) and the clearing effect of the corruption will become
|
||
irrelevant. Note that the DEFAULT_JUMP directive would override this default though.
|
||
e) Place the following instructions at the start of your program so that address 003
|
||
is avoided.
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> JUMP cold_start ;Avoid address 003 on start up
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> JUMP cold_start
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> JUMP cold_start
|
||
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> JUMP cold_start ;Address 003
|
||
<20><><EFBFBD><EFBFBD><EFBFBD> <20><><EFBFBD> ;
|
||
cold_start: <normal program code starts here>
|
||
|
||
f) Modify the ChipScope Analyser project file '.cpj' as described below.
|
||
|
||
Note that this method requires ISE v13.3 or later to work correctly.
|
||
|
||
i) Insert the line 'avoidUserRegDevice0=2' in your '.cpj' file.
|
||
For example...
|
||
|
||
#ChipScope Pro Analyzer Project File, Version 3.0
|
||
#Tue Aug 20 16:17:05 BST 2013
|
||
avoidUserRegDevice0=2
|
||
device.0.configFileDir= ....
|
||
|
||
This tells ChipScope Analyser to avoid 'USER2' which is assigned to JTAG Loader
|
||
from being scanned in the first device (device '0') in the JTAG chain. Adjust
|
||
'avoidUserRegDevice0' as appropriate for the device position in your JTAG chain.
|
||
ii) Start ChipScope Anaylser and open the project (.cpj file). You must do this first.
|
||
iii) Then you can 'Open Cable/Search JTAG Chain' and you should see a messages similar
|
||
to "INFO: Skipping xsdb core scan on device 0, user register 2" displayed in
|
||
the console confirming that 'USER2' has been avoided.
|
||
iv) Configure your device (probably worth using 'jtagloader -r' to confirm that
|
||
everything worked correctly the first time you try it but should be Ok after that).
|
||
|
||
Answer Record 19337 (http://www.xilinx.com/support/answers/19337.htm) may also be
|
||
useful reference when using ChipScope Analyser.
|
||
|
||
|
||
KCPSM6 program memory can be corrupted when using Vivado Hardware Manager
|
||
-------------------------------------------------------------------------
|
||
|
||
This is very similar to the known issue described immediately above but there are fewer options
|
||
when it comes to implementing a workaround. Please see page 24 of 'PicoBlaze_Design_in_Vivado.pdf'
|
||
for more details of this known issue.
|
||
|
||
|
||
Poor Display of Strings in ISE Simulator
|
||
----------------------------------------
|
||
|
||
The way in which iSim (in ISE) displays text strings is not ideal for the observation of
|
||
'kcpsm6_opcode' and 'kcpsm6_status' during simulation. It seems unlikely that this will be
|
||
rectified in ISE. These text strings are displayed correctly when using the Vivado Simulator.
|
||
|
||
|
||
KCPSM6 Assembler window takes a long time to appear on screen
|
||
-------------------------------------------------------------
|
||
|
||
In most cases the assembler window should open almost immediately so if it takes more than a few
|
||
seconds, especially if your PC is not busy processing other applications, then this is worthy of
|
||
some investigation and an experiment. Have a look to see what your default printer is set to...
|
||
|
||
Start -> Printers and Faxes
|
||
|
||
The default printer will have a small tick next to it. Ideally you should assign a local printer
|
||
and make sure that the selected printer is available to Windows applications (a printer
|
||
doesn't actually need to be turned on but should be capable of printing from applications
|
||
e.g., a USB connected printer will normally automatically turn on when sent a document).
|
||
|
||
Right click on the desired printer and select 'Set as Default Printer'.
|
||
The small tick mark will move.
|
||
|
||
Run the KCPSM6 assembler again and see if that has made it open faster. If it is not convenient
|
||
to change the default printer then the quickest and easiest way to use KCPSM6 in interactive
|
||
mode. Run KCPSM6 and wait for it to open. Then enter the name of your PSM file and let it
|
||
assemble your PSM code. Then just leave the KCPM6 assembler open and then use the 'R' and 'N'
|
||
options to control assembly. In this way you avoid having to wait for the assembler to open
|
||
each time.
|
||
|
||
Although rare, this issue typically occurs when a network printer has been assigned as the
|
||
default but the Windows applications cannot find it. This can also be associated with the print
|
||
driver being incorrect or requiring an update. If the network and/or printer driver can not
|
||
be resolved then consider assigning a local printer as the default. If you don't have a physical
|
||
local printer then a useful technique is to install a PDF writer and make that your default
|
||
printer.
|
||
|
||
-------------------------------------------------------------------------------------------------
|
||
End of file 'READ_ME_FIRST.txt'
|
||
-------------------------------------------------------------------------------------------------
|