EDK : FSL macros defined by Xilinx are wrong

[Jim Granville]

Austin Lesea wrote:

I have wondered why more regulator chips do not offer this type of
'wide hysteresis' in their operation.

-jg


The problem is how do you tell? A band gap reference takes a lot of
area, and is hard to be accurate in the really deep sub micron
tecnologies. So if you can't measure more accurately that +/-5%, why
bother?

I did say regulator chip, not FPGA .
In the analog realm of regulators this is a no-brainer, all the support
silicon is already there, it just needs a difference in the
enable/disable details.

Regulators/reset generators on FPGA is another topic entirely...
The best indicator of what is possible, are the MOSFET charge based
Vref chips from Xicor (now intersil), and the bigger embedded
controllers, esp towards the Automotive area, where on chip regulators
are more and more common.

Todays FPGAs are such power hogs, that this is less practical, but
on the 'zero power' CPLDs it makes sense to engineer it better than the
present numbers.

-jg

 

[mucikas]

And then jaxato@gmail.com wrote:

My design is microprocessor based, on which 8-bit binary values
representing a picture are written to some region in my block rams. I
would like to know if it is possible to extract those value by using a
program, similar to data2bram, through JTAG out from the FPGA

Jacques

 

[lecroy7200]

The oscillator itself is at a much higher frequency, and is divided down
to the number listed in the data sheet. At least, we still do it that
way, even today.

This is not what the data sheet states. The 4000 data sheet makes a
distinction that it runs at 8MHz and divides down to the 1MHz where the 3000
is at 1MHz. I am not disagreeing with you. I believe that the 3000 was
changed overtime and the clock was part of these changes and now runs at
around 16MHz. The documents were never updated to reflect this change
because it was "transparrent" to the end user. Of course this is all a
guess on my part.

