Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 159825

Article: 159825
Subject: Re: Master Xilinx FPGA like Jtag bridge.
From: =?UTF-8?Q?Adam_G=c3=b3rski?= <gorskiamalpawpkropkapeel_@xx>
Date: Fri, 24 Mar 2017 17:08:40 +0100
Links: << >>  << T >>  << A >>

>>>>>>> How to make master FPGA to connect to many FPGAs ?
>>>>>>>
>>>>>>> Two FPGAs connected by serial  TDI - TDO, and two fpgas  TMS TCK
>>>>>>> TDO and TDI connect to master fpga, master fpga has TMS TDI TDO
>>>>>>> TCK connected and working to pc normally, it need to make
>>>>>>> connection JTAG of two fpgas to other 4 ports or somehow can
>>>>>>> connect to master's jtag port ?
>>>>>>
>>>>>> |   |---------|-TMS----|------------|-TMS----
>>>>>> |   | FPGA 0  |-TCK----|            |-TCK----
>>>>>> |   |         |-TDO----|            |-TDO----
>>>>>> |   |---------|        |            |-TDI----
>>>>>> |       |              |            |
>>>>>> |      TDI             |            |
>>>>>> |       |              |            |
>>>>>> |       |              | MASTER FPGA|
>>>>>> |       |              |            |
>>>>>> |      TDO             |            |
>>>>>> |       |              |            |
>>>>>> |   |---------|-TMS----|            |
>>>>>> |   | FGPA 1  |-TCK----|            |
>>>>>> |   |         |-TDI----|            |
>>>>>> |   |---------|        |------------|
>>>>>>
>>>>>
>>>>> Why do you want the master FPGA to control the others rather than
>>>>> loading them all in one chain?  Connect all TMS and TCK lines in
>>>>> parallel and connect all TDI and TDO in one big daisy chain.  If the
>>>>> slave FPGAs are loaded by the master, where will the data come from?
>>>> It is reverse engineering, someone did this but i just want reuse
>>>> board only
>>>
>>> The JTAG signals to the master chip, do they connect to general I/Os as
>>> well as to the FPGA JTAG signals?  Or just JTAG or just I/Os?
>>>
>>> You didn't say where you expect the data to come from to program the
>>> chained slave FPGAs.  Is it supposed to come from the main JTAG port as
>>> if it was talking to the slave chain?  Or will the master FPGA have a
>>> separate interface from an MCU or a Flash chip?
>>>
>>> What is your overall plan?
>> Slave FPGAs connects to USER I/O ports. for example:
>> TMS of salve FPGA chip connects to user i/o pin  CC
>> TDI of slave FPGA chip connects to user i/0 pin  VRP
>> TCK of slave FPGA ship connects to user i/o pin  CC
>
> What do you connect the user I/O of the master to internally?  If you
> try using the JTAG on the master it will control the master, no?
>

Perhaps you are looking  for something similar like Altera JAM Player 
for embedded.

Take a look here 
https://www.altera.com/support/support-resources/support-centers/devices/programming-tools/jam-stapl/tls-jam-embedded.html

There is pice of C code able to send chip image from embedded system to 
another fpga.

Unfortunatell I don't know X as good as I would like to.

BR

Adam

Article: 159826
Subject: Re: Simulation of PCIe at TLP level
From: gtwrek@sonic.net (Mark Curry)
Date: Fri, 24 Mar 2017 20:18:40 -0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3f49ff11-d6b9-4772-b626-ff6e87ecf04b@googlegroups.com>,
Svenn Are Bjerkem  <svenn.bjerkem@gmail.com> wrote:
>Hi,
>has anybody simulated PCIe at TLP level? I would like to feed a 1x PCIe 
>endpoint interface with data as if it was inserted into a host PCIe slot.
>
>I need some pointers to documents or code describing what I have to do
>to make a simplem memory read and memory write.

Svenn,

There's multiple ways to tackle this.  Since this is an FPGA group,
one assumes you're implementing this on an FPGA.  Xilinx for example
will generate some sort of example design which you can run in your
favorite simulator, and watch your TLP packets pass by.  Hack at it
and recode as you see fit.

Normally, if your implementing an PCIE endpoint within and FPGA,
the generated example will just insert an equivalent root complex
inside the testbench to manage the low-level PCIE negotiations, etc.

Other options include purchasing PCIE verification IP from a vendor.
There's many options here. 

Other options include writing your own PCIE TLP source/sync models (at perhaps
a higher level), and tying that up in your testbench.

