EDK : FSL macros defined by Xilinx are wrong

[Jeremy Stringer]

Peter Alfke wrote:

Less! That's the whole idea...
But watch whether your package and density is available. If it is, it
will be chaeper.

What about similar packages - for instance, a S3-1500 vs a S3E-1600?

Jeremy

 

[Jeremy Stringer]

A Beaujean wrote:

Pardon me if I am presently missing a very simple way to tell the tool
"Please do not use one of your GCLK resources", but I am not a very
frequent user of VHDL and had no chance to go to any advanced seminar
of any kind.

A solution to that problem ?

Please answer if you are aware of some.

If you are using synplify, you can use the syn_noclockbuf constraint.

Jeremy

 

[Austin Lesea]

Jeremy,

The Spartan 3E represents a relayout, with improved design rules, and
other optimizations to reduce area, improve yield, and overall reduce
the cost.

One family is optimized for logic per $, and the other is optimized for
IO per $.

If both families have the logic, and the IO needed to do you
application, then I would say that the new 3E family will have the $
edge since it is the third generation 90nm product in the line.

Austin

 

[Kolja Sulimma]

Sea Squid wrote:

I found PP is unable to drive such LEDs, which needs 20mA, but what is the
converter chip I shall order?
Any logic would be rather inconvenient because there is no power supply

at the parallel port.
The parallel port can drive at least 2mA which is not extremly bright
but visible for most leds. Just connect a series resistor of 300 ohms or
so to each LED.

Kolja Sulimma

 

Yesterday was another loss.

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?

All of the testing is being done with the real hardware.

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 ?

No, it could result in device failure. But not on this board.

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

Based on textbook data, yes. Have I seen a problem, no. Again, a lot
of care was taken to ensure this could not happen.

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?

I did several tests with the supplies yesterday. No damage to the
board it would appear, but I also was not able to reproduce the
problem.

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

I tried drop out testing on all supplies in every combination. The ECL
seemed to have little problem with the testing I did.

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 ?

Yes we do, and again we have done a lot of testing like this and have
not seen any problems like the one I am describing.

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.

I am VERY surprized that I have not seen a destructive failure with all
the testing I have done.

If I were to make a guess, it's like the Xilinx device goes into sleep
mode somehow and won't wake back up. But again, while testing the
power down pin I was not able to replicate the problem.

No word from Xilinx yet.

 

[Jim Granville]

lecroy7200@chek.com wrote:

Yesterday was another loss.


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?


All of the testing is being done with the real hardware.

Have you done aggressive field (impulse & RF burst) testing yet ?
This would be on as near a real field-install as practical.

Do you have a stats map, of the failure count/installed unit/site/time ?
[ ie these are truly random failures ?]

