EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

EDK : FSL macros defined by Xilinx are wrong

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - EDK : FSL macros defined by Xilinx are wrong

Goto page Previous  1, 2, 3 ... , 356, 357, 358  Next


Guest

Tue Jan 24, 2017 12:04 am   



On Wednesday, March 28, 2012 at 1:31:41 PM UTC-4, Elam wrote:
Quote:
I understand that the price depends on the volume etc
but I would like to know the per unit price of Virtex 7 FPGA..

Any guesses..

Thanks
Elam.


Elam,
We can save you substantially off of the Xilinx or Avnet screen pricing on most Xilinx.
John.Pallazola_at_earthtron.com

rickman
Guest

Tue Jan 24, 2017 7:58 am   



On 3/11/2014 5:32 PM, langwadt_at_fonz.dk wrote:
Quote:
Den tirsdag den 11. marts 2014 22.23.36 UTC+1 skrev Jon Elson:
GaborSzakacs wrote:







A quick DigiKey search showed a range of $2,583.75 (XC7VX330T-1FFG1157C)

to $39,452.40 (XC7V2000T-G2FLG1925E). These won't end up in any of my

designs any time soon.



REALLY! 1900 balls, and all of them have to solder perfectly or the chip

has to come off and be re-balled! Arghhhh! I'd LOVE to know who is

actually USING chips that expensive. Must be the military in those

$500 Million airplanes.

Jon

if it does the job of an asic that would require a million dollar NRE and
you only need 20 it's a bargain


One place I worked at used a very expensive Xilinx device (not sure just
how bad it was, I think $1,500 in around 2000) when only 20% was being
used. Room for expansion in a $100,000 product. It was test equipment
and I think they only sold a couple of handfulls.

--

Rick C

rickman
Guest

Tue Jan 24, 2017 8:02 am   



On 4/2/2012 7:55 PM, Ed McGettigan wrote:
Quote:
On Mar 28, 10:31 am, Elam <elampoora...@gmail.com> wrote:
I understand that the price depends on the volume etc
but I would like to know the per unit price of Virtex 7 FPGA..

Any guesses..

Thanks
Elam.

There are too many variables (device, package, speed grade, volume,
delivery date, etc..) involved in pricing for any simple answer.
Contact your local Xilinx sales rep and they would be happy to sit
down and discuss your needs and come up with the right pricing that
matches your situation.
http://www.xilinx.com/company/contact/sales-reps.htm

Using online pricing data for 1-10 parts today will not be reflective
of 1K-10K pricing 18 months from now.


No only do prices vary on a lot of factors, prices are *always* cheaper
(sometimes *much* cheaper) if you give them a design win using their new
product line. They barely care about new sockets using old parts, even
one generation old. It's all about paying for the NRE on the new
product line. If you are buying even just 10k per year, you can get a
great discount typically, much better than the online prices.

--

Rick C


Guest

Fri Feb 17, 2017 5:06 pm   



Quote:
I suppose one could tweak Vcc vs temp to null out a native tempco.


I am not an expert in this field either, but to my knowledge, things got much more complex with the smaller process geometries.

Generally things will still become faster at higher supply voltage and lower temperature, but I had also designs which (according to the timing analyzer) passed at 85°C but failed at 0°C.

Regards,

Thomas

www.entner-electronics.com - Home of EEBlaster and JPEG CODEC


Guest

Tue Mar 28, 2017 12:22 pm   



On Friday, February 7, 2003 at 7:02:37 PM UTC+5:30, llaa57 wrote:
Quote:
I implemented the circuit described in the application note "Unusual
clock dividers" written by Peter Alfke:
http://www.xilinx.com/xcell/xl33/xl33_30.pdf.
I used a Xilinx XC9536 and the input clock is generated by an
oscillator (SCO-061S 48MHz) by Sunny.
My problem is that the output clock's duty cycle is 33% and not 50% as
expected. Why? Is the CPLD unsuitable for this circuit?

Many thanks in advance.