There's many options here to explore, all depending on your requirements.

Good luck.

--Mark




Article: 159827
Subject: Re: Divide clock frequency by 1.5: output duty cycle is not 50%
From: vjkaran19@gmail.com
Date: Tue, 28 Mar 2017 03:22:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
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.

Article: 159828
Subject: Re: Divide clock frequency by 1.5: output duty cycle is not 50%
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Tue, 28 Mar 2017 14:46:40 +0000 (UTC)
Links: << >>  << T >>  << A >>
vjkaran19@gmail.com wrote:
> 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@elektron.ikp.physik.tu-darmstadt.de

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

Article: 159829
Subject: Re: Divide clock frequency by 1.5: output duty cycle is not 50%
From: vjkaran19@gmail.com
Date: Tue, 28 Mar 2017 21:41:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
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,
     Thanks to all..

Article: 159830
Subject: handshacking between modules, best practices ?
From: kristoff <kristoff@skypro.be>
Date: Tue, 4 Apr 2017 17:08:45 +0200
Links: << >>  << T >>  << A >>
Hi,


Last weekend, I was continueing on my small project to use a FPGA as 
DAC. I now use a hardware DAC (tlc5615).


So I have two modules, a top-level module for the DDS and an additional 
module to drive the TLC. I have two signal for handshacking ("load" and 
"done").
At a certain point, I had the problem that one of the signals wasn't 
dropped fast enough, which resulted in a weird timing-issue.

In the end, I managed to fix my particular by adding a state with a 
small delay in my FSM, but -looking back- it is probably also possible 
to have done this with some additional checks in the state-machine.



Question: are there known "best practices" when designing a 
handshacking-protocol between different modules in a FPGA design?
Is there documentation about this? Or text-books?


My question is not about this particular bug but a generic question on 
"do-s" and "do not-s" in general.



Kristoff

Article: 159831
Subject: Re: handshacking between modules, best practices ?
From: gtwrek@sonic.net (Mark Curry)
Date: Tue, 4 Apr 2017 16:03:34 -0000 (UTC)
Links: << >>  << T >>  << A >>
In article <oc0cog$j4c$1@dont-email.me>, kristoff  <kristoff@skypro.be> wrote:
>Hi,
>
>Question: are there known "best practices" when designing a 
>handshacking-protocol between different modules in a FPGA design?
>Is there documentation about this? Or text-books?
>
>
>My question is not about this particular bug but a generic question on 
>"do-s" and "do not-s" in general.

I like the handhaking done in the various AXI like protocol's from ARM - 
basically "VALID", "READY" signals.  The key to making things work is there's
NO combinational paths between a VALID and a READY port i.e. the protocol is
fully synchronous with all module I/O registered. 

Asynch handshaking is another beast altogether.  I'm assuming you're not
talking about that.

Do a web search on the AXI protocols.  ARM's specific document is titled
"AMBA AXI and ACE Protocol Specification".  The handshaking is described
in section A3.2.1

Regards,

Mark



Article: 159832
Subject: Re: handshacking between modules, best practices ?
From: kristoff <kristoff@skypro.be>
Date: Tue, 4 Apr 2017 21:36:53 +0200
Links: << >>  << T >>  << A >>
Hi Mark,




On 04-04-17 18:03, Mark Curry wrote:
> In article <oc0cog$j4c$1@dont-email.me>, kristoff  <kristoff@skypro.be> wrote:

>> Question: are there known "best practices" when designing a
>> handshacking-protocol between different modules in a FPGA design?
>> Is there documentation about this? Or text-books?
>>
>>
>> My question is not about this particular bug but a generic question on
>> "do-s" and "do not-s" in general.

> I like the handhaking done in the various AXI like protocol's from ARM -
> basically "VALID", "READY" signals.  The key to making things work is there's
> NO combinational paths between a VALID and a READY port i.e. the protocol is
> fully synchronous with all module I/O registered.
(...)
> Do a web search on the AXI protocols.  ARM's specific document is titled
> "AMBA AXI and ACE Protocol Specification".  The handshaking is described
> in section A3.2.1


Thanks for the link. Very interesting reading.

Yes, the handshaking protocol I used was syncronised, but I only used 
the positive edge of the clock.

The AXI protocol used the positive edge of the clock to set the 
control-signals and the negative edge of the clock to clear them.

That's indeed a good idea. I'll try to use this in my handshaking 
mechanism to try to make it more robust.