The accuracy of this oscillator would be from 1/2 to 2X the nominal (it
just isn't critical).

Agree, it just needs to work. Too bad it seems to have problems.

Since this part still had paper schematics (REALLY) it is far too old
for us to go look at its design.

Funny, we can still pull up our paper documents if needed. I agree, its
not fun but sometimes you just have to roll up your sleves and dig in.

Phil is on the right track.

This part did have a brownout issue (if the the voltage dropped just
right, for just the right amount of time, and came back up) that would
place it in a locked state that could not be recovered until the power
was cycled.

Again, I read Xilinx's app. note on the brown out problem and it makes it
clear that the part can be reset without removing power. I don't disagree
that the internal logic could get into a locked state and that there was not
a problem with brown out. I also think it is very possible that the current
devices being sold could have a second problem with the internal oscillator.
There is no mention anywhere about the oscillators failing to start or
locking up in the brown out app. note. I am sure if Xilinx would have known
this, it would have been documented and the power cycle requirements would
have been called out, which they are not.

I solved this problem 15 years ago by using a Dallas Semi Power on Reset
part to reset the power supply if it detected a glitch.

Again, power cycling the device, no matter how it could be done, is not an
option for this system.

It sounds like Xilinx is not willing to dig into the root problem of the
oscillator. I can understand this to some degree. After all the software
has not supported the device in several years. So my next question is if
you are able to tell me if the oscillator design used in the currently sold
3000s is being used in other Xilinx devices?

 

[lecroy7200]

Do you recall how low the Vcc had to cycle, in order to correctly
recover ?

As I recall, it had to go below 150 mV to 300 mV to recover.

After testing the second failure, I tried the power cycle test again. The

second part behaved the same as the first. Removing power from the device
and shorting the supply (much less than 150mV) for over 1mS would not cause
the oscillator to restart (observing it with the spectrum analyzer).

 

[Hal Murray]

Just as a reminder, here what Hal Wrote:

I think there is a combined ~prog and done pin. It's pulled low
(open drain) by the 3000 until it gets configured. Power up starts
needing configutation. A high-to-low transition on ~prog asks for
another configuration cycle. If your attempted configuration gets
confused, there is no way to start over until you finish configuration
since ~done is held low so you can't make it go high-to-low.

Configuration starts with a 24 bit bit-count value. After that many
configuration clocks, all the devices in the the chain release
their done pulldown. If one of the devices in the chain gets
(somehow) a low value in that counter you have to cycle through
2**24 cycles to wrap around and finish the current cycle.

My memory if very fuzzy. I think the Reset pin would break
out of that mess. The catch was that the system we were working
on didn't have a way for the CPU that was supplying the bits
to flap Reset.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

 

[Marc Randolph]

lgh wrote:

Am I allowed to change the pin location on the same bank generated by
MIG for my virtex4 design ? Would it not be a hassle or restricted if
I am forced to use the exact pin location for my DDR2 design ? One of
my Virtex4 eval board has it's own fixed DDR2 pins and I would like
MIG to follow those pins constraint. Thanks a lot.

Howdy,

I've not used MIG, so I don't know what kind of placement constraint(s)
it places on the design, but I find it a little hard to believe that
you could only use the set of pins that it chooses. With the
exception, of course, that any clock pins (GCLK and CC_LC/BUFIO pins)
must move to other clock pins.

Good luck,

Marc

 

[Austin Lesea]

lecroy,

If repowering the device will return the part to a state where it can be
programmed, then I have to say it is a bad device.

Trying to infer the operation by sniffing for a oscillator that is the
wrong frequency sounds suspicious.

Austin

lecroy7200 wrote:

Do you recall how low the Vcc had to cycle, in order to correctly

recover ?

As I recall, it had to go below 150 mV to 300 mV to recover.


After testing the second failure, I tried the power cycle test again. The
second part behaved the same as the first. Removing power from the device
and shorting the supply (much less than 150mV) for over 1mS would not cause
the oscillator to restart (observing it with the spectrum analyzer).

 

[lecroy7200@chek.com]

lecroy,

If repowering the device will return the part to a state where it can
be
programmed, then I have to say it is a bad device.

Austin, not to make fun of the situation, but I really have no idea
what you are trying to tell me in this statement.

Trying to infer the operation by sniffing for a oscillator that is
the
wrong frequency sounds suspicious.

Austin

I am sorry, but again I must be missing something. Are you stating
that you don't believe my test results and that looking at the devices
internal oscillator with a spectrum analyzer is not a valid test??

 

[lecroy7200@chek.com]

Well, it's not just any piece of paper, it's the Xilinx published
papers. I agree, it does appear that the documents for this device
were not kept up.

I don't know if the problem is 15 years old or not. Is it tied to when
the oscillators frequency was changed to 16MHz, it is possible. I am
guessing that this happend after 1997 when the 4000 data sheet I have
was published. Again, its all a guess on my part. Xilinx would need
to answer this.

The problem now is how to prevent it with the next design. The first
step is to determine if the design used for the currently sold 3000
series oscillators was used in other devices. If so, I plan to stay
clear of these.

 

[Austin Lesea]

lecroy,

No one changed the frequency of any oscillator.

The layout has been shrinking so as to be able to be fabricated, that is
all.

Did the oscillator go from 8 MHz to 16 MHz over this period of time?

Maybe.

But, for you to infer something from a 16 MHz signal is suspect: does
failure to configure 100% correlate with this signal?

If you power it down, and back on, can it be reprogrammed? If not, it
is a bad part. If it can be reprogrammed, then it is a good part (as
far as configuration is concerned).

If you have a case open with the hotline, what have they said, and what
are they doing?

If you do not have a case open with the hotline, then you should have
one open.

Austin


lecroy7200@chek.com wrote:

Well, it's not just any piece of paper, it's the Xilinx published
papers. I agree, it does appear that the documents for this device
were not kept up.

I don't know if the problem is 15 years old or not. Is it tied to when
the oscillators frequency was changed to 16MHz, it is possible. I am
guessing that this happend after 1997 when the 4000 data sheet I have
was published. Again, its all a guess on my part. Xilinx would need
to answer this.

The problem now is how to prevent it with the next design. The first
step is to determine if the design used for the currently sold 3000
series oscillators was used in other devices. If so, I plan to stay
clear of these.

 

[Jim Granville]

lecroy7200@chek.com wrote:
<snip>

So far there is 100% correlation of the failure, but we are only
talking one data point. I can also tell you that once I reset the
power that the 16MHz signal for that device was present (again which it
was not while in this failed state) and the part began to function
normally.

The oscillator locking fits with what I am seeing, not being able to
reprogram the devices.

I would expect (generally speaking) a Config Ring osc to gate itself
off, after config is completed.
What does a normally operating device show - does this osc appear
to gate in normal usage ?

If you power it down, and back on, can it be reprogrammed?


Again, this depends what you mean. Looking at the power on the device,
I can bring it below what I can detect for over 1mS and turn it back on
and the part will not allow me to reprogram it. Nor will the
oscillator start running. I have to remove power for a much longer time
in order for the oscillator to start and allow me to reprogram. This
appears to be the case with all six failures I have seen, in that they
need the power removed for several seconds inorder to recover.

It may pay to get a closer number on that - < 5 seconds and > 1ms is
quite wide...
Most vanilla buried POR cells are RC in nature (tho the R may be a
FET ), and they will have a TIME as well as a voltage requirement for
reset. Austin has given ~150mV-350mV region as voltage, but no one
have a time value yet.

You could ask Xilinx explicitly if newer devices have any buried POR
cells, that are not also replicated by a RESET ?

I would expect this type of oops to be eliminated

-jg

 

[Austin Lesea]

lecroy,

I have found the case, and the CAE assigned, and I am working with
Peter to resolve this.

So, your support for this issue is now Peter Alfke and Austin Lesea.
All I can say is that if we can't help you, then no one can, so you can
not complain about not getting the best resources assigned to the job!

Basically, as an officially usupported part (end of life, last time buy
status, etc. ...), we will do what we can.

Peter and I are the only ones here who remember anything about the XC3000.

The hotline was unable to follow through on this due to the age of the
part, and the total lack of information on it. In future, we will
provide the hotline for a way to deal with this other than just getting
frustrated.

I apologize for that on the part of Xilinx. It is a situation that we
had not anticipated (support of an obsolete product).

I suggest we move this off of this forum.

Austin

 

[Jim Granville]

lecroy7200 wrote:

<snip>

It may pay to get a closer number on that - < 5 seconds and > 1ms is
quite wide...


Yes I agree, except I am not sure what value this information is. Next time
I reproduce the problem, I will measure it.

You may have to document this, for those units in the field, plus if
you decide to retro-fit a power removal WDOG, this will be an important
number for that design.

-jg

 

[lecroy7200]

I have found the case, and the CAE assigned, and I am working with
Peter to resolve this.

So, your support for this issue is now Peter Alfke and Austin Lesea.
All I can say is that if we can't help you, then no one can, so you can
not complain about not getting the best resources assigned to the job!

Thanks!! You should now have my contact information. Feel free to use this.

Basically, as an officially usupported part (end of life, last time buy
status, etc. ...), we will do what we can.

I am hopeful it will get resolved one way or another.

I suggest we move this off of this forum.

I look forward to working with you and Peter on this.

 

[Peter Alfke]

lecroy7200 wrote:

I have found the case, and the CAE assigned, and I am working with
Peter to resolve this.

Wow, I was gone for 2 weeks, and here is a 52-thread mushroom.

I joined Xilinx early 1988, when the XC3020 was being announced, and I
was responsible for applications, technical support and all device
documentation. I also started a quarterly magazine called Xcell (still
alive) and wrote a 1.3-page article "The Effect of Marginal Supply
Voltage" (Xcell#6, 4Q90, and reprinted in edited form in every
databook up to 1994) Don't google it, you get only one valid hit, and
it is in Russian. The last paragraph may be relevant here:

