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
On Wed, 22 Aug 2007 09:19:08 -0700, Andy <jonesandy@comcast.net> wrote: >I don't suppose we need to tell you that having neither reset nor >initializers is a bad design practice, even when it "works" in FPGA >hardware. > >This is one case where a two-state optimization on the simulator would >be worth its weight in gold. I wonder.... I just wonder.... if anyone has created a replacement for std_logic_1164 that has all the same names and things in it, but rewrites the operator definitions so that 'U' gets treated as zero.... it would simulate dog-slow because the simulator's internal accelerations for std_logic_1164 would be bypassed, but it would be useful in ugly situations like this. You could even implement the operators as foreign language functions, making it possible for them to randomize the replacement value for 'U'... And no, I'm not signing-up to do it. I don't have the time, and in any case I can't sell my soul for a second time now that I've learnt SystemVerilog :-) -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 123276
On Wed, 22 Aug 2007 07:45:52 -0700, wittenjon@googlemail.com wrote:
>Hi,
>
> I have a VHDL design which has no reset, within the design
>are statements that rely on the last know state of a signal i.e sig_a
><= not sig_a, sig_a has not had an initial value declared in the
>signal region, hence it's value is X, there are numerous occurrences
>of this within the design. The design has been place and routed and
>works ok on the board as in the real world all signals have a default
>value. I can not change the RTL code, I therefore need to force all
>signals in the design to a known state, I understand that force only
>works on 1 signal at a time. Does anybody know how to force all nets,
>or have any better ideas than using force?
Most simulators have a way to inquire about what signals exist in
a given scope. You could incorporate that into a Tcl script.
For example, in ModelSim try loading a simulation and then issuing
the command
find signals -recursive *
So here's a script that forces all signals in your toplevel
testbench to zero:
foreach sig [find signals *] {
force $sig -deposit 0
}
Yuck.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 123277A lot depends on the design. Careful floorplanning can reduce power by 20% or more by reducing the complexity and length of routing. If your logic has multiple levels of LUTs between flip-flops, adding pipeline stages to reduce the number of levels of logic can reduce power by a bit. This is counter-intuitive. It works because a good percentage of an FPGA's power dissipation comes from propagation of glitch energy through combinatorial logic. Adding flip-flops stops the propagation of a glitch. There was a paper at FPGA, probably around 2002 that talked about this and claimed as much as 25% reduction of power by using deep pipelining. The example used, as I recall was rather extreme, but I think the idea is still valid. Again, most of the dissipation is in the routing channels, not in the lut logic, so adding the flip-flops is outweighed by the reduced dissipation in the routing channels. You can use the BUFGMUXs to gate your clocks if needed, however most designs need the clocks running, and gating clocks brings its own set of problems. You can time multiplex one instance of logic over multiple "channels" if that can be done with relatively little multiplex/de-multiplex logic to get a smaller gate count at the expense of running at a higher frequency. This often reduces power because routing complexity is reduced and because you only take one hit on the static dissipation instead of an added hit for each channel. There will be no savings in teh dynamic dissipation, as that is proportional to toggle rate. The dynamic power may even be a little bit higher because of capacitive effects on the clock distribution. Of these, the most effective will be careful floorplanning. You might also be able to reduce the voltages a bit if you can still make timing with reduced voltage. Power aries with the square of the supply voltage so even small changes in voltage will yeild large savings on power at the expense of some performance. tgschwind@tiscalinet.ch wrote: > I have a design on a Spartan 3 2000. It uses nearly all slices, two > thirds of the FF and LUTs. Also all BlockRam and all BlockMultiplier > are used. > The design uses three clock. A 40 Mhz clock for configuration and > registers, 80 Mhz for data processing, and 160 Mhz for internal > processing in certain blocks. > > The problem is that the device becomes hot, so hot, that you can burn > your fingers. I measured up to 104 °C on the FPGA Ituses nearly 1.3 W. > I have alredy implemeted ClockEnables everywhere possible. Also on > RAMs. I have already sythesized with Power Reduction option. > > The Device can't have a active cooling, like a fan. > > Does anybody have some advice how to further reduce the power ? 25 % > would be great. >Article: 123278
>- but it can only do it if the driver has been told it can operate >for a given vendorID and productID that the peripheral is setup as (I >was unable to find a generic USB "spy" program that would simply >interrogate and debug any attached USB device - which made the debug >process all the more painful. Linux has a lsusb utility that tells you what is connected. Sample printout: Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 001 Device 008: ID 091e:0003 Garmin International GPSmap (various models) Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. Bus 001 Device 001: ID 0000:0000 Bus 001 Device 003: ID 0bc2:0502 Seagate RSS LLC Bus 001 Device 002: ID 05e3:070e Genesys Logic, Inc. Bus 003 Device 001: ID 0000:0000 -- These are my opinions, not necessarily my employer's. I hate spam.Article: 123279
RCIngham wrote: > By choosing to implement in an FPGA, you must accept the limitations of the > architecture of the target device, including the number of permitted > clocks. This may restrict the design style to some extent. > > In an ASIC you (generally speaking) have no such restrictions, but the > up-front cost and turn-around times are much increased. > >>> IP should have a clock port and a clock enable >>> port. So, if you need to integrate several bits of IP, you can use one > clock >>> with different enables. >> Thank you but I do not get the point. >> >> Problem was that >> --------------------------- >> If there is single global system clock, the overhead (by having only >> one global clock) becomes bigger and bigger. >> --------------------------- >> >> My question was that >> ----------------------------- >> Can FPGA come up with "Globally Asynchronous, Locally Synchronous >> (GALS)" design style that ASIC tends to do? >> If yes, how? >> ----------------------------- >> All (afaik) FPGAs are capable of running a single global clock over the whole chip, so long as you use the resources provided for that purpose. The chip maker takes care of the distribution problems. If you want multiple clocks so you can shut down an area & save power, most modern FPGAs offer several clock nets. But you are now responsible for synchronising them.Article: 123280
LilacSkin wrote: > Hello > > I have just the MCS file and I want to configure directly my FPGa with > a bitstream. > So I had to convert the MCS in BIT. > > What I have done: > 1)MCS->HEX with promgen: promgen -r <promfile> -p hex > 2)HEX->BIT with Hex2bits : hex2bits -k <hexfile> <bitfile> > > But iMPACT doen't work with the generated bitstream. > Do you have any idea ? > > Thanks ! > Xilinx bit files are LSB first, IIRC. You may need to flip the bit sequence between bytes. Then, you need to send some extra config clocks to the FPGA to complete the configuration sequence. The bit file may have something at the end that causes iMPACT to do that, and that something may have been trimmed when converting to PROM format in the MCS file. Also, bit files have a header at the beginning that specifies the FPGA part #, and the date and time of creation of the file. Everything up to the 0xFF is header info, and can be read with an ASCII editor or hex file viewer. If the header info is not right, it may cause iMPACT to not work right. The MCS file has a checksum at the end of every line. Hopefully promgen gets rid of that. JonArticle: 123281
On Aug 22, 10:57 am, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >- but it can only do it if the driver has been told it can operate > >for a given vendorID and productID that the peripheral is setup as (I > >was unable to find a generic USB "spy" program that would simply > >interrogate and debug any attached USB device - which made the debug > >process all the more painful. > > Linux has a lsusb utility that tells you what is connected. > > Sample printout: > Bus 005 Device 001: ID 0000:0000 > Bus 004 Device 001: ID 0000:0000 > Bus 002 Device 001: ID 0000:0000 > Bus 001 Device 008: ID 091e:0003 Garmin International GPSmap (various models) > Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. > Bus 001 Device 001: ID 0000:0000 > Bus 001 Device 003: ID 0bc2:0502 Seagate RSS LLC > Bus 001 Device 002: ID 05e3:070e Genesys Logic, Inc. > Bus 003 Device 001: ID 0000:0000 > > -- > These are my opinions, not necessarily my employer's. I hate spam. Hi Hal, Thanks for that - useful to know. Unfortunately I don't have root on my linux machine (work machine), and it's the 2.4 kernel (don't ask!) So I was not able to use any of those nice Linux utilities. Windows was all I had "root" on to install stuff. But lsusb sounds like the way to go if you can use it. P.S. Sorry for the numerous typos in my previous post - I was rushing a bit. Also, I assume the OP has access to the EDK - which was what I used for talking to the EZ-Host on the FPGA side, I didn't make that clear in the original post. You don't have to use the MicroBlaze, some HDL could be written to implement the HPI protocol too. But it did make it a little easier to be able to use C code to implement the protocol. JohnArticle: 123282
On Aug 20, 1:54 pm, Peter Alfke <pe...@xilinx.com> wrote: > Somebody asked for access to old XCell magazines. > I was able to download all issues #17 through #39 ( 2Q1995 through > 1Q2001) by clicking on:ftp://ftp.xilinx.com/pub/documentation/xcell/xcell17.pdf etc. > Peter Alfke Hi Peter, Do you have the newer XCell magazines to download at once? I like XCell very much. Thank you. WengArticle: 123283
>What does your IO look like? Can you soften your drive strengths, and/ >or reduce slew rates? How much energy/heat does that save? You aren't changing the toggle rate or the size of the external cap, just the rise/fall times. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 123284
>Hi Hal, >Thanks for that - useful to know. Unfortunately I don't have root on >my linux machine (work machine), and it's the 2.4 kernel (don't ask!) >So I was not able to use any of those nice Linux utilities. Windows >was all I had "root" on to install stuff. But lsusb sounds like the >way to go if you can use it. You don't need to be root. (at least on a vanilla Fedora 6 system) There is more info in /proc/bus/usb/, things like this: T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0bc2 ProdID=0502 Rev= 2.00 S: Manufacturer=Seagate S: Product=ST94811U2-RK S: SerialNumber=344E463039384754 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 4mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms -- These are my opinions, not necessarily my employer's. I hate spam.Article: 123285
Many thanks all for the input. At some stage, once I'm done with designing the system, I'll try to gauge things in real-world and hope for the best. Regards, -MannyArticle: 123286
On 22 Aug, 21:07, Weng Tianxiang <wtx...@gmail.com> wrote: > On Aug 20, 1:54 pm, Peter Alfke <pe...@xilinx.com> wrote: > > > Somebody asked for access to old XCell magazines. > > I was able to download all issues #17 through #39 ( 2Q1995 through > > 1Q2001) by clicking on:ftp://ftp.xilinx.com/pub/documentation/xcell/xcell17.pdf etc. > > Peter Alfke > > Hi Peter, > Do you have the newer XCell magazines to download at once? > > I like XCell very much. > > Thank you. > > Weng Here is a link: http://www.xilinx.com/publications/xcellonline/index.htm SvenArticle: 123287
On Aug 22, 9:27 am, Andreas Ehliar <ehl...@lysator.liu.se> wrote: > Is the static power consumption of an > empty slice the same as the static power consumption of a configured > slice with static inputs? > > /Andreas The answer is YES (same static power) IMHO. Peter AlfkeArticle: 123288
tgschwind@tiscalinet.ch wrote: >I have a design on a Spartan 3 2000. It uses nearly all slices, two >thirds of the FF and LUTs. Also all BlockRam and all BlockMultiplier >are used. >The design uses three clock. A 40 Mhz clock for configuration and >registers, 80 Mhz for data processing, and 160 Mhz for internal >processing in certain blocks. > >The problem is that the device becomes hot, so hot, that you can burn >your fingers. I measured up to 104 =B0C on the FPGA Ituses nearly 1.3 W. >I have alredy implemeted ClockEnables everywhere possible. Also on >RAMs. I have already sythesized with Power Reduction option. Where is that power reduction option? I'm working on a design which is heating a Spartan 3 FPGA a bit too much (not so extreme as your design, I can still keep my finger on the chip but it is not comfortable). I would like some power savings. According to XPower, it saves quite some power when the drive strength of outputs is reduced. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 123289
Andreas Ehliar wrote: > On 2007-08-22, Ray Andraka <ray@andraka.com> wrote: > >>You can use the BUFGMUXs to gate your clocks if needed, however most >>designs need the clocks running, and gating clocks brings its own set of >>problems. > > > Your post got me thinking about dynamically reconfiguring an FPGA to > save power. I wonder how much power you can save by reconfiguring an > FPGA so that an unused block is not there as compared to just turning > off the clock to that block. Is the static power consumption of an > empty slice the same as the static power consumption of a configured > slice with static inputs? > > /Andreas I think unconfigured logic has the same static dissipation as configured logic that has all the inputs held static, so reconfiguring to take logic out isn't going to save you anything. On top of that, reconfiguration takes a considerable amount of power so you'd end up with a greater net power. Now if you were to reconfigure so that unused logic gets replaced with new logic that wouldn't have fit otherwise, then you'll likely get some savings as long as the reconfiguration is done infrequently enough for the power overhead of doing the reconfiguraiton doesn't overshadow the savings. Basically, if reconfiguration lets you get into a smaller device, then it might be a win for power. If it doesn't shrink the device size, then you aren't going to realize any power saving.Article: 123290
On Aug 22, 12:48 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >Hi Hal, > >Thanks for that - useful to know. Unfortunately I don't have root on > >my linux machine (work machine), and it's the 2.4 kernel (don't ask!) > >So I was not able to use any of those nice Linux utilities. Windows > >was all I had "root" on to install stuff. But lsusb sounds like the > >way to go if you can use it. > > You don't need to be root. (at least on a vanilla Fedora 6 system) > > There is more info in /proc/bus/usb/, things like this: > > T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=0bc2 ProdID=0502 Rev= 2.00 > S: Manufacturer=Seagate > S: Product=ST94811U2-RK > S: SerialNumber=344E463039384754 > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 4mA > I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > -- > These are my opinions, not necessarily my employer's. I hate spam. I think you need to be root to enable some usb features in the 2.4 kernel and I think lsusb only works with the 2.6 kernel - so I was caught both ways - could not change my linux version, and could not get the usb functions to work on the 2.4 kernel without root. I could be completely wrong - I'm far from a Linux guru - but that's more or less what I found at the time. It would have made my life a lot easier though - maybe I should have gotten a live linux cd for my laptop and saved all this trouble! Thanks again for the tip!Article: 123291
On Aug 22, 9:59 pm, John McGrath <tail...@gmail.com> wrote: > On Aug 22, 12:48 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal > > > > Murray) wrote: > > >Hi Hal, > > >Thanks for that - useful to know. Unfortunately I don't have root on > > >my linux machine (work machine), and it's the 2.4 kernel (don't ask!) > > >So I was not able to use any of those nice Linux utilities. Windows > > >was all I had "root" on to install stuff. But lsusb sounds like the > > >way to go if you can use it. > > > You don't need to be root. (at least on a vanilla Fedora 6 system) > > > There is more info in /proc/bus/usb/, things like this: > > > T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 > > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > > P: Vendor=0bc2 ProdID=0502 Rev= 2.00 > > S: Manufacturer=Seagate > > S: Product=ST94811U2-RK > > S: SerialNumber=344E463039384754 > > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 4mA > > I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > > E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > > -- > > These are my opinions, not necessarily my employer's. I hate spam. > > I think you need to be root to enable some usb features in the 2.4 > kernel and I think lsusb only works with the 2.6 kernel - so I was > caught both ways - could not change my linux version, and could not > get the usb functions to work on the 2.4 kernel without root. > I could be completely wrong - I'm far from a Linux guru - but that's > more or less what I found at the time. It would have made my life a > lot easier though - maybe I should have gotten a live linux cd for my > laptop and saved all this trouble! Thanks again for the tip! Thanks, Using the microblaze processor seems a bit like overkill. All I need to do is be able to send/receive bytes from the PC to the Cypress micro. The FPGA can then read/write from the micro over the GPIO pins. There is an example in the cypress docs which connects leds to the GPIOs of the micro and allows the PC to set/clear them by sending bytes over the USB. Supposidly the micro should appear as a standard HID device and the standard USB HID drivers can be used on windows. Unfortunately when I download that example code it does not work. Looking at USBview it appears that the Cypress micro has not been enumerated properly. All fields appear as zero, hence windows does not know what driver to use. I'll try using linux to dump the raw transactions of the usb bus if this is possible, to attempt to debug it.Article: 123292
On Aug 22, 2:29 pm, alle...@gmail.com wrote: > On Aug 22, 9:59 pm, John McGrath <tail...@gmail.com> wrote: > > > > > On Aug 22, 12:48 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal > > > Murray) wrote: > > > >Hi Hal, > > > >Thanks for that - useful to know. Unfortunately I don't have root on > > > >my linux machine (work machine), and it's the 2.4 kernel (don't ask!) > > > >So I was not able to use any of those nice Linux utilities. Windows > > > >was all I had "root" on to install stuff. But lsusb sounds like the > > > >way to go if you can use it. > > > > You don't need to be root. (at least on a vanilla Fedora 6 system) > > > > There is more info in /proc/bus/usb/, things like this: > > > > T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 > > > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > > > P: Vendor=0bc2 ProdID=0502 Rev= 2.00 > > > S: Manufacturer=Seagate > > > S: Product=ST94811U2-RK > > > S: SerialNumber=344E463039384754 > > > C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 4mA > > > I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage > > > E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > > E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > > > > -- > > > These are my opinions, not necessarily my employer's. I hate spam. > > > I think you need to be root to enable some usb features in the 2.4 > > kernel and I think lsusb only works with the 2.6 kernel - so I was > > caught both ways - could not change my linux version, and could not > > get the usb functions to work on the 2.4 kernel without root. > > I could be completely wrong - I'm far from a Linux guru - but that's > > more or less what I found at the time. It would have made my life a > > lot easier though - maybe I should have gotten a live linux cd for my > > laptop and saved all this trouble! Thanks again for the tip! > > Thanks, > > Using the microblaze processor seems a bit like overkill. All I need > to do is be able to send/receive bytes from the PC to the Cypress > micro. The FPGA can then read/write from the micro over the GPIO pins. > There is an example in the cypress docs which connects leds to the > GPIOs of the micro and allows the PC to set/clear them by sending > bytes over the USB. Supposidly the micro should appear as a standard > HID device and the standard USB HID drivers can be used on windows. > Unfortunately when I download that example code it does not work. > Looking at USBview it appears that the Cypress micro has not been > enumerated properly. All fields appear as zero, hence windows does not > know what driver to use. > > I'll try using linux to dump the raw transactions of the usb bus if > this is possible, to attempt to debug it. Well the Cypress device will appear like a standard HID device if you first program it to do so! You have to compile the source code for the microcontroller running inside the EZ-Host to make it behave like the USB Host or Peripheral you want it to be. So the first thing to do is to load this program into the EZ-Host (there is a default program running when it powers on, but I don't think it's a peripheral). I used the MicroBlaze to upload this program to the EZ-Host. You don't need to do this, but you do need to upload something to the Cypress chip in order to get it working. I believe the Cypress Development kit does this uploading for you, when you use their development board, etc. The HPI protocol was the method I used to upload the program to the Cypress chip - but there are others too (SPI, etc). The reason I used this was because the ml401 usb-keyboard demo uses this setup to initialize the EZ-Host, so I built on that. The uploading of the program has to come from the FPGA side. Once done, the FPGA re-boots the Cypress chip and then it starts implementing the USB function that has been programmed into it. Hope it's a little clearer now. JohnArticle: 123293
On Aug 22, 2:42 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >What does your IO look like? Can you soften your drive strengths, and/ > >or reduce slew rates? > > How much energy/heat does that save? You aren't changing the toggle > rate or the size of the external cap, just the rise/fall times. > > -- > These are my opinions, not necessarily my employer's. I hate spam. OK, you got me there. It saves peak power, but not average (thermal) power. If you could redesign the board, you might be able to make the power supply run cooler, and thus not heat up the FPGA, but that's probably out of scope. OTOH, if he's got SSO problems causing inputs (perhaps not observed at the time) to toggle excessively, then that could cause extra power to be consumed, which would be reduced/eliminated by slowing the outputs down. Admittedly, a bit of a reach though :) AndyArticle: 123294
Peter Alfke wrote: > On Aug 22, 9:27 am, Andreas Ehliar <ehl...@lysator.liu.se> wrote: > >> Is the static power consumption of an >>empty slice the same as the static power consumption of a configured >>slice with static inputs? >> >>/Andreas > > > The answer is YES (same static power) IMHO. Has anyone measured this, to check it is the same ? I have seen CPLDs where the Macrocell logic state did have a measurable effect on static Icc :) ( this was not the product term fuses, but the logic levels in a working device ) At a first look, CMOS is Vcc.Gnd level agnostic, but when you start adding all the complex leakages, and maybe level shifters, then you may find some variation. (it may not be much..) -jgArticle: 123295
On Aug 22, 12:20 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Wed, 22 Aug 2007 09:19:08 -0700, > > Andy <jonesa...@comcast.net> wrote: > >I don't suppose we need to tell you that having neither reset nor > >initializers is a bad design practice, even when it "works" in FPGA > >hardware. > > >This is one case where a two-state optimization on the simulator would > >be worth its weight in gold. > > I wonder.... I just wonder.... if anyone has created a replacement > for std_logic_1164 that has all the same names and things in it, > but rewrites the operator definitions so that 'U' gets treated > as zero.... it would simulate dog-slow because the simulator's > internal accelerations for std_logic_1164 would be bypassed, but > it would be useful in ugly situations like this. You could > even implement the operators as foreign language functions, > making it possible for them to randomize the replacement > value for 'U'... > > And no, I'm not signing-up to do it. I don't have the time, > and in any case I can't sell my soul for a second time now that > I've learnt SystemVerilog :-) > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. That's scary; I was just thinking the same thing. I use numeric_bit conversion and logic functions in my bitwise integer functions. I wonder if simulators have accelerated operations for type bit/ bit_vector? You could just create a package that defines std_logic as a subtype of bit, and std_logic_vector as a subtype of bit_vector or numeric_bit.unsigned. So long as you don't use tri-states, etc. that might work pretty well, and likely be quicker than custom operators that remap 'u'; Initial values would get become '0' automatically. You'd have to re-create rising/falling_edge() if they had been used. Once upon a time, I wrote a replacement package for an old MVL7/MVL9 package, that created named subtypes of SL & SLV to match their original type names. I can't remember how I handled bit literals though.... I've often thought they should go back and re-define bit as a subtype of std_logic in the language for just this purpose, especially now that std_logic1164 falls under the main 1076 standard. AndyArticle: 123296
On Mon, 20 Aug 2007 17:53:02 -0700, "Eddie H" <> wrote:
>John,
>
>The load is is VCC referenced CML type. The positive rail is connected to 0.8V and VEE is connected to -2.5V. Do you think that I can use the TTL to ECL converter?
Sounds nasty, given the +0.8 Vcc. Most of the translators assume a
common 0v ground pin as both the TTL low and the ECL high.
>
>Thanks.
>
>Eddie
how about....
fpga---------R1--------+--------cml input
0/3.3 |
|
R2
|
|
|
|
-2.5v
which looks pretty good if R2 = 0.78 * R1
Does this have to be fast? Are the traces long? Those issues would
affect the absolure values of the R's.
John
Article: 123297Hi, Rob hit most of the points I would make. I would also refer you to http://www.altera.com/products/devices/cyclone2/features/power/cy2-power-compare.html -- this is our take on the Cyclone *II* vs. Spartan-3 power story. Regardless of how much of that material you believe (it can be independently verified with hardware from the two vendors), when you extend this comparison to Cyclone III devices, Cyclone III will clearly have lower power. I'll focus on dynamic power, since Rob didn't touch on it much. Both chips have the same Vdd supply voltage (1.2V). However, Cyclone III devices are manufactured in a 65 nm process vs. a 90 nm process in the case of Spartan-3 (and Cyclone II devices). This results in (a) a reduction in the linear dimensions of the chip and thus metal capacitance, and (b) a reduction in the size of the transistors and resulting capacitance. Overall, this leads to a ~30% (off the top of my head) dynamic power reduction compared to Cyclone II devices. On top of this, the Cyclone device family has been highly optimized for low area (e.g. cost). One side-effect of this is that the dynamic power for a given amount of logic tends to be lower than higher- performance families. On top of this, we found in Cyclone II device vs. Spartan-3 comparisons (referenced above) that the Cyclone II device's power was significantly lower (~1/2) than that of Spartan-3, despite being in the same process and with the same supply voltage. Bottom line: You should expect much lower power in Cyclone III vs. Cyclone II (you can trust us on that!), and thus it should not be hard to convince yourself that Cyclone III should have signficantly less power consumption than Spartan-3 (which is harder to trust us on :-)). Regards, Paul Leventis Altera Corp.Article: 123298
Hi, Hopefully I can be of assistance despite your use of an inferior part ;-p You mention 1.3W of power @ 104C, presumably at room temperature (25C) and nominal (1.2V) voltage with still air and no heatsink, measured on the case (?). How are you arriving at 1.3W? Is this just the current draw off VccInt x 1.2V? Remember that there is also current drawn off VccAux (65 mA * 2.5V = 163mW according to XPE). And assuming you have I/Os in your chip, there will additional power drawn from your VccO (for all I/O standards) and off-chip Vtt rails (if using terminated standards) -- more on that later. Assuming your 1.3W is correct, then you've got a ThetaCA (case-to- ambient thermal resistance) of (104-25) / 1.3 = 60 degrees per W!!! That seems unlikely, so I will assume that there is some additional source of power dissipation in your FPGA. With no air movement, I'd figure a thetaJA of ~15 deg/W is more reasonable (based on Cyclone III EPE). Assuming this is the case, you are burning somewhere in the neighbourhood of (104 - 25) / 15 = 5.3W in your FPGA (eek). I think you need to find that power source! First, I would check to be 100% certain that your I/Os are not shorted or nothing else bad like that is happening. Shorted I/Os (for example, unused I/Os driving ground but hooked up to a signal or vcc on the board) can really burn a ton of power. Measure your device temperature with the clocks completely disabled so that the only contributors are static core and static I/O power -- what's the temperature? Then run with the I/Os clocked correctly, but disable as much core logic functionality as possible. Even if your I/Os are not shorted, it would help to describe your I/O configuration. I/Os can burn a lot of power. Unterminated I/O standards (such as 3.3V LVTTL) will consume power to charge and discharge the (a) FPGA pin (b) PCB trace and (c) far-end load; all of this current draw is dissipated as heat inside the FPGA, and is irrespective of drive strength and slew rate (well, almost -- these will affect the short-circuit current, but unlikely to be more than a 10% impact). Terminated I/O standards are a whole other beast. There is a static current drawn through the voltage-divider network formed by your I/O drive transistor, the series termination resistor, and the near/far- end parallel termination resistor to Vtt. This is true regardless of whether you are driving a 1 or a 0. Only some of that current draw is dissipated as heat within the FPGA -- the rest is dissipated in off- chip components. This means that your *thermal power* will depend on the drive strength of your SSTL I/O -- the higher the drive, the higher the *system power* consumption but the lower the *FPGA thermal power* will be. You can download the Cyclone II or Cyclone III Early Power Estimator to play around with I/O standards and see how much power is dissipated on vs. off-chip for various configurations of I/O. All the data in that tool is from HSPICE simulations of our I/O buffer, and we've carefully seperated out on-chip power from system power/current draw. While Spartan-3 will have slightly different I/Os, they should behave similarly to first order so the trends/results should be good enough for your purposes. The tool is available at http://www.altera.com/support/devices/estimator/cy3-estimator/cy3-power_estimator_download.html. If you verify that indeed you aren't burning a ton of I/O power, next step is the core. This is trickier -- the best things you can do are to set clock enables on the global clocks, set clock enables on the FFs (which disables some local clocking), and only read/write to your RAMs when you really need the data. For example, don't be lazy with your FIFOs -- if you aren't using the read port on a given cycle, disable the read enable / clock enable on the block. You can also try area-driven synthesis (vs. speed or balanced mapping). This will result in smaller circuits which will tend to use less power (but not always). Hopefully you'll respond with some more information on your design and your measurements. If all else fails and your design really is running at 104C, and you can't slap a heat sink on it (without fan), then I'd suggest taking the bluer road and migrate your design to Cyclone III :-) Regards, Paul Leventis Altera Corp.Article: 123299
On Wed, 22 Aug 2007 08:19:12 -0700, tgschwind@tiscalinet.ch wrote: >I have a design on a Spartan 3 2000. It uses nearly all slices, two >thirds of the FF and LUTs. Also all BlockRam and all BlockMultiplier >are used. >The design uses three clock. A 40 Mhz clock for configuration and >registers, 80 Mhz for data processing, and 160 Mhz for internal >processing in certain blocks. > >The problem is that the device becomes hot, so hot, that you can burn >your fingers. I measured up to 104 °C on the FPGA Ituses nearly 1.3 W. >I have alredy implemeted ClockEnables everywhere possible. Also on >RAMs. I have already sythesized with Power Reduction option. > >The Device can't have a active cooling, like a fan. > >Does anybody have some advice how to further reduce the power ? 25 % >would be great. We epoxy pin-fin heatsinks to some of our Spartan chips. It cools them off and reduces prop delay creep. Makes them look very imposing, too, and hides the fact that they're just FPGAs. If they're not bga's, you can also put a "power pad" under them, and dump some additional heat into a ground plane. Some sort of thermal interface gunk would help. John
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