> Regards,
> Mark
Kristoff


Article: 159833
Subject: Re: handshacking between modules, best practices ?
From: rickman <gnuarm@gmail.com>
Date: Tue, 4 Apr 2017 15:54:04 -0400
Links: << >>  << T >>  << A >>
On 4/4/2017 11:08 AM, kristoff wrote:
> Hi,
>
>
> Last weekend, I was continueing on my small project to use a FPGA as
> DAC. I now use a hardware DAC (tlc5615).
>
>
> So I have two modules, a top-level module for the DDS and an additional
> module to drive the TLC. I have two signal for handshacking ("load" and
> "done").
> At a certain point, I had the problem that one of the signals wasn't
> dropped fast enough, which resulted in a weird timing-issue.
>
> In the end, I managed to fix my particular by adding a state with a
> small delay in my FSM, but -looking back- it is probably also possible
> to have done this with some additional checks in the state-machine.
>
>
>
> Question: are there known "best practices" when designing a
> handshacking-protocol between different modules in a FPGA design?
> Is there documentation about this? Or text-books?
>
>
> My question is not about this particular bug but a generic question on
> "do-s" and "do not-s" in general.

I've not used handshakes very often.  What would be going on that a 
handshake is required?  Are you talking about clock domain crossing?  Or 
are you talking about two FSMs talking to each other.  In both cases I 
use a direct handshake where one signal does not change state until the 
other "sees" it and acknowledges the previous change.

0,0 -> 1,0 -> 1,1 -> 0,1 -> 0,0

This has no opportunity for a race or timing problem.  Is there 
something I am missing?

-- 

Rick C

Article: 159834
Subject: Re: handshacking between modules, best practices ?
From: rickman <gnuarm@gmail.com>
Date: Tue, 4 Apr 2017 16:06:49 -0400
Links: << >>  << T >>  << A >>
On 4/4/2017 3:36 PM, kristoff wrote:
>
> On 04-04-17 18:03, Mark Curry wrote:
> (...)
>> Do a web search on the AXI protocols.  ARM's specific document is titled
>> "AMBA AXI and ACE Protocol Specification".  The handshaking is described
>> in section A3.2.1
>
>
> Thanks for the link. Very interesting reading.
>
> Yes, the handshaking protocol I used was syncronised, but I only used
> the positive edge of the clock.
>
> The AXI protocol used the positive edge of the clock to set the
> control-signals and the negative edge of the clock to clear them.
>
> That's indeed a good idea. I'll try to use this in my handshaking
> mechanism to try to make it more robust.

Looking at section A3.2 I don't see any signals changing state on the 
falling edge of the clock.  Where do you see this?  It is *very* hard to 
design synchronous logic that operates on both edges of the clock.  The 
two sides of an interface can operate on different clock edges, but this 
only gives half a clock cycle for timing.

Am I completely missing something?

-- 

Rick C

Article: 159835
Subject: Re: handshacking between modules, best practices ?
From: Rob Gaddi <rgaddi@highlandtechnology.invalid>
Date: Tue, 4 Apr 2017 13:20:39 -0700
Links: << >>  << T >>  << A >>
On 04/04/2017 12:36 PM, kristoff wrote:
> Hi Mark,
>
>
>
>
> On 04-04-17 18:03, Mark Curry wrote:
>> In article <oc0cog$j4c$1@dont-email.me>, kristoff
>> <kristoff@skypro.be> wrote:
>
>>> Question: are there known "best practices" when designing a
>>> handshacking-protocol between different modules in a FPGA design?
>>> Is there documentation about this? Or text-books?
>>>
>>>
>>> My question is not about this particular bug but a generic question on
>>> "do-s" and "do not-s" in general.
>
>> I like the handhaking done in the various AXI like protocol's from ARM -
>> basically "VALID", "READY" signals.  The key to making things work is
>> there's
>> NO combinational paths between a VALID and a READY port i.e. the
>> protocol is
>> fully synchronous with all module I/O registered.
> (...)
>> Do a web search on the AXI protocols.  ARM's specific document is titled
>> "AMBA AXI and ACE Protocol Specification".  The handshaking is described
>> in section A3.2.1
>
>
> Thanks for the link. Very interesting reading.
>
> Yes, the handshaking protocol I used was syncronised, but I only used
> the positive edge of the clock.
>
> The AXI protocol used the positive edge of the clock to set the
> control-signals and the negative edge of the clock to clear them.
>
> That's indeed a good idea. I'll try to use this in my handshaking
> mechanism to try to make it more robust.
>
>
>> Regards,
>> Mark
> Kristoff
>

