EDK : FSL macros defined by Xilinx are wrong

Jim Granville wrote:

lecroy7200@chek.com wrote:

Thanks. I read the note and agree that the problem could be
related to
some kind of transient. If the Done/Program pin were stuck in the
low
state it appears that the device will still reset by monitoring the
state of the Reset pin.

Err, maybe.
Keep in mind that on many devices, the RESET does NOT reset
everything,
and is more aptly labeled reset request.

I am just going by what their data sheet says. From my testing, it
does appear that the part functions this way as well. Not to say that
it has not reached some "safe state" that reset won't shake it loose,
because that appears to be what I am seeing.

This design has the power down pin tied to VCC, but I broke it out to
test this mode as well. I tried doing some basic DC tests as well as
sweeping RF into the pin, but again was not able to replicate the
problem.

Yes, I can detect when the problem happens. Power cycling the system
is not an option. Are the Xilinx guys still browsing this group? If
so, any ideas from the masters? I am running out of ideas to try.

 

[Gabor]

Repzak wrote:

Hej

anyone who easily can tell me wich prom i have to add on this board :

http://www.coreworks.pt/basicboard.htm

I would like the prom to be big enough to contain so much data as i
can use
all the "space" in the fpga.. spartan2 300k

i used just to upload, but have to use it to a school project and i
want to
order the prom's in a good time before i have to use them

thanks

--
Mvh Kasper

It's hard to tell from the documentation what sort of PROM you need.
If it is in an 8-pin DIP package you may be out of luck, since the
2 Megabit parts don't come in this package. Check out Atmel's site
for AT17Fxxx flash-based or AT17LVxxx EEPROM parts.

 

[Austin Lesea]

Have you opened a case with our hotline?

It appears you are getting into some strange state between on, and off.

The devil is in the details, and working directly with the hotline is
your best bet to resolve it.

Austin

lecroy7200@chek.com wrote:

Jim Granville wrote:

lecroy7200@chek.com wrote:


Thanks. I read the note and agree that the problem could be

related to

some kind of transient. If the Done/Program pin were stuck in the

low

state it appears that the device will still reset by monitoring the
state of the Reset pin.

Err, maybe.
Keep in mind that on many devices, the RESET does NOT reset

everything,

and is more aptly labeled reset request.


I am just going by what their data sheet says. From my testing, it
does appear that the part functions this way as well. Not to say that
it has not reached some "safe state" that reset won't shake it loose,
because that appears to be what I am seeing.

This design has the power down pin tied to VCC, but I broke it out to
test this mode as well. I tried doing some basic DC tests as well as
sweeping RF into the pin, but again was not able to replicate the
problem.

Yes, I can detect when the problem happens. Power cycling the system
is not an option. Are the Xilinx guys still browsing this group? If
so, any ideas from the masters? I am running out of ideas to try.

 

[Brian Philofsky]

Hmmm. That is not how it is supposed to work. We are looking into this
and either I or someone else will get back to you. XST is supposed to
catch this but perhaps something strange is happening.

-- Brian


Marius Vollmer wrote:

Brian Philofsky <brian.philofsky@no_xilinx_spam.com> writes:


[...]
If you did not use any translate_off / ons in the code, you should
have seen errors during either XST or NGDBUILD as it would have
identified the incorrect parameter and properly warned but if those
are in the code, the tools ignore them as you are instructing with
those commands.


This is not my experience. In the code below, the generic
associations marked with XXX are clearly wrong but go unnoticed.

Also, I was unsuccessful in setting the "PERIOD" attribute from VHDL
(also marked with XXX in the code). Xst says:

Timing constraint: NET clkgen_clk_100_buf PERIOD = 10 nS HIGH 5 nS

But par does not see this constraint, I think. If I put the
constraint in a .ucf file, then par does see it. Hmmm.

Thanks a lot, Brian!


Here is the code fragment:

-- clock_generator -- generates deskewed system clocks and handles reset

library ieee;
use ieee.std_logic_1164;

library unisim;
use unisim.vcomponents.all;

use work.common.all;

entity clock_generator is

generic (
clk_var_mult : positive; -- Frequency multiplier for variable clock
clk_var_div : positive); -- Frequency divider

