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
I am no longer running Windows. Are there any open source programs for programming fpgas? I know about Icarus, but I don't think that program actually programs chips. Thanks, Dave FeustelArticle: 95676
"Antti Lukats" <antti@openchip.org> wrote in message news:dr7sh4$2qa$00$1@news.t-online.com... > > Transmitting encrypted voice over band-limited analog link is VERY VERY > complicated task. If you want secure and reliable connection over analog > link that does not reduce the quality (eg provides almost the same > bandwidth as clear channel) then calculate at least one man-year > development time. Probably more. > > I have hacked an secured digital sound transmittion standard once a long > time ago. It is amazing what has to be done to digitized voice in order to > hide its nature of being voice data. Anything that is from our world eg > sound, voice, captured image keeps its characteristics after large amount > of distortion applied, things like bit swapping/interleaving, xor patterns > do not change almost anything - methods exist to recover the original. > > Although, I think I could get a Linux box with a sound card and a modem to send an encrypted MP3 compressed stream over POTS in a lot less than a year. Cheap too! You could use ssh and send it over the internet. Perhaps you could run Linux on the FPGA's PowerPC? Cheers, Syms.Article: 95677
Try a google search on scatter gather dma. I don't know the details but I know you have to allocate blocks of memory in the pc space, program their locations and sizes to the pci, and then monitor the transfers and swap out buffers to disk before their overwritten. "Nitesh" <nitesh.guinde@gmail.com> wrote in message news:1138169559.651307.267740@o13g2000cwo.googlegroups.com... > I changed the front end core given by amirix for dma functionality. > For a dma transfer what is the destination address that I should > specify? How can I get this address. > I am sending data from the card to the host memory. > Nitesh >Article: 95678
And the low noise preamp, and the low pass filter and power amp for the speaker, and the DSP-based acoustic echo cancellation, and the analog noise generator (for the keys) and the controlling microprocessor (if not using the DSP chip for this) and the power supply components, and ... and ... and. Naturally, one leaves out some irrelevant details. Regards, Allan P.S. how did you know it was a sunny day here?Article: 95679
Antti Lukats wrote: > >Marc Randolph" <mrand@my-deja.com> schrieb im Newsbeitrag > >news:1138192752.155593.278520@z14g2000cwz.googlegroups.com... > > yusufilker@gmail.com wrote: > >> hi, > > > > Howdy yusuf, see below... > > > >> I would like to implement a secure channel over an unsecure medium. > >> > >> mic(voice) => A/D conv =>digital, unsecure, unknown comm link => D/A > > Transmitting encrypted voice over band-limited analog link is VERY VERY > complicated task. If you want secure and reliable connection over analog > link that does not reduce the quality (eg provides almost the same bandwidth > as clear channel) then calculate at least one man-year development time. > Probably more. > > I have hacked an secured digital sound transmittion standard once a long > time ago. It is amazing what has to be done to digitized voice in order to > hide its nature of being voice data. Anything that is from our world eg > sound, voice, captured image keeps its characteristics after large amount of > distortion applied, things like bit swapping/interleaving, xor patterns do > not change almost anything - methods exist to recover the original. Obviously, if a design uses poor crypto, then it can be cracked without too much diffculty. Even "good" crypto (e.g. AES) can be misused. It's quite hard to get right in practice. I rather like the wikipedia entry on Block Cypher modes of operation that shows a striking flaw in ECB. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation I'm guessing that CTR mode would suit the OP's application. Regards, AllanArticle: 95680
<allanherriman@hotmail.com> wrote in message news:1138195695.581945.80890@g44g2000cwa.googlegroups.com... > > P.S. how did you know it was a sunny day here? > He's obviously been following the cricket now that Holland have qualified for the world cup. It looks sunny at the SCG in the picture of Jayasuriya after he hit a century! http://news.bbc.co.uk/sport1/hi/cricket/4634280.stm Cheers, Syms.Article: 95681
Dave Feustel wrote: > I am no longer running Windows. Are there any open source programs > for programming fpgas? I know about Icarus, but I don't think that > program actually programs chips. I know of no good (*) open source simulators or synthesis tools. You can forget about the back end tools - there are compelling reasons for these to be completely closed. I suggest you drop your dogma, and use some of the many low cost or free (beer) tools, or learn about Wine (assuming you have an x86 machine). (*) other people may regard certain offerings (e.g. Icarus) as good. YMMV. Regards, AllanArticle: 95682
Jim Granville wrote: > Peter Alfke wrote: > >> The circuit is reliable, although the generated pulse width is >> determined by gate delays. But it is self-compensating, since the clock >> pulse will not end until the flip-flop has toggled. > > This circuit really shouldn't be advocated for FPGA use. It is an asynchronous hack. It would not get through a serious design review except in extenuating circumstances. Generally speaking, depending on gate delays for circuit operation is bad practice. This particular circuit has potential problems with pulse width and is dependent on the clock duty cycle for proper operation. (Yes, I can remember using it a long long time ago with some TTL designs, but then those designs also had one-shots in them). Another problem with it, is the static timing analyzer and timing driven place and route do not consider the asynchronous behavior of this circuit.Article: 95683
kcl wrote: > Hello, > > I get trouble to run a project(synthetize and p&r) It complete sucessfully > all the steps but it doesn't validate it so when I try to remake just one > step like the P&R it restarts also the synthetize as it has never been > done. Also when I made a step instead of putting a green mark on this step > when it have been done , it puts a a point of interrogation ( and not a red > cross) > > for example : > I make my project and synthetize it . ISE says me that it have been > completed but it keeps the point of interrogation. Then I run the Implement > Step and it restarts the synthetize first. As if I have done a a rerun > command. > > If I make a full run (synthetize+translate+map+P&R) It validates all steps > when they are finish (but still running the next step) with the green mark > but when it finish the run all the step are unvalidate ( by a ? sign) > > does anyone have already meet these problem? > > I have already try to reinstall ISE (6.3 sp3) and remake all the project > (just keeping the vhd) > > Thanks you for your answer. > > alex I've found that this is often a system problem. ISE keeps track of source module modification times and generated file creation times. If some of the files are located on another computer these times may not be directly comparable. This happens if the systems are not set to the same time zone for instance, or sometimes if they don't use the same operating system. It can also happen if the computers' clocks are not set correctly.Article: 95684
thanks for your replies, I have to give more details It is not analog channel . It is digital and it is not easy to access to software/hardware , may be only to hardware that mic-A/D conv part.) The device encrypts data BUT i do not trust encrypted data. becouse it is already listened (like internet = do you trust in your IE :) If I encrypt data in the device's microprocessor it can be recognized or at least overwritten by an software upgrade remotely etc... So I will add external circuit if i can.those A/D and D/A s required for this. Crosstalk can be a problem but how much i can not guess. i will insert a small circuit between mic and host A/D conv. I am aware multiple A/Ds will generate too much noise but it is acceptable. voice like signal = same freq with original voice, same data dept, but just scrambled / I will feed encrypted voice like signal into device's A/D. I will remove the original mic/ sorry for bad english. no need for compression, bandwidth is ok. voice is 8kbps\ scrambled voice is also 8kbps \ device can send both of them without caring.Article: 95685
<yusufilker@gmail.com> schrieb im Newsbeitrag news:1138197217.486165.248730@z14g2000cwz.googlegroups.com... > thanks for your replies, I have to give more details > > It is not analog channel . It is digital and it is not easy to access > to software/hardware , may be only to hardware that mic-A/D conv > part.) > The device encrypts data BUT i do not trust encrypted data. becouse it > is already listened (like internet = do you trust in your IE :) > If I encrypt data in the device's microprocessor it can be recognized > or at least overwritten by an software upgrade remotely etc... > > So I will add external circuit if i can.those A/D and D/A s required > for this. > > Crosstalk can be a problem but how much i can not guess. i will insert > a small circuit between mic and host A/D conv. > I am aware multiple A/Ds will generate too much noise but it is > acceptable. > > > voice like signal = same freq with original voice, same data dept, but > just scrambled / I will feed encrypted voice like signal into device's > A/D. I will remove the original mic/ sorry for bad english. > > > no need for compression, bandwidth is ok. voice is 8kbps\ scrambled > voice is also 8kbps \ device can send both of them without caring. > this is exactly the most complicated case. if you want the encrypted voice to be transmitted over the same analog channel, (eg feed it into AD) then it is VERY VERY complicated to get it done right. in other words you can forget doing it. -- Antti Lukats http://www.xilant.comArticle: 95686
yusufilker@gmail.com wrote: > thanks for your replies, I have to give more details > > It is not analog channel . It is digital and it is not easy to access > to software/hardware , may be only to hardware that mic-A/D conv > part.) > The device encrypts data BUT i do not trust encrypted data. becouse it > is already listened (like internet = do you trust in your IE :) > If I encrypt data in the device's microprocessor it can be recognized > or at least overwritten by an software upgrade remotely etc... > > So I will add external circuit if i can.those A/D and D/A s required > for this. > > Crosstalk can be a problem but how much i can not guess. i will insert > a small circuit between mic and host A/D conv. > I am aware multiple A/Ds will generate too much noise but it is > acceptable. > > > voice like signal = same freq with original voice, same data dept, but > just scrambled / I will feed encrypted voice like signal into device's > A/D. I will remove the original mic/ sorry for bad english. > > > no need for compression, bandwidth is ok. voice is 8kbps\ scrambled > voice is also 8kbps \ device can send both of them without caring. Don't confuse 8kHz sampling rate with 8kb/s data rate. They are very different concepts! AllanArticle: 95687
On a sunny day (25 Jan 2006 05:28:15 -0800) it happened allanherriman@hotmail.com wrote in <1138195695.581945.80890@g44g2000cwa.googlegroups.com>: >And the low noise preamp, and the low pass filter and power amp for the >speaker, and the DSP-based acoustic echo cancellation, and the analog >noise generator (for the keys) and the controlling microprocessor (if >not using the DSP chip for this) and the power supply components, and >... and ... and. > >Naturally, one leaves out some irrelevant details. You wrote: <quote> This would be the minimum required to make a "professional-grade" voice encryptor: <quoted> So tha twas not very professional, as i tshows no knowledge of signal processing. >Regards, >Allan >P.S. how did you know it was a sunny day here? I only know you reply to me because of the headers, you forgot to qute what and who you are replying to. Not very professional either. As for the sunny day, try a suitable reference frame.Article: 95688
Hi One thing more. As I saw moment before, DCM - you can't use/set CLK_FEEDBACK="2X" - only "1X" or "NONE" regards Jerzy GburArticle: 95689
fpga_toys@yahoo.com wrote: > Ray Andraka wrote: > >>fpga_toys@yahoo.com wrote: >> >>>So, my point is, and nobody seems to disagree, that it's unrealistic to >>>assume that the devices can be 100% packed, use the marketing numbers >>>for system design clock speeds, at a modest toggle rate, and not blow >>>right thru the power the device can handle. Disagree? > > >>You won't get the density and performance without handcrafting to meet >>both the density and performance limits. The typical user is going to >>run into place and route issues before he even gets close to the high >>density, high clock rate corner. I don't care if it is an RC >>application or not, you just don't get into that corner unless you do a >>considerable amount of handcrafting on the design. > > > Thanks for making my point. The Xilinx product chips + ISE is unable to > route > designs which have a high usage level, which is believe is because it > both > lacks routing resources and P&R needs improvement. You are probably one > of better 1/4 of percent of engineers that might have the experience to > beat > P&R regularly ... but for the rest of us mortals the product isn't > usabel as > you get close to 100% packing. > > For RC uses I have a laundry list of things that are wrong with P&R, > some of > which are WHY you can not get high density designs routed with ISE. P&R > fails to pack FF's with the LUT that has it's input term ... choosing > instead to > use another LUT as a pass thru that is several CLB's away. Given a > netlist > that is obviously a 6x15 mesh from the routing, it tends to place the > parts in > an arc around the center of the chip instead. ... and a number of other > observations > that says it's costing algorithms have a very different goal, and fail > because of > it for some designs. > > The problem is that P&R is not optional, they will not release the doc > for an > open source implementation which is turned to other applications, like > RC. > So until P&R can automatically route the same dense designs you pull > off, > I say the product chips+ISE isn't usable for dense designs. > > The reason they get away with it today is that for hardware design > there is > a VERY strong incentive to buy up ... purchase a larger device, just to > make > sure that in the future changes will fit. So many designs will always > have the > headroom, and presure on Xilinx to improve P&R for high density routing > is > relatively low, as few designs will cross above 95% use. > > With RC there is a completely different goal, and that is to use the > entire chip, > in fact, all of every chip in an FPGA processor array. High density > designs are > the norm with RC, and half device designs will be relatively rare. > The issue is not the devices; the current devices are actually over-routed. That is, there is more than enough routing in them. You can prove this to some degree by setting your timing constraints low. If you can accept poor timing, it is difficult to make an unroutable design. The router does have issues that have to do with trading quality of results for faster time to completion. You can still get a lot of mileage out of doing a bit of floorplanning. The problem is that in its haste, the router puts down routes working to connect everything up, and then works to shorten any routes that don't meet timing. Unfortunately, that ends up in a lot of circuitous routes that in turn congest the routing resources to the point where the router is tripping over itself. There used to be a delay based clean-up that ripped up and re-routed to minimize propagation delays rather than just reduce them to meet timing. That was removed in an effort to reduce overall compile time. I do not do hand-routing. I avoid it like the plague because it is outisde of the normal tool flow, is difficult to embed in the design, is extremely time consuming, and is perishable meaning that if you have to run PAR again, your hand placement also has to be redone. I do use floorplanning extensively, both embedded in the code for frequently used components, and in the UCF for less used and placement of upper levels in the hierarchy. The point is, the tools will route a high density design just fine. They often need a helping hand to get a decent placement (although they will generally work for placement too if timing isn't critical). As far as placing LUTs away from the flip-flops, that occurs in jsut a few specific cases: 1) you have more than one level of LUT between flip-flops. The first level LUT connected to the flip-flop D input will get put with the flip-flop. The second level obviously cannot go into the LUT occupied by the first. The placer doesn't do a very good job with second level LUTs, so they tend to be placed too far away. The easiest way to work around this is with deeper pipelining to ensure you have only 4 input logic functions between flip-flops. You can also put placement constraints on both LUTs to force placement in adjacent slices (the placer will generally not put them next to each other otherwise) 2) your combinatorial logic drives more than one flip-flop. 3) the LUT is driving the reset input to the flip-flop. The reset input is not directly connected to the LUT in the same slice, so the placer generally doesn't put it there. Resets sourced from combinatorial terms are also generally feeding more than one flip-flop, so you also run into the issue with the logic driving more than one flip-flop 4) The LUt is driving a clock enable input to the flip-flop. Same deal as the reset. 5) you have logic between the carry chain and the flip-flop that does not map into the XORCY. This is usually a mux or gating function. Off hand, I can't think of any other scenarios that cause the LUT to be physically separated from the flip-flop. RC is going to give you dissappointing results if you insist on defining the designs with an RTL description. Synthesis and PAR without physical constraints is too slow, and the results are not generally going to get you into the high density-high performance corner. RC has a much better shot of working if it uses a library of hand crafted components that it simply stitches together. Those components will need to be designed by someone far more familiar with the FPGA architecture and high performance/density design for FPGAs than the typical user you described. My point is, it isn't so much the tools, nor the devices that prevent a high density high performance design. It is the lack of expertise of the user. FPGAs are certainly not unique in this regard. Opening up the bitstream is not going to change this one iota. Aiming for 100% device use is also a faulty goal. Quite the contrary, RC should be targetting less than 50% utilization for any one overlay so that it can hit a reasonable performance target with a minimum of effort. What is the point of performing an operation 2x as fast (100% utilization vs 50%) if it takes 10x the time to prepare to do it, especially when the time to prepare is already orders of magnitude longer than the execution time? As long as 50% utilization provides a good performance advantage over not using RC, it is still a large win.Article: 95690
Hey All, Just wondering if anyone has tried out the Spartan-3 starter board offered on Xilinx's website (the 99 dollar one). I am a student developing a project on an FPGA and that seemed like the most cost effective option for me. Has anyone tried it? If so, how is the speed/capacity for your needs? How about the simplified JTAG interface, does that perform OK? Thanks in advance and I look forward to hearing from you. ChrisArticle: 95691
<Chris.Gammell@gmail.com> schrieb im Newsbeitrag news:1138199130.162720.321920@g44g2000cwa.googlegroups.com... > Hey All, > > Just wondering if anyone has tried out the Spartan-3 starter board > offered on Xilinx's website (the 99 dollar one). I am a student > developing a project on an FPGA and that seemed like the most cost > effective option for me. Has anyone tried it? If so, how is the > speed/capacity for your needs? How about the simplified JTAG interface, > does that perform OK? Thanks in advance and I look forward to hearing > from you. > > Chris > its ok, but if you can wait then the Spartan3e kit $149 USD includes also on board Platform USB Cable (sold standalone for $149!) as free bonus :) -- Antti Lukats http://www.xilant.comArticle: 95692
Hi, on page 25 of DS099-3 Spartan3 DC and Switching Characteristics, there's a a formula for the maximum number of SSOs allowed within an I/O bank. I have a XC3S200FT256 working in LVCMOS33 standard (fast, 2mA), its table 22 value is 3, while its table 23 value is 44. Do I really have a limit of 3x44=132 SSOs for each bank? This value excedes by far the number of pin per bank in this package... It is "reasonable" for output currents of 24mA or 16mA, where it limits the SSOs to 9 and 21 respectively. This post is only to check if what I found is correct or if I'm wrong. Thanks, MarcoArticle: 95693
Dave Feustel wrote: > I am no longer running Windows. Are there any open source programs > for programming fpgas? I know about Icarus, but I don't think that > program actually programs chips. Depends on your fpga's. For Xilinx there is no alternative since the P&R and bitstream generation tools are vendor proprietary. For Altera parts it's unclear at this point, at least one source believes they might open up shortly. Atmel isn't fighting open source at this point, and is actually relatively open about bitstream formats and architecture for AT40K/AT94K products to the point that we will be actively supporting those products in ways with FpgaC that simply are not possible on Xilinx. I suspect that will bring Altera out as well, since the breadth of the FpgaC project is pretty exciting for Reconfigurable Computing (RC). The core patents for Fpga's will be expiring this decade, and if the open source RC movement is careful to establish prior art and register core technology patents, it should be possible to safely create an open source basis for RC similar to what gcc, gnu, FreeBsd, and Linux did for the mainstream software world. Xilinx may try to control the market as AT&T/USL/Novel/SCO did, but in the end vendor neutral open source projects have a strong chance of being mainstream in the FPGA RC community inside a few years. I suspect that Altera, Amtel, Intel, and a few others will sieze the SoC market to take RC mainstream from the ground up. In that market Altera with the Arm core has a clear market edge as most embedded folks are already Arm experienced, where PPC is still a minority player in the global embedded market. The Altera Excalibur devices have been a very interesting pairing in that respect ARM + 20KE fpga and that product family is certainly going to grow, especially if an open source partnership develops for it. With core patents expiring this decade, and early in the next, I would not be suprised if Intel, AMD, Actel, ASCII(One Chip MSX), and a few others are all capable of making the current FPGA leaders marketshare insignificant in a few years as embedded RC goes mainstream. FpgaC is just getting off the ground, but with a strong vision toward realizing the 10 year old dream of mainstream RC.Article: 95694
Ray Andraka wrote: > Aiming for 100% device use is also a faulty goal. Quite the contrary, > RC should be targetting less than 50% utilization for any one overlay so > that it can hit a reasonable performance target with a minimum of > effort. What is the point of performing an operation 2x as fast (100% > utilization vs 50%) if it takes 10x the time to prepare to do it, > especially when the time to prepare is already orders of magnitude > longer than the execution time? As long as 50% utilization provides a > good performance advantage over not using RC, it is still a large win. you are not the only one that is suggesting that derating Xilinx parts 50% is the minimum rational target for an RTL based RC system on those platforms. I don't think this is acceptable long term, and very hard to justify. That Xilinx actively prevents alternative P&R and bit stream tools to improve an this, simply means they are not interested in better fit for their product line ... IE go away, we don't care about that market. Thanks for clearly expressing this.Article: 95695
\quote Ray Andraka wrote This circuit really shouldn't be advocated for FPGA use. \quote Thanks for help. I am not sure how to realize the same function (double the frequence of the clk)? Maybe some of the FPGA's architecture support this. Then I would like to know how this circuit perform as far as asic is concerned?Article: 95696
Antti Lukats wrote: > <Chris.Gammell@gmail.com> schrieb im Newsbeitrag > news:1138199130.162720.321920@g44g2000cwa.googlegroups.com... > >>Hey All, >> >>Just wondering if anyone has tried out the Spartan-3 starter board >>offered on Xilinx's website (the 99 dollar one). I am a student >>developing a project on an FPGA and that seemed like the most cost >>effective option for me. Has anyone tried it? If so, how is the >>speed/capacity for your needs? How about the simplified JTAG interface, >>does that perform OK? Thanks in advance and I look forward to hearing >>from you. >> >>Chris >> > > its ok, > but if you can wait then the Spartan3e kit $149 USD includes also on board > Platform USB Cable (sold standalone for $149!) as free bonus :) > > If you are a student you may be able to get Xilinx to donate a couple to your Lab at School! -EliArticle: 95697
unlogic@o2.pl wrote: > Ive would like to start feel whats going on fpga field .. soo if anyone > would point me in some directions would be great. Do both. Look at Altera parts which have both ARM processors and and FPGA on the same chip ;)Article: 95698
Dave Feustel wrote: > I am no longer running Windows. Are there any open source programs > for programming fpgas? I know about Icarus, but I don't think that > program actually programs chips. > > Thanks, > Dave Feustel Don't waste your time. Vendor's spend a *VERY* long time working out bugs in their software. With the level of complexity of an FPGA, you don't want to waste time with buggy software that is developed in someone else's spare time. All of the actually chip programming, routing stuff is vendor locked(for good reason), so your out of luck on that. That being said, Xilinx does offer their software for Linux. It is not opensource but it does give you a non-windows alternative. -EliArticle: 95699
Antti Lukats yazdi: > <yusufilker@gmail.com> schrieb im Newsbeitrag > news:1138197217.486165.248730@z14g2000cwz.googlegroups.com... > > thanks for your replies, I have to give more details > > > > It is not analog channel . It is digital and it is not easy to access > > to software/hardware , may be only to hardware that mic-A/D conv > > part.) > > The device encrypts data BUT i do not trust encrypted data. becouse it > > is already listened (like internet = do you trust in your IE :) > > If I encrypt data in the device's microprocessor it can be recognized > > or at least overwritten by an software upgrade remotely etc... > > > > So I will add external circuit if i can.those A/D and D/A s required > > for this. > > > > Crosstalk can be a problem but how much i can not guess. i will insert > > a small circuit between mic and host A/D conv. > > I am aware multiple A/Ds will generate too much noise but it is > > acceptable. > > > > > > voice like signal = same freq with original voice, same data dept, but > > just scrambled / I will feed encrypted voice like signal into device's > > A/D. I will remove the original mic/ sorry for bad english. > > > > > > no need for compression, bandwidth is ok. voice is 8kbps\ scrambled > > voice is also 8kbps \ device can send both of them without caring. > > > > this is exactly the most complicated case. if you want the encrypted voice > to be transmitted over the same analog channel, (eg feed it into AD) then > it is VERY VERY complicated to get it done right. > > in other words you can forget doing it. > > -- > Antti Lukats > http://www.xilant.com Hi Antti, everything is naturally analog. But I did not say the channel is analog. It is digital channel. I use very small part of the device = just want to insert my circuit between microphone and A/D conv. my circuit = A/D+fpga+D/A it seems very simple to me. (ok I pass LNA, LPF, etc but still simple) transmitting and receiving done by the device. every kind of noise reduction, crosstalk issues already handled by the device. OR do not I understand what you mean?
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