NO NO NO STOP STOP STOP.

The AXI handshake protocols DO NOT do that.  They are, like all good 
synchronous logic should be, sensitive only to the rising edge of the clock.

What the AXI handshake protocol does is use the concept of "mutually 
agreed upon".  If at the rising clock edge a) the master has already 
asserted VALID and b) the slave has already asserted READY, then the 
information present on all the rest of the wires is agreed to have been 
handed off from the master to the slave.  Otherwise, that information 
(if available) is still the master's responsibility.

The point is that there's no need for a recovery cycle.  The master can 
leave VALID asserted and change to new valid data.  The slave can leave 
READY asserted if it doesn't need to wait while it processes the data 
that it just picked up, and the next information can be transferred on 
the very next rising edge.  But this comes with the requirement that 
whether the master's data is valid is entirely uninformed by whether the 
slave is ready for it and vice versa.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Article: 159836
Subject: Re: handshacking between modules, best practices ?
From: kristoff <kristoff@skypro.be>
Date: Wed, 5 Apr 2017 01:07:17 +0200
Links: << >>  << T >>  << A >>
Hi Rob,

On 04-04-17 22:20, Rob Gaddi wrote:

>> Yes, the handshaking protocol I used was syncronised, but I only used
>> the positive edge of the clock.
>> The AXI protocol used the positive edge of the clock to set the
>> control-signals and the negative edge of the clock to clear them.

> NO NO NO STOP STOP STOP.
>
> The AXI handshake protocols DO NOT do that.  They are, like all good
> synchronous logic should be, sensitive only to the rising edge of the
> clock.

Hum. You are correct (as also noted by Rick). I misread the timing. My 
error. My appologies.




> What the AXI handshake protocol does is use the concept of "mutually
> agreed upon".  If at the rising clock edge a) the master has already
> asserted VALID and b) the slave has already asserted READY, then the
> information present on all the rest of the wires is agreed to have been
> handed off from the master to the slave.  Otherwise, that information
> (if available) is still the master's responsibility.

Well, what I had was a bit like that.

I have a signal "load" (equivalent to "valid" in the AXI handshake) and 
"done" (equivalent to "not ready" in AXI).

The master is the top-level module: the DDS module
The slave is a a module that writes out a value to the SPI interface.




The problem I had (at least in the simulator), was a timing-issue:

- In the AXI process, when the slave has received its data, it drops the 
"ready" line, indicating that the slave is still working on the data it 
has justreceived (in my case, it is still sending it out the SPI interface).


In the simulation of my design, this "drop ready line" event took 1 
clock-cyclus. (the slave need to detect this bit-change, clear the 
"ready" line and sends this signal back to the master)


- However, by the time that this signal did arrived at the master, the 
master module had gone to the next steps in its FSM: "wait for the slave 
to indicate it is ready to receive new data (i.e. ready is high), if 
ready: continue".


As the "not ready" signal of the slave had not yet arrived, the 
top-block happily said "ready line is high, so the slave is ready, so 
let's go on".

And, and additional issue, as the FSM of the master had just checked the 
"ready" signal, it simply went on to calculate the next DDS value and 
then the "trigger the slave to read the next value" stage, all this 
without without checking that signal again.



In short, the bug was the result of this assumption:
"When the slave notifies that the master that is not-ready to receive 
any more data, this signal arrives in time for the state-machine of the 
master to process it correctly."


In my case, that assumpion turned out to be wrong.




In my case, I fixed this with a small delay in the FSM, but I guess it 
makes more sence to always do a "check if slave is ready" JUST BEFORE 
sending the data to it.


Therefor my question for "do's and dont's" when designing a protocol 
that controls dataflow between two modules.

I guess -especially if you are designing modules that get on github and 
will be used by others- it is logical to apply more "strict" rules to 
these parts of the code that interfaces with code written by other people.



Kristoff

Article: 159837
Subject: How to download ISPLSI 1032 and how to program it?
From: =?UTF-8?B?7J6E7IOB7KeE?= <marsuan40@gmail.com>
Date: Fri, 7 Apr 2017 00:13:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
ISPVM 18.1 and ISP (HW-USBN-2A) are connecting and downloading and it says that there is no information of ISPLSI 1032 Chip continuously.

I tested 10 boards and it is hard because I have the same problem.

I would like to help you.