"...The XC3000 stays configured for small dips, and is smart enough
to reconfigure itself (if a master) or to ask for reconfiguration by
pulling INIT and D/P Low (if a slave). XC3000 will not lock up; the
user can initiate reconfiguration at any time by pulling D/P Low, or,
if D/P is Low already, by forcing a High-to-Low transition on
RESET..." NOTE: IT SAYS: HIGH-TO-LOW TRANSITION ON RESET.

Then follows a description of brown-out (as Phil Freidin mentioned) but
that only relates to early XC2000, which lack the circuit that responds
to the High-to-Low transition on RESET. Once Vcc has dropped below 2 V,
these chips need a very low voltage (<0.1V) on Vcc before they can be
reconfigured. But that was early XC2000, not XC3000.

I very much doubt that the XC3000 can spontaneously unconfigure itself.
In those days we shipped tens of thousands of parts per week, today we
ship millions per week. If our devices were unreliable, Xilinx would be
out of business. And we obviously are not!

After 45 years in this profession, I have formulated Peter's Rule:
"If a problem is so obscure that it defies solution by the smartest
and most helpful engineers, then the real cause is most likely so
primitive and basic that nobody stooped low enough to see it"
So, check the power supply, the connectors, the traces and solder
joints and decoupling capacitors. And check for transients on any pin.
I am sure the problem is outside the chip. And please try the
High-to-Low transition on RESET.

Peter Alfke, Xilinx Applications

 

[lecroy7200@chek.com]

Seeing that you have decided to continue to post to the public thread
rather than contact me directly, I will assume that this is how you
wish to handle this issue.

"...XC3000 will not lock up; the
user can initiate reconfiguration at any time by pulling D/P Low, or,
if D/P is Low already, by forcing a High-to-Low transition on
RESET..." NOTE: IT SAYS: HIGH-TO-LOW TRANSITION ON RESET.

I have read this document and I agree that this is what it states. If
you had taken the time to read all of the posts, you would notice that
this was one of the first things I had verified.

I very much doubt that the XC3000 can spontaneously unconfigure
itself.

I am only posting what I am seeing. You can choose to agree or disagree
or even roll up your sleeves and check for yourself.

In those days we shipped tens of thousands of parts per week, today
we
ship millions per week. If our devices were unreliable, Xilinx would
be
out of business. And we obviously are not!

It would be interesting to see how many of the 3000 series devices are
sold. Regardless, I really don't care about the companies track record
at this point.
I am having a specific problem with a specific device and the question
is how best to handle it. If Xilinx does not want to be part of the
problem solving, this is fine.