Hi All,
I'm trying to implement the frequency divider of 1.5 for 100mhz clock frequency. i need to obtain 65mhz as output. i'm using xc6slx16 fpga..could anyone help me with vhdl codes for the above..No problem with duty cycle..

Thanks all.

Uwe Bonnes
Guest

Tue Mar 28, 2017 4:46 pm   



vjkaran19_at_gmail.com wrote:
Quote:
On Friday, February 7, 2003 at 7:02:37 PM UTC+5:30, llaa57 wrote:
I implemented the circuit described in the application note "Unusual
clock dividers" written by Peter Alfke:
http://www.xilinx.com/xcell/xl33/xl33_30.pdf.
I used a Xilinx XC9536 and the input clock is generated by an
oscillator (SCO-061S 48MHz) by Sunny.
My problem is that the output clock's duty cycle is 33% and not 50% as
expected. Why? Is the CPLD unsuitable for this circuit?

Many thanks in advance.

Hi All,
I'm trying to implement the frequency divider of 1.5 for 100mhz clock frequency. i need to obtain 65mhz as output. i'm using xc6slx16 fpga..could anyone help me with vhdl codes for the above..No problem with duty cycle..

Thanks all.


Capturing a thread that old is evil!

Why don' you start a new thread?

100 /1.5 != 65?

For a 66,666_ clock, use a DCM clock module and first multiply by 2 and then
divide by 3.

Bye
--
Uwe Bonnes bon_at_elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------


Guest

Wed Mar 29, 2017 6:41 am   



On Friday, February 7, 2003 at 7:02:37 PM UTC+5:30, llaa57 wrote:
Quote:
I implemented the circuit described in the application note "Unusual
clock dividers" written by Peter Alfke:
http://www.xilinx.com/xcell/xl33/xl33_30.pdf.
I used a Xilinx XC9536 and the input clock is generated by an
oscillator (SCO-061S 48MHz) by Sunny.
My problem is that the output clock's duty cycle is 33% and not 50% as
expected. Why? Is the CPLD unsuitable for this circuit?

Many thanks in advance.



Hi,
Thanks to all..

Kevin Neilson
Guest

Tue Apr 11, 2017 6:29 pm   



On Monday, April 10, 2017 at 7:13:23 PM UTC-6, John Larkin wrote:
Quote:
We have a ZYNQ whose predicted timing isn't meeting decent margins.
And we don't want a lot of output pin timing variation in real life.

We can measure the chip temperature with the XADC thing. So, why not
make an on-chip heater? Use a PLL to clock a bunch of flops, and vary
the PLL output frequency to keep the chip temp roughly constant.


I'm confused by the concept. Doesn't timing get *worse* as temp increases? How would a higher temperature help? By "output pin timing variation" do you mean that there are combinatorial output paths? I think the best best is to stay as cool as possible and keep all outputs registered. If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.

I have used precision oscillators with built-in heaters. In that case, it's more important that the crystal stay at a constant temp than what the temp is. By making that temperature above the highest possible ambient temp, the heater can keep the crystal temp constant.

Kevin Neilson
Guest

Tue Apr 11, 2017 6:31 pm   



Quote:
https://dl.dropboxusercontent.com/u/53724080/Thermal/ESM_Ring_Oscillator.jpg

The change in prop delay vs temp is fairly small.


That's more linear than I would've guessed. Is that the ambient temperature or junction temp?

John Larkin
Guest

Wed Apr 12, 2017 7:30 am   



On Tue, 11 Apr 2017 09:29:03 -0700 (PDT), Kevin Neilson
<kevin.neilson_at_xilinx.com> wrote:

Quote:
On Monday, April 10, 2017 at 7:13:23 PM UTC-6, John Larkin wrote:
We have a ZYNQ whose predicted timing isn't meeting decent margins.
And we don't want a lot of output pin timing variation in real life.

We can measure the chip temperature with the XADC thing. So, why not
make an on-chip heater? Use a PLL to clock a bunch of flops, and vary
the PLL output frequency to keep the chip temp roughly constant.

