Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
Den onsdag den 12. april 2017 kl. 22.20.19 UTC+2 skrev John Larkin: > On Wed, 12 Apr 2017 12:37:59 -0700 (PDT), Kevin Neilson > <kevin.neilson@xilinx.com> wrote: >=20 > >> > If you really need to control output delay you can use the IODELAY b= lock, possibly along with a copper trace feedback line. > >>=20 > >>=20 > >> 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. > >>=20 > >> We can't crank in a constant delay to fix anything; the problem is the > >> predicted variation in delay. > >>=20 > > > >I still think the IODELAY could help you. The output goes through an ad= justable IODELAY, then you route the output back in through a pin, adjust t= he input IODELAY to figure out where the incoming edge is, and then use a f= eedback loop to keep the output delay constant. It's a technique used for = deskewing DRAM data. I think the main clock would also have to be deskewed= with a BUFG so you have a good reference for the input. Or, if you charac= terized the delay-vs-temp in the lab, you could run in open-loop mode by ad= justing the IODELAY tap based on the temperature you read.=20 > > > >Yes, the tools are definitely pessimistic. They're only useful for wors= t-case. I'm pretty sure you can put in the max temperature when doing PAR,= so you could isolate the effects of just that, but it will still probably = be worse variation than in reality. >=20 > My FPGA guy says that the ZYNQ does not have adjustable delay after > the i/o block flops. We can vary drive strength in four steps, and we > may be able to do something with that. you are right the 7010 and 7020 only have high range IO so no odelay are you just trying to keep a fixed alignment between clock and data output= ? you can do tricks with DDR output flops, data out with a DDR with both inpu= ts as data, clock out with a DDR with 0,1 as input -LasseArticle: 159876
> My FPGA guy says that the ZYNQ does not have adjustable delay after > the i/o block flops. We can vary drive strength in four steps, and we > may be able to do something with that. > Hmm. I've used a real-time-adjustable ODELAY block, but that wasn't in a Zynq. If you can add more hardware to the board, you could re-register the data in some external 74LS flops. You could use unregistered outputs and make your own delay line with a carry chain, which you can create with behavioral code.Article: 159877
On Wed, 12 Apr 2017 15:22:25 -0700 (PDT), Kevin Neilson <kevin.neilson@xilinx.com> wrote: >> My FPGA guy says that the ZYNQ does not have adjustable delay after >> the i/o block flops. We can vary drive strength in four steps, and we >> may be able to do something with that. >> > >Hmm. I've used a real-time-adjustable ODELAY block, but that wasn't in a Zynq. > >If you can add more hardware to the board, you could re-register the data in some external 74LS flops. We are exactly trying to drive external flops, some 1 ns CMOS parts. They are clocked by the same clock that is going into the ZYNQ, and the FPGA needs to set up their D inputs reliably. We can't use a PLL or DLL inside the FPGA. So the problem is that the Xilinx tools are reporting a huge (almost 3:1) spread in possible prop delay from our applied clock to the iob outputs. The tools apparently assume the max process+temperature+power supply limits, without letting us constrain these, and without assigning any specific blame. > >You could use unregistered outputs and make your own delay line with a carry chain, which you can create with behavioral code. I think that has even higher uncertainty, probably more than a full clock period, so we couldn't reliably load those external flops. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 159878
On 4/12/2017 7:21 PM, John Larkin wrote: > On Wed, 12 Apr 2017 15:22:25 -0700 (PDT), Kevin Neilson > <kevin.neilson@xilinx.com> wrote: > >>> My FPGA guy says that the ZYNQ does not have adjustable delay after >>> the i/o block flops. We can vary drive strength in four steps, and we >>> may be able to do something with that. >>> >> >> Hmm. I've used a real-time-adjustable ODELAY block, but that wasn't in a Zynq. >> >> If you can add more hardware to the board, you could re-register the data in some external 74LS flops. > > We are exactly trying to drive external flops, some 1 ns CMOS parts. > They are clocked by the same clock that is going into the ZYNQ, and > the FPGA needs to set up their D inputs reliably. We can't use a PLL > or DLL inside the FPGA. > > So the problem is that the Xilinx tools are reporting a huge (almost > 3:1) spread in possible prop delay from our applied clock to the iob > outputs. The tools apparently assume the max process+temperature+power > supply limits, without letting us constrain these, and without > assigning any specific blame. > > >> >> You could use unregistered outputs and make your own delay line with a carry chain, which you can create with behavioral code. > > I think that has even higher uncertainty, probably more than a full > clock period, so we couldn't reliably load those external flops. The way you have constrained the design I think you will need to design your own chip. I would say you need to find a way to relax one of your many constraints. Not using the PLL/DLL is a real killer. That would be a good one to fix. I haven't use the Xilinx tools in a long time, but I seem to recall there was a way to work with a single temperature. It may have been the hot number or the cold number, but not an arbitrary value in between. But that may have been the post layout simulation timing. Simulation is not a great way to verify timing in general, but it could be made to work for your case. I'd say get a Xilinx FAE involved. -- Rick CArticle: 159879
On Friday, March 24, 2017 at 10:08:43 PM UTC+6, Adam G=C3=B3rski wrote: > >>>>>>> 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 th= e > >>>>> 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? > > >=20 > Perhaps you are looking for something similar like Altera JAM Player=20 > for embedded. >=20 > Take a look here=20 > https://www.altera.com/support/support-resources/support-centers/devices/= programming-tools/jam-stapl/tls-jam-embedded.html >=20 > There is pice of C code able to send chip image from embedded system to= =20 > another fpga. >=20 > Unfortunatell I don't know X as good as I would like to. >=20 > BR >=20 > Adam I dont know CArticle: 159880
> We are exactly trying to drive external flops, some 1 ns CMOS parts. > They are clocked by the same clock that is going into the ZYNQ, and > the FPGA needs to set up their D inputs reliably. We can't use a PLL > or DLL inside the FPGA. >=20 > So the problem is that the Xilinx tools are reporting a huge (almost > 3:1) spread in possible prop delay from our applied clock to the iob > outputs. The tools apparently assume the max process+temperature+power > supply limits, without letting us constrain these, and without > assigning any specific blame. Like Lasse said above, you can adjust the output delay with a half-cycle re= solution using ODDRs. This sounds good enough for your application. I use= d that exact method once for a DRAM (single-data-rate) interface. (I think= the training method was to write data to an unused location in DRAM with v= arious phase relationships, read it back, and see which writes were success= ful.) Your issue sounds a lot like the same issues people have with DRAM. = I don't think you'll see a 3:1 variation in reality.Article: 159881
On Thu, 13 Apr 2017 15:22:52 -0700 (PDT), Kevin Neilson <kevin.neilson@xilinx.com> wrote: > >> We are exactly trying to drive external flops, some 1 ns CMOS parts. >> They are clocked by the same clock that is going into the ZYNQ, and >> the FPGA needs to set up their D inputs reliably. We can't use a PLL >> or DLL inside the FPGA. >> >> So the problem is that the Xilinx tools are reporting a huge (almost >> 3:1) spread in possible prop delay from our applied clock to the iob >> outputs. The tools apparently assume the max process+temperature+power >> supply limits, without letting us constrain these, and without >> assigning any specific blame. > >Like Lasse said above, you can adjust the output delay with a half-cycle resolution using ODDRs. I can declare the differential-input clock polarity either way, which would shift things 3.5 ns (out of a 7 ns clock.) But the guaranteed data-valid window is less than 2 ns. > This sounds good enough for your application. I used that exact method once for a DRAM (single-data-rate) interface. (I think the training method was to write data to an unused location in DRAM with various phase relationships, read it back, and see which writes were successful.) Your issue sounds a lot like the same issues people have with DRAM. I don't think you'll see a 3:1 variation in reality. I sure hope so. -- John Larkin Highland Technology, Inc lunatic fringe electronicsArticle: 159882
Den fredag den 14. april 2017 kl. 06.12.52 UTC+2 skrev John Larkin: > On Thu, 13 Apr 2017 15:22:52 -0700 (PDT), Kevin Neilson > <kevin.neilson@xilinx.com> wrote: > > > > >> We are exactly trying to drive external flops, some 1 ns CMOS parts. > >> They are clocked by the same clock that is going into the ZYNQ, and > >> the FPGA needs to set up their D inputs reliably. We can't use a PLL > >> or DLL inside the FPGA. > >> > >> So the problem is that the Xilinx tools are reporting a huge (almost > >> 3:1) spread in possible prop delay from our applied clock to the iob > >> outputs. The tools apparently assume the max process+temperature+power > >> supply limits, without letting us constrain these, and without > >> assigning any specific blame. > > > >Like Lasse said above, you can adjust the output delay with a half-cycle resolution using ODDRs. > > I can declare the differential-input clock polarity either way, which > would shift things 3.5 ns (out of a 7 ns clock.) But the guaranteed > data-valid window is less than 2 ns. > the point of using DDR was not to shift the clock but to keep the clock and data aligned "regenerating" the clock with a DDR, means the clock and data gets treated the same and both have the same path DDR-IOB so they should track getting the output clock aligned with the input clock (if needed) might be possible using the "zero-delay-buffer" mode of the MMCMArticle: 159883
On 11 Apr 2017 09:52:20 -0700, Winfield Hill <hill@rowland.harvard.edu> wrote: > Here's my fan speed controller. Quite serious. >https://www.dropbox.com/s/7gsrmb9uci1wdb9/RIS-764Gb_fan-speed-controller.JPG?dl=0 > > First there's an LM35 TO-220-package temp sensor > mounted to the heat sink, amplify and offset its > 10mV/deg signal by 11x, to generate a fan-speed > voltage, present to a TC647 fan-speed PWM chip, > add optional MOSFET for when using a non-PWM fan. > E.g., cool, fan runs at 0%, ramps its speed over > a 30 to 40 degree range, thereafter runs at 100%. > TC647 chip senses stalled fan, makes error signal. > Complicated. Here's my simple controller. https://www.dropbox.com/s/u6b7ujxv3y5g20p/Tnduction_fan_controller.pdf?dl=1 The ATtiny88 is about as cheap as the LM35. The microprocessor allows many things other than simple linear control. It has derivative action, for instance, to catch a rapidly heating heat sink before it gets very hot. Other features include a POST that, among other things, spins the fan to full speed for about a second before settling down into the control loop. I've found some fans that have enough bearing stiction that they won't start at the 20% of full voltage that idle provides. So the full power pulse gives them a starting kick. The 3rd output is designed to allow any voltage up to the transistor's limit to be controlled. I designed this controller for a device that had a 45 volt fan. The board is tiny - about the size of 2 postage stamps. The LM35 in a surface mount package is on the bottom of the board. The board is designed to be glued in place with the LM35 in contact with the heat sink. I use the E6000 neoprene adhesive available at Wal-mart in their marine department or in calking gun tubes from McMaster. It is VERY strong but pulls loose from the substrate when stretched. I'm going to open source this design so as soon as I get a round tuit, I'll put the CAD files (KiCAD) and firmware source and hex on http://www.neon-john.com. John John DeArmond http://www.neon-john.com http://www.tnduction.com Tellico Plains, Occupied TN See website for email addressArticle: 159884
Neon John wrote...
>
> Complicated. Here's my simple controller.
>
>https://www.dropbox.com/s/u6b7ujxv3y5g20p/Tnduction_fan_controller.pdf?dl=1
>
>The ATtiny88 is about as cheap as the LM35. The microprocessor allows
>many things other than simple linear control. It has derivative
>action, for instance, to catch a rapidly heating heat sink before it
>gets very hot. Other features include a POST that, among other
>things, spins the fan to full speed for about a second before settling
>down into the control loop. I've found some fans that have enough
>bearing stiction that they won't start at the 20% of full voltage that
>idle provides. So the full power pulse gives them a starting kick.
>
>The 3rd output is designed to allow any voltage up to the transistor's
>limit to be controlled. I designed this controller for a device that
>had a 45 volt fan.
>
>The board is tiny - about the size of 2 postage stamps. The LM35 in a
>surface mount package is on the bottom of the board. The board is
>designed to be glued in place with the LM35 in contact with the heat
>sink. I use the E6000 neoprene adhesive available at Wal-mart in
>their marine department or in calking gun tubes from McMaster. It is
>VERY strong but pulls loose from the substrate when stretched.
>
>I'm going to open source this design so as soon as I get a round tuit,
>I'll put the CAD files (KiCAD) and firmware source and hex on
>http://www.neon-john.com.
>
>John
>John DeArmond
>http://www.neon-john.com
>http://www.tnduction.com
>Tellico Plains, Occupied TN
>See website for email address
Thanks John, that is pretty simple. Of course the processor
requires a program, but if you put it up, that's good. And
include the controller code-burning instructions.
--
Thanks,
- Win
Article: 159885On Fri, 14 Apr 2017 11:47:57 -0400, Neon John <no@never.com> wrote: >On 11 Apr 2017 09:52:20 -0700, Winfield Hill ><hill@rowland.harvard.edu> wrote: > >> Here's my fan speed controller. Quite serious. >>https://www.dropbox.com/s/7gsrmb9uci1wdb9/RIS-764Gb_fan-speed-controller.JPG?dl=0 >> >> First there's an LM35 TO-220-package temp sensor >> mounted to the heat sink, amplify and offset its >> 10mV/deg signal by 11x, to generate a fan-speed >> voltage, present to a TC647 fan-speed PWM chip, >> add optional MOSFET for when using a non-PWM fan. >> E.g., cool, fan runs at 0%, ramps its speed over >> a 30 to 40 degree range, thereafter runs at 100%. >> TC647 chip senses stalled fan, makes error signal. >> > >Complicated. Here's my simple controller. > >https://www.dropbox.com/s/u6b7ujxv3y5g20p/Tnduction_fan_controller.pdf?dl=1 > >The ATtiny88 is about as cheap as the LM35. The microprocessor allows >many things other than simple linear control. It has derivative >action, for instance, to catch a rapidly heating heat sink before it >gets very hot. Other features include a POST that, among other >things, spins the fan to full speed for about a second before settling >down into the control loop. I've found some fans that have enough >bearing stiction that they won't start at the 20% of full voltage that >idle provides. So the full power pulse gives them a starting kick. > >The 3rd output is designed to allow any voltage up to the transistor's >limit to be controlled. I designed this controller for a device that >had a 45 volt fan. > >The board is tiny - about the size of 2 postage stamps. The LM35 in a >surface mount package is on the bottom of the board. The board is >designed to be glued in place with the LM35 in contact with the heat >sink. I use the E6000 neoprene adhesive available at Wal-mart in >their marine department or in calking gun tubes from McMaster. It is >VERY strong but pulls loose from the substrate when stretched. > >I'm going to open source this design so as soon as I get a round tuit, >I'll put the CAD files (KiCAD) and firmware source and hex on >http://www.neon-john.com. > >John >John DeArmond >http://www.neon-john.com >http://www.tnduction.com >Tellico Plains, Occupied TN >See website for email address The LM35 is supposedly not c-load stable, but most things are c-load stable with enough c. It is a kinda tricky part. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.comArticle: 159886
On 4/14/2017 8:10 AM, lasselangwadtchristensen@gmail.com wrote: > Den fredag den 14. april 2017 kl. 06.12.52 UTC+2 skrev John Larkin: >> On Thu, 13 Apr 2017 15:22:52 -0700 (PDT), Kevin Neilson >> <kevin.neilson@xilinx.com> wrote: >> >>> >>>> We are exactly trying to drive external flops, some 1 ns CMOS parts. >>>> They are clocked by the same clock that is going into the ZYNQ, and >>>> the FPGA needs to set up their D inputs reliably. We can't use a PLL >>>> or DLL inside the FPGA. >>>> >>>> So the problem is that the Xilinx tools are reporting a huge (almost >>>> 3:1) spread in possible prop delay from our applied clock to the iob >>>> outputs. The tools apparently assume the max process+temperature+power >>>> supply limits, without letting us constrain these, and without >>>> assigning any specific blame. >>> >>> Like Lasse said above, you can adjust the output delay with a half-cycle resolution using ODDRs. >> >> I can declare the differential-input clock polarity either way, which >> would shift things 3.5 ns (out of a 7 ns clock.) But the guaranteed >> data-valid window is less than 2 ns. >> > > the point of using DDR was not to shift the clock but to keep the clock and > data aligned > > "regenerating" the clock with a DDR, means the clock and data gets treated the same and both have the same path DDR-IOB so they should track > > getting the output clock aligned with the input clock (if needed) might be possible using the "zero-delay-buffer" mode of the MMCM He has already said he has some constraint that won't let him use a PLL or DLL inside the FPGA, so I expect he can't use this either. I can't imagine what his constraint is, maybe the clock is not regular like a typical clock but rather is an async data strobe. I don't recall the upper limits of what can be done with the SERDES that most FPGAs have on chip. But they all run at multi-GHz data rates and are clocked much slower with an internal clock multiplier. Likely that can't be used either. It does seem pretty silly to be adjusting timing by varying the temperature of the die. Not just crude, but fairly ineffective as delays are controlled by local temperature and a die can have hot spots. If the full problem were explained perhaps a solution could be offered. Anyone know what a "1 ns CMOS part" means? -- Rick CArticle: 159887
On 14 Apr 2017 10:07:41 -0700, Winfield Hill <hill@rowland.harvard.edu> wrote: > Thanks John, that is pretty simple. Of course the processor > requires a program, but if you put it up, that's good. And > include the controller code-burning instructions. I'll put up the code and instructions on programming. I used Atmel's Studio development environment (unfortunately based on Microsoft Studio) for development (use GNU-C suite backend) and use AVRDUDE in a command script to program in production. The genuine Atmel programmer is about $35 from Digikey et al but there are plenty of articles on the web about how to build $5 programmers. I notice that AVRDUDE even has a model based on a parallel port. Check out http://www.avrfreaks.com. John John DeArmond http://www.neon-john.com http://www.tnduction.com Tellico Plains, Occupied TN See website for email addressArticle: 159888
On Fri, 14 Apr 2017 10:58:11 -0700, John Larkin <jjlarkin@highland_snip_technology.com> wrote: >The LM35 is supposedly not c-load stable, but most things are c-load >stable with enough c. > >It is a kinda tricky part. It is in this design. There are several hundred of these boards in service in our products. I added the cap because the processor was picking up lots of RFI from the intense RF field inside the induction heater. John John DeArmond http://www.neon-john.com http://www.tnduction.com Tellico Plains, Occupied TN See website for email addressArticle: 159889
On Sat, 15 Apr 2017 10:23:42 -0400, Neon John <no@never.com> wrote: >On Fri, 14 Apr 2017 10:58:11 -0700, John Larkin ><jjlarkin@highland_snip_technology.com> wrote: > > >>The LM35 is supposedly not c-load stable, but most things are c-load >>stable with enough c. >> >>It is a kinda tricky part. > >It is in this design. There are several hundred of these boards in >service in our products. I added the cap because the processor was >picking up lots of RFI from the intense RF field inside the induction >heater. > >John >John DeArmond >http://www.neon-john.com >http://www.tnduction.com >Tellico Plains, Occupied TN >See website for email address LM35 output is an emitter follower with a weak pulldown. An ideal RF detector. And it latches up if it possibly can. LM71, SPI interface, is a nice part. -- John Larkin Highland Technology, Inc lunatic fringe electronicsArticle: 159890
On 2017/04/11 7:26 PM, John Larkin wrote: > On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote: > >> On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin >> <jjlarkin@highlandtechnology.com> 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. >> >> You can do the same thing with the flops. Use a shift register to >> enable flops in a "thermometer code" sort of thing. Too low - shift >> right. Wait. Still to low - shift right. Wait. Too high - shift >> left... >> >> There are all sorts of algorithms that can be built into spare flops. >>> >>> I'm thinking we could reduce the overall effect of ambient temp >>> changes by some healthy factor, 4:1 or 10:1 or something. >> >> Seems reasonable. IBM used to add heater chips for the same purpose >> (bipolar circuits run faster at high temperature). > > CMOS is slower at high temps. Somewhere between about 1000 and 3000 > PPM/K prop delay. > Do you use that property of CMOS (slower the warmer it gets) as an automatic negative feedback loop for your heater? JohnArticle: 159891
On 4/15/2017 12:21 PM, John Robertson wrote: > On 2017/04/11 7:26 PM, John Larkin wrote: >> On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote: >> >>> On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin >>> <jjlarkin@highlandtechnology.com> 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. >>> >>> You can do the same thing with the flops. Use a shift register to >>> enable flops in a "thermometer code" sort of thing. Too low - shift >>> right. Wait. Still to low - shift right. Wait. Too high - shift >>> left... >>> >>> There are all sorts of algorithms that can be built into spare flops. >>>> >>>> I'm thinking we could reduce the overall effect of ambient temp >>>> changes by some healthy factor, 4:1 or 10:1 or something. >>> >>> Seems reasonable. IBM used to add heater chips for the same purpose >>> (bipolar circuits run faster at high temperature). >> >> CMOS is slower at high temps. Somewhere between about 1000 and 3000 >> PPM/K prop delay. >> > > Do you use that property of CMOS (slower the warmer it gets) as an > automatic negative feedback loop for your heater? That would likely not work nearly as well as directly measuring the temperature of the die. Notice he said the chip has a built in thermometer. The only issue with using the thermometer is the temperature across the die will vary. Using the delay to control the heater might work well in concept, but would be hard to measure and still only work for the output being measured. Any other outputs will be spread around the die and so not isothermal. But mostly the timing would be hard to measure. He has an oven/refrigerator. He could measure the change in timing over temperature for some number of samples. This would give him an idea of how much spread is involved. There are multiple sources of timing spread and he can control one and sort of control another. He wants an idea of how much timing spread is left. -- Rick CArticle: 159892
On 2017/04/15 9:37 AM, rickman wrote: > On 4/15/2017 12:21 PM, John Robertson wrote: >> On 2017/04/11 7:26 PM, John Larkin wrote: >>> On Tue, 11 Apr 2017 21:09:52 -0400, krw@notreal.com wrote: >>> >>>> On Mon, 10 Apr 2017 20:06:57 -0700, John Larkin >>>> <jjlarkin@highlandtechnology.com> 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. >>>> >>>> You can do the same thing with the flops. Use a shift register to >>>> enable flops in a "thermometer code" sort of thing. Too low - shift >>>> right. Wait. Still to low - shift right. Wait. Too high - shift >>>> left... >>>> >>>> There are all sorts of algorithms that can be built into spare flops. >>>>> >>>>> I'm thinking we could reduce the overall effect of ambient temp >>>>> changes by some healthy factor, 4:1 or 10:1 or something. >>>> >>>> Seems reasonable. IBM used to add heater chips for the same purpose >>>> (bipolar circuits run faster at high temperature). >>> >>> CMOS is slower at high temps. Somewhere between about 1000 and 3000 >>> PPM/K prop delay. >>> >> >> Do you use that property of CMOS (slower the warmer it gets) as an >> automatic negative feedback loop for your heater? > > That would likely not work nearly as well as directly measuring the > temperature of the die. Notice he said the chip has a built in > thermometer. The only issue with using the thermometer is the > temperature across the die will vary. Using the delay to control the > heater might work well in concept, but would be hard to measure and > still only work for the output being measured. Any other outputs will > be spread around the die and so not isothermal. But mostly the timing > would be hard to measure. > > He has an oven/refrigerator. He could measure the change in timing over > temperature for some number of samples. This would give him an idea of > how much spread is involved. There are multiple sources of timing > spread and he can control one and sort of control another. He wants an > idea of how much timing spread is left. > Thanks for the explanation. I am not a qualified board designer, just a bit of a hacker designing and making the few I need for my restoration business. It is nice to get the background of design considerations as I find that information useful in determining where designs have gone wrong in our equipment and try to make improvements to the systems. As an example - Common/Ground designs in early arcade games were not always at their best. A number of early electronic pinball games used to burn up driver transistors and coils at random until I traced the problem - which was a design error where all the commons (MPU, Audio, Solenoids, Lamps) came together at the regulator board through several different pins, and as each pin connection oxidized slightly it allowed ground potential differences between the MPU and the solenoid logic grounds, leading to the transistors being slightly biased on... And this game logic had been designed by Rockwell. JohnArticle: 159893
On Saturday, 4/15/2017 1:15 PM, John Robertson wrote: > > As an example - Common/Ground designs in early arcade games were not > always at their best. A number of early electronic pinball games used to > burn up driver transistors and coils at random until I traced the > problem - which was a design error where all the commons (MPU, Audio, > Solenoids, Lamps) came together at the regulator board through several > different pins, and as each pin connection oxidized slightly it allowed > ground potential differences between the MPU and the solenoid logic > grounds, leading to the transistors being slightly biased on... > And this game logic had been designed by Rockwell. > > John This sort of poor design is common in consumer electronics. Likely the engineer wanted more or better ground connections, but got shot down due to increased cost of connectors with either more pins or better plating (silver or gold). As long as the oxidation issue happens _after_ the warranty period expires, there's no incentive to correct the design, either. -- GaborArticle: 159894
I have a question about how FPGAs handle signals into combinational logic. I have following setup: always @(posedge interrupt_check) interrupt_detect <= interrupt_request; assign interrupt_ack = interrupt_request & enable; The interrupt_request signal may happen at any time relative to interrupt_check so I know that interrupt_detect may be metastable for a bit. However, enable is guaranteed to be asserted a minimum of 150ns after interrupt_check so it ought to hold interrupt_ack low until interrupt_detect is stable. And there's my question. Will the AND gate implementation in an FPGA do that? Or are LUTs odd enough that I can't depend on it? If the answer is FPGA specific, I'm using an Artix 7 FPGA. I've considered "fixing" this by changing the AND gate to a flop with: always @(posedge enable) interrupt_ack <= interrupt_detect; but that has the problem that I'm left looking for a signal to clear that flop at the right time. I want to clear it when enable goes low again but that's not allowed. Thanks for any insight, DaveArticle: 159895
On 4/23/2017 9:34 AM, David Bridgham wrote: > I have a question about how FPGAs handle signals into combinational > logic. I have following setup: > > always @(posedge interrupt_check) interrupt_detect <= interrupt_request; > > assign interrupt_ack = interrupt_request & enable; > > The interrupt_request signal may happen at any time relative to > interrupt_check so I know that interrupt_detect may be metastable for a > bit. However, enable is guaranteed to be asserted a minimum of 150ns > after interrupt_check so it ought to hold interrupt_ack low until > interrupt_detect is stable. > > And there's my question. Will the AND gate implementation in an FPGA do > that? Or are LUTs odd enough that I can't depend on it? If the answer > is FPGA specific, I'm using an Artix 7 FPGA. > > I've considered "fixing" this by changing the AND gate to a flop with: > > always @(posedge enable) interrupt_ack <= interrupt_detect; > > but that has the problem that I'm left looking for a signal to clear > that flop at the right time. I want to clear it when enable goes low > again but that's not allowed. I'm sorry but I can't picture the timing from your description. You have two circuits with one input in common. You then ask "Will the AND gate implementation in an FPGA do that?" I don't understand what you are asking. Are you saying that enable is not asserted *until* at least 150 ns after interrupt_check rising edge? Or that enable is *held* for 150 ns after the interrupt_check rising edge? Is the idea that interrupt_detect is not considered by other logic until interrupt_ack is asserted? Or is interrupt_detect supposed to be conditioned by enable rather than interrupt_request? -- Rick CArticle: 159896
On Sunday, 4/23/2017 9:34 AM, David Bridgham wrote: > I have a question about how FPGAs handle signals into combinational > logic. I have following setup: > > always @(posedge interrupt_check) interrupt_detect <= interrupt_request; > > assign interrupt_ack = interrupt_request & enable; > > The interrupt_request signal may happen at any time relative to > interrupt_check so I know that interrupt_detect may be metastable for a > bit. However, enable is guaranteed to be asserted a minimum of 150ns > after interrupt_check so it ought to hold interrupt_ack low until > interrupt_detect is stable. > > And there's my question. Will the AND gate implementation in an FPGA do > that? Or are LUTs odd enough that I can't depend on it? If the answer > is FPGA specific, I'm using an Artix 7 FPGA. > > I've considered "fixing" this by changing the AND gate to a flop with: > > always @(posedge enable) interrupt_ack <= interrupt_detect; > > but that has the problem that I'm left looking for a signal to clear > that flop at the right time. I want to clear it when enable goes low > again but that's not allowed. > > Thanks for any insight, > Dave > AND gates in an FPGA work like real AND gates. The LUTs are designed not to glitch when inputs change, but the output should remain the same. LUTs may glitch when multiple inputs change and some combination of values during the change would cause the output to change. However this is usually due to the skew between inputs. Also in an AND gate of any size that fits in one LUT, any combination of other inputs would not make the output go high, and therefore you should not get a glitch on the outputs. On the other hand, FPGAs are not really designed to do asynchronous sequential logic well. What you're trying to do is typically done using a high-speed free-running clock to sample the input signals and then make decisions synchronously. -- GaborArticle: 159897
On Sun, 23 Apr 2017 15:51:33 -0400, rickman wrote: > I'm sorry but I can't picture the timing from your description. You > have two circuits with one input in common. One input in common? Well crap, I screwed up the verilog. Try this instead: always @(posedge interrupt_check) interrupt_detect <= interrupt_request; assign interrupt_ack = interrupt_detect & enable; > You then ask "Will the AND gate implementation in an FPGA do that?" I > don't understand what you are asking. If an actual AND gate has an input that's 0, the output will be 0 regards of the other input. If the other input is 0, is 1, is a clock, or even if it's somewhere in-between because the driver has gone metastable, the output of the AND gate will be 0. My question was, can I depend on that from a synthesized AND gate in an FPGA? > Are you saying that enable is not asserted *until* at least 150 ns after > interrupt_check rising edge? Or that enable is *held* for 150 ns after > the interrupt_check rising edge? The former; enable is not asserted until at least 150ns after interrupt_check rising edge. > Is the idea that interrupt_detect is not considered by other logic until > interrupt_ack is asserted? Or is interrupt_detect supposed to be > conditioned by enable rather than interrupt_request? Both, I think. Well, interrupt_detect is not used by any other logic, only interrupt_ack. interrupt_detect is internal to just what you see there while interrupt_ack is the signal that goes on to the rest of the logic. To see more of the context of this question, I'm working on bus arbitration circuitry for the Unibus and QBUS. I'm writing up what I'm doing in a short paper that you can find at the URL below. The paper isn't done yet but it's starting to get closer. http://www.froghouse.org/~dab/papers/bus-arbitration/ba.htmlArticle: 159898
On Mon, 24 Apr 2017 08:30:06 -0400, Gabor wrote: > On the other hand, FPGAs are not really designed to do asynchronous > sequential logic well. What you're trying to do is typically done > using a high-speed free-running clock to sample the input signals and > then make decisions synchronously. I've read this before, that FPGAs are not really suitable for asynchronous logic. And yet, if the gates are glitch-free than I'm not seeing the problem with doing what I'm suggesting here. Converting the input signals to synchronous seems like a bunch of extra work for something that ought to be fairly straightforward. In the larger picture, I do have a desire someday to play around with asynchronous designs. Not this project with the QBUS but a future project, possibly even implementing an entire processor asynchronously. Being able to use FPGAs would sure be easier than having to get out the wire-wrap gun.Article: 159899
On Mon, 24 Apr 2017 14:04:34 -0000 (UTC) David Bridgham <dab@froghouse.org> wrote: > On Mon, 24 Apr 2017 08:30:06 -0400, Gabor wrote: > > > On the other hand, FPGAs are not really designed to do > > asynchronous sequential logic well. What you're trying to > > do is typically done using a high-speed free-running clock > > to sample the input signals and then make decisions > > synchronously. > > I've read this before, that FPGAs are not really suitable for > asynchronous logic. And yet, if the gates are glitch-free > than I'm not seeing the problem with doing what I'm suggesting > here. Converting the input signals to synchronous seems like > a bunch of extra work for something that ought to be fairly > straightforward. Aren't there usually handy latches in the input buffer structure? Better safe than frustrated... > In the larger picture, I do have a desire someday to play > around with asynchronous designs. Not this project with the > QBUS but a future project, possibly even implementing an > entire processor asynchronously. Being able to use FPGAs would > sure be easier than having to get out the wire-wrap gun. I'd also like to prototype a fully asynchronous processor in an FPGA. The Microsemi (ex Actel) Igloo/ProASIC3 parts have no LUTs. An element of the fine grained fabric can either be a latch or the equivalent of a LUT3. But, you may have to hand-wire the input delays if timing is really critical? It seems to me that the 2 wire 4 state logic should be fastest, because only one of the wires needs to make a single transition to indicate the next data phase. On-chip RAM would seem to be a problem though - any ideas?. Jan Coombs --
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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