After 45 years in this profession, I have formulated Peter's Rule:
"If a problem is so obscure that it defies solution by the smartest
and most helpful engineers, then the real cause is most likely so
primitive and basic that nobody stooped low enough to see it"

Now this is an arrogant statement! You are entitled to your opinions
of your customers and yourselves.

So, check the power supply, the connectors, the traces and solder
joints and decoupling capacitors. And check for transients on any
pin.
I am sure the problem is outside the chip. And please try the
High-to-Low transition on RESET.

Your way behind on what has been done to determine the root cause of
this problem. It is a shame that you have decided to take what I would
consider the unprofessional route of pointing the finger at your
customer rather than trying to understand what has been done to
identify the problem. If you do decide that your would like to try and
work with us to solve this issue, I am more than willing to share with
you everything I have seen to date.

In the mean time I plan to continue with my testing to determine if
there is a reliable way to detect the fault.

 

[Jim Granville]

lecroy7200@chek.com wrote:

Seeing that you have decided to continue to post to the public thread
rather than contact me directly, I will assume that this is how you
wish to handle this issue.

I think Peter posted here, because there was a large thread, and he was
back from a 2 week absence.

<snip>

Your way behind on what has been done to determine the root cause of
this problem. It is a shame that you have decided to take what I would
consider the unprofessional route of pointing the finger at your
customer rather than trying to understand what has been done to
identify the problem. If you do decide that your would like to try and
work with us to solve this issue, I am more than willing to share with
you everything I have seen to date.

If you want Xilinx to assist on support for an EOL device, you could
try to not annoy them ?

In the mean time I plan to continue with my testing to determine if
there is a reliable way to detect the fault.

IIRC you have seen this ~6 times. Do you have a 'feel' yet for the
correlating cause, over those 6 times - any common event or stimulus ?

Even tho this is an EOL device, the reason to try and nail this is to
check that no new devices have the same issue.

-jg

 

[lecroy7200@chek.com]

Jim Granville wrote:

lecroy7200@chek.com wrote:

Seeing that you have decided to continue to post to the public
thread
rather than contact me directly, I will assume that this is how
you
wish to handle this issue.

I think Peter posted here, because there was a large thread, and he
was
back from a 2 week absence.

I agree that it is a lot to take in. I will not comment on why Peter
felt he should post to the group. That was his choice to make. I was
under the impression from Austin's last post that we would handle this
outside of a public group.

If you want Xilinx to assist on support for an EOL device, you could
try to not annoy them ?

Sorry you feel this way Jim. The goal here was certainly not to do so.
I am only presenting my findings. If my findings do not match up with
what Xilinx has published or stated in the group, I will point it out.
How they react to that is up to them. If your refering to my posting
on how the hotline was handled, remember that it was Xilinx who asked
for this information in a public group. Up till then I only posted
that I had been having little to no responce from them.

In the mean time I plan to continue with my testing to determine if
there is a reliable way to detect the fault.

IIRC you have seen this ~6 times. Do you have a 'feel' yet for the
correlating cause, over those 6 times - any common event or stimulus
?

Yes, you are correct in that I have seen the failure six times now. At
this time everything still appears to be random, but again I have only
duplicated the problem twice from when I started posting. It's not a
lot of data to draw a conclusion from. I am trying everything I can to
cause the parts to get into this mode, but nothing I do seems to effect
it. The only thing I have a "feel" about is the internal oscillator
dropping out. If I reproduce the problem and the oscillator drops out
as before I will have a lot more confidence that this is why the part
can not recover.

Even tho this is an EOL device, the reason to try and nail this is to
check that no new devices have the same issue.

There are two items that need to be addressed. The first and most
important is to minimize the effect this will have on our customers.
That is why my focus is on finding a way to detect the failure (with no
changes to the hardware). The second reason is to minimize our risk in
future designs.

 

[Jim Granville]

Antti Lukats wrote:

Hi

http://wiki.openchip.org/index.php/OpenChip:FpgaFreqMeter

there is prelimary info about Application that turns any FPGA into 8 channel
frequency meter -
all you need is FPGA and download cable (and the Frequency meter SW
application of course)

initial support is for Xilinx FPGA's only, Altera/Lattice will be added
later

Impressive.
Can you add to your web pages, a brief overview of the design, covering
- Appx MAX Ctr limit, either from SW estimate, or from a bench test
(typ), and the LOGIC resources used

- Counter performance, typically digits/second for reciprocal Ctrs,
or simply gate times and count rates, for the really vanilla ones ?

- Output choices - your examples seem to be PC-centric. Any options
for LCD module output ( as on some eval PCBs ?)

jg

 

[genlock]

Yes the decimal number is a constant value.

What do you mean by embedded multipliers?

Is there a VHDL code available for that or how do we go about coding
one.

I dont need a clock for this one.

Thankyou