I'm confused by the concept. Doesn't timing get *worse* as temp increases?


Prop delays get slower.

> How would a higher temperature help?

High temperature is an unfortunate fact of life some times. I'm after
constant temperature, to minimize delay variations as ambient temp and
logic power dissipations change.

> By "output pin timing variation" do you mean that there are combinatorial output paths? I think the best best is to stay as cool as possible and keep all outputs registered.

All our critical outputs are registered in the i/o cells. Xilinx tools
report almost a 3:1 delay range from clock to outputs, over the full
range of process, power supply, and temperature. Apparently the tools
assume the max specified Vcc and temperature spreads for the part and
don't let us tease out anything, or restrict the analysis to any
narrower ranges.


Quote:
If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.


Our output data-valid window is predicted by the tools to be very
narrow relative to the clock period. We figure that controlling the
temperature (and maybe controlling Vcc-core vs temperature) will open
up the timing window. The final analysis will have to be experimental.

We can't crank in a constant delay to fix anything; the problem is the
predicted variation in delay.

Quote:

I have used precision oscillators with built-in heaters. In that case, it's more important that the crystal stay at a constant temp than what the temp is. By making that temperature above the highest possible ambient temp, the heater can keep the crystal temp constant.


That's the idea, keep the FPGA core near the max naturally-expected
temperature, heat it up as needed, and that will reduce actual timing
variations to below the worst-case predicted by the tools.

I expect that the tools are grossly pessimistic. I sure hope so.



--

John Larkin Highland Technology, Inc

lunatic fringe electronics

rickman
Guest

Wed Apr 12, 2017 7:30 am   



On 4/11/2017 12:31 PM, Kevin Neilson wrote:
Quote:

https://dl.dropboxusercontent.com/u/53724080/Thermal/ESM_Ring_Oscillator.jpg

The change in prop delay vs temp is fairly small.


That's more linear than I would've guessed. Is that the ambient temperature or junction temp?


Even if it wasn't especially linear, the proportionality is based on
degrees Kelvin. So the non-linearity would not be terribly pronounced.

That was part of the reason for the inflate-gate thing a couple of years
ago. I remember that between the pressure being relative rather than
absolute and the temperature being Celsius or Fahrenheit rather than
Kevin, the people here took some time to figure out that the reported
pressures were easily explained by the difference in temperature between
the locker rooms and the playing field.

--

Rick C

rickman
Guest

Wed Apr 12, 2017 7:30 am   



On 4/11/2017 11:37 PM, John Larkin wrote:
Quote:
On Tue, 11 Apr 2017 09:29:03 -0700 (PDT), Kevin Neilson
kevin.neilson_at_xilinx.com> wrote:

On Monday, April 10, 2017 at 7:13:23 PM UTC-6, John Larkin wrote:
We have a ZYNQ whose predicted timing isn't meeting decent margins.
And we don't want a lot of output pin timing variation in real life.

We can measure the chip temperature with the XADC thing. So, why not
make an on-chip heater? Use a PLL to clock a bunch of flops, and vary
the PLL output frequency to keep the chip temp roughly constant.

I'm confused by the concept. Doesn't timing get *worse* as temp increases?

Prop delays get slower.

How would a higher temperature help?

High temperature is an unfortunate fact of life some times. I'm after
constant temperature, to minimize delay variations as ambient temp and
logic power dissipations change.

By "output pin timing variation" do you mean that there are combinatorial output paths? I think the best best is to stay as cool as possible and keep all outputs registered.

All our critical outputs are registered in the i/o cells. Xilinx tools
report almost a 3:1 delay range from clock to outputs, over the full
range of process, power supply, and temperature. Apparently the tools
assume the max specified Vcc and temperature spreads for the part and
don't let us tease out anything, or restrict the analysis to any
narrower ranges.


If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.


Our output data-valid window is predicted by the tools to be very
narrow relative to the clock period. We figure that controlling the
temperature (and maybe controlling Vcc-core vs temperature) will open
up the timing window. The final analysis will have to be experimental.