Lattices Know how to download ISPLSI 1032 and Jtag / ISP cable and how to get the program.

Article: 159838
Subject: FPGA as heater
From: John Larkin <jjlarkin@highland_snip_technology.com>
Date: Mon, 10 Apr 2017 18:13:13 -0700
Links: << >>  << T >>  << A >>
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.


-- 

John Larkin         Highland Technology, Inc
picosecond timing   precision measurement 

jlarkin att highlandtechnology dott com
http://www.highlandtechnology.com


Article: 159839
Subject: Re: FPGA as heater
From: krw@notreal.com
Date: Mon, 10 Apr 2017 22:15:50 -0400
Links: << >>  << T >>  << A >>
On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin
<jjlarkin@highland_snip_technology.com> 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.

Why not?  Don't bother with the output frequency, just vary the number
of flops wiggling.

Article: 159840
Subject: Re: FPGA as heater
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Mon, 10 Apr 2017 20:06:57 -0700
Links: << >>  << T >>  << A >>
On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote:

>On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin
><jjlarkin@highland_snip_technology.com> 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.
>
>Why not?  Don't bother with the output frequency, just vary the number
>of flops wiggling.

That would work too. Maybe have a 2-bit heat control word, to get
coarse steps of power dissipation, 4 groups of flops. I suppose a
single on-off bit could be a simple bang-bang thermostat.

The PLL thing would be elegant, proportional control of all the flops
in the distributed heater array.

I'm thinking we could reduce the overall effect of ambient temp
changes by some healthy factor, 4:1 or 10:1 or something.


-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 


Article: 159841
Subject: Re: FPGA as heater
From: rickman <gnuarm@gmail.com>
Date: Mon, 10 Apr 2017 23:31:29 -0400
Links: << >>  << T >>  << A >>
On 4/10/2017 11:06 PM, John Larkin wrote:
> On Mon, 10 Apr 2017 22:15:50 -0400, krw@notreal.com wrote:
>
>> On Mon, 10 Apr 2017 18:13:13 -0700, John Larkin
>> <jjlarkin@highland_snip_technology.com> 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.
>>
>> Why not?  Don't bother with the output frequency, just vary the number
>> of flops wiggling.
>
> That would work too. Maybe have a 2-bit heat control word, to get
> coarse steps of power dissipation, 4 groups of flops. I suppose a
> single on-off bit could be a simple bang-bang thermostat.
>
> The PLL thing would be elegant, proportional control of all the flops
> in the distributed heater array.
>
> I'm thinking we could reduce the overall effect of ambient temp
> changes by some healthy factor, 4:1 or 10:1 or something.

Are the die temperature variations caused by ambient temp changes, or on 
chip heat generation changes?

-- 

Rick C

Article: 159842
Subject: Re: FPGA as heater
From: Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat>
Date: Tue, 11 Apr 2017 00:26:33 -0400
Links: << >>  << T >>  << A >>
On Mon, 10 Apr 2017 18:13:13 -0700, the renowned John Larkin
<jjlarkin@highland_snip_technology.com> 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.

Clever, and maybe patentable. Maybe you could servo a ring oscillator
frequency to the clock by changing the dissipation and directly
stabilize the timing. 

--sp 

-- 
Best regards, 
Spehro Pefhany

Article: 159843
Subject: Re: FPGA as heater
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Mon, 10 Apr 2017 21:37:09 -0700
Links: << >>  << T >>  << A >>
On Tue, 11 Apr 2017 00:26:33 -0400, Spehro Pefhany
<speffSNIP@interlogDOTyou.knowwhat> wrote:

>On Mon, 10 Apr 2017 18:13:13 -0700, the renowned John Larkin
><jjlarkin@highland_snip_technology.com> 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.
>
>Clever, and maybe patentable. Maybe you could servo a ring oscillator
>frequency to the clock by changing the dissipation and directly
>stabilize the timing. 
>
>--sp 

That would work too. We'd have to persuade/fool the tools into letting
us build a ring oscillator!

I've used ring oscillators to measure FPGA chip temp before:

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

The change in prop delay vs temp is fairly small.


-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 


Article: 159844
Subject: Re: FPGA as heater
From: Piotr Wyderski <peter.pan@neverland.mil>
Date: Tue, 11 Apr 2017 07:48:17 +0200
Links: << >>  << T >>  << A >>
John Larkin wrote:

> 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.

Reminds me my old idea of building domestic heaters out of Pentium4 
chips. 20 chips with TDP of 135W make a decent heater and one can
always sell the waste MIPS.

	Best regards, Piotr