When all else fails, you can always blame Alpha particles ?
( see this highly selective test
http://www.actel.com/company/press/2005pr/RadiationReliability.html )

-jg

 

[Nemesis]

Mentre io pensavo ad una intro simpatica "Stephan Neuhold" scriveva:

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

Thanks, that's exactly what I was looking for.
--
Brain dysfunction detected...

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

 

[Wing Fong Wong]

more <fengmingxin_714@hotmail-dot-com.no-spam.invalid> wrote:

Hello,

I am doing my thesis on Xilinx ML310 board. My target is to
realise the real-time image processing. First I have to find the port
where I can input the captured data. I am going to use the usb port on
MD1535D+ south bridge. To access this south bridge I need to access
the PCI bus since it is connected to the PCI. I have installed the
PCI v3.0 logicore but when I create a project, I can't find this PCI
v3.0 logicore to add into my project. Does anyone know how to access
this PCI v3.0 logicore?

Much appreciate for your kindly help!

Hey, I doing pretty much the same thing, image processing on the ML310!
Unlike you, I decided to use the personality module connectors. The
connectors appear to connect directly to the FPGA. Its simpler
to use that than USB, unless of course your data source is being streamed
via USB then its a whole different story.

As a side not does anyone know where I can get Tyco's Z-Dok connectors
that are used in the ML310? I need the recepticals.

--

Wing Wong.

 

[Jens Baumann]

rgebru wrote:

Hi,

I'm thinkin go of designing a heating/cooling system with VHDL and
need to interface my Spartan 3 board to a real temp sensor. Does
anyone have an idea of how I can do this?

Thanks!!

There are several temperature sensors with i2c interface. They should easily
be connected to your board.

http://www.google.de/search?hl=en&q=i2c+temperature+sensor

Jens

 

[Aurelian Lazarut]

Marc,

DDC stand for Down Digital Convertor (DSP core)

Aurash

Marc Randolph wrote:

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

--
__

 

[design]

Hi henrik
I am not sure but is this got something to do with the DONE pin not
going high. I dont know abt platform studio but then with Project
navigator there is a setting which drives the done pin high that is if
the done pin in the circuit is not connected to a pullup resistor.
Hope this helps.

 

[Marc Randolph]

Aurelian Lazarut wrote:

Marc,

DDC stand for Down Digital Convertor (DSP core)

Ahhh, yes - thank you. RF is a little out of my field... my telecom
experience revolves around wireline and fiber, so to stops a little
short of the base-stations.

And thank you to Stephan Neuhold for pointing out where Xilinx has put
up a comprehensive list of their cores online.

Have fun,

Marc

 

[Brendan Cullen]

Hi Swamy,

swamydp@yahoo.com wrote:

Hello Brendan

Thanks for the reply. When we enter a frequency for the primary input
in Xpower, for example 1 Mhz, does it consider the input to be a square
wave ?

Yes.

My primary inputs do not toggle every cycle, so the term
"frequency" is confusing to me. any clarification is greatly
appreciated.

I'd suggest assessing your primary i/ps' average transition rate over a
period of time and inferring frequencies from that.

Brendan

Thanks
swamy

Brendan Cullen wrote:
Hi Swamy,

swamydp@yahoo.com wrote:

Hi

what algorithm does xpower use to calculate the freqency of
internal
nodes in a netlist ? is it some kind of transition density
propagation
but that method requires activity factor for primary inputs and
also
probabilities of primary inputs.

Also is the interconnect power dissipation taken into account ?

The most basic method is through user i/p. Others include importing
simulation information and also the use of a probability algorithm in
how
primary i/ps are propagated.

The interconnect power dissipation is definitely taken into account.

Brendan



Thanks for any help
swamy

 

[Henrik Koksby Hansen]

[...]

Hi henrik
[...]

Hello, design?

I am not sure but is this got something to do with the DONE pin not
going high. I dont know abt platform studio but then with Project
navigator there is a setting which drives the done pin high that is if
the done pin in the circuit is not connected to a pullup resistor.
[...]

Yeah, but I can't seen to find any settings that does this. I am
pretty new to this.
Anyways, I powered off the board and soldered a 10kOhm resistor from
the DONE-pin to Vcc. And it actually worked after I powered it on
again and programmed it.

Hope this helps.
[...]

I hope so too. Only time will show if the pull-up resistor did the
trick. ;-)



--
Henrik

 

Have you done aggressive field (impulse & RF burst) testing yet ?

Again, yes.

This would be on as near a real field-install as practical.

Do you have a stats map, of the failure count/installed
unit/site/time ?
[ ie these are truly random failures ?]

Again, yes they are random.

When all else fails, you can always blame Alpha particles ?

No, this is not an option.

After running an automated test for the last 24 hours, finally one part
on my test unit failed. Because the software would try and program the
devices after a fixed amount of time in order to detect the fault, I am
not sure if the pins were in this state at the time of the failure.
However, Looking at the the control pins, HDC is high, LDC is low,
done/pgm' is low and init is low.

I increased the reset time to over a second with no luck. I tried
reloading the device over 50 times with no luck. This is what we are
seeing. I am not sure why it entered this mode and if it had anything
to do with my testing, or was just its time.

I have left the device in this state is anyone has ideas on further
test.

 

After waiting an hour for Xilinx to return my phone call, I decided to
attempt further tests. From previous failures it seemed that the
supply had to be turned off for a long time in order to recover from
this failure. Using the dual FET test setup I started pulseing the
power to the FPGAs. Using a scope which was connected to the device, I
started out pulsing the power off for 10uS. I then tried to program
the device 5 times. The device was in the same state, so I increased
the off time and repeat the process. At 1ms (0.001 seconds) the part
would still not recover. Thinking that the device may have actually
been damaged I decided to try a much longer power cycle of about 5
seconds and sure enough, the part came back to life.

Of course, none of this helps me. I have started another test where I
do not attempt to reprogram the devices. This will allow me to
determine the state of the control pins prior to attempting the reload.


