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
Nothing much in formal words yet other than a brief description here of Craignell http://www.enterpoint.co.uk/component_replacements/craignell.h= tml. The main points are FPGA XC3S100E or XC3S250E or XC3S500E. Pullups to input voltage that in currently version can range cica 3.7V - 5.5V. Bus switches protection FPGA I/O. Serial flash for loading and possibly code store for Microblaze. Initial parts we are fitting a 4Mbit flash but up to 16Mbit is possible. Headers for JTAG and SPI loading. Price for a one off from circa GBP=A330, 45 euro, US$60 depending on variation. We will have university discounts and OEM quantity discounts. John Adair Enterpoint Ltd. On 21 Mar, 10:24, Herbert Kleebauer <k...@unibwm.de> wrote: > John Adair wrote: > > > Going sideways on what you are looking for it is worth looking at a > > couple of ideas from our product line to allow the easy use of modern > > FPGAs. The first is our Craignell family > >http://www.enterpoint.co.uk/component_replacements/craignell.html > > which operate from 5V, in a DIL format, and are fully 5V tolerant. At > > the moment we do 32,36,40 pin versions but I expect to have 28 and 48 > > pin versions added to the range. Maybe a few others if someone gives > > us a good reason. > > > Almost a bigger brother our product Darnaw1 is waiting in our lab for > > a couple of days test before it goes into mass manufacture. This is a > > 2.54mm pitch PGA style module that lets you use a XC3S1200E/1600E > > Spartan. This module is 3.3V tolerant and operates from a single 3.3V > > input. The module also has spi flash and sdram to allow the > > implementation of fairly powerful processor applications. > > Sounds interesting. Are there any data sheets available?- Hide quoted tex= t - > > - Show quoted text -Article: 117051
Hi all, I am working on a project which needs matrix inversion (dense matrix) of order 40x40 with floating point numbers. I am in need of help in doing the same with systolic array architecture in an efficient manner. I am trying this in Verilog. It will be very helpful for me if anybody can give me an explaination for the architecture or a sample verilog code for implementing matrix inverse in systolic arrays. Thanks and regards, SivaArticle: 117052
On Mar 22, 9:30 am, j...@zilium.de wrote: > On Mar 22, 9:21 am, Rem...@gmail.com wrote: > > > > I'ts running on my Spartan-3E starter kit and I'm currently porting it > > > over to the > > > Altera Cyclone-II Starter kit. > > > > I don't have it integrated into the Eclipse IDE Lattice is shipping -- > > > but at least I've > > > got theCPUrunning in my own wishbone based SOC. > > I am just Altium User and I love the tool for sch capture, layout, > > SPICE and signal Integrity Analysis. > > haven't jumped on it with FPGA develpments. So far I've been using > > Xilinx ISE. > > Never used Altium -- can't comment on that. > > My workflow is far from nice. Although there are wishbone system > builders (Counting the Lattice IDE as one of them), my workflow for > Xilinx ISE and Altera Quantus still heavily depend on cut'n paste. > > > > I'ts running on my Spartan-3E starter kit and I'm currently porting it > > > over to the > > > Altera Cyclone-II Starter kit. > > > you really got my attention on Mico32, since my target hardware is > > Xilinx. How is performance running on Xilinx Spartan3, what clock > > frequency can you push it to. > > On my XC3S500E-4 I get between 90 and 95 MHz -- with default XST/PAR > options. So I'd expect 100MHz to be the limit. > > Takes < 1500 LUTs. > > I'll publish my ISE project as soon as I fixed some problems with the > DDR > controller. But that won't be before ~10 days. > > Porting the actual CPU is trivial -- only some small changes to make > XST > happy. > > > And thanks for clarifying this. I always thought that Lattice Mico32 > > is like Microbalze, with code tailored for specific architecture. Well > > I guess then it was one unselfish move from Lattice point of view :) > > LM32 ist straight-forward verilog RTL code. > > > Just have read that uClinux is in the process of being ported to > > Mico32. This open source project could really take off. > > Hope so. > > Having a mutually compatible set of OSS hard- and softwarecomponents > whould be really great -- and could bring a boost to reconfigurable > hardware. > > Sad, that there's no OSS toolchain for synthesis and par :( Or at > least > a common build system where different verndor tools could plug in. > Changing your FPGA vendor is still too much pain. > > j. > I'll publish my ISE project as soon as I fixed some problems with the > DDR > controller. But that won't be before ~10 days. I would be interested once you done. BTW, which DDR controller are you using? I've just done some reading on Mico32 on Lattice website, they mention a range of Wishbone compliant peripherals, including DDR contr, UART, DMA, SPI, etc. Are all of these cores available from Lattice under open source as well? If so, I wonder if they've reused any cores from opencores.org Using Mico32 on other than Lattice architecture would need to tackle solution for JTAG debugging. has anyone approached this yet? If Mico System Builder (MSB) can be used independantly from Lattice ispLEVER, then this package could be used to generate Wishbone Interconnect. RNArticle: 117053
I am trying to configure Spartan 3e (Starter Kit) with a Parallel Cable IV (J28) with flying leads instead of USB. The reason is that I must use flying leads with other fpga and first of all I prefer to try with my cheap kit. Does anyone know why impact give me the following error: I have only connected the flying leads with the j28 six pins; TDI, TD0, TMS, VCC... Welcome to iMPACT // *** BATCH CMD : setMode -bs // *** BATCH CMD : setMode -bs GUI --- Auto connect to cable... // *** BATCH CMD : setCable -port auto AutoDetecting cable. Please wait. PROGRESS_START - Starting Operation. Connecting to cable (Parallel Port - LPT1). Checking cable driver. Driver windrvr6.sys version = 8.1.1.0. LPT base address = 0378h. ECP base address = 0778h. ECP hardware is detected. Cable connection established. Connecting to cable (Parallel Port - LPT1) in ECP mode. Checking cable driver. Driver xpc4drvr.sys version = 1.0.4.0. LPT base address = 0378h. Cable Type = 1, Revision = 3. Setting cable speed to 5 MHz. Cable connection established. PROGRESS_END - End Operation. Elapsed time = 1 sec. Attempting to identify devices in the boundary-scan chain configuration...Command: Identify // *** BATCH CMD : Identify ERROR:iMPACT:2243 - A reference voltage has not been detected on the ribbon cable interface to the target system ( pin 2 ). Check that power is applied to the target system and that the ribbon cable is properly seated at both ends. The status LED on Parallel Cable IV will be GREEN if target voltage is in the proper range and applied to the correct pin.// *** BATCH CMD : identifyMPM ERROR:iMPACT:2243 - A reference voltage has not been detected on the ribbon cable interface to the target system ( pin 2 ). Check that power is applied to the target system and that the ribbon cable is properly seated at both ends. The status LED on Parallel Cable IV will be GREEN if target voltage is in the proper range and applied to the correct pin. Regards PabloArticle: 117054
Judging by the error you have a problem with the VCC or GND pin not being connected. The P-IV cable needs to 'sense' the voltage level on the board so it can drive the JTAG pins to the correct levels. Make sure the wires are seated properly, if they are then test the flying leads - they are easy to break! Ben "Pablo" <pbantunez@gmail.com> wrote in message news:1174568628.171929.227320@e1g2000hsg.googlegroups.com... >I am trying to configure Spartan 3e (Starter Kit) with a Parallel > Cable IV (J28) with flying leads instead of USB. The reason is that I > must use flying leads with other fpga and first of all I prefer to try > with my cheap kit. Does anyone know why impact give me the following > error: > > I have only connected the flying leads with the j28 six pins; TDI, > TD0, TMS, VCC... > > Welcome to iMPACT > // *** BATCH CMD : setMode -bs > // *** BATCH CMD : setMode -bs > GUI --- Auto connect to cable... > // *** BATCH CMD : setCable -port auto > AutoDetecting cable. Please wait. > PROGRESS_START - Starting Operation. > Connecting to cable (Parallel Port - LPT1). > Checking cable driver. > Driver windrvr6.sys version = 8.1.1.0. LPT base address = 0378h. > ECP base address = 0778h. > ECP hardware is detected. > Cable connection established. > Connecting to cable (Parallel Port - LPT1) in ECP mode. > Checking cable driver. > Driver xpc4drvr.sys version = 1.0.4.0. LPT base address = 0378h. > Cable Type = 1, Revision = 3. > Setting cable speed to 5 MHz. > Cable connection established. > PROGRESS_END - End Operation. > Elapsed time = 1 sec. > Attempting to identify devices in the boundary-scan chain > configuration...Command: Identify > // *** BATCH CMD : Identify > ERROR:iMPACT:2243 - A reference voltage has not been detected on the > ribbon cable > interface to the target system ( pin 2 ). Check that power is > applied > to the target system and that the ribbon cable is properly seated at > both ends. The status LED on Parallel Cable IV will be GREEN if > target > voltage is in the proper range and applied to the correct pin.// *** > BATCH CMD : identifyMPM > ERROR:iMPACT:2243 - A reference voltage has not been detected on the > ribbon cable > interface to the target system ( pin 2 ). Check that power is > applied > to the target system and that the ribbon cable is properly seated at > both ends. The status LED on Parallel Cable IV will be GREEN if > target > voltage is in the proper range and applied to the correct pin. > > > Regards Pablo >Article: 117055
On Mar 21, 5:11 pm, Eric Smith <e...@brouhaha.com> wrote: > mtsuka...@gmail.com wrote: > > Working with a coolrunner2 CPLD. Is there a way to erase whatever has > > been programmed into the CPLD, without using JTAG? > > Unless you're storing crytographic keys in the CPLD, what's the point > of erasing it without using JTAG? > > Dave Pollum wrote: > > As far as I know, the only way to erase/program Xilinx CPLDs is via > > JTAG. > > For erasure, thermite works too. A hammer may work but is not as certain. well... the CPLD I'm using is in a BGA package (which means I can't attach leads to the pins), and another device on the JTAG chain got stuck in reset, so the chain 'broke' and couldn't be accessed. That's why I was askingArticle: 117056
Martin Thompson wrote: > Dmitry Teytelman <dimtey@moc.liamg> writes: > >> Hello Daniel, >> >> On Thu, 22 Mar 2007, Daniel S. wrote: >> >>> Would the unimportant warnings in question happen to be the one >>> about PAR/MAP getting confused between PAD and IOB FFs timing >>> constraints? I am glad I saw this thread because I was about to make >>> the very same mistake to get rid of those warnings too! >> I added FFS(*) to the constraint to get rid of the following warning >> in the translation report: >> >> WARNING:XdmHelpers:662 - Period specification "TS_clk_ctrl_aclk4_dcm" >> references the TNM group "clk_ctrl_aclk4_dcm", which contains both >> pads and synchronous elements. The timing analyzer will ignore the >> pads for this specification. You might want to use a qualifier >> (e.g. "FFS") on the TNM property to remove the pads from this group. >> > > I reckon that warning ought to end with > "... but you probably don't as this might break all sorts of other > things unless you really understand what this does" > > :-) > > Xilinx: How about > a) A better warning > b) the ability to say "NOPADS" on the TNM property (or NOFFS, NORAMS > etc...) > > Cheers, > Martin I know the EXCEPT can be used to define timing groups but I'm not sure about the TNM_NET. I'd be interested to see if NET myclk TNM_NET = EXCEPT PADS(*) myclk; or NET myclk TNM_NET = ALL EXCEPT PADS(*) myclk; works. I think ALL may be a proper keyword but I forget the details. It might be a matter of 1) defining a catchall TNM_NET, then 2) redefining that timing group with the EXCEPT keyword. I'd love to see someone spend a few minutes with the constraints guide and see if they can get that error to go away in one or two statements to fully define the group. Personally, I don't push my clocks directly out onto pads (I'll run them though an ODDR2 primitive first) so I don't end up seeing the warnings. The syntax NET myclk TNM_NET = FFS(*) LATCHES(*) MULTS(*) RAMS(*) myclk; (and any othere synchronous elements I've forgotten) is another approach that should work.Article: 117057
Okay.... Have you hooked up the reference voltage flying lead to the appropriate JTAG voltage level? Does the little light on the pod turn from amber to green when you do? That's the indicator it has a valid voltage. Pablo wrote: > I am trying to configure Spartan 3e (Starter Kit) with a Parallel > Cable IV (J28) with flying leads instead of USB. The reason is that I > must use flying leads with other fpga and first of all I prefer to try > with my cheap kit. Does anyone know why impact give me the following > error: > > I have only connected the flying leads with the j28 six pins; TDI, > TD0, TMS, VCC... > > Welcome to iMPACT > // *** BATCH CMD : setMode -bs > // *** BATCH CMD : setMode -bs > GUI --- Auto connect to cable... > // *** BATCH CMD : setCable -port auto > AutoDetecting cable. Please wait. > PROGRESS_START - Starting Operation. > Connecting to cable (Parallel Port - LPT1). > Checking cable driver. > Driver windrvr6.sys version = 8.1.1.0. LPT base address = 0378h. > ECP base address = 0778h. > ECP hardware is detected. > Cable connection established. > Connecting to cable (Parallel Port - LPT1) in ECP mode. > Checking cable driver. > Driver xpc4drvr.sys version = 1.0.4.0. LPT base address = 0378h. > Cable Type = 1, Revision = 3. > Setting cable speed to 5 MHz. > Cable connection established. > PROGRESS_END - End Operation. > Elapsed time = 1 sec. > Attempting to identify devices in the boundary-scan chain > configuration...Command: Identify > // *** BATCH CMD : Identify > ERROR:iMPACT:2243 - A reference voltage has not been detected on the > ribbon cable > interface to the target system ( pin 2 ). Check that power is > applied > to the target system and that the ribbon cable is properly seated at > both ends. The status LED on Parallel Cable IV will be GREEN if > target > voltage is in the proper range and applied to the correct pin.// *** > BATCH CMD : identifyMPM > ERROR:iMPACT:2243 - A reference voltage has not been detected on the > ribbon cable > interface to the target system ( pin 2 ). Check that power is > applied > to the target system and that the ribbon cable is properly seated at > both ends. The status LED on Parallel Cable IV will be GREEN if > target > voltage is in the proper range and applied to the correct pin. > > > Regards PabloArticle: 117058
Paul, Thanks for this morning's good laugh. Wondered where you were hiding. Welcome back. AustinArticle: 117059
On Mar 22, 5:34 am, Herbert Kleebauer <k...@unibwm.de> wrote: > cs_post...@hotmail.com wrote: > > On Mar 21, 5:22 am, Herbert Kleebauer <k...@unibwm.de> wrote: > > Is this an engineering major's course or some sort of survey thing? > > These are not electrical engineering but computer science students. > Their job will be to design software and not hardware systems. But > in order to do a proper software design, you need to understand the > principles of the underlying hardware so you get a feeling what a > few lines of HL code can mean for the hardware. Yes, that's why you look at some parts of the problem in depth. But the key to being a working engineer - especially a software engineer - is becoming comfortable with the uses (and wary of the potential ABuses) of abstraction. > I don't know if all the supporters of VHDL/Verilog/HandleC here have > done low level logic development using a graphical representation and > just don't recognize how important that is to become a good designer > at VHDL level. The problem I see is that you are making the assumption that _graphical representation_ is the only appropriate way to do low level design. I'd argue it generally isn't. More suitable low level design notations are things like minimum-sum- of-products equations, and the Karnough maps that one might use to create those by hand. Sum of products is directly implementable in hardware - you could indeed have them draw some representative examples as gates. But it's a much better notation system when you find it necessary to take the black boxes apart and look at their functionality. Conversely, if you've got most of the functionality as black boxes, and putting in a single NAND symbol gate somewhere to show how a some interrupt signal works or something is a great idea. But don't draw the ALU using logic gates - instead, draw a half adder using gates, and then draw a full adder made from half adders, or get into carry chains, or whatever. > But if you know > the layout of the city and you know that there is a river with > only two bridges where you have to wait a long time because of > the high traffic and you also know that there is a small bridge > which could only be passed by foot, then you could do a much > better job by driving to the small bridge, cross the river by foot > and use an other taxi on the other side. A key reality that you are refusing to acknowledge is that you will not receive an actual "map to the city" of anything but a first- generation FPGA. That kind of detail is proprietary. What you get on the data sheet is a programming model, with a lot of things already hidden from you. Using an FPGA to implement something that you've designed at the gate level is not a bad idea, but you must come to terms with the fact that your gate level design is only theoretical - even if you draw it in schematic entry, the tools is going to refactor it using its knowledge of the proprietary details of the hardware. So what I'm saying is, if you want your students to do low level implementation, that is fine - but as they will in reality be implementing agaisnt a theoretical technology rather than a real one, pick an academically convenient theoretical technology (rather than a dated commerical programming model) and handle the inevitable translation to a purchasable chip in a more elegant way. - Come up with a schematic entry tool if you really want to, that spits out gate-level VHDL. - Come up witha preprocessor tool that allows students to code in a gate-and-register logic language - either a subset of a real language like Verilog or VHDL, or a made up academic one. > The same is true for software: if you know how the hardware > works you maybe can choose a different approach to solve the > problem which is much more appropriate for the hardware. In today's world you do not in fact get to know how the hardware works for a processor either. Instead, you have to work against a programming model published by the processor vendor - hopefully it is not a model that causes the actual hardware to thrash around doing things that do not suit it well. It's been a long time since an x86 CPU actually ran "native". > The purpose of Universities is not to teach the students the > use of tools but to teach them how to recognize, analyze and > solve problems. The tools you use to solve the problems change > rapidly but the ability to understand the source of a problem > and analyze it from all angeles without using blinders is an > essential requirement for the whole life. And ever since we stopped designing chips on single pieces of paper, the number one skill for a solving problems has been developing a healthy relationship with the _concept of abstraction_. > Sorry, but it really doesn't matter whether the AND gate is implemented > as AND gate, by multiplexers or as a look-up table. They have learned > that this all is equivalent and that the order of complexity is the > same. But they must learn that there is big difference in the complexity > for the ALU operation "add" and "div" and they don't see this in > the VHDL source code. They most certainly will see this in the VHDL source code if you have require them to code up the ALU functionality from sufficiently small building blocks! Case in point: I re-did one of my computer archictures courses using Verilog and Xilinx FPGA, in place of the theoretical simulation. The course work walked you through building all the pieces of the ALU functionality - shifter, adder, etc... but left out hardware multiply. So I resigned myself to not using multiply. Unfortunately, when I moved on from low level assembly programming to trying to get some real work done with gcc, I couldn't convince it to not generate multiply instructions (even for things where there would have been better choices). So I decided to cheat... I instantiated a spartan-3 multiplier. The result is that I have a very good idea how my project accomplished all the other functions, but only a vague sense of how it multiplies. And that was a strategic choice - had I wanted to know about how the multiplier works I could have eventually built one, but I was satisfied with understanding the rest of the ALU, and I know that the hardware mutliplier in the spartan is much better than any FPGA-fabric implementation. The moral? Pick your battles. Your course project doesn't have anything that can't easily be implemented as gates and registers, so let your students implement in a gates and registers programming model. But recognize that just because a language will let you utilize fancy functions like a hardware multiplier does not mean that you have to choose to do so, or let your students do so. There is nothing but obstinance stopping your student from doing very educational gate level implementation in a language also capable of higher level functions!Article: 117060
Paul, Very good post. I agree with everything (thanks for the fruit basket) except the loading comment. The interconnect design is such that all paths are buffered, so the only way to take more loading into account is to move up to the more complete tool, which uses the placement, and the resources, and the transition file. After all, it is not called an "estimator" because it is exact. Good luck with the roll-out of all the C3 family. AustinArticle: 117061
Paul, Perhaps we have different architectures for RAM blocks? AustinArticle: 117062
> The interconnect design is such that all paths are buffered, so the only > way to take more loading into account is to move up to the more complete > tool, which uses the placement, and the resources, and the transition file. I'm not talking about pure electrical loading. From a topological perspective, if you have a FF that fans out to 1 destination vs. a FF that fans out to 5 destinations, I would expect the latter FF to have more wiring than the former (all other things being equal). As you increase the number of sinks on a net, the wirelength of that net increases (sub-linearly). Wirelength = power, even with buffers -- if you need 4 buffers + 4 wires you will consume more routing power than if you need 1 buffer + 1 wire. In addition, as you point out, the loading on each wire will impact the power burned. If you're using the Quartus II PowerPlay Power Analyzer, then all this stuff is taken into account. The exact pieces of metal used in each route are factored into the power analysis -- in fact, Quartus even looks at the shape of the waveform at each buffer to derive short- circuit current, in addition to computing the current due to capacitive charging. The EPE tool obviously doesn't know the P&R of the design, so it must guess the # of wires or total power of the routing. We break our power estimate into two pieces -- block power and routing power -- to make clear how much of our estimate is high-confidence (block power) vs. lower-confidence (routing power). Returning to the XPE tool, the FF power *should* be including associated routing, since it's not accounted for anywhere else in the tool. However, the power of the FF is low, and doesn't change with the fanout of the FF. This just doesn't make sense. Regards, Paul LeventisArticle: 117063
> Perhaps we have different architectures for RAM blocks? We've run our RAM power characterization patterns various Xilinx and Altera chips. While the absolute results vary somewhat with the organization (width x depth) of the implemented RAMs, both of our devices behave similarly with RAM data pattern, enables, etc. Which makes sense, since at the end of the day, a RAM is a RAM -- if you read it, you burn power. If you stop reading it, you burn less power. Customers who have many RAMs in their design clocked at high frequencies and don't bother shutting them off at all will burn more power than they need to, regardless of their vendor. - PaulArticle: 117064
Yes, I know that led light must turn from ambar to green . That is the problem. The light doesn`t turn to green, so Parallel Cable IV doesn=B4t "feel" the reference problem. I suppose I have to configure spartan 3e to program from PC IV instead of USB. RegardsArticle: 117065
"Paul Leventis" <paul.leventis@gmail.com> wrote in message news:1174576872.128881.281150@p15g2000hsd.googlegroups.com... >> Perhaps we have different architectures for RAM blocks? > > We've run our RAM power characterization patterns various Xilinx and > Altera chips. While the absolute results vary somewhat with the > organization (width x depth) of the implemented RAMs, both of our > devices behave similarly with RAM data pattern, enables, etc. Which > makes sense, since at the end of the day, a RAM is a RAM -- if you > read it, you burn power. If you stop reading it, you burn less power. > > Customers who have many RAMs in their design clocked at high > frequencies and don't bother shutting them off at all will burn more > power than they need to, regardless of their vendor. > > - Paul To help users like me understand what's burning when a RAM with an active ENA but no change in address or data is left alone clock after clock, what dynamic power is there? You mentioned "precharging" which - to me - suggests DRAM as opposed to SRAM. The SRAM cells still have the bit lines, still have the decodes, still have the same contents. If the address buffers don't change, register contents don't change, ram contents don't change, where's the dynamic power? I appreciate the insights, - John_HArticle: 117066
Your code accesses multiple locations in the data array on the same clock cycle. RAMs cannot do that (dual port rams can access two addresses simultaneously). Redesign your code/design to avoid accessing more than one location in the array. Andy On Mar 20, 12:26 pm, "CMOS" <manu...@millenniumit.com> wrote: > i have a byte array of size 10 and i need to shift values in the array > to left by 5 positions in 5 clocks. > here is the code im using. > > reg [7:0] data[0:9]; > > // data shifting process > reg ps_shift_start; > reg ps_done; > > reg [1:0] ps_state; > parameter ps_s0 = 2'b00; > parameter ps_s1 = 2'b01; > > reg [12:0] ps_shift; > integer ps_index; > > always @ (posedge clk) begin > if(reset == 1) begin > ps_done <= 0; > ps_state <= ps_s0; > end > else begin > case(ps_state) > ps_s0: begin > if(ps_shift_start == 1) begin > ps_done <= 0; > ps_shift <= 0; > ps_state <= ps_s1; > end > end > // > ps_s1: begin > if(ps_shift < 5) begin > for(ps_index = 0; ps_index < 10; ps_index = ps_index + 1) begin > data[ps_index] <= data[ps_index + 1]; > end > end > else begin > ps_done <= 0; > ps_state <= ps_s0; > end > end > endcase > end > end > > the problem is XST syntherziser infferes lot of flip-flops for the > signal 'data'. is't is possible to use > distributed RAM for signal 'data'. if posssible, how do i do that? > > thank youArticle: 117067
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:46020799$1@clear.net.nz... > Thanks Steve, - can you comment on the relative effort/quality of the HDL > branches for VHDL/Verilog/Abel(CPLD), and the long term plans for the XST > Simulator (relative to Modelsim et al ) ? > > -jg The effort going into VHDL and Verilog is about the same. ABEL is in maintenance mode so only gets attention when serious bugs are reported. "MM" <mbmsv@yahoo.com> wrote in message news:56fnqfF28iph7U1@mid.individual.net... > Hello Steve, > > Would you now be willing to comment on the MAP and PAR quality? To me this > is a much bigger problem than XST not supporting certain aspects of VHDL. > Based on experience I have learned to write my code using only a small > subset of the language, which is supported for sure. > > Thanks, > /Mikhail > There seems to be an infinite number of things our users can implement in an FPGA so it's impossible to find every bug. However, less than 15% of the map and par bugs are found by customers and we continue to try to lower that number. In 7.1i, we replaced our database and took a hit for map and par quality. Since then, we have improved considerably, and have made quality the highest priority for 9.1i and future releases. Other priorities for map and par are new device support, QOR, runtime, incremental design and partial reconfiguration. SteveArticle: 117068
Hi John, I'm no RAM designer, but I'll give it a shot... > You mentioned "precharging" which - to me - suggests DRAM as opposed to > SRAM. The SRAM cells still have the bit lines, still have the decodes, > still have the same contents. If the address buffers don't change, register > contents don't change, ram contents don't change, where's the dynamic power? A common way that SRAMs are designed is to take an MxN array of SRAM cells (for example, standard 6-T cell). The address is decoded into a word line signal, one per row of the SRAM -- when that signal is high, the SRAM cell outputs are connected to the bit and bit-bar lines (one for the +ve side of the cell, one for the -ve). So you have N*2 bit lines running through the SRAM. The way a read happens is you first pre-charge the bit lines to some reference value (Vref). Then, you strobe the word line for the cells of interest. The bit and bit_bar will be pulled in opposite directions by the cell. A sense amp listens to the difference on a bit line pair, and once some threshold is passed, it decides it must be reading a '1' or a '0'. What happens after this is not important -- you could disable the word line and pull the bit lines back to Vref, or let them continue pulling apart, etc. Why do you pre-charge? One reason I can think of is that otherwise your read could be destructive. In a simple SRAM, the transistors you use to read the SRAM cell are the same ones used to write to the cell. So if your bit lines are at 1/0, and you open up the access transistors, you might ending writing 1 into the cell instead of reading the 0 that was contained in it. Another reason is for power. If you let the bitlines swing only a little bit apart, register the value, and then push them back to Vref, you don't swing the voltage on the bit lines as much, and thus reduce power. This is also important for speed -- you don't have to wait for the long, relatively highly loaded bit lines to swing fully before figure out what value is stored in the memory. What does all this mean for power? Well, if you execute a read in the RAM, of the same location with the same value in it, you are always pre-charging to Vref and then swinging the signals to the value you want to read. So the *core* of the RAM burns constant power. Of course, there is a lot of other circuitry in the RAM. The address decoder, for example, won't burn any additional power if you haven't changed the address. The output registers and output logic of the RAM will not burn any power if the value read from the RAM doesn't change. Etc. All of these effects are modeled in Quartus for our 90nm and 65nm families. The EPE also makes a good guess at this (which is why there are the variety of enable %s you need to provide). In our RAMs, there are a number of clocks and enable signals that go into the RAM. Some of these control what data is registered into the input data & address registers when, what is registered into the output registers & when, and whether the core of the RAM is clocked. By intelligently hooking up these signals, you can ensure that only the bits of the RAM are operating when you need them to, which can reduce your power significantly. Things get funkier when you start thinking about FPGA configurable RAMs. You have a variety of modes for the RAM -- single port, dual port, x1, x9, x18, etc. If you are using a block that is natively 18x512, but only using it in x8 mode, do burn the read power of x18 mode or is the RAM smart enough to read only part of the array? If you're only using half the depth, is the RAM array segmented in some way to avoid burning some of the power? We have a variety of techniques (circuit, architecture, and software) we employ to optimize speed, area and power in the presence of this configurability. Hope this helps, Paul Leventis Altera Corp.Article: 117069
Actually, it's simpler: you don't have a valid VCC and GND hookup. Get a volt meter. If you have nothing else hooked up except VCC and GND to valid levels, you should get a green light. "Pablo" <pbantunez@gmail.com> wrote in message news:1174577212.710465.258760@o5g2000hsb.googlegroups.com... Yes, I know that led light must turn from ambar to green . That is the problem. The light doesn`t turn to green, so Parallel Cable IV doesn´t "feel" the reference problem. I suppose I have to configure spartan 3e to program from PC IV instead of USB. RegardsArticle: 117070
Hello Steve, Would you now be willing to comment on the MAP and PAR quality? To me this is a much bigger problem than XST not supporting certain aspects of VHDL. Based on experience I have learned to write my code using only a small subset of the language, which is supported for sure. Thanks, /MikhailArticle: 117071
Paul, The lemons in the basket were especially good, by the way. The 36K BRAM block in V5 is built as four separate 9K blocks, so if the BRAM is arranged such that it can power down half, or 3/4 of the arrays, it will. This is another trick that gets used to limit the power, and burn those mA only when it is required. In addition, the DSP48E blocks have local dedicated interconnect so that a filter can be made with no fabric interconnection, excepting the inputs, and outputs. This also saves a tremendous amount of power. Regardless of the small details in the estimators, the overall result is very useful in comparing power between devices, and product offerings. I would only ask that one tries a number of different designs if trying to decide "best" performance. My example was just trying to target ~80% of all resources, running at 100 MHz, near a Tj of 85C. As the ad goes "your actual results may vary." AustinArticle: 117072
> Regardless of the small details in the estimators, the overall result is > very useful in comparing power between devices, and product offerings. Unfortunately, when it comes to comparing dynamic power between vendors, I don't think these tools are too useful. In order for such a comparison to be valid, one must assume that both companies invested similar engineering resources into the tools, both companies strive to faithfully respresent the typical design case, and that no one is trying to cheat in order to make their power look better. Perhaps the lack of an XPE FF power model and ignoring clock power are simple mistakes or poor engineering choices. However, given how long those "bugs" have been in the tool, I can't help but think there are marketing reasons behind them. Regards, PaulArticle: 117073
> > I wonder how it should be possible to work with > > even larger FPGAs!? > > For larger FPGAs, we recommend 64bit Linux systems. Hi, While this will not help you for your Virtex designs, going the Quartus II + Stratix II/III route does offer substantially lower memory requirements. Most designs up to a EP3S200 should compile on 32-bit Windows (<=2.0 GB of RAM). For the largest designs (EP3S340), you will usually need 3.5 GB of RAM and occasionally up to 4.0 GB. At that point, your options are to run 32-bit Quartus on 32-bit Linux, or run 32-bit Quartus under 64-bit Windows/Linux -- Windows XP-32 maxes out at 2GB per application, but linux and 64-bit OSes provide close to the full 4GB of virtual memory for a 32-bit process. You shouldn't have to move to 64-bit Quartus unless you are running an unusually complex EP3S340 design. As you can see from the linked data below, once you need to move to 64-bit, your RAM requirements increase. This is due to the increase in size of all pointers from 32- to 64-bits. See http://www.altera.com/products/software/products/quartus2/memory/qts-memory.html for more details. Regards, Paul Leventis Altera Corp.Article: 117074
Paul, I would not be the one to throw mud at the other (on power estimation)! The question of who has the more "honesty" in marketing is one that you or I are unlikely to get any sympathy for in this forum. All I will say, is that since I run the verification and characterization shop, and I see the actual power numbers, the time spent on the subject with all 5 process corners for all three oxide transistors, is immense. And, until you actually have all this data, the typical is really meaningless. And as such, our tendency is to choose the process corner fast 1-sigma as "typical" initially. It has been clear (to me, by using your tools for S2, using actual measurements on the 'Battle-Board') that your policy is different. That is OK. You had your disclaimer clearly visible. That is being honest. I also agree that dynamic power does not vary hardly at all with process or temperature. I will say that estimating dynamic power is also very difficult, as the customer not only has to have a vector file from his simulations, but that vector file has to be faithful to their application, and cover actual intended operating situations. The number of customers with the patience to run extensive simulations and check to see how "real" they are is not a large number. Most will find the initial estimate from the spreadsheet adequate for their first guess at power supply and heatsink. After their prototype pcb is built, there is the opportunity to fine tune the power supplies and cooling (if needed). I wish engineers were more disciplined, and spent more time on simulation, but FPGA devices are marketed as "fast to market" and many sometimes take that as "not much risk to skip a few steps..." One more thing: prunes in a fruit basket? I'd like to know what on-line shop you used... Gotta run, Austin
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