Article: 159845
Subject: versatile_FFT core has no output
From: _Xilinx <feiphung27@gmail.com>
Date: Mon, 10 Apr 2017 22:53:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am trying to use https://github.com/freecores/versatile_fft , but after I run "make all", data_out.txt and res.txt are all empty.

Anyone have same experience ?

Article: 159846
Subject: Re: FPGA as heater
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 11 Apr 2017 12:26:08 +0100 (BST)
Links: << >>  << T >>  << A >>
In comp.arch.fpga Piotr Wyderski <peter.pan@neverland.mil> wrote:
> John Larkin wrote:
> 
> > 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.

We do that by controlling the fan speed: keeps the FPGA ~40C which is in the
middle of its timing range.

> Reminds me my old idea of building domestic heaters out of Pentium4 
> chips. 20 chips with TDP of 135W make a decent heater and one can
> always sell the waste MIPS.

BTDT. It's not as simple as that, because CPUs are point heat sources.  To
distribute the heat (and stop them melting) you need decent heatsinks and
cooling.  Servers, which do useful compute and emit waste heat, tend to be
cooled assuming a high-velocity, high-noise environment.  Domestic heating
wants low-velocity, low-noise - which needs different enclosure and cooling
arrangements.  The system ends up being substantially custom by the end of
it.

You can get a long way with a dual-socket server board (~400W) in a
'workstation' case, but it's quite space-inefficient.  You can't pack CPUs
too closely together, first for thermal reasons but also because RAM and IO
take up board area.  (Blade servers do that, but again they're designed for
fast air cooling).

Unless you plan to put your 'furnace' in the basement with enough sound
insulation to deaden the howling fans.  Or watercool - needing most custom
stuff.

Theo

Article: 159847
Subject: Re: FPGA as heater
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Tue, 11 Apr 2017 07:02:58 -0700
Links: << >>  << T >>  << A >>
On Tue, 11 Apr 2017 07:48:17 +0200, Piotr Wyderski
<peter.pan@neverland.mil> wrote:

>John Larkin wrote:
>
>> 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.
>
>Reminds me my old idea of building domestic heaters out of Pentium4 
>chips. 20 chips with TDP of 135W make a decent heater and one can
>always sell the waste MIPS.
>
>	Best regards, Piotr
>

What a waste of Pentium chips. They make such excellent x-acto knife
sharpeners.


-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 


Article: 159848
Subject: Re: FPGA as heater
From: John Larkin <jjlarkin@highlandtechnology.com>
Date: Tue, 11 Apr 2017 07:11:54 -0700
Links: << >>  << T >>  << A >>
On 11 Apr 2017 12:26:08 +0100 (BST), Theo Markettos
<theom+news@chiark.greenend.org.uk> wrote:

>In comp.arch.fpga Piotr Wyderski <peter.pan@neverland.mil> wrote:
>> John Larkin wrote:
>> 
>> > 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.
>
>We do that by controlling the fan speed: keeps the FPGA ~40C which is in the
>middle of its timing range.

We do have provision for adding a pin-fin heat sink and a fan directly
over the chip. Like this:

https://dl.dropboxusercontent.com/u/53724080/Thermal/Uzed_Fan_Side.JPG

Just yesterday someone was harassing me to make the fan speed software
controllable, so maybe I will.

I'd rather not have an FPGA fan, but it's pretty likely we'll need it.
There will be an overall box fan, and it is speed controlled.

https://dl.dropboxusercontent.com/u/53724080/Circuits/Power/Fan_Regulator.jpg


-- 

John Larkin         Highland Technology, Inc

lunatic fringe electronics 


Article: 159849
Subject: Re: versatile_FFT core has no output
From: Tim Wescott <tim@seemywebsite.com>
Date: Tue, 11 Apr 2017 10:18:01 -0500
Links: << >>  << T >>  << A >>
On Mon, 10 Apr 2017 22:53:54 -0700, _Xilinx wrote:

> I am trying to use https://github.com/freecores/versatile_fft , but
> after I run "make all", data_out.txt and res.txt are all empty.
> 
> Anyone have same experience ?

Are you feeding it real inputs and doing anything with the outputs?

Synthesis tools are really good at figuring out what logic isn't being 
used, and trimming it.  It's pretty common to make something just to see 
if it'll synthesize and find out that it's not there because you gave it 
constant inputs or didn't bring the outputs to pins.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search