We can't crank in a constant delay to fix anything; the problem is the
predicted variation in delay.


I have used precision oscillators with built-in heaters. In that case, it's more important that the crystal stay at a constant temp than what the temp is. By making that temperature above the highest possible ambient temp, the heater can keep the crystal temp constant.

That's the idea, keep the FPGA core near the max naturally-expected
temperature, heat it up as needed, and that will reduce actual timing
variations to below the worst-case predicted by the tools.

I expect that the tools are grossly pessimistic. I sure hope so.


The nature of designing synchronous logic is that you want to know the
worst case delay so you can design to a constant period clock cycle. So
the worst case is the design criteria. The timing analysis tools are
naturally "pessimistic" in that sense. But that is intended so that the
design process is a matter of getting all timing paths to meet the
required timing rather than trying to compare delays on this path to
delays on that path which would be a nightmare.

When you need better timing on the I/Os, as you have done, the signals
can be clocked in the IOB FFs which give the lowest variation in timing
as well as the shortest delays from clock input to signal output.
Typically I/O timing also needs to be designed for worst case as well
because the need is to meet setup timing while hold timing is typically
guaranteed by the spec on the I/Os. But if you are not doing
synchronous design this may not be optimal. If you are trying to get a
specific timing of an output edge, you may have to reclock the signals
through discrete logic.

--

Rick C

colin
Guest

Wed Apr 12, 2017 9:54 am   



Our biggest box takes about a kilowatt, which includes 70W for the fans. We build enough of them, which run 24/7, to work out the total cost of ownership and running the box a little bit hotter reduces reliability a bit but saves enough electricity to make it worthwhile.

Colin

John Larkin
Guest

Wed Apr 12, 2017 5:58 pm   



On Tue, 11 Apr 2017 09:31:20 -0700 (PDT), Kevin Neilson
<kevin.neilson_at_xilinx.com> wrote:

Quote:

https://dl.dropboxusercontent.com/u/53724080/Thermal/ESM_Ring_Oscillator.jpg

The change in prop delay vs temp is fairly small.


That's more linear than I would've guessed. Is that the ambient temperature or junction temp?


Foil-sticky thermocouple on the top of the chip. It was an Altera
Cyclone 3, clocked internally at 250 MHz.

https://dl.dropboxusercontent.com/u/53724080/PCBs/ESM_rev_B.jpg

The ring oscillator was divided internally before we counted it, by 16
as I recall.

Newer chips tend to have an actual, fairly accurate, die temp sensor,
which opens up complex schemes to control die temp, or measure it and
tweak Vccint, or something.







--

John Larkin Highland Technology, Inc

lunatic fringe electronics

rickman
Guest

Wed Apr 12, 2017 6:10 pm   



On 4/11/2017 12:29 PM, Kevin Neilson wrote:
Quote:
On Monday, April 10, 2017 at 7:13:23 PM UTC-6, John Larkin wrote:
We have a ZYNQ whose predicted timing isn't meeting decent margins.
And we don't want a lot of output pin timing variation in real life.

We can measure the chip temperature with the XADC thing. So, why not
make an on-chip heater? Use a PLL to clock a bunch of flops, and vary
the PLL output frequency to keep the chip temp roughly constant.

I'm confused by the concept. Doesn't timing get *worse* as temp increases? How would a higher temperature help? By "output pin timing variation" do you mean that there are combinatorial output paths? I think the best best is to stay as cool as possible and keep all outputs registered. If you really need to control output delay you can use the IODELAY block, possibly along with a copper trace feedback line.

I have used precision oscillators with built-in heaters. In that case, it's more important that the crystal stay at a constant temp than what the temp is. By making that temperature above the highest possible ambient temp, the heater can keep the crystal temp constant.


That is exactly what John is talking about, except the heater will be on
the FPGA itself.

--

Rick C

Goto page Previous  1, 2, 3 ... , 356, 357, 358  Next

elektroda.net NewsGroups Forum Index - FPGA - EDK : FSL macros defined by Xilinx are wrong

Ask a question - edaboard.com

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map