port (
-- external connections
clk_100_in : in u1; -- 100MHz Clock from external oscillator
clk_sd_out : out u1; -- 100MHz to SDRAM
clk_sd_in : in u1; -- 100MHz feedback from SDRAM
reset_in : in u1; -- Reset input from switch

-- global clock and reset
clk_100 : out u1; -- Deskewed 100MHz clock, suitable for the
-- SDRAM controller, for example.
clk_var : out u1; -- Variable frequency clock, see generics.
reset : out u1); -- Reset

end entity;

architecture syn of clock_generator is

signal clk_sd_in_buf, clk_100_deskewed, clk_100_buf : u1;
signal clk_var_unbuf, clk_var_buf : u1;
signal locked : u1;

attribute period : string;
attribute period of clk_100 : signal is "10 ns"; -- XXX - no effect
attribute period of clk_var : signal is "40 ns"; -- XXX - no effect

begin

-- The 100MHz clock is directly routed to the SDRAM. The clock for
-- internal logic is deskewed with respect to the clock coming back
-- from the SDRAM.

clk_sd_out <= clk_100_in;

inbuf: IBUFG
port map (
i => clk_sd_in,
o => clk_sd_in_buf);

deskew: DCM
generic map (
clkfx_mult => clk_var_mult, -- XXX - no error for this
clkfx_div => clk_var_div, -- XXX - no error for this
hi_xst_how_is_your_day => 0, -- XXX - no error for this
clkin_period => 10.0)
port map (
rst => reset_in,
clkin => clk_sd_in_buf,
clkfb => clk_100_buf,
clk0 => clk_100_deskewed,
clkfx => clk_var_unbuf,
locked => locked);

buf_clk_100: BUFG
port map (
i => clk_100_deskewed,
o => clk_100_buf);

buf_clk_var: BUFG
port map (
i => clk_var_unbuf,
o => clk_var_buf);

clk_100 <= clk_100_buf;
clk_var <= clk_var_buf;
reset <= not locked;

end syn;

 

[Philip Freidin]

On 14 Mar 2005 08:28:33 -0800, lecroy7200@chek.com wrote:

Thanks. I read the note and agree that the problem could be related to
some kind of transient. If the Done/Program pin were stuck in the low
state it appears that the device will still reset by monitoring the
state of the Reset pin.

The key word in my previous article is "transient", as in maybe only
for a microsecond or two.

This corrupts an internal state machine, and the illegal state is something
like "house cleaning complete", "configured" (which is no longer true),
and "done" pin low (caused by "house cleaning complete").

As the done pin is an open drain signal, if the FPGA is pulling it low,
then it cant tell if you are pulling it low out side as well. It needs
for the FPGA to release this signal, and an external resistor to pull
it up, before it can recognize an external pull down of this signal.

As a test, I forced the Prog pin low on one device in the chain. The
pin latches low as expected. I then forced a few clock cycles to get
the device into some mid data stream mode. I then pulled the reset low
and started a normal configuration. The part did recover, releasing the
Prog. pin at the end of the programming cycle. So, at least this all
seems to work.

Yep.

My next step is to conduct noise onto the supply to see if I can
replicate the problem. Because this happens so infrequent, it is next
to impossible to find any other clues.

I tried a few different tests. I first reduced the supply votage on
the Xilinx devices by 500mV and ran the system as normal, but saw no
problems. I then reduced the supply voltage until I started to see
problem with the function of the devices (this was around 3.5 volts),
but as soon as the supply was returned to normal the parts would
function normal as well. Using a bias T I then injected a sinewave
onto the supply line. I ran the supply at 4.5 volts and injected a
500mV signal. I did multiple sweeps from 100KHz up to a bit over a GHz
and saw no problems. I then ran the same test with the supply at 5
volts and again saw no problems.

So far, it would appear the problem is not related to the supply
voltage or operating temperature.

You haven't tried something like I have suggested. Try and have the power
sitting at 5V, and pulse it low to 3V or 2.5V for 1 to 2 microseconds,
then back high for much longer time (seconds).

The problem I seem to remember is that the narow pulse is recognized by
the voltage level detector in the FPGA, which starts the house cleaning,
that wipes the config memory, but the 6uS filter stops the power glitch
from being detected by the reconfiguration logic.

The problem with the sinewave is that when it goes low it does so for too
long to trigger the brownout problem.

I am still fairly sure this is a powersupply transient problem.

Philip


Philip Freidin
Fliptronics

 

[praveen]

The serial PROM required depends on the configuration bits of the
FPGA. Just look at the datasheet of the FPGA, you will come to know
the configuration bit required, from which you can choose the serial
prom required. The serial PROM required is also specified in the
datasheet. Go through the datasheet.

