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
chrisjc31415@yahoo.co.uk (Chris Cowdery) writes: > I've got a cut down PCI design which works nicely in a > MAX7256SQC208-7. I have changed device to a FLEX10KA30-1 to port it to > CardBus. > > What I do not understand is why the simulation shows that the design > on the FLEX10K part has delays of about twice that of the 7256, even > though the flex part is a -1, and the max is a -7? Thus the timing > becomes marginal to say the least, yet the datasheet claims PCI 33MHz > compliance. > IIRC the -7 is a pin to pin delay for the MAX parts, whereas the -1 is the propogation delay through a LE in the FLEX parts, or somethingl ike that. Anyway, the arhcitectures are completely different, so the 'speed' number means something completely different. In fact in the FLEX parts going up a device size in the same speed grade can slow the design down due to the longer 'wires' used in the larger parts... > Any ideas? > Wide logic is more expensive timewise in the FLEX archtecture than in MAX chips, as the 4-LUTs need to be cascaded using the cascade chain, whereas the MAX logic element has a larger number of inputs (can't remember how many, its been a while since I used a MAX chip). You have more registers in the FLEX part so pipelining can help, but I imagine not in this case as it's a PCI interface! All I can suggest is using the timing analyser to find the critical paths and see how you can optimise them. Or go back to the 7256... Sorry not to be more help! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 39026
>I don't remember the output voltage of a Li-ion battery. Is it higher >than 3.3 volts so that a simple LDO regulator is sufficient? I seem to >recall that the MSP430 will operate down to 1.8 volts but needs more >like 2.7 volts to program it's internal flash. BTW, the high end >MSP430F148/9 have 48/60 KB of Flash on chip. If your program only takes >1 or 2 kBytes, you might be able to use the internal Flash for your >data. But I assume you need it to be removable. > >Just for my own benifit, how many mAHours can you get from a Li-ion cell >running a device at 2.7 or 3.3 volts? You might also consider using a >small switcher to optimize your efficiency and make the unit run when >the cell drops below (or starts below) the operating voltage of your >chips. They can be very small, but of course they cost a bit more than >an LDO. The Li-ion battery from my digital camera (Sony) says 3.6V 4.1Wh. Camcorders have bigger batteries which are, well bigger, and heavier and hold more power. NiMH AAs get a lot of use in digital cameras. Raw lithum is generally better (more power per pound/cell) if you are willing to work with non-rechargable technology. Digital cameras are nasty to batteries because of the high current drain. Other technologies may work better for very low loads. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 39027
Geert Van Doorselaer wrote: > > Our idea is to use the Hard-drive memory to store the various FPGA > > configurations, and to use a small 32 I/O MCU (8051) to perform the FPGA > > reconfiguration from the HDD. (the 8051 would share the IDE bus with the > > FPGA, but they would have a mutual exclusive use of the HDD, since the > > MCU would only be used during reconfiguration) > > This means that your FPGA should contain 'code' to access your hard drive. Absolutely ! > > Why not assigning this job to the MCU (as it is already implemented for the > (re)configuration of the FPGA). This will create less overhead in your FPGA. Yes, but the interface is likely to be very slow (in don't imagine getting close to the ATA-5 timing (>33Mhz) with a 80C51). > > Now we are wondering whether this idea is good or not :), we are > > specifically concerned with : > > The idea itself looks challenging ... If power consumption is not a big > issue here ... Why not? > > - PCB layout and signal integrity problems due to the fact that the IDE > > connection is shared between the MCU and the FPGA. For ex. would it be > > possible to use high-speed IDE (50Mhz clock) protocols from the FPGA ? > > > > Is this 50MHz clock really needed? If not, the MCU can handle this task. It is needed, since we want to perform processing on the data stream coming from the hard-drive (we are building a kind of network attached storage device). > > - Feasibility : How difficult would it be to design and debug such a > > system ? > > Less development and debug time when you don't implement the IDE interface > on your FPGA. > > > > > Any advice, comments, critics, ideas are welcome, > > > > Just my thoughts ... Thanks, > > Thank you in advance. > > Steven > > > > You are welcome, > GeertArticle: 39028
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:3C575644.364D6C8F@yahoo.com... > Arash Salarian wrote: > > > > First of all, thank you all for your answers and help. > > > > "Ulf Samuelsson" <ulf@atmel.REMOVE.com> wrote in message > > news:CYu58.6963$O5.17299@nntpserver.swip.net... > > > > > I'm starting a new design in which I'm using a multi-channel A/D with > > a > > > low > > > > > sampling-rate and Flash memory for the storage and the system is going > > > to be > > > > > powered by battery. In this stage, I'm not yet sure if using a FPGA > > > would be > > > > > wise, as I'm very concerned with the power consumption. The gate count > > > of > > > > > > You need to tighter specify what your requirements > > > How much data? > > I'm going to use 4 channels of A/D at 200Hz, but only to store 3 of them > > (one is used to monitor the battery). Data is stored on a Flash, MultiMedia > > Card (i.e. SPI interface...) with 64+Mbytes. That means the the system > > should be able to function over 15 hours by using a small Litium-Ion > > battery. > > I don't remember the output voltage of a Li-ion battery. Is it higher > than 3.3 volts so that a simple LDO regulator is sufficient? I seem to > recall that the MSP430 will operate down to 1.8 volts but needs more > like 2.7 volts to program it's internal flash. BTW, the high end > MSP430F148/9 have 48/60 KB of Flash on chip. If your program only takes > 1 or 2 kBytes, you might be able to use the internal Flash for your > data. But I assume you need it to be removable. > > Just for my own benifit, how many mAHours can you get from a Li-ion cell > running a device at 2.7 or 3.3 volts? You might also consider using a > small switcher to optimize your efficiency and make the unit run when > the cell drops below (or starts below) the operating voltage of your > chips. They can be very small, but of course they cost a bit more than > an LDO. I'm considering using a Li-ion battery from Renata (ICP633027) wich is small is size (27x30x6.3 mm) and has a 300mAh capacity. The voltage is between 4.1 to 2.75 over the dicharge period and I guess although the 4.1v is more than the recommened value for the MCU, yet as it's within the absolute maximum range, would be OK. Well I'm not sure if this is a good practice, an have to investigate more as omitting the LDO is so nice but the effect of running the device out if it's recomended rating for a long period is not that beautiful... Anyway, I'm going to use one channel of the A/D to monitor the battery level, so switching the LDO on a certian point of the discharge curve is an option but all this means area and weight and I'm too conservative about them in this design.. > > > > How often do you want to store it. > > Interface to the MultiMedia card is packet based, so data is going to be > > soted in packets of 512 bytes.... > > > > > Resolution/speed of A/D. > > 12 bit A/D with 200Hz sampling rate. > > This is a very low performance task. If you don't need high timing > resolution, you can get away with a 32 kHz clock on either the MCU or > the FPGA. But Jim's idea of running at a higher clock speed while > writing to the Flash card is good. The Flash card can be powered down > between writes saving a lot of power. > > If you use an FPGA, you will need an external ADC (which can be as > simple as some high tolerance resistors and a comparator depending on > how consistent the output drive voltage is) . But at a 200 Hz sample > rate, this can be powered down between samples as well. You will also > need an external oscillator. I don't have a part number for you, but I > am sure there are small, very low power 32 kHz devices available either > with or without a crystal included. > > But this is starting to make the MCU look cheap in comparison. > > > > An FPGA does not have an ADC internally, so you need to add power for > > that. > > > > > > The Atmel AVR will draw less power than the Atmel 8051. > > > I'd try out with an ATmega8, which has internal R/C oscillator and power > > > down mode. > > This sounds like a good idea. The MSP430 has that as well as do many > chips. But certainly the Atmel devices have a lot to offer. > > > > -- > > > Best Regards > > > Ulf at atmel dot com > > > These comments are intended to be my own opinion and they > > > may, or may not be shared by my employer, Atmel Sweden. > > > > > > > Btw Ulf, What's your idea about MSP430 series suggested by Jim Granville? > > Ulf is an Atmel representative, so it is not likely he will say much > about a TI product. He would be ill advised to say anything good for the > sake of his job and won't say anything bad for being thought of as > badmouthing the competition. :) Even if we ask... > > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 39029
I've got a module that has a bunch of combinatorial logic that is instantiated via generate statements, and also has two synchronization registers. For various reasons, that I cannot go into, I don't want the synthesizer to optimize out redundant logic, so I put a dont_touch attribute on the module ... so far so good. When I look in the FPGA editor, it looks like the combinatorial logic has been compacted into the LUT's, so there does not appear to be a 1:1 correspondence between the instantiated combinatorial logic and the LUT's. What I want to do, but don't know how best to proceed, is to be able to locate this module to a specific area of the FPGA. My first preference would be to put attributes or something in the VHDL to do this. My second preference would be to use the UCF if possible. My third preference is to use the floorplanner or whatever. I currently am using FPGA Express, but would be willing to go through the hassle of sharing a dongle with my co-workers if Synplicity gets me there via the VHDL approach. Thanks for taking the time to read about my dilemma. NewmanArticle: 39030
Exactly. Beats the heck out of boolean analysis to figure out how many cells it will occupy. I remember using the Atmel 6K extensively for bit serial stuff in the early 90's (see my FIR filter paper from '92). With that device you had to become best of friends with deMorgan, and you spent an inordinate amount of time doing logic analysis to get a fast compact design. For it's time though, the device could be extremetly fast, and it had more flip-flops than any other FPGA by a significant margin. Peter Alfke wrote: > Whether it is 65,000 or only a few thousand, a LUT is a very versatile tool. I > still remember my enthusiasm when, arriving here at Xilinx, I could draw a > circle around any piece of logic with 4 inputs + one output ( and no flip-flop > inside) and I could say: "Fits into one LUT, I don't care how, let's go on". > Gets your mind off the nitty-gritty :-) > > Peter Alfke -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759Article: 39031
What are you're thoughts about Java and other bytecode processors? Is anyone out there using them? We are developing a bytecode processor for a high-level language (i.e. NOT Java), and I'm curious as to what people think of these things. --Scott Thibault Green Mountain Computing Systems, Inc. http://www.gmvhdl.comArticle: 39032
Steven Derrien wrote: > > Hello, > > This post is just for submitting an idea to those who are familiar with > embedded system design, in order to get some feed-back (with respect to > feasibility, cost, usefulness and so on?). > > The basic idea is the following : > > We want to design a reconfigurable SoC, which will be connected to an > IDE hard-drive, used by the application running on the SoC. One of the > key point, is that we need to perform dynamic reconfiguration of the > FPGA. > > Our idea is to use the Hard-drive memory to store the various FPGA > configurations, and to use a small 32 I/O MCU (8051) to perform the FPGA > reconfiguration from the HDD. (the 8051 would share the IDE bus with the > FPGA, but they would have a mutual exclusive use of the HDD, since the > MCU would only be used during reconfiguration) > > Since the FPGA should be a relatively big Virtex/Spartan-II, and since a > large density configuration EEPROMs (several Mbits) are quite expensive > compared to a small MCU, we feel that this could be a nice way to reduce > the total system cost. > > Now we are wondering whether this idea is good or not :), we are > specifically concerned with : > > - PCB layout and signal integrity problems due to the fact that the IDE > connection is shared between the MCU and the FPGA. For ex. would it be > possible to use high-speed IDE (50Mhz clock) protocols from the FPGA ? A standard IDE interface supports 2 devices on the cable, that is, 2 cmos inputs per signal. I have the PCB of an old IDE drive in front of me and it looks like they use a series termination of 330 Ohm between the cable and the ASIC. My suggestion is to have a close look at a modern harddrive and mime that circuitry for your microcontroller. Then you connect the controller instead of the second disk. This way, the micro will load the signals like a slave disk does. For the transfer speeds you are going to achieve with the micro, the weird cable shape shouldn't matter. #============#=====# IDE PORT HDD1 HDD0 #============#=====# FPGA uC HDD > > - Reliability : since the hard-drive will be used for both read and > write operation during the application, we must ensure that some part of > the HDD storage is locked (to guarantee that the configurations are not > overwritten by mistake) I don't think there is an easy way to 'lock' part of the disk without changing the disk's firmware. If you can control the IDE IP in your FPGA, you could ignore write requests for a certain block range... > > - Feasibility : How difficult would it be to design and debug such a > system ? Not having done it myself - it shouldn't be too hard, as long as you have a good logic analyser... ;^) Have a nice day, IwoArticle: 39033
synthesis generally doesn't allow don't cares as a mask to compares. Instead use the std_match function in ieee.numeric_std. Falk Brunner wrote: > Hello everyone, > > Iam using ISE & modelsim for a few weeks, things are getting better ;-) But > doing a plain functional simulation of comparators using dont cares does not > work. Yes, there is a warning in the docu of ISE about the use of dont > cares, but is thereno workaround for this?? Can I write my own resolution > function to make a dont care really dont care?Anyone has done this before > and got some code? > > -- > Regards > Falk -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759Article: 39034
Rick, True, the I grade improvement is smaller than the C grade improvement. Kick starting that 'bike on those cold -40C mornings is hell. Austin rickman wrote: > Tim wrote: > > > > Sorry to return to this topic yet again... > > > > XAPP450/451 show the SpartanII power-up current requirement as > > 500mA for _all_ parts, provided the temperature requirements > > are met. > > > > However, I have a distant recollection that someone (Austin?) > > has at one time posted that the smaller parts need less than > > this? Any ideas on the slope of the curve from the 2S15 > > to the 2S200? > > > > I am particularly interested in the 2S30. > > I'm not a Xilinx rep, but I have had a couple of conversations with Kim > Goldblatt about this. Basically, they are very confident that they will > be able to reduce the curve somewhat, but I seem to recall that the > improvement was not large. But that may be due to the chip I was asking > about, the XC2S50, IIRC. This device was said to be expected to pass 1.5 > Amp at industrial temps vs. 2 Amps in the data sheet. Better for sure, > but not a large improvement. > > But you should contact Kim directly about it. He is the expert. :) > > -- > > Rick "rickman" Collins > > rick.collins@XYarius.com > Ignore the reply address. To email me use the above address with the XY > removed. > > Arius - A Signal Processing Solutions Company > Specializing in DSP and FPGA design URL http://www.arius.com > 4 King Ave 301-682-7772 Voice > Frederick, MD 21701-3110 301-682-7666 FAXArticle: 39035
Thanks. I posted my review comments from the earlier NG post as well as my comments to an amazon review. Thanks for the suggestion. Tom Burgess wrote: > Thanks! - This is much more like it - Your contents listing would make > a useful review comment for other prospective buyers since Amazon > didn't provide ANY detailed info, hence my visit to the competition. > You can expect your kickback from my purchase whenever Amazon gets > around to it :) > > regards, tom > > Ray Andraka wrote: > > > > Looks like they truncated the table of contents. The chapters are: > > > > 1. Intro, which goes over FPGA architectures, 25 pages > > > > 2. Computer arithmetic. Covers computer arithmetic from the slant of hardware. Includes > > distributed arithmetic and cordic discussion, 46 pages, > > > > 3. FIR filters 34 pages > > > > 4. IIR filters 24 pages > > > > 5. Multirate signal processing -- decimation &interpolation, polyphase decomp, CIC filters, > > Multistage decimators, Frequency sampling, filterbanks, wavelets. 59 pages > > > > 6. Fourier Transforms -- 42 pages > > > > 7. Advanced topics -- Rectangular and number theoretic transforms, error control and > > cryptography, modulation & demodulation --76 pages > > > > 8 . references and source code 76 pages > > > > If you decide to buy this book please use this link: > > http://www.amazon.com/exec/obidos/ASIN/3540413413/andraka/102-6110898-2675311 > > or go through the link on my website bookstore. The sales commision I get helps to support > > the website. Thanks. > > > > Tom Burgess wrote: > > > > > From the table of contents (found on http://www.barnesandnoble.com) it appears that > > > basic arithmetic, MACs, and SOPs take up the first 66 pages, then there's about 270 > > > pages on computation of special functions using Cordic, and it ends with about 90 pages > > > of references and source code. Is this an accurate description of the contents? > > > > > > It looks useful to me as I am interested in practical Cordic details and can always use > > > good HDL examples, but I wonder if someone hoping for a more comprehensive treatment of > > > DSP with FPGAs would be disappointed. > > > > > -- > Tom Burgess > Digital Engineer > Dominion Radio Astrophysical Observatory > P.O. Box 248, Penticton, B.C. > Canada V2A 6K3 -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759Article: 39036
"Sudip Saha" wrote > I want to know about synthesis of a function package. > I have a design(in VHDL) which includes a file where I have declared three functions. > In design I am using only two functions. When I am synthesizing I am getting a certain percentage of device utilization. What I want to know, does this include the unused function also or is it optimized since I am not calling this function any time in design? Unused functions are not included. Think of a VHDL function as a macro definition. comp.lang.vhdl is the place for VHDL queries.Article: 39037
Kevin Brace <ihatespamkevinbraceusenet@ihatespamhotmail.com> wrote in message news:<a3809f$aau$1@newsreader.mailgate.org>... > Chris Cowdery wrote: > > > > I've got a cut down PCI design which works nicely in a > > MAX7256SQC208-7. I have changed device to a FLEX10KA30-1 to port it to > > CardBus. > > > > Why use FLEX 10KA? > If you want to stick with Altera parts, why not use FLEX 10KE or ACEX > 1K? Mostly because I've got a drawer full, and on paper they look like they will support a PCI core. Also, 10KE won't drive a 5V TTL part, and I suspect ACEX is the same. > It looks like for Altera FLEX FPGAs (Altera ridiculously calls > it CPLDs), a device with a smaller speed grade number is a faster part. > You may want to download FLEX 10KA datasheet to verify that. > PCI compliance means that it is electrically compatible with PCI, but it > doesn't in any way guarantee that your design (your PCI IP core) will > meet 33MHz PCI timings. > It sounds like you didn't buy your PCI IP core from Altera, so > you can make modifications to it. I can. > I think the hardest part of 33MHz PCI design is meeting Tsu < 7ns setup > time requirement, and since FLEX 10KE or ACEX 1K are faster devices, > they will fare better in terms of meeting Tsu, but even on those > devices, you may still have to do manual floorplanning. > What I learned from my experience of trying to get my PCI IP core to > meet 33MHz PCI setup timings of Tsu < 7ns is that a signal path starting > from an unregistered input (a raw input) going through several levels of > LUT to an output FF or a tri-state buffer control FF often tends to be > the part that doesn't meet the setup timings. > Yes, such a signal path I described is not taking advantage of > registering inputs, but in PCI, it is not always possible to use > registered inputs. > For example, when a PCI target is asserting STOP#, but waiting for the > initiator to deassert FRAME# so that AD[31:0] can be tri-stated > immediately during a target read cycle. > Registered version of FRAME# cannot be used in this case. > For 4-input LUT-based FPGAs, from my own experience, the levels of LUT > should be kept at or below 3 levels as much as possible. > In target part of a PCI IP core, signal paths starting from FRAME# and > IRDY# going towards AD[31:0] often tends to be timing critical. > That path is the most I had problems with my own design because the > routing distance was fairly long, so I couldn't have too much LUT > delays. > Keeping the levels of LUT to 3 for such a path was pretty tough, but I > did it through simplifying my Verilog RTL code. > If the code is simple, it might be possible to implement such a path in > 2 levels of LUT. > If your PCI IP core's parity generator was designed for a CPLD > (a wide product term-based device) in mind, you may need to redesign it > a little bit with a 4-input LUT-based FPGA's architecture in mind. > I am not an expert in arithmetic, but I heard that a parity of 36-bit > can be computed with carry chain logic or with combinational logic > (LUT). Parity isn't a problem hopefully - I will ignore incoming parity, and for outgoing parity, I pregenerate it and store it along with the registers, effectively a 33bit register. You get a clock period to calculate it whilst the address is being latched. I am using the Quartus fitter - free license at the moment, which doesn't support timing driven fitting. If I get the full version, is it smart enough to give me a working design if I tell it about Tsu for example? Thanks, Chris.Article: 39038
"Davis Moore" <davis.moore@xilinx.com> wrote in message news:3C571986.3BA5959F@ieeeNOSPAM.org... > Muzaffer Kal wrote: > > > > > > else > > > counter<=counter; > > >end > > > > It is OK except you don't need the final else block. counter remembers > > its value when there are no events which change it. > > > > That depends on what synthesis tool is being used. In earlier > versions of FPGA Express (I haven't used it in a while, so I don't know > if this still applies) an undefined state would cause a latch to be inferred. > For example, if the default: option was not provided in a case statement, > a latch would be inferred. This is not exactly like this. That rule is for desing of combinational circuits and here, infering a "register" is excatly what we need... > > When I learned Verilog, we were taught the importance of making sure that > all states were defined - don't let the synthesis tool guess > what to do in the case of an undefined state. > > -- > Davis Moore >Article: 39040
No, only what is used is included in the design, in fact if you have unused outputs in your design, the synthesizer and/or the mapper will optimize out all the logic that only affects the unused outputs unless you take extraordinary steps to prevent it. Sudip Saha wrote: > Hi, > > I want to know about synthesis of a function package. > I have a design(in VHDL) which includes a file where I have declared three functions. > In design I am using only two functions. When I am synthesizing I am getting a certain percentage of device utilization. What I want to know, does this include the unused function also or is it optimized since I am not calling this function any time in design? > > Waiting for reply. -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759Article: 39041
>We are developing a bytecode processor for a high-level language (i.e. NOT >Java), and I'm curious as to what people think of these things. It's a great way to save memory but you pay for it in decoding time/resources. Memory is cheap these days. Do you have a lot of code? Compare with a RISC type system, or an even wider instruction as used in (old) microcoded machines. FPGAs can do many things in parallel. It's harder to take advantage of that if you are starting from an instruction set that thinks you have a single ALU. Another potential advantage is that you might be able to get an off-the-shelf programming environment if you pick a byte code like Java that many other people are using. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 39042
The Hot 2 system works this way. You just route a I/O to the program pin (make sure you pull it up and come up tristated). 300ns after you drive the pin low you force the internal state machine into the "clear memory" state and then your device will be reset. You have to have some way to reprogram it from there. I have a little xc9500 that looks at all the signals and starts to feed the fpga a configuration when it want to reboot (either from a flash or a static ram). Steve "Fong Chii Biao" <ericfcb@tm.net.my> wrote in message news:3c50130f_1@news.tm.net.my... > Hi, i really need help bout this, as i worked for this for a week, no result > turns out. > first, any one ever try reconfigure Xilinx FPGA using the chip itself? (i'm > using a single XC4010XL) > > the problem is.. when i connect the user I/O to the /program pin, the > configuration can't even complete at power start up.. > when i disconnect the I/O .. the configuration working pretty well.. whats > the solution for this? > > anyone, anyone at all, who has any idea, ple reply to me, thnaks > > chiibiao > >Article: 39043
> > I'm not a Xilinx rep, but I have had a couple of conversations with Kim > Goldblatt about this. Basically, they are very confident that they will > be able to reduce the curve somewhat, but I seem to recall that the > improvement was not large. But that may be due to the chip I was asking > about, the XC2S50, IIRC. This device was said to be expected to pass 1.5 > Amp at industrial temps vs. 2 Amps in the data sheet. Better for sure, > but not a large improvement. > Wow!!! So big current. How about its working current?Article: 39044
Hello, for image processing applications, having gray scale of 255. the pixel values go from 0 to 255, so i need 9 bits to represent them in 2's compliment... so why the authors use 8 bits instead? do they suppose that the dynamic is half? -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 39045
"Hristo Stevic" <hristostev@yahoo.com> schrieb im Newsbeitrag news:0fac03ce0a49908fa1e14106e8ce01fd.52609@mygate.mailgate.org... > for image processing applications, having gray scale of 255. the pixel > values go from 0 to 255, so i need 9 bits to represent them in 2's > compliment... Why do you need 2's complement? Is there negative brightness?? (Black holes? ;-)) -- MfG FalkArticle: 39046
DG_1 wrote: > > > I have also ordered the Flash > > Emulation Tool, so I will be able to check it out myself in a few days. > > I belive this includes the same emulation HW/SW are the IAR toolset. It > > is just limited in program size. > Well, MSP430 comes _only_ with IAR's tool set. Smaller (free) version > is called KickStart but essentially it's a stripped-down version of their > IAR Workbench where assembler is full, but C compiler can generate only > up to 2K of binary code. Full IAR Workbench costs $2500. > Recently I hears over Atmel mailer-list that ImageCraft Inc is preparing > their ICC, a C compile, to be ported onto MSP430. Well, will see.. > That emulator you were talking about is probably a Eval Board with just a > JTAG emulator, a nice small package of QFP socket on a small 3x3" PCB > with a JTAG connector. The "real" emulator, according to TI supprt, costs > 'about' $3000. The CD that comes with the FET also includes information about the SwiftX development system, including a link to download a free trial version (also limited in program size). SwiftX is available for only $450, including a royalty-free multitasking kernel, library of several hundred functions, full support for low-power mode, etc. The HLL is Forth, but assembler is also supported. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310-491-3356 5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454 Hawthorne, CA 90250 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================Article: 39047
Your grey scale never goes negative, so that 9th bit is always 0. Use unsigned arithmetic instead. Note that if your processing can produce negative values, you'll probably want to clamp it so that it doesn't over/underflow the 8 bits. Hristo Stevic wrote: > Hello, > > for image processing applications, having gray scale of 255. the pixel > values go from 0 to 255, so i need 9 bits to represent them in 2's > compliment... > > so why the authors use 8 bits instead? do they suppose that the dynamic > is half? > > -- > Posted via Mailgate.ORG Server - http://www.Mailgate.ORG -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759Article: 39048
I'll have to let others answer questions 1-3 but re #4, the answer depends on whether you can arrange the tables that you are selecting so that each starts at a nice binary offset in the longer BlockROM, not worrying about "wasted" memory. If not, you could use a more complicated addressing scheme, for example a small ROM containing pointers into the BlockROM (like an array of index registers) and an adder to compute the final indexed address. But if multiplexing the outputs of separate ROMs will fit and is fast enough, go for it - it's a lot simpler. I have assumed that dynamically reconfiguring the part for each table is not an option. regards, tom Antonio wrote: > > Buongiorno Cher, > I hope you will excuse me but I've some other questions : > 1) When I choose to fit in a ROM using the case, I see in FPGA Editor > that everything is well ordered but inside CLB, does this means that > the design is slower and the routing more difficult, in practice, > what's the difference between the case that the synthesizer discover > the ROM and the case it does not discover it ?? > > 2) Why for RAM is required the clock and not for ROM (I know it's a > stupid question but I don't know the answer) > > 3) Have sense a ROM with a clock port ?? > > 4) Do you suggest to use a blockram for each block of memory or a > blockram for all three block of memory in the case the dimension of > the three blocks isn't equal ?? > > Thanks Antonio -- Tom Burgess Digital Engineer National Research Council of Canada Herzberg Institute of Astrophysics Dominion Radio Astrophysical Observatory P.O. Box 248, Penticton, B.C. Canada V2A 6K3 Email: tom.burgess@nrc.ca Office: (250) 490-4360 Switch Board: (250) 493-2277 Fax: (250) 493-7767Article: 39049
On Tue, 29 Jan 2002 05:52:47 GMT, Peter Alfke <palfke@earthlink.net> wrote: > >My sugestion is to build any counter you want, synchronous or ripple, but have >a one-bit prescaler toggle-flip-flop generate the clock. So the clock is divided by 2 in the prescaler, and the Q is the clock to the rest of the counter (via a BUFG, if it is a synchronous counter, or nothing special if it is a ripple counter). >This prescaler must >use the Xilinx CE feature, which really is a multiplexer in the D input. Right. >Since CE changes asynchronously, but does not affect the clock, you never get >a runt clock pulse, but you might ( once in a blue moon) get a longer Q >delay. It will be many thousands (millions?) of years between the worst >happening, when this extra metastable delay swallows one incoming clock tick. > >Peter Alfke, Xilinx Applications >================================== Tragically, I disagree. The asynchronous CE signal is just as bad to a FF as an asynchronous D signal. The FF can go metastable, and you can get runt low or high pulses from the FF. Since this feeds your follow on counter as its clock, the results will be sub-optimal. The only safe way to use the CE is with a synchronous signal, so the asynchronous control signal should be passed through a multi stage synchronizer, before being presented to the CE pin. Philip Freidin Philip Freidin Fliptronics
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