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
Depend on the accuracy you need, but if it is not "too bad" you can simple use memories as LUT which you preload with the sin result. The amount of logic is minimal and the speed is as fast as you can run the memory. Have fun.Article: 84901
Berty wrote: > Depend on the accuracy you need, but if it is not "too bad" you can > simple use memories as LUT which you preload with the sin result. If you use two memories with 256 entries each (the first one for sin(k), 18-bit wide and the second one, 11-bit wide for sin(k+1)-sin(k)) and an unsigned 11x8 multiplier, then you can compute sin(x) with 17 significant binary digits. It will consume about 450 LEs. Best regards Piotr WyderskiArticle: 84902
John_H wrote: > ... > There are 2 clock inputs for the two registers in the IOB schematic > representation. What will happen when 100 MHz is applied on one clock and a > 50 MHz clock with the rising edge coincident with the 100 MHz falling edge > applied to the other clock? This is not true DDR but the edges are aligned > to DDR transition locations. > Draw a picture. The rising edge of the 50MHz clock will only be coincident with every other 100MHz falling edge.Article: 84903
"Duane Clark" <dclark@junkmail.com> wrote in message news:V75ne.23271$J12.1106@newssvr14.news.prodigy.com... > John_H wrote: > > ... > > There are 2 clock inputs for the two registers in the IOB schematic > > representation. What will happen when 100 MHz is applied on one clock and a > > 50 MHz clock with the rising edge coincident with the 100 MHz falling edge > > applied to the other clock? This is not true DDR but the edges are aligned > > to DDR transition locations. > > > > Draw a picture. The rising edge of the 50MHz clock will only be > coincident with every other 100MHz falling edge. Sure, but my point is that *every* 50 MHz transition is coincident with *a* 100 MHz falling edge, not that every 50 MHz transition is coincident with EVERY 100 MHz falling edge. Draw a picture. Yikes. If you don't have ABABABABABABAB register interlacing, what happens? In the example I apparantly failed to illustrate - or draw a picture - I'm looking at an example sequence such as ABA-ABA-ABA-ABA where A is the 100 MHz clock and B is the phase shifted 50 MHz clock and the "-" represents no activity because the 50 MHz edge is falling.Article: 84904
Hi Marco, Marco wrote: > Which C function should I use to perform read or write into block ram (connected to opb bus with opb bus controller)? > > Xio_in8 and Xio_out8 ? Not necessary - just read and write it like normal memory. Regards, JohnArticle: 84905
Hi Sven, Sven wrote: > I try to find some information about the internal structure of the > configuration-frames for Xilinx Virtex-II (Pro) architecture. On Xilinx > websites I just find informations about the > configuration-memory-addressing > for these architectures and some informations for the Virtex > architecture, > but i`m intressted in the meaning of the bits in the frames. Can > anybody > help me? You won't find much (any?) official xilinx documentation about the meaning of individual bits in the frames. There are some tools you can use to reverse engineer for yourself, such as the "-l" switch to bitgen, the ngc2xdl, and so on. This subject is/has been discussed at some length on the partial-reconfig mailing list - details here: http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux/Mailing_List/ Googling a topic and adding the search term "partial-reconfig" often finds the list archive as well. Hope this helps, JohnArticle: 84906
I tried with Synplify 8.10, and it does work correctly. So, this is probably a limitation (or bug, call it what you want!) with 7.7.1! Thanks.Article: 84907
Hi, Can anybody recommend a book that has good stuff about implementing the discrete Hilbert transform, preferably in an FPGA? I need practical stuff, like accuracy over frequency ranges for given tap count, windowing, truncation effects, etc. I need to take a stream of digitized (16 bit) analog samples and produce an I-Q data stream pair over roughly a 20:1 frequency range, to maybe 1 degree accuracy. Max signal frequency will be low, 1 KHz maybe. Any other resource tips would be appreciated. We could pay for a bit of consulting maybe, too. Thanks, JohnArticle: 84908
The NIOS IDE produces a ext_flash.flash file and a .elf file. I'm assuming that the .flash file contains the entire program data with a Flash to SDRAM copier for booting. I'm relying on the Altera tools such as the Flash file generator (which seems to run as a part of the software compilation in NIOS IDE), and the Altera supplied boot loader (which performs the copy from Flash to SDRAM). I'll poke around a bit more, but it gets extreme I wonder if I can disassemble the .flash file to see if the boot loader is in fact there. Correcting something in my previous post, the SDRAM does not connect to the FPGA via the Avalon tri-state bus, but rather a dedicated bus to the FPGA. Cheers, Joseph TanArticle: 84909
I remember that every high-school student used to learn that sin(90 + x) = sin(90 -x), and sin(180+x) = -sin(180-x), and sin-x = -sinx Peter AlfkeArticle: 84910
Hello John, Skolnik's "Radar Handbook" has some I/Q error budgeting in chapter 3 but I don't think it'll suffice here. I have never seen a book that goes this far into practical matters on Hilbert (except for the analog version), maybe too small a market for publishers. If there is anything out there it'll be most likely for Doppler applications. Artech House may have some good stuff and you could check them. Most books about transforms come with a CD full of helpful routines but often they will be plain C code: http://www.artechhouse.com/default.asp?Frame=Book.asp&Book=C5P10&Country=&Continent=ME&State= Possibly you could start at one of the math simulator vendors, like here: http://www.mathworks.com/access/helpdesk/help/toolbox/signal/filterd9.html Simulators are almost a must when doing this kind of stuff. My turf is med imaging and there usually every company invents the wheel again, simulates until smoke comes out of the PC and then it all becomes a trade secret. They rarely publish. What do you want to do? Does it have to be poured into the FPGA? Regards, Joerg http://www.analogconsultants.comArticle: 84911
Sean Durkin wrote: > Hi *, > > I keep coming across answer records and script files containing the > setting of undocumented environment variables, such as > XIL_ROUTE_ENABLE_DATA_CAPTURE, XIL_BITGEN_VIRTEX2ES, > XIL_XST_HIDEMESSAGES and so on. > > Is there a complete list of these hidden cheat codes? Any "official" > documentation at all? > > Whenever I'm stuck in a design, and find out that some magical > environment variable just fixes my problem, I wonder if maybe there is > something like the Holy Grail... something like the "Answer to Life, the > Universe and Everything", as in a "XIL_MAKE_EVERYTHING_WORK"- or > "XIL_42"-variable or something. Haven't found it but thought I could ask. > > cu, > Sean XIL_XST_HIDEMESSAGES is supposed to suppress the warnings that cause my report files to grow to several tens of thousands of lines long... IT DOESN'T WORK! -JimArticle: 84912
Jorge wrote: > Hi, > > I am trying to implement the PCI Brige in a Spartan II board (XC2S200). The problem is when I try to program the board I got that error: > > ERROR:iMPACT:583 - '1': The idcode read from the device does not match the idcode in the bsdl File. > > I read from the manual that I need to associate the ISO PROM with a dummy.mcs file or a .bsd file to allow the JTAG programming software to pass data through the ISP PROM. I don't know how to that to resolved my problem. If someone know how to resolve the problem please help me. > > Thank you Jorge Jorge, When Impact asks you to associate a file with the PROM, click the "BYPASS" button in the file open dialog. This eliminates the need for a dummy .MCS file for the PROM. I found that when Impact starts up, it does not scan the chain, you must do this manually by right-clicking an empty space in the Impact window and choosing "Initialize Chain". Hope this helped! -JimArticle: 84913
On Wed, 01 Jun 2005 00:44:18 GMT, Joerg <notthisjoergsch@removethispacbell.net> wrote: >Hello John, > >Skolnik's "Radar Handbook" has some I/Q error budgeting in chapter 3 but >I don't think it'll suffice here. I have never seen a book that goes >this far into practical matters on Hilbert (except for the analog >version), maybe too small a market for publishers. If there is anything >out there it'll be most likely for Doppler applications. > >Artech House may have some good stuff and you could check them. Most >books about transforms come with a CD full of helpful routines but often >they will be plain C code: > >http://www.artechhouse.com/default.asp?Frame=Book.asp&Book=C5P10&Country=&Continent=ME&State= > >Possibly you could start at one of the math simulator vendors, like here: > >http://www.mathworks.com/access/helpdesk/help/toolbox/signal/filterd9.html > >Simulators are almost a must when doing this kind of stuff. My turf is >med imaging and there usually every company invents the wheel again, >simulates until smoke comes out of the PC and then it all becomes a >trade secret. They rarely publish. > >What do you want to do? Does it have to be poured into the FPGA? > Suppose I have an AC power system, and I can digitize a pair of voltage and current waveforms. I want to report everything: trms volts/amps, true power, reactive power, phase angle. The line frequency could vary from maybe 20 to 80 Hz for a stationary generator, or 200-800 for an aircraft system (including startup and weird situations.) I'll digitize to 16 bits, at maybe 20K samples/second or something. I'm considering doing all the signal processing in an FPGA, crunching maybe 8 voltage+current pairs. For the rms volts/amps, we could just square the samples, filter, and allow my pokey uP to occasionally pick up that and square root. True power is just the product of the e*i samples, lowpass filtered. Easy. What's tricky is the reactive power/phase angle thing. The ideal thing would be to delay the voltage samples 90 degrees and then multiply by the current samples, then filter to get the signed reactive power. The trick is to delay the voltage sample data stream 90 degrees. A discrete (fir) Hilbert would give me the phase-shifted voltage signal (actually 135 deg, not 90, so I'd have to delay the current samples, too, but that's OK.) I just need to quantify how good a given implementation might be. The other way to do it would be to use a fifo clocked at a multiple of the waveform frequency, delaying the voltage or current samples by 90 degrees. That would take a digital PLL to track the voltage waveform frequency and generate a 128x or something tracking clock. Maybe a dds/nco clock gen with some fancy digital phase detector? That's complex, too, but has the advantage of acquiring the waveform frequency essentially for free. I could have a range bit the user sets for the 60 vs 400 Hz situations, so I'd only need about a 4:1 tracking range on the clock. Either way, it sounds like I'm in for some simulation. PowerBasic! JohnArticle: 84914
Marc Randolph wrote: > I typed 21127 into the search engine on their top level site and it > works fine for me... give it another try. I have run into a problem > before where I had to exit my browser and get back in before the Xilinx > site would work properly, so you might try that as well (as > non-technical as it sounds). I think that happens when websites use cookies, and the website gets upgraded, while the cookies for the session don't. (So there is perhaps a technical reason :) ) JeremyArticle: 84915
John Larkin wrote: > On Wed, 01 Jun 2005 00:44:18 GMT, Joerg > <notthisjoergsch@removethispacbell.net> wrote: > > >>Hello John, >> >>Skolnik's "Radar Handbook" has some I/Q error budgeting in chapter 3 but >>I don't think it'll suffice here. I have never seen a book that goes >>this far into practical matters on Hilbert (except for the analog >>version), maybe too small a market for publishers. If there is anything >>out there it'll be most likely for Doppler applications. >> >>Artech House may have some good stuff and you could check them. Most >>books about transforms come with a CD full of helpful routines but often >>they will be plain C code: >> >>http://www.artechhouse.com/default.asp?Frame=Book.asp&Book=C5P10&Country=&Continent=ME&State= >> >>Possibly you could start at one of the math simulator vendors, like here: >> >>http://www.mathworks.com/access/helpdesk/help/toolbox/signal/filterd9.html >> >>Simulators are almost a must when doing this kind of stuff. My turf is >>med imaging and there usually every company invents the wheel again, >>simulates until smoke comes out of the PC and then it all becomes a >>trade secret. They rarely publish. >> >>What do you want to do? Does it have to be poured into the FPGA? >> > > > Suppose I have an AC power system, and I can digitize a pair of > voltage and current waveforms. I want to report everything: trms > volts/amps, true power, reactive power, phase angle. The line > frequency could vary from maybe 20 to 80 Hz for a stationary > generator, or 200-800 for an aircraft system (including startup and > weird situations.) I'll digitize to 16 bits, at maybe 20K > samples/second or something. I'm considering doing all the signal > processing in an FPGA, crunching maybe 8 voltage+current pairs. > > For the rms volts/amps, we could just square the samples, filter, and > allow my pokey uP to occasionally pick up that and square root. > > True power is just the product of the e*i samples, lowpass filtered. > Easy. > > What's tricky is the reactive power/phase angle thing. The ideal thing > would be to delay the voltage samples 90 degrees and then multiply by > the current samples, then filter to get the signed reactive power. The > trick is to delay the voltage sample data stream 90 degrees. A > discrete (fir) Hilbert would give me the phase-shifted voltage signal > (actually 135 deg, not 90, so I'd have to delay the current samples, > too, but that's OK.) I just need to quantify how good a given > implementation might be. > > The other way to do it would be to use a fifo clocked at a multiple of > the waveform frequency, delaying the voltage or current samples by 90 > degrees. That would take a digital PLL to track the voltage waveform > frequency and generate a 128x or something tracking clock. Maybe a > dds/nco clock gen with some fancy digital phase detector? That's > complex, too, but has the advantage of acquiring the waveform > frequency essentially for free. I could have a range bit the user sets > for the 60 vs 400 Hz situations, so I'd only need about a 4:1 tracking > range on the clock. > > Either way, it sounds like I'm in for some simulation. PowerBasic! > > > John why not a synchronous demodulator (or lock-in amp ;) if you have 3 phases, its trivial. measure all 3 phases, and do a 3-2 phase transform to create an equivalent rotating vector a + jb. for a single-phase system, build a 90 degree phase shifter so you have Vpeak*sin(theta) + j*Vpeak*cos(theta). then multiply by exp(-jtheta) (decompose into real & imaginary calcs) You will then get 2 outputs, call them Vd and Vq. If you have a pure sinusoidal system, and theta = integral(w_line.dt) is the correct phase, one of these will be zero. Use this as the feedback to a PI controller, whose reference is zero. PI output has ideal line frequency added to it (if you want, not necessary) and is then integrated to produce theta. once it syncs up, you have your real & imaginary V,I components in the stationary reference frame, IOW they are DC quantities. easy to figure out reactive power etc. Cheers TerryArticle: 84916
John Larkin wrote: [...] > Suppose I have an AC power system, and I can digitize a pair of > voltage and current waveforms. I want to report everything: trms > volts/amps, true power, reactive power, phase angle. The line > frequency could vary from maybe 20 to 80 Hz for a stationary > generator, or 200-800 for an aircraft system (including startup and > weird situations.) I'll digitize to 16 bits, at maybe 20K > samples/second or something. I'm considering doing all the signal > processing in an FPGA, crunching maybe 8 voltage+current pairs. > > For the rms volts/amps, we could just square the samples, filter, and > allow my pokey uP to occasionally pick up that and square root. > > True power is just the product of the e*i samples, lowpass filtered. > Easy. Isn't that Volt-Amperes? You need the phase angle to separate the components into true power and reactive power. > What's tricky is the reactive power/phase angle thing. Can't you just detect the zero crossings in the voltage and current waveforms and get the phase angle between them? Then solve the relationship: cos(phi) = True Power / Total Power Any waveform distortion could mess things up a bit trying to find the zero crossings. A simple boxcar integrator is very fast in software and might help improve the accuracy. Is this what you are looking for, or did I miss something fundamental in your post? [...] > John Mike MonettArticle: 84917
Hi , >>>>>>>>> 3100 lines of tripe deleted by archive owner. this problem it do for each example why? >>>>>>>>> Because you were too stupid to read the error messages that clearly >>>>>>>>> showed that that your header files were not being found. thanks bssArticle: 84918
Hi there! I have the following problem. I develop FPGA IP core for ATA HDD. I have tested it on 40 GB 2.5" Fujitsu HDD. PIO and Ultra DMA operated fine. When I switched to Maxtor DiamondMax HDD (3.5" 60 and 200 GB) it was found out that after I perform Ultra DMA write operation (DMA Write) I get different results using PIO and Ultra DMA read: - if I read sector using Ultra DMA commands (DMA Read), I get data which was written earlier using PIO write commands (Write Sector) not written by Ultra DMA write commands. - if I read sector using PIO command (Read Sector), I get data which was written by Ultra DMA write command. The strange thing is that if I read the same sector again using PIO command, I get data which was written earlier using PIO write commands. What can be the problem? I have tried to turn off cache and read-ahead options but it didn't help. Thanks in advance. EugArticle: 84919
Hi all, I am doing some programmes with EDK 6.3i on the Virtex-II Pro50. There are many math computing in the program, and I do them using the software libs provided by the board, as a result, it is very very slow that we could not endure. So I would like to know the effective and simple method to speed up the float computing. Please help me. Thank you very much.Article: 84920
hi Ed, thanks for ur reply. i went around and solved the problem of generating .ace file using the steps explained in ml40x getting started tutorial. but now i stucked with generating system ACE file using the option in EDK..tools..Generate system ACE. here I found a genace.tcl script and tried to get .ace file simply clicking on Generate system ACE file option in EDK. but i was not that lucky to get .ace file instead getting some error messages.. when I looked into the genace.tcl script, found that needs to be changed for proper xmd flow. here can u tell me what r the changes need to be done in genace.tcl script. thanks in advance.. if its not possible i can take .bit file and use the steps explained in the ml40x tutorial guide to get my .ace file, this now i became failiar and using right now. thanks for ur help regardsArticle: 84921
Get EDK 7.1, which has support for h/w floating point.Article: 84922
I can program the platform flash OK on my Spartan 3 kit using the parallel cable and the application runs OK, but I can't configure the FPGA on its own. When I try to program the FPGA I get an error message about the msk file, which is used for flash, not FPGA, programming. I've tried setting the flash device to BYPASS, but that doesn't help. Leon -- Leon Heller, G1HSM http://www.geocities.com/leon_hellerArticle: 84923
Leon, the msk file (mask file) is used for verifying the content of the fpga (read back) against the *.bit file if you click right in impact (with the mouse on the part) and uncheck verify, will work. Aurash Leon Heller wrote: >I can program the platform flash OK on my Spartan 3 kit using the parallel >cable and the application runs OK, but I can't configure the FPGA on its >own. When I try to program the FPGA I get an error message about the msk >file, which is used for flash, not FPGA, programming. I've tried setting the >flash device to BYPASS, but that doesn't help. > >Leon > > -- __ / /\/\ Aurelian Lazarut \ \ / System Verification Engineer / / \ Xilinx Ireland \_\/\/ phone: 353 01 4032639 fax: 353 01 4640324Article: 84924
"Aurelian Lazarut" <aurash@xilinx.com> wrote in message news:d7k1t1$bju1@cliff.xsj.xilinx.com... > Leon, > the msk file (mask file) is used for verifying the content of the fpga > (read back) against the *.bit file > if you click right in impact (with the mouse on the part) and uncheck > verify, will work. > Aurash Thanks very much, Aurash. It works OK, now. I noticed that Verify was ticked and thought of unticking it, but it didn't really seem relevant. 8-( Leon
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