Regards
Praveen

 

[Göran Bilski]

Gog wrote:

Hi all,

I'm a student and newbie in FPGA design.
I have a port of uC/OS-II on Memec Virtex-II MB1000 Development Kit
from the Micrium's website and i want to port it on a Spartan3 Board
from Digilent
(https://www.digilentinc.com/Sales/Product.cfm?Prod=S3BOARD).
All services of the OS are disabled. There is only 1 task and print.
The program size is 21 KB. On S3, there is 216Kbits/27KB of BRAM.
In parameters Tab of EDK, i set C_MEMSIZE if Bram to 27000 and my both
lmb controller to 16KB (max). I have always ".elf cannot reside
completely in bram", i set microblaze_0_bootloop to "marked to
initialize BRAMs" and follow the instructions as written in many
tutorials for debugging. XMD told me : "unable to stop Microblaze,
verify if FPGA is configured and Microblaze system clock is connected
properly". I have change the .ucf file
to correspond with my card and the system clock is set.

Are there other files to change? Could someone help me to understand
that is wrong?

Thanks for your answer !

Hi,

You can't get a 21kbyte program into a 16kbyte memory.
The memory blocks in EDK can only have the size of 2**N so you need two memory
blocks, one of 16kbyte and one of 8 kbyte.
This should give you enough memory.

But I would suggest that you starting to use the external memory on the board.

On the problem with debugging, much more information is needed about your system.
Have you enabled HW debug logic on MicroBlaze?

Göran

 

[Marius Vollmer]

Brian Philofsky <brian.philofsky@no_xilinx_spam.com> writes:

Hmmm. That is not how it is supposed to work. We are looking into
this and either I or someone else will get back to you.

Excellent! Thank you very much.

If you need more information to reproduce this bug, I will be happy to
provide it, of course.

--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405

 

Thanks again. I will try the pulsed supply as suggested today and post
my findings.

To give you an idea of the MTBF, of about 90 ICs being run, I have seen
or heard of the problem 5 times over about a six month period. There
is not a good way to probe the parts after the fact to see what is
going on. Reproducing the problem seems to be the only good way to
solve it at this point.

 

[Jim Granville]

lecroy7200@chek.com wrote:

Thanks again. I will try the pulsed supply as suggested today and post
my findings.

To give you an idea of the MTBF, of about 90 ICs being run, I have seen
or heard of the problem 5 times over about a six month period. There
is not a good way to probe the parts after the fact to see what is
going on. Reproducing the problem seems to be the only good way to
solve it at this point.

Besides power supply transient, you should also look at IO pin
transients, or even RF field bursts. The consensus is the logic is being
disturbed, but the source is a mystery.
Large IO transisents can cause lateral currents in the die.
Do the failures have any site/user-clusters ?
-jg

 

[Nemesis]

Mentre io pensavo ad una intro simpatica "Jim George" scriveva:

Hi everyone,
I'm going to buy Xilinx ISE Foundation, I'd like to know if this package
contains also IP cores like DDC, FFT and so on.
It seems that the "LogiCore" IPs should be shipped within ISE
Foundations, am I right?
Yes, ISE Foundation comes with Coregen.

Thanks, I'm still trying to found a complete list of the IP shipped with
ISE. I found at least on LogiCore IP wich is not given for free (the PCI
IP).

--
"Costacurta colpisce Batistuta al polpaccio, che finisce a terra"
(Carlo Sassi)

|\ | |HomePage : http://nem01.altervista.org
| \|emesis |XPN (my nr): http://xpn.altervista.org

 

Do the failures have any site/user-clusters ?
-jg

Not sure what you mean by this.

I did look at all of the signals to/from the devices and there is not
an excessive amount of over/undershoot.

I tried setting up a test to pulse the power to the board. The problem
in doing this is the amount of bulk and high frequency capacitance on
the board prevents me from getting a good solid pulse. I thought about
doing a push-pull but have not tried this yet. Just interrupting the
power, I set the pulse time to where the devices would just start to
become effected. I would then reprogram them and repulse the supply.
I ran this test for about four hours today and was still not able to
replicate the problem.

I also opened a case file with Xilinx. I would drop the old 3000A
parts if I knew that would fix the problem, but until I am able to
reproduce it I don't see this being an option. I have never seen an
FPGA get into a mode like this that required a power cycle to clear it.

 

[Jim Granville]

lecroy7200@chek.com wrote:

Do the failures have any site/user-clusters ?
-jg


Not sure what you mean by this.

Are the failures random across all your installations, or
do they cluster in a few sites or users. Often these
external impact effects are local.
Any relays or contactors involved ?

I did look at all of the signals to/from the devices and there is not
an excessive amount of over/undershoot.

It is not a 'normal signal' effect, but an external impulse effect.

A good 'chip cracker' test is a self commutating mains relay, and a
short 'wand' cable. The arcing contact + bounce effects mean you can
generate wave fronts of over 1KV/ns. Wave the wand around your cables
and PCB, and watch for your effect.

We have used this type of severe test setup, to find that a number of
chips have the (Reset < Power Cycle) effects.

I tried setting up a test to pulse the power to the board. The problem
in doing this is the amount of bulk and high frequency capacitance on
the board prevents me from getting a good solid pulse. I thought about
doing a push-pull but have not tried this yet. Just interrupting the
power, I set the pulse time to where the devices would just start to
become effected. I would then reprogram them and repulse the supply.
I ran this test for about four hours today and was still not able to
replicate the problem.

I also opened a case file with Xilinx. I would drop the old 3000A
parts if I knew that would fix the problem, but until I am able to
reproduce it I don't see this being an option. I have never seen an
FPGA get into a mode like this that required a power cycle to clear it.

 

Jim Granville wrote:

lecroy7200@chek.com wrote:
Do the failures have any site/user-clusters ?
-jg


Not sure what you mean by this.

Are the failures random across all your installations, or
do they cluster in a few sites or users. Often these
external impact effects are local.
Any relays or contactors involved ?

This is a random failure from what I am able to tell and not tied to a
particular location or setup. The environment is clean (from a noise
perspective).

I did look at all of the signals to/from the devices and there is
not
an excessive amount of over/undershoot.

It is not a 'normal signal' effect, but an external impulse effect.

A good 'chip cracker' test is a self commutating mains relay, and a

short 'wand' cable. The arcing contact + bounce effects mean you can
generate wave fronts of over 1KV/ns. Wave the wand around your cables
and PCB, and watch for your effect.

We have used this type of severe test setup, to find that a number
of
chips have the (Reset < Power Cycle) effects.

We sell products all over the world and require CE certification. We
perform a full set of conducted and radiated tests on every product.
During these tests I have not seen this problem. This is a much worse
environment than where the units are being run.

The main clock on this card is 500MHz and we sample on both edges.
There are several layers of ECL before getting to the Xilinx parts that
are running at a modest 60MHz. So termination and correct layout are a
big factor in making the designs work. Almost every trace is
controlled.

I went ahead and installed a second FET to crowbar the supply to the
card once power was cut in order to force the bulk and high frequency
caps. to discharge at a faster rate. This did help me achieve a faster
edge with my power supply testing, but again I was not able to
reproduce the problem.

 

[Marc Randolph]

Nemesis wrote:

Mentre io pensavo ad una intro simpatica "Jim George" scriveva:

Hi everyone,
I'm going to buy Xilinx ISE Foundation, I'd like to know if this
package
contains also IP cores like DDC, FFT and so on.
It seems that the "LogiCore" IPs should be shipped within ISE
Foundations, am I right?
Yes, ISE Foundation comes with Coregen.

Thanks, I'm still trying to found a complete list of the IP shipped
with
ISE. I found at least on LogiCore IP wich is not given for free (the
PCI
IP).

Howdy,

I looked everywhere I could think of and could not find a list of
which cores cost money and which are included with Core gen.

I don't know what DDC is (did you mean DCT, in which case there are 1-D
and 2-D DCT's included). There are a number of different FFT's
included with Coregen as well.

Good luck,

Marc

 

[Stephan Neuhold]

Nemesis wrote:

Hi everyone,
I'm going to buy Xilinx ISE Foundation, I'd like to know if this package
contains also IP cores like DDC, FFT and so on.
It seems that the "LogiCore" IPs should be shipped within ISE
Foundations, am I right?

Nemesis,

You can find all supported IP for Coregen 7.1i at the following site
http://www.xilinx.com/ipcenter/coregen/coregen_iplist_71i.htm

Regards,
Stephan

 

[Brian Davis]

lecroy7200@chek.com wrote:

There are several layers of ECL before getting to the Xilinx parts

other startup tales (that may not fit your one-of-N AWOL symptoms):

If that's real negative ECL, I have had similar bizarre powerup
problems with both an ancient Altera CPLD and an Atmel AVR, when
residing in a mixed TTL/ECL design:

A temporary failure, or delayed startup, of the +5.0V supply would
allow the -5.2V supply to slightly reverse bias the +5.0V rail.

Under these conditions, when the +5.0V supply did come up,
the CPLD or uC would not initialize properly, until both supplies
were removed and then restarted at the same time.

Also, TTL<->ECL translators can have strange clamp bias paths
into a pin when one supply fails ( IIRC, more of a severe problem
in PECL across boards with a failed supply on one card )

Brian

 

[backhus]

Hi Jan

jandc schrieb:

I wonder if there is any simple way to send the data from a block-ram
to the RS232-interface, without the need to write all the RS232
VHDL-code myself!


There you go. And can we now stop requesting RS232 stuff?

Sorry, but we can't

There are still some packages missing to make it work:

library work;
use work.shift_registers.all;

library nicethings;
use nicethings.ASCII.all, nicethings.overloaded_std_logic_arith.all;

In another posting on
http://www.castalk.com/ftopic211.html
you posted a buffer_procedures package. This package had shifting
procedures with similar names to those expected in the shift_registers
package. Is the shift_registers package a replacement for the
buffer_procedures package?

There are also two packages that can be compiled to nicethings.
(ascii_constants and ascii_functions). Are these former versions of
nicethings ascii and nicethings.overloaded_std_logic_arith??

It would be nice if you could post the missing packages as well, so we
can test your design.

Besides that, your RS232 core looks good and clearly coded, AND is one
of the rare examples that supports RTS/CTS handshaking. I made a similar
thing years ago with schematic entry. The q&d-VHDL port of that is quite
unreadable and not suitable as a vhdl reference design. I would like to
compare these two designs, if only I had the missing packages.


best regards
Eilert Backhus

backhus_who hates spam__at__no spam wanted_isms.hs-bremen.de_where spam
is deleted anyway_

 

If that's real negative ECL, I have had similar bizarre powerup
problems with both an ancient Altera CPLD and an Atmel AVR, when
residing in a mixed TTL/ECL design:

Yes, it's real negative ECL. 100H603s are used for the translation.

A temporary failure, or delayed startup, of the +5.0V supply would
allow the -5.2V supply to slightly reverse bias the +5.0V rail.

Under these conditions, when the +5.0V supply did come up,
the CPLD or uC would not initialize properly, until both supplies
were removed and then restarted at the same time.

This is interesting. During the power supply design, a lot of pain
went into the sequencing. A few of the parts have problems when the
power is not brought up correcly. The problem so far seems to have
happened not during power cycles of the instruments, but while the
instruments are in their normal run mode.

Also, TTL<->ECL translators can have strange clamp bias paths
into a pin when one supply fails ( IIRC, more of a severe problem
in PECL across boards with a failed supply on one card )

It's a good point.

 

[Brian Davis]

This is interesting. During the power supply design, a lot of pain
went into the sequencing.

In attempting to reproduce the problem, are you testing in an actual

system with all boards and I/O connected in the usual configuration,
or in the lab with just the problematic board on a bench supply?

A few of the parts have problems when the power is
not brought up correcly.

Does that result in any symptoms like your FPGA config problem,

or is everything so locked up that you can't tell ?

Without the power-up sequencing, do you get destructive failures?

If not a destructive failure mode, can you briefly disconnect
(not clamp) the +5.0 V supply to the board, with -5.2V present,
and see what level the +5.0V plane on the board goes to?

Or, intentionally disable/break the supply sequencer and power cycle.

The problem so far seems to have happened not during power cycles
of the instruments, but while the instruments are in their normal
run mode.

Do you have an AC disturbance/brownout generator to see how

the supply sequencer for the +5.0 and -5.2 rails behaves during
a brief AC dropout ?

Is one supply rail much more heavily loaded than the other, so it
would dip faster on an AC brownout?

Yes, it's real negative ECL. 100H603s are used for the translation.

Hmmm, that also rings some faint old warning bells- I seem to

recall having problems once after I redesigned a card to replace
some obsolete translators with either the '602 or '603. Symptoms
were field returns with either a failed bit or two on the '60x,
or occasionally a part that looked it like had undergone some sort
of latchup/runaway and self destructed.

Brian