fpga locks up with slow signal, spartan chip, pin type issues.
jleslie48
# chipset:
# xc3s500e-4cp132
#
# 3s500E
# xxxxx-xxxx
# korea
# C6-DGQ 4C
#
# apparently the c6 defines the packages as CPG132 as per
# xilinx document ds312.pdf
# 1 --|DGND 5V IN |-- 40
# 2 --|DGND DGND |-- 39
# 3 --|PIN3 dual PIN38 |-- 38 dual/gclk
# 4 --|PIN4 dual PIN37 |-- 37 dual
# 5 --|PIN5 rhclk/dual PIN36 |-- 36 I/O
# 6 --|PIN6 rhclk/dual PIN35 |-- 35 dual/gclk
# 7 --|PIN7 rhclk/dual PIN34 |-- 34 lhclk
# 8 --|PIN8 rhclk/dual PIN33 |-- 33 lhclk
# 9 --|PIN9 rhclk/dual PIN32 |-- 32 I/O
# 10 --|PIN10 I/0 PIN31 |-- 31 lhclk
# 11 --|PIN11 dual PIN30 |-- 30 I/O
# 12 --|PIN12 dual PIN29 |-- 29 lhclk
# 13 --|PIN13 lhclk PIN28 |-- 28 lhclk
# 14 --|PIN14 rhclk/dual PIN27 |-- 27 I/O
# 15 --|PIN15 dual PIN26 |-- 26 I/O
# 16 --|PIN16 gclk PIN25 |-- 25 I/O
# 17 --|PIN17 gclk PIN24 |-- 24 vref
# 18 --|PIN18 lhclk PIN23 |-- 23 I/O
# 19 --|DGND DGND |-- 22
# 20 --|DGND DGND |-- 21
I checked against the Xilinx documentation for the type associated
with the pins so I mapped them out using xilinx ds312.pdf and came up
with this type configuration for CP132 Ball.
It seems what I put out on the output pins is relevant. Pin15 has a
1/4 second blink code, while pins 17 and 18 have a 2mhz signal going
out and all is OK.
If I swap pins 15 and 18, I lock up. IF I drive Pin 13 with the
2mhz signal, no problem also.
Simply put, if I drive PIN13 or PIN18 (the lhclk types) at 2mhz, no
problem, but if I drive them at 4hz, they lock up the fpga.
Any insight or suggested reading/ places to look in the multitude of
summary reports that ISE generates? I found it strange that nothing
strange appears in the build process or in testbench, but when I
download the program, the FPGA locks up and only a power down and up
resets it.
jleslie48
Ok, its not that simple. I've been messing with this all day. I
can't find a pattern
that is repeatable.
Right now I'm driving PIN18 at 2mhz 50% duty cycle, and PIN 17
similiarly.
If I so much as add PIN 15 to the UCF, the PORT layout, and simply tie
the same
std_logic wire that drives PIN18 to PIN15, the FPGA fails.
I also checked the pin's types once more, I documented them wrong. it
turns out PIN15 is not DUAL but rather I/O
the layout of the pins is:
# 1 --|DGND 5V IN |-- 40
# 2 --|DGND DGND |-- 39
# 3 --|PIN3 dual PIN38 |-- 38 dual/gclk
# 4 --|PIN4 dual PIN37 |-- 37 dual
# 5 --|PIN5 rhclk/dual PIN36 |-- 36 I/O
# 6 --|PIN6 rhclk/dual PIN35 |-- 35 dual/gclk
# 7 --|PIN7 rhclk/dual PIN34 |-- 34 lhclk
# 8 --|PIN8 rhclk/dual PIN33 |-- 33 lhclk
# 9 --|PIN9 rhclk/dual PIN32 |-- 32 I/O
# 10 --|PIN10 I/0 PIN31 |-- 31 lhclk
# 11 --|PIN11 dual PIN30 |-- 30 I/O
# 12 --|PIN12 dual PIN29 |-- 29 lhclk
# 13 --|PIN13 lhclk PIN28 |-- 28 lhclk
# 14 --|PIN14 rhclk/dual PIN27 |-- 27 I/O
# 15 --|PIN15 I/O PIN26 |-- 26 I/O
# 16 --|PIN16 gclk PIN25 |-- 25 I/O
# 17 --|PIN17 gclk PIN24 |-- 24 vref
# 18 --|PIN18 lhclk PIN23 |-- 23 I/O
# 19 --|DGND DGND |-- 22
# 20 --|DGND DGND |-- 21
It really got frustrating for a while, I added Pin13 for a stretch,
and then deleted it but no matter what I did,
The place and route report complained that PIN13 was unrouted. The
pinout report also showed PIN13 in there.
No amount of of re-run all fixed the problem. I made a new project,
dragged copies of my sources over, and re-built the project, and that
finally destroyed all references to the PIN13 However since then,
Even if I try and drive pin 15 at 4hz, it fails.
I don't know if I'm supposed to be changing some of the defaults in
the build process, or if I need to update my ISE package.
My ISE package is 10.1 and I also loaded service pack 3, but I know
there are more patches to the software available. I just hate to load
updates unless I know they are directly associated to some
functionality I need.
Brian Drummond
wrote:
>On Apr 17, 10:55 am, jleslie48 <j...@jonathanleslie.com> wrote:
>> here's the pinout of a board I'm using:
>Ok, its not that simple. I've been messing with this all day. I
>can't find a pattern
>that is repeatable.
>No amount of of re-run all fixed the problem. I made a new project,
>dragged copies of my sources over, and re-built the project, and that
>finally destroyed all references to the PIN13 However since then,
>Even if I try and drive pin 15 at 4hz, it fails.
There has to be something else going on...
One question: where are you getting a 4Hz clock?
Does it have a reasonable rise/fall time or such a slow ramp that the Xilinx
input buffers are oscillating like crazy as it passes through the transition
region?
You might be better using a 100MHz clock and a 4Hz enable signal...
- Brian
jleslie48
wrote:
the system has a 40Mhz oscillator and I set a countdown counter to
10,000,000,
subtract 1 every oscillator clock and
at 0 I reset the counter to10,000,000 and:
clk_4hz <= not clk_4hz;
something like that, I don't have the exact code in front of me.
bascially I use this as a heartbeat indicator for the FPGA, I use
this heartbeat to drive an
led so I know the program is running; I've been doing it for years on
systems. I also will
enhance the blink code occasionally to indicate software versons.
This way if a field test engineer
is having an issue, Over the phone I can have him check the blink
pattern (ex dot,dot,dot, off, dot,dot,dot ...)
and I can know if he has the right version of code or not by making
sure that I change the blink code on each
version of the code.
Meantime, I wrote some code that worked great and put out my 2mhz
signal just fine. I then tried to copy the
blink code to a pin that is connected to a header so I put the blink
code on the front panel of the project box, and
all of a sudden I stuck on this ridiculous problem. GRRRRRR.....
I also will need to duplicate the 2mhz signal to as many as 4 output
pins, this kind of stuff should be a no-brainer but I must have some
underlying issue of no-no's under the surface. I'm willing to bet the
FPGA lockup on adding the pin connection is just because by adding
that bit of logic things get moved around during the SIG (synthesis,
implement, generate) just enough so that my mistake ends up causing a
lock up. I did have the driver on pin15 at 1/4 second working at one
time, but then I tried to add pin 13, it died, and then when I removed
the logic for pin 13, pin 15 was broken as well.
This ISE 10.1 is very buggy. I have a whole list of WTF??? and
situations where I just crashed it. I've only installed service pack
3, and I know there are some other patches that go, but until someone
says "oh yeah!!! I had that problem if you update ISE 10.1 with xyz
then the problem is fixed!!!!" I'm reluctant to introduce the new
variable of a software patch.
Brian Drummond
wrote:
>> One question: where are you getting a 4Hz clock?
>> You might be better using a 100MHz clock and a 4Hz enable signal...
>>
>> - Brian
>
>the system has a 40Mhz oscillator and I set a countdown counter to
>10,000,000,
>subtract 1 every oscillator clock and
>at 0 I reset the counter to10,000,000 and:
>
>clk_4hz <= not clk_4hz;
OK so it's internally generated; rise times aren't the problem.
But it may not be identified by the tools as a clock; and that can cause
problems.
Do the tools actually identify it as a clock signal? (Should appear in the
Translate clock report, and in PAR and timing reports)
One approach would be to generate an enable ( a pulse 1 clk40MHz cycle wide)
from it (easy: e.g. delay it 1 cycle and XOR them for an 8Hz enable) and clock
the actual logic off 40MHz. This will ensure the tool's timing analysis works
correctly and eliminates a major potential set of problems; it may waste a few
mw if that matters.
Another approach would be to instantiate a BUFG on the 4Hz clock. Then the BUFG
output should be automatically routed on low skew networks and analyzed for
timing hazards.
>
>This ISE 10.1 is very buggy. I have a whole list of WTF??? and
>situations where I just crashed it.
Absolutely and you are correct to be wary of upgrading without good cause. I
used ISE7.1 exclusively until changing to 10.1 last year. (10.1 is sufficiently
better to be worth it though)
But though the tools crash, and may not be able to handle a clock they can't
identify, they are pretty solid at delivering reliable results when used within
their limits; e.g. with either technique above.
- Brian
jleslie48
wrote:
Brian,
Thanks for the tips. they will be tried/looked at on monday morning.
I am confused though. what's the big deal about it being a "clock"?
All I'm doing is sending it out an output pin to blink an led, whats
the deal with BUFG, etc? I don't care about mw or even if its
delayed, its just a blinking led on the project box...
I don't get why tying a std_logic value to a second output pin can be
a catalyst to a catastrophic failure of an FPGA.
jleslie48
> identify, they are pretty solid at delivering reliable results when used within
> their limits; e.g. with either technique above.
>
> - Brian
this has me very scared. I know for a fact at one point I put in a
pin13 and then removed it, but the build still had references to pin13
(the map failed and the pinout report showed pin13) It wasn't until
a made a whole new project that I eliminated the reference to pin13.
After I made my new project, I found out about the clean up thing
under projects and my old project was able to then build, but at that
point PIN15 was broken.
The point is, I get different results based on previous compile
situations and previous results of the software. this is really bad.
It means I can't reliably make a burn image, or possibly have to make
a new project for each SIG/ reboot the computer between builds (I also
notice that even if I shutdown the software, task manager has plenty
of ISE images still in the background)
Brian Drummond
wrote:
>> One approach would be to generate an enable ( a pulse 1 clk40MHz cycle wide)
>> from it (easy: e.g. delay it 1 cycle and XOR them for an 8Hz enable) and clock
>> the actual logic off 40MHz. This will ensure the tool's timing analysis works
>> correctly and eliminates a major potential set of problems; it may waste a few
>> mw if that matters.
>>
>> Another approach would be to instantiate a BUFG on the 4Hz clock. Then the BUFG
>> output should be automatically routed on low skew networks and analyzed for
>> timing hazards.
>Thanks for the tips. they will be tried/looked at on monday morning.
>I am confused though. what's the big deal about it being a "clock"?
For all other signals, the tools basically only need to guarantee the routing is
faster than the clock period (+/- small allowance for jitter, clock skew etc);
which at 4Hz or even 40MHz is easy.
For a clock, the tools must perform a much more rigorous analysis; it is equally
bad for a clock signal to arrive too early as too late!
I presume your 4Hz clock is driving a simple state machine to blink blink blink;
pause; repeat.
If the clock delay to each FF in that SM isn't tightly controlled, it will reach
some FFs before their inputs change, and others after their inputs (output from
FFs clocked earlier) change. Hence there is no predicting what the SM will do.
And each routing pass will behave differently; by chance, some may even work!
>I don't get why tying a std_logic value to a second output pin can be
>a catalyst to a catastrophic failure of an FPGA.
That can cause the routing to change significantly.
Don't let it scare you - once you find the groove; avoiding dodgy design areas -
the tools will deliver reliable results. It's not any worse than C's pointer
arithmetic!
Re: persistence of obsolete pins: how are you generating constraints (UCF
files)?
If you are using the ISE tools, it's worth checking the UCF file in a text
editor; I just use the editor and forget the tools (which maddeningly force
another synthesis pass first because I updated a comment somewhere)
I also check the translate (.bld) report, the map (.mrp) report and the PAR
(.par) report; if any of these stages fail, you CAN end up using obsolete files
(at least from the command line)
- Brian
jleslie48
wrote:
Yeah, I only use the UCF file in the text editor. I'll take a look at
all those files very
carefully. I tried doing a diff at one point between a working
version using pin 15 and an non
working version using pin13 but nothing jumped up at me. On several
occasions I just went into
the ucf file with notepad, added a trailing space and saved just to
make sure it was touched, Didn't help though.
jleslie48
Ok, I'm looking at the PACE and pinout report, nothing jumps out at
me, maybe you can see something.
Here's the program that drives the LED, and pins 17, 18. This one
works fine:
and heres the one where all I did was add PIN15_LED, but it locks up
the FPGA:
I hi-lighted/ red-boxed what appears to me to be the significant
lines.
It just doesn't make any sense.
the UCF file differs by one line, I added:
NET "PIN15_led" LOC = "A13"; #"FPGA_IO14"
and the top.vhd differs by two,
I've added the pin15_led line here:
-----------------------------------------------------------------------
ENTITY lprj_TOP IS
Port
(
-- CLOCKS.UCF SIGNALS
SYSTEM_CLOCK : IN STD_LOGIC;
-- RS232.UCF SIGNALS
RS232_DSR_OUT : OUT STD_LOGIC;
HUART_TX_LINE : OUT STD_LOGIC;
RS232_CTS_OUT : OUT STD_LOGIC;
HUART_RX_LINE : IN STD_LOGIC;
--RS232_RTS_IN : IN STD_LOGIC;
-- SIGNALS
a2mhz_HUART_TX_LINE : OUT STD_logic;
a2mhz_HUART_CK_LINE : OUT STD_LOGIC;
-- LEDS.UCF SIGNALS
led_2 : OUT STD_LOGIC;
led_3 : OUT STD_LOGIC;
led_4 : OUT STD_LOGIC;
led_5 : OUT STD_LOGIC;
pin15_led : OUT STD_LOGIC;
-- FPGA pin JTAG signals -- dummy placeholders.
-- TCK : IN STD_LOGIC;
-- TDI : IN STD_LOGIC;
-- TDO : in STD_LOGIC;
-- TMS : IN STD_LOGIC;
-- jtag_or_dummy : OUT STD_LOGIC;
-- PUSHBUTTON.UCF SIGNALS
button_1 : IN STD_LOGIC;
--PB_UP : IN STD_LOGIC;
PB_DOWN : IN STD_LOGIC;
button_2 : IN STD_LOGIC;
PB_RIGHT : IN STD_LOGIC
);
-----------------------------------------------------------------------
and in the main body of the behavioral I added this pin15_led line:
-----------------------------------------------------------------------
led_3 <= clk_4hz;
pin15_led <= not clk_4hz; -- default state for pin 15 is on.
-----------------------------------------------------------------------
Sincerely,
Jonathan
Leslie
jleslie48
>
> and heres the one where all I did was add PIN15_LED, but it locks up
> the FPGA:
>
here's another view of some stuff, looks neat, does it show anything
of the problem?
Here's the report that is only partially visible:
--------------------------------------------------------------------------------
Release 10.1.03 Trace (nt)
Copyright (c) 1995-2008 Xilinx, Inc. All rights reserved.
C:\Xilinx\10.1\ISE\bin\nt\unwrapped\trce.exe -ise
C:/jon/fpga_uartjl_01/r-drigmorn1/Pchu_cc02/ms_d03/ms_d03.ise -
intstyle ise -v
3 -s 4 -xml lprj_TOP lprj_TOP.ncd -o lprj_TOP.twr lprj_TOP.pcf -ucf
C:/jon/fpga_uartjl_01/r-drigmorn1/Pchu_cc02/ms_d03/source/ucf/
DRIGMORN1.ucf
Design file: lprj_TOP.ncd
Physical constraint file: lprj_TOP.pcf
Device,speed: xc3s500e,-4 (PRODUCTION 1.27 2008-01-09)
Report level: verbose report
Environment Variable Effect
-------------------- ------
NONE No environment variables were set
--------------------------------------------------------------------------------
INFO:Timing:2698 - No timing constraints found, doing default
enumeration.
INFO:Timing:2752 - To get complete path coverage, use the
unconstrained paths
option. All paths that are not constrained will be reported in the
unconstrained paths section(s) of the report.
INFO:Timing:3339 - The clock-to-out numbers in this timing report are
based on
a 50 Ohm transmission line loading model. For the details of this
model,
and for more information on accounting for different loading
conditions,
please see the device datasheet.
Data Sheet report:
-----------------
All values displayed in nanoseconds (ns)
Setup/Hold to clock SYSTEM_CLOCK
-------------+------------+------------+------------------+--------+
| Setup to | Hold to | | Clock |
Source | clk (edge) | clk (edge) |Internal Clock(s) | Phase |
-------------+------------+------------+------------------+--------+
HUART_RX_LINE| 3.122(R)| 0.430(R)|SYSTEM_CLOCK_BUFGP| 0.000|
PB_RIGHT | 7.180(R)| 0.479(R)|SYSTEM_CLOCK_BUFGP| 0.000|
button_1 | 1.756(R)| -0.118(R)|SYSTEM_CLOCK_BUFGP| 0.000|
button_2 | 8.952(R)| 0.424(R)|SYSTEM_CLOCK_BUFGP| 0.000|
-------------+------------+------------+------------------+--------+
Clock SYSTEM_CLOCK to Pad
-------------------+------------+------------------+--------+
| clk (edge) | | Clock |
Destination | to PAD |Internal Clock(s) | Phase |
-------------------+------------+------------------+--------+
HUART_TX_LINE | 9.086(R)|SYSTEM_CLOCK_BUFGP| 0.000|
a2mhz_HUART_CK_LINE| 7.697(R)|SYSTEM_CLOCK_BUFGP| 0.000|
a2mhz_HUART_TX_LINE| 6.159(R)|SYSTEM_CLOCK_BUFGP| 0.000|
led_2 | 8.511(R)|SYSTEM_CLOCK_BUFGP| 0.000|
led_3 | 9.097(R)|SYSTEM_CLOCK_BUFGP| 0.000|
led_4 | 9.246(R)|SYSTEM_CLOCK_BUFGP| 0.000|
led_5 | 6.159(R)|SYSTEM_CLOCK_BUFGP| 0.000|
pin15_led | 11.171(R)|SYSTEM_CLOCK_BUFGP| 0.000|
-------------------+------------+------------------+--------+
Clock to Setup on destination clock SYSTEM_CLOCK
---------------+---------+---------+---------+---------+
| Src:Rise| Src:Fall| Src:Rise| Src:Fall|
Source Clock |Dest:Rise|Dest:Rise|Dest:Fall|Dest:Fall|
---------------+---------+---------+---------+---------+
SYSTEM_CLOCK | 10.491| | | |
---------------+---------+---------+---------+---------+
Analysis completed Mon Apr 20 10:50:56 2009
--------------------------------------------------------------------------------
Peak Memory Usage: 119 MB
glen herrmannsfeldt
> Simply put, if I drive PIN13 or PIN18 (the lhclk types) at 2mhz, no
> problem, but if I drive them at 4hz, they lock up the fpga.
Can you define what you mean by 'lock up'?
That has a specific meaning for CMOS circuits, though it
isn't supposed to happen anymore. Even so, there might
still be some conditions where you could get the chip
to do it.
-- glen
jleslie48
yes, I am not using any formal definition of "lock up"
the symptoms are this:
without pin15_led driven, the program starts up and on LED_3 I see
a blink code that is driven by:
-----------------------------------------------------------------------------------
clock_4hz: PROCESS ( system_clock_used )
BEGIN
IF ( rising_edge(system_clock_used)) then
IF ( clk_4hz_countdown = 0) THEN
clk_4hz_countdown <= human_clock_count;
clk_4hz <= NOT clk_4hz;
else
clk_4hz_countdown <= clk_4hz_countdown -1;
End if; -- countdown ife
END IF;
END PROCESS clock_4hz;
led_3 <= clk_4hz;
-------------------------------------------------------------
when I download the code using the jtag device to the blink code on
the led_3 starts, messages appear on my rs232 port, and all is well.
If I add the line:
----------------------------------------------------
led_3 <= clk_4hz;
pin15_led <= not clk_4hz; -- default state for pin 15 is on.
---------------------------------------------------------
after I download the code using the jtag device, I get a solid light
on the led_3, and none of my messages appear on the RS232 port.
I just went as far as to remove PIN15_led out of the UCF completely,
and let the tools assign it; it still locks up. Its not a hardware
to pin issue.
after the "lock up" I am unable to communicate with the FPGA with the
jtag. Here is the download of the program that locks up the FPGA:
// *** BATCH CMD : Program -p 1
Maximum TCK operating frequency for this device chain: 10000000.
Validating chain...
Boundary-scan chain validated successfully.
'1': Programming device...
PROGRESS_START - Starting Operation.
done.
'1': Reading status register contents...
CRC error : 1
Decryptor security set : 1
DCM locked : 1
DCI matched : 1
legacy input error : 1
status of GTS_CFG_B : 1
status of GWE : 1
status of GHIGH : 1
value of MODE pin M0 : 1
value of MODE pin M1 : 1
value of MODE pin M2 : 1
value of CFG_RDY (INIT_B) : 1
DONEIN input from DONE pin : 1
IDCODE not validated while trying to write FDRI : 1
write FDRI issued before or after decrypt operation: 1
Decryptor keys not used in proper sequence : 1
WARNING:iMPACT:2217 - Error shows in the status register, CRC Error
bit is NOT 0.
INFO:iMPACT:2219 - Status register values:
INFO:iMPACT - 1111 1111 1111 1111 1111 1111 1111 1111
INFO:iMPACT:579 - '1': Completed downloading bit file to device.
INFO:iMPACT - '1': Checking done pin....done.
'1': Programmed successfully.
PROGRESS_END - End Operation.
Elapsed time = 1 sec.
------------------------------------------------------------------------------------------------
Please note the WARNING: iMPACT:2217 - Error shows in the status
register, CRC Error bit is NOT 0.
a subsequent call to 'get device id' yields:
// *** BATCH CMD : ReadIdcode -p 1
INFO:iMPACT:583 - '1': The idcode read from the device does not match
the idcode in the bsdl File.
INFO:iMPACT:1578 - '1': Device IDCODE :
00001111111111111111111111111111
INFO:iMPACT:1579 - '1': Expected IDCODE:
00000001110000100010000010010011
and a big red 'ReadIDcode failed' block pops up in instead of the nice
blue block saying 'succeeded'
djj08230
> > Here's the program that drives the LED, and pins 17, 18. This one
> > works fine:
>
> >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen...
>
> > and heres the one where all I did was add PIN15_LED, but it locks up
> > the FPGA:
>
> >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen...
>
Just a hunch. Spartan 3E has some pins that are input only. I recall
hitting this some time ago. The tools wouldn't give a warning. I may
be completely wrong, but I think my problem was when using a GCLK as
output.
Josep
rickman
package, but your pin numbers in the comments are not BGA type
numbers. Where did you get the pin numbers 1....N? The way you are
listing them it looks more like a connector. What are the pin numbers
on the FPGA? Is there any circuitry on the card between the FPGA and
the connector? Or am I all wrong about this being a connector?
Rick
On Apr 17, 10:55 am, jleslie48 <j...@jonathanleslie.com> wrote:
jleslie48
yeah, you're the second person to tell me that, meantime the one of
the few pins (17) that IS working correctly is a GCLK...
good thought though.
jleslie48
the report I listed is from the ucf file that came with the card.
Here is the entire ucf file:
-----------------------------------------------
# 090403 JL first usage of the drigmorn1 card.
# functionality from the raggedstone1 is pulled over here
and
# used in the drogmorn1.
# chipset:
# xc3s500e-4cp132
#
# 3s500E
# xxxxx-xxxx
# korea
# C6-DGQ 4C
#
# apparently the c6 defines the packages as CPG132 as per
# xilinx document ds312.pdf
#
# 090403 JL ok, commented out everything, and then put back what I
wanted, renaming
# as I went along. pins 11, 12 for input buttons, 17, 18
for bae signal,
# and the rs232 port for the Huart.
#
#
#DRIGMORN PACKAGE IS CP132/CPG132
#
#####################################
#CLOCK
#####################################
#--NET "CLOCK_40MHZ" LOC = "M6";
NET "system_clock" LOC = "M6";
#####################################
#RS232 PINS
#####################################
#--NET "RTS" LOC = "A9"; #OUTPUT FROM RS232 CHIP
#--NET "TXD" LOC = "B9"; #OUTPUT FROM RS232 CHIP
NET "Huart_tx_line" LOC = "B9"; #OUTPUT FROM RS232 CHIP
#--NET "CTS" LOC = "M12" | PULLUP; #INPUT FROM RS232 CHIP
#--NET "RXD" LOC = "A7" | PULLUP; #INPUT FROM RS232 CHIP
NET "Huart_rx_line" LOC = "A7" | PULLUP; #INPUT FROM RS232 CHIP
#####################################
#LED PINS
#####################################
#--NET "LED1" LOC = "C14"; #'1' = ON
NET "led_2" LOC = "C14"; #'1' = ON
#--NET "LED2_N" LOC = "P6"; #'0' = ON
NET "LED_3" LOC = "P6"; #'0' = ON
#--NET "LED3_N" LOC = "P7"; #'0' = ON
NET "led_4" LOC = "P7"; #'0' = ON
#####################################
#MODULE I/O PINOUT
#####################################
#
# ---------
# | RS232 |
# --------------------------
# 1 --|DGND 5V IN |--
40
# 2 --|DGND DGND |--
39
# 3 --|PIN3 dual PIN38 |-- 38 dual/gclk
# 4 --|PIN4 dual PIN37 |-- 37 dual
# 5 --|PIN5 rhclk/dual PIN36 |-- 36 I/O
# 6 --|PIN6 rhclk/dual PIN35 |-- 35 dual/gclk
# 7 --|PIN7 rhclk/dual PIN34 |-- 34 lhclk
# 8 --|PIN8 rhclk/dual PIN33 |-- 33 lhclk
# 9 --|PIN9 rhclk/dual PIN32 |-- 32 I/O
# 10 --|PIN10 I/0 PIN31 |-- 31 lhclk
# 11 --|PIN11 dual PIN30 |-- 30 I/O
# 12 --|PIN12 dual PIN29 |-- 29 lhclk
# 13 --|PIN13 lhclk PIN28 |-- 28 lhclk
# 14 --|PIN14 rhclk/dual PIN27 |-- 27 I/O
# 15 --|PIN15 I/O PIN26 |-- 26 I/O
# 16 --|PIN16 gclk PIN25 |-- 25 I/O
# 17 --|PIN17 gclk PIN24 |-- 24 vref
# 18 --|PIN18 lhclk PIN23 |-- 23 I/O
# 19 --|DGND DGND |--
22
# 20 --|DGND DGND |--
21
#
----------------------------
# | 5V |
# | IN |
# ------
#####################################
#LHS PINS FROM TOP
#####################################
#PIN1 = DGND
#PIN2 = DGND
#--NET "PIN3" LOC = "L14"; #"FPGA_IO27"
#--NET "PIN4" LOC = "N14"; #"FPGA_IO25"
#--NET "PIN5" LOC = "H12"; #"FPGA_IO24"
#--NET "PIN6" LOC = "J12"; #"FPGA_IO23"
#--NET "PIN7" LOC = "G13"; #"FPGA_IO20"
#--NET "PIN8" LOC = "J14"; #"FPGA_IO21"
#--NET "PIN9" LOC = "K14"; #"FPGA_IO22"
#--NET "PIN10" LOC = "C12"; #"FPGA_IO16"
#--NET "PIN11" LOC = "F12"; #"FPGA_IO17"
NET "button_1" LOC = "F12" | PULLUP ; #"FPGA_IO17"
#--NET "PIN12" LOC = "F14"; #"FPGA_IO18"
NET "button_2" LOC = "F14" | PULLUP ; #"FPGA_IO18"
#--NET "PIN13" LOC = "F2"; #"FPGA_IO19"
#--NET "PIN14" LOC = "G14"; #"FPGA_IO15"
#--NET "PIN15" LOC = "A13"; #"FPGA_IO14"
#--NET "PIN15_led" LOC = "A13"; #"FPGA_IO14"
#--NET "PIN16" LOC = "A10"; #"FPGA_IO13"
#--NET "PIN17" LOC = "C9"; #"FPGA_IO12"
NET "a2mhz_huart_tx_line" LOC = "C9"; #"FPGA_IO12"
#--NET "PIN18" LOC = "G3"; #"FPGA_IO11"
NET "a2mhz_huart_ck_line" LOC = "g3"; #"FPGA_IO11"
#PIN19 = DGND
#PIN20 = DGND
#####################################
#RHS PINS FROM TOP
#####################################
#PIN40 = 5V
#PIN39 = DGND
#--NET "PIN38" LOC = "M5"; #"FPGA_IO32"
#--NET "PIN37" LOC = "P4"; #"FPGA_IO33"
#--NET "PIN36" LOC = "L3"; #"FPGA_IO26"
#--NET "PIN35" LOC = "M4"; #"FPGA_IO38"
#--NET "PIN34" LOC = "F1"; #"FPGA_IO34"
#--NET "PIN33" LOC = "H1"; #"FPGA_IO37"
#--NET "PIN32" LOC = "J3"; #"FPGA_IO36"
#--NET "PIN31" LOC = "H3"; #"FPGA_IO35"
#--NET "PIN30" LOC = "A3"; #"FPGA_IO3"
#--NET "PIN29" LOC = "F3"; #"FPGA_IO2"
#--NET "PIN28" LOC = "G1"; #"FPGA_IO1"
#--NET "PIN27" LOC = "B1"; #"FPGA_IO0"
#--NET "PIN26" LOC = "C5"; #"FPGA_IO4"
#--NET "PIN25" LOC = "C3"; #"FPGA_IO5"
#--NET "PIN24" LOC = "C6"; #"FPGA_IO6"
#--NET "PIN23" LOC = "B5"; #"FPGA_IO7"
#PIN22 = DGND
#PIN21 = DGND
------------------------------------------------
Brian Drummond
wrote:
>It just doesn't make any sense.
>
>the UCF file differs by one line, I added:
>
>NET "PIN15_led" LOC = "A13"; #"FPGA_IO14"
Total wildcard, since it really doesn't make sense...
Reinstate than line (in both source and UCF, but with a different name (like
xxx15 for example..). Report whether it behaves any differently.
Just occasionally you see odd behaviour from some toolset or other because you
have used a name which is not legally a reserved word, but is treated as such by
one tool...
I wonder if this could be the case here?
(I have a very poor opinion of the syntax of UCF files. I would love to see a
BNF grammar for it but have a sneaking suspicion it would provoke nothing more
useful than blank stares from the support crew... recently spent about half a
day fighting constraints where XST appeared to convert half my names to lower
case - but leave the rest - and some constraints but not others would be
rejected by "Translate" until I capiTalIZed the UCF the way IT wanted...)
- Brian
jleslie48
wrote:
> On Mon, 20 Apr 2009 08:46:14 -0700 (PDT), jleslie48 <j...@jonathanleslie.com>
> wrote:
>
> >It just doesn't make any sense.
>
> >the UCF file differs by one line, I added:
>
> >NET "PIN15_led" LOC = "A13"; #"FPGA_IO14"
>
> Total wildcard, since it really doesn't make sense...
> Reinstate than line (in both source and UCF, but with a different name (like
> xxx15 for example..). Report whether it behaves any differently.
>
> Just occasionally you see odd behaviour from some toolset or other because you
> have used a name which is not legally a reserved word, but is treated as such by
> one tool...
>
> I wonder if this could be the case here?
>
> (I have a very poor opinion of the syntax of UCF files. I would love to see a
> BNF grammar for it but have a sneaking suspicion it would provoke nothing more
> useful than blank stares from the support crew... recently spent about half a
> day fighting constraints where XST appeared to convert half my names to lower
> rejected by "Translate" until I capiTalIZed the UCF the way IT wanted...)
>
> - Brian
I hear you. That's generally why I put the "_led" on the net line.
just to change it.
Someone else has also suggested that. I made them all CAPS. but
nothing changed.
I took the line out of the UCF in the hopes that maybe the pin I was
using was inappropriate and by letting the toolset pick the pin it
would resolve the issue. It didnt
I'm beginning to think that the problem hinges on the CRC error. I
think that is the key to the whole issue. I can't imagine any syntax
situation causing a CRC error.
djj08230
>
> Please note the WARNING: iMPACT:2217 - Error shows in the status
> register, CRC Error bit is NOT 0.
>
> a subsequent call to 'get device id' yields:
>
> // *** BATCH CMD : ReadIdcode -p 1
> INFO:iMPACT:583 - '1': The idcode read from the device does not match
> the idcode in the bsdl File.
> INFO:iMPACT:1578 - '1': Device IDCODE :
> 00001111111111111111111111111111
> INFO:iMPACT:1579 - '1': Expected IDCODE:
> 00000001110000100010000010010011
>
> and a big red 'ReadIDcode failed' block pops up in instead of the nice
> blue block saying 'succeeded'
This may not be related to your VHDL at all.
When using a Spartan3 (not E) I recall experiencing a similar
behaviour. Configuration seemed not to be reliable when configuring
the FPGA directly and bypassing the serial FLASH.
Usually I had to power cycle a few times before being able to
succedfully configure the FPGA. I never got an explanation to this
behavior, it could be the board I was using, the tools or whatever. In
my case programing the serial flash and then rebooting the board got a
100% success.
Another point worth checking is the programming cable you are using. I
used to get bad results with home made and cheap compatible programmig
cables. All problems seemed to dissapear when using official USB
Xilinx cable.
Josep
Antti....@googlemail.com
>
> - Show quoted text -
oh,
I fogot to mention this
YOU MUST ERASE platform flash for reliable JTAG configuration
if you dont you may have random errors..
Antti
jleslie48
Yes, I'm beginning to believe that this an error in the jtag loading
procedure and not my code.
Xilinx support wants me to try the following:
iMPACT and JTAG:
A1. Provide an ordered list of devices in the JTAG chain
A2. Note the cable speed (MHz), and try running the system at the
slowest cable speed possible
A3. Collect the _impact.log in your project directory after
performing the failing operation
A4. Read the Status Register after failing operations on an FPGA
A5. Use the latest version of the software available from the
Download Center
Configuration via PROM:
B1. What is the status of INIT and DONE
B2. What configuration mode is being used
B3. Will source files work via iMPACT
B4. After the failed configuration attempt, read the Status
Register of the FPGA via iMPACT
B5. Get scope shots of power supplies and control pins during
configuration, if possible
------------------------------------------------------------------------
How do I accomplish A1, A2, A4, B1, B2, B4?
I can't find anything in this package...
Also the system is non-responsive after the CRC error, how can I (B4)
"read the Status Register of the FPGA via iMPACT"
or is there something that still might be responsive after the "lock
up"
Antti....@googlemail.com
>
> - Show quoted text -
you cant scan JTAG chain after CRC error?
if that so you have major hardware issue, get another board (another
type of board!)
the config prom can cause one time failure of jtag conf, but chain
should remain scannable
Antti
jleslie48
I certainly can't 'get device id' or 'get device signature/
usercode'
I didn't initialize chain.
I have eliminated my program from causing any error though.
I wrote my program to the SPI FLASH and it starts up fine and PIN15 is
not an issue.
However now that I did that, the JTAG connection to the is completely
non-functional, but does not lock up the
FPGA:
------------------------------------------------------------------------
// *** BATCH CMD : setMode -pff
// *** BATCH CMD : setMode -pff
// *** BATCH CMD : setMode -bs
// *** BATCH CMD : setMode -bs
// *** BATCH CMD : ReadIdcode -p 1
INFO:iMPACT:583 - '1': The idcode read from the device does not match
the idcode in the bsdl File.
INFO:iMPACT:1578 - '1': Device IDCODE :
00001111111111111111111111111111
INFO:iMPACT:1579 - '1': Expected IDCODE:
00000001110000100010000010010011
Attempting to identify devices in the boundary-scan chain
configuration...// *** BATCH CMD : Identify
PROGRESS_START - Starting Operation.
Identifying chain contents ....done.
ERROR:iMPACT:585 - A problem may exist in the hardware configuration.
Check that the cable, scan chain, and power connections are intact,
that the specified scan chain configuration matches the actual
hardware, and
that the power supply is adequate and delivering the correct
voltage.
PROGRESS_END - End Operation.
Elapsed time = 0 sec.
// *** BATCH CMD : identifyMPM
Enumerating cables. Please wait.
PROGRESS_START - Starting Operation.
Connecting to cable (Usb Port - USB21).
Checking cable driver.
Driver file xusb_xlp.sys found.
Driver version: src=1029, dest=1029.
Driver windrvr6.sys version = 8.1.1.0. WinDriver v8.11 Jungo (c) 1997
- 2006 Build Date: Oct 16 2006 X86 32bit SYS 12:35:07, version = 811.
Cable PID = 0008.
Max current requested during enumeration is 300 mA.
Type = 0x0005.
Cable Type = 3, Revision = 0.
Setting cable speed to 6 MHz.
Cable connection established.
Firmware version = 2401.
File version of C:/Xilinx/10.1/ISE/data/xusb_xp2.hex = 2401.
Firmware hex file version = 2401.
=======================================================
Found cable - > Type = 0x0005.
ESN option: 00001322B47101.
ESN = 00001322B47101.
=======================================================
Connecting to cable (Usb Port - USB22).
Checking cable driver.
Driver file xusb_xlp.sys found.
Driver version: src=1029, dest=1029.
Driver windrvr6.sys version = 8.1.1.0. WinDriver v8.11 Jungo (c) 1997
- 2006 Build Date: Oct 16 2006 X86 32bit SYS 12:35:07, version = 811.
Cable connection failed.
PROGRESS_END - End Operation.
Elapsed time = 2 sec.
Error opening cdb file for reading.
// *** BATCH CMD : setCable -port usb21 -baud 3000000
Connecting to cable (Usb Port - USB21).
Checking cable driver.
Driver file xusb_xlp.sys found.
Driver version: src=1029, dest=1029.
Driver windrvr6.sys version = 8.1.1.0. WinDriver v8.11 Jungo (c) 1997
- 2006 Build Date: Oct 16 2006 X86 32bit SYS 12:35:07, version = 811.
Cable PID = 0008.
Max current requested during enumeration is 300 mA.
Type = 0x0005.
Cable Type = 3, Revision = 0.
Setting cable speed to 3 MHz.
Cable connection established.
Firmware version = 2401.
File version of C:/Xilinx/10.1/ISE/data/xusb_xp2.hex = 2401.
Firmware hex file version = 2401.
PLD file version = 200Dh.
PLD version = 200Dh.
Type = 0x0005.
ESN option: 00001322B47101.
Attempting to identify devices in the boundary-scan chain
configuration...// *** BATCH CMD : Identify
PROGRESS_START - Starting Operation.
Identifying chain contents ....done.
ERROR:iMPACT:585 - A problem may exist in the hardware configuration.
Check that the cable, scan chain, and power connections are intact,
that the specified scan chain configuration matches the actual
hardware, and
that the power supply is adequate and delivering the correct
voltage.
PROGRESS_END - End Operation.
Elapsed time = 0 sec.
// *** BATCH CMD : identifyMPM
--------------------------------------------------------------------
but the SPI port works fine:
------------------------------------------------------------
Connecting to cable (Usb Port - USB21).
Checking cable driver.
Driver file xusb_xlp.sys found.
Driver version: src=1029, dest=1029.
Driver windrvr6.sys version = 8.1.1.0. WinDriver v8.11 Jungo (c) 1997
- 2006 Build Date: Oct 16 2006 X86 32bit SYS 12:35:07, version = 811.
Cable PID = 0008.
Max current requested during enumeration is 300 mA.
Type = 0x0005.
Cable Type = 3, Revision = 0.
Setting cable speed to 6 MHz.
Cable connection established.
Firmware version = 2401.
File version of C:/Xilinx/10.1/ISE/data/xusb_xp2.hex = 2401.
Firmware hex file version = 2401.
PLD file version = 200Dh.
PLD version = 200Dh.
PROGRESS_END - End Operation.
Elapsed time = 2 sec.
---------------------------------------------------------------------
jleslie48
ok yeah, once the crc error happens its dead, I get:
----------------------------------------------------------------------------------------------------------
WARNING:iMPACT:2217 - Error shows in the status register, CRC Error
bit is NOT 0.
INFO:iMPACT:2219 - Status register values:
INFO:iMPACT - 1111 1111 1111 1111 1111 1111 1111 1111
INFO:iMPACT:579 - '1': Completed downloading bit file to device.
INFO:iMPACT - '1': Checking done pin....done.
'1': Programmed successfully.
PROGRESS_END - End Operation.
Elapsed time = 1 sec.
Attempting to identify devices in the boundary-scan chain
configuration...// *** BATCH CMD : Identify
PROGRESS_START - Starting Operation.
Identifying chain contents ....done.
ERROR:iMPACT:585 - A problem may exist in the hardware configuration.
Check that the cable, scan chain, and power connections are intact,
that the specified scan chain configuration matches the actual
hardware, and
that the power supply is adequate and delivering the correct
voltage.
PROGRESS_END - End Operation.
Elapsed time = 0 sec.
// *** BATCH CMD : identifyMPM
----------------------------------------------------------------------------------------------------------------
I have a second board, and it does the same thing, and remember all I
have to do to generate the problem is to drive pin15, and try and load
the FPGA thru the jtag header.
If I don't touch a cable, and simply comment out the driving of pin15
then all is well.
This led me to believe that the problem was with the pin usage,
however, if I take that same .bit program that drives PIN15 and kills
the FPGA, make a .MCS burn image out of it, load it into the SP flash
using the SPI header using the same cables as before, the program runs
fine, and I am even properly driving PIN15.
So it appears that driving PIN15 is not an issue at all when the
program loads from the SP flash, and I'm leaning to the conclusion
that the CRC error is a function of the impact 10.1 having an issue,
making higgley-piggley out of my program and locking up the FPGA.
Xilinx has no documentation of any of this, and their support, well
let's just leave it as leaves a lot to be desired.
jleslie48
NOW, I took a look over at Xilinx (god I hate their website) and I
noticed in
the download section:
Update Type: BSDL Models
Device Family: Spartan-3E
File Type: ZIP (384 KB)
Release Date: 05/29/2008
Release Notes:
Spartan-3E BSDL Files
------------------------------------------------------------------------
This is a "Device Models for Boundary Scan operations"
download and has .BSD files in it. Does this have anything that might
solve this issue?
Brian Davis
>
> So it appears that driving PIN15 is not an issue at all when the
> program loads from the SP flash, and I'm leaning to the conclusion
> that the CRC error is a function of the impact 10.1 having an issue,
> making higgley-piggley out of my program and locking up the FPGA.
>
>Xilinx has no documentation of any of this, and their support, well
>let's just leave it as leaves a lot to be desired.
>
The conflict between SPI-mode configuration and JTAG configuration
in various Spartan-3's is well known and documented in several places
by Xilinx (see below), as well as being a fairly regular topic here.
The only workarounds I know of are to either erase the flash
(as Antti suggested), disconnect/disable the flash, or to set
the configuration mode on the chip to JTAG when programming
the FPGA directly.
After a quick look at the Drigmorn1 board schematic, it does not
appear that the configuration mode can be changed, as the mode pins
are hardwired to VCC/ground; the erase-the-flash-before-JTAG-download
method is probably your best bet if you want to program the FPGA
directly without loading up the SPI flash.
Brian
Xilinx Documentation:
XAPP951 v1.2 Configuring Xilinx FPGAs with SPI Serial Flash
http://www.xilinx.com/support/documentation/application_notes/xapp951.pdf
figure3, footnote 6 :
"
" 6. For dual configuration mode usage, it is recommended to have the
" option to hold the M2 signal High for JTAG configuration mode.
"
Answer Records:
http://www.xilinx.com/support/answers/9013.htm
http://www.xilinx.com/support/answers/22142.htm
http://www.xilinx.com/support/answers/22255.htm
http://www.xilinx.com/support/answers/16829.htm
jleslie48
> jleslie48 wrote:
>
> > So it appears that driving PIN15 is not an issue at all when the
> > program loads from the SP flash, and I'm leaning to the conclusion
> > that the CRC error is a function of the impact 10.1 having an issue,
> > making higgley-piggley out of my program and locking up the FPGA.
>
> >Xilinx has no documentation of any of this, and their support, well
> >let's just leave it as leaves a lot to be desired.
>
> The conflict between SPI-mode configuration and JTAG configuration
> in various Spartan-3's is well known and documented in several places
> by Xilinx (see below), as well as being a fairly regular topic here.
>
> The only workarounds I know of are to either erase the flash
> (as Antti suggested), disconnect/disable the flash, or to set
> the configuration mode on the chip to JTAG when programming
> the FPGA directly.
>
> After a quick look at the Drigmorn1 board schematic, it does not
> appear that the configuration mode can be changed, as the mode pins
> are hardwired to VCC/ground; the erase-the-flash-before-JTAG-download
> method is probably your best bet if you want to program the FPGA
> directly without loading up the SPI flash.
>
> Brian
>
> Xilinx Documentation:
>
> figure3, footnote 6 :
> "
> " 6. For dual configuration mode usage, it is recommended to have the
> " option to hold the M2 signal High for JTAG configuration mode.
> "
>
> Answer Records:
>
> http://www.xilinx.com/support/answers/9013.htmhttp://www.xilinx.com/support/answers/22142.htmhttp://www.xilinx.com/support/answers/22255.htmhttp://www.xilinx.com/support/answers/16829.htm
Brian,
Thank you very much. It wasn't untll the end that I connected the
JTAG load problem with my previous SPI load, mostly because after I
loaded the SPI, I successfully changed the code using the JTAG to FPGA
without any issue. It was only when I added signals to pins did the
error message pop up.
One would think Xilinx would have that listed in the possible causes
of the 2217 error and that a search of Xilinx for "iMpact:2217 crc
error bit not 0" (the actual error message that pops up) would be
acknowledged.
For the amount of money I paid for this development suite and support
I cannot believe the level and frequency of bugs in the software and
lack of support I get from these folks.
Antti....@googlemail.com
>
> Brian,
>
> Thank you very much. It wasn't untll the end that I connected the
> JTAG load problem with my previous SPI load, mostly because after I
> loaded the SPI, I successfully changed the code using the JTAG to FPGA
> without any issue. It was only when I added signals to pins did the
> error message pop up.
>
> One would think Xilinx would have that listed in the possible causes
> of the 2217 error and that a search of Xilinx for "iMpact:2217 crc
> error bit not 0" (the actual error message that pops up) would be
> acknowledged.
>
> For the amount of money I paid for this development suite and support
> I cannot believe the level and frequency of bugs in the software and
>
> - Show quoted text -
impact s****
always has...
there are things to KNOW
JTAG configuration mode does OVERRIDE other modes
but it not always works with impact
this may depend 2 bitfiles bit difference you are trying to load
or the speed of the PC, or the type of cable you use..
so while it should be ALWAYS be possible to configure
over jtag without concern of the MODE pins settings
with impact this isnt true
i once designed a workaround that used boundary scan
to place the SPI flash into deep powerdown mode
to allow the configuration to be done properly..
Antti
jleslie48
The thing that really burns my, err kiester, is that here the iMPACT
tool not only generates an error, but a full blown pop up window:
"WARNING:iMPACT:2217 - Error shows in the status register, CRC Error
bit is NOT 0. "
that I have to click an [OK] button to get around.
first off, its not a warning it totally KILLS the fpga. that's not a
warning thats a FATAL ERROR.
secondly and more importantly, How in god's name can it be that if I
search Xilinx for that exact error I don't get a connection to the
links that Brian so nicely provided? Here the problem is a known
issue for 2 years, yet its most glaring symptom, a big pop up window
with an error code, can't be cross referenced against what caused the
error. That is pathetic.
Meantime Webcase support is 3 days into looking at the issue, and all
they can tell me is do I have the unit powered up...
This I pay $600 a year for. This forum should be getting the $600...
Thanks everyone.
- Jon
Antti....@googlemail.com
>
> - Show quoted text -
HA HA HA
I talked with my wife once about xilinx "Answer Record" system
saying, you know they have special AR database, there are 30K+
here she interrupted me:
"Ah this is the place where you DO NOT GET ANSWERS!"
I said, yes this is the place.
If you dont know the AR number, you would not find it.
but not only you, Xilinx employees and webcase personel
are equally unable to find them as well. At least it happens..
Antti
Antti....@googlemail.com
>
> - Show quoted text -
Jon,
I forgot... your problem is you are paying too little !!!
there is "Xilinx Platinum support" option they promise
that clients will speed up time to market by 6 months
if they use Platinum support.
6 month TTM is more then 6 man-manths, I wonder
how much Xilinx takes for this service. But I can
see how those 6 months are posssible to save..
(you need sick software, and sick documents and support -
this opens the window for the platinum guys todo miracle
in saving customer frustration)
everybody can milder the above saying to their liking..
its not that bad always, even xilinx software is getting better
(in some ways at least)
Antti
jleslie48
My letter to Xilinx:
Possibly the worst website support center/response to issues I have
ever had to pay for.
Thursday, April 23, 2009 9:28 AM
From:
"Jonathan Leslie" <jles...@yahoo.com>
To: isscs...@xilinx.com
Cc: euc...@xilinx.com, apac...@xilinx.com
The level of amateur responses and website development at the Xilinx
website and support center is inexcusable. Between having to login in
every 10 minutes, and a search engine that can't find anything, and
webcase responses that make make a rag of a newspapers horoscope
section seem intelligent. I cannot believe that you have the nerve to
charge money for this.
Ok, so I found my solution, this is an known issue. a known issue for
some 2 years and yet to be fixed:
Answer Records:
http://www.xilinx.com/support/answers/9013.htm
http://www.xilinx.com/support/answers/22142.htm
http://www.xilinx.com/support/answers/22255.htm
http://www.xilinx.com/support/answers/16829.htm
the moral is you can't use the JTAG load if the SPI is loaded with a
program.
Just load up the SPI.
The thing that really annoys me is that here the iMPACT
tool not only generates an error, but a full blown pop up window:
"WARNING:iMPACT:2217 - Error shows in the status register, CRC Error
bit is NOT 0. "
that I have to click an [OK] button to get around.
first off, its not a warning, it totally KILLS the fpga. that's not a
warning, that's a FATAL ERROR.
secondly and more importantly, How in god's name can it be that if I
search Xilinx for that exact error I don't get a connection to the
known issue? Here the problem is a known issue for 2 years, yet its
most glaring symptom, a big pop up window with an error code, can't be
cross referenced against what caused the
error. That is inexcusable.
For that matter, not one response of your search engine for "warning
2217" comes up with any match against any of your hundreds of 1000's
of documents. IT'S YOUR OWN ERROR MESSAGE. How is it possible I
can't look up YOUR OWN ERROR MESSAGE ON YOUR OWN WEBSITE?????
It is inexcusable.
I have always said that Xilinx puts out so much documentation just to
say its documented (aka, CYA) but really is just hiding behind
complete incompetence in organization. Here is just another example.
Meantime Webcase support is 3 days into looking at the issue, and all
they can tell me is do I have the unit powered up...
This I pay $600 a year for. I bother you guys 3 maybe 4 times a
year, and I can't even get someone with half a brain to look at the
problem, which if they properly organized their errors and known
issues should of been a 10-minute to solution lookup.
rickman
If you want a connection to be made between the problem and the links
Brian provided, try making a report. First, be sure to search in
other ways for these links in the Xilinx data base. If you find them,
it may have just been a glitch in the search engine. If you don't
find them, then making a report will likely result in a data base
entry.
That is how most of the data base is built, from reported problems and
solutions that are found.
Rick
Brian Drummond
<Antti....@googlemail.com> wrote:
>
>HA HA HA
>
>I talked with my wife once about xilinx "Answer Record" system
>saying, you know they have special AR database, there are 30K+
>
>here she interrupted me:
>
>"Ah this is the place where you DO NOT GET ANSWERS!"
>
>I said, yes this is the place.
>
>If you dont know the AR number, you would not find it.
Heh, that's a BIG improvement!
Used to be, if you DID know the AR# you still didn't find it!
You could search on an AR number and search would come up with nothing...
The only way I could find the AR was to search for something else, click on any
AR, then edit the AR# into the URL...
So at least Xilinx have fixed something!
I even opened a webcase that they should do the same for error, warning and info
numbers; even if you only get a default page for that number until there is some
content to add.
Like "see <link to AR12345> for more information"
or
"No content yet. Open a webcase to start the content for this page"
- Brian