I am starting to suspect that the devices internal oscillator has a
problem. There is very little information about it. There appears to
be no way to detect it's failure. Has anyone seen any detailed
information about how the oscillator was designed? Was the same design
used for all Xilinx devices? I am thinking to try and detect the
internal oscillator with a spectrum analyzer.

 

[Jim Granville]

lecroy7200@chek.com wrote:

I have left the device in this state is anyone has ideas on further
test.

You could measure Icc, to try and guage how much of the Clock tree
is operational, and compare that with a device that is held in
config-ready state ?
Also see if some of the simplest pin-pin paths are still 'alive'.
[ but, of course, be careful not to remove the power ]

Your description thus far sounds like it is flipping back into
part-way through a config cycle, but in such a way re-config
cannot shake it loose.

-jg

 

[Jim Granville]

lecroy7200@chek.com wrote:

After waiting an hour for Xilinx to return my phone call, I decided to
attempt further tests. From previous failures it seemed that the
supply had to be turned off for a long time in order to recover from
this failure. Using the dual FET test setup I started pulseing the
power to the FPGAs. Using a scope which was connected to the device, I
started out pulsing the power off for 10uS. I then tried to program
the device 5 times. The device was in the same state, so I increased
the off time and repeat the process. At 1ms (0.001 seconds) the part
would still not recover. Thinking that the device may have actually
been damaged I decided to try a much longer power cycle of about 5
seconds and sure enough, the part came back to life.

Of course, none of this helps me.

It does confirm that there is an internal RC style Reset block, that has
a recovery somewhere between 1ms and 5 sec.

It could be usefull to narrow that Trec ( and also Vrec) down more.
For example, I have seen devices that state "Vcc must reduce to less
than 0.2V for POR to operate correctly"

I have started another test where I

do not attempt to reprogram the devices. This will allow me to
determine the state of the control pins prior to attempting the reload.


I am starting to suspect that the devices internal oscillator has a
problem. There is very little information about it. There appears to
be no way to detect it's failure. Has anyone seen any detailed
information about how the oscillator was designed? Was the same design
used for all Xilinx devices? I am thinking to try and detect the
internal oscillator with a spectrum analyzer.

good idea.

-jg

 

[Philip Freidin]

On 18 Mar 2005 12:09:04 -0800, lecroy7200@chek.com wrote:

After running an automated test for the last 24 hours, finally one part
on my test unit failed. Because the software would try and program the
devices after a fixed amount of time in order to detect the fault, I am
not sure if the pins were in this state at the time of the failure.
However, Looking at the the control pins, HDC is high, LDC is low,
done/pgm' is low and init is low.

I increased the reset time to over a second with no luck. I tried
reloading the device over 50 times with no luck. This is what we are
seeing. I am not sure why it entered this mode and if it had anything
to do with my testing, or was just its time.

I have left the device in this state is anyone has ideas on further
test.

Great.

As I have read further, you no longer have it in this state.
Assuming you get it into this failed state again, please try the followig 2 things:

1) supply a continuous CCLK, with DIN alternating 0 and 1. Please tell us what
you see on the DOUT pin.

2) Supply a continuous CCLK for at least 2**24 cycles (16 million cycles) plus
a few extra 100000 cycles. At 1 MHz, this will take about 16 seconds. Set
DIN to 1 for all of this. Please report any changes you observe on Done/Prog,
HDC, LDC, and DOUT. There is a "fault " mode where if it gets some clock
cycles that are unexpected at the beginning, or corruption of the header
it can take 16000000 clocks for it to get back to the beginning of the
state sequence.


I am suspecting that the note by Hal Murray of a week ago may be occuring,
although your observation are also in line with guess of Brownout.

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.

Keep working on it,
Philip



Philip Freidin
Fliptronics

 

[Marc Randolph]

Preben Holm wrote:

Hi everyone,
[...]

Really a comp.lang.vhdl question, but since you're here... at the
beginning of your process (right after the begin), I think you'd want a
default assignment for next_state:

next_state <= current_state;

This will make it obvious to the tools that they should remain in the
current state unless one of the following conditions turns out to be
true.

stateTransitions : process(current_state, holdoff, read,
trig)
begin
-- stateStart
if current_state(0) = '1' then
hold <= '0';

if holdoff = '0' and read = '0' and trig = '0' then
next_state <= stateWait;
end if;
end if;

[...]
WARNING:Xst:737 - Found 5-bit latch for signal <next_state>.
Found 5-bit register for signal <current_state>.

The latch warning for next_state is your clue.

Good luck,

Marc