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
At the fourth line of the report, there is mention about CPU time and Elapsed time. Similarly at the end of the report, just before the message total memory usage, there is again mention about another CPU time and Elapsed time. I would like to know precisely what do these two times mean and what can be interpreted from them for a particular HDL program. Do they carry significance ? --Starting of the report -- Release 8.2i - xst I.31 Copyright (c) 1995-2006 Xilinx, Inc. All rights reserved. --> Parameter TMPDIR set to ./xst/projnav.tmp CPU : 0.00 / 5.14 s | Elapsed : 0.00 / 5.00 s --> Parameter xsthdpdir set to ./xst CPU : 0.00 / 5.14 s | Elapsed : 0.00 / 5.00 s --> Reading design: fsopform.prj --End of Report -- ========================================================================= CPU : 15.02 / 20.44 s | Elapsed : 15.00 / 21.00 s --> Total memory usage is 241916 kilobytesArticle: 113226
Hello, I am using FFT v.3.2 core from Xilinx to implement FFT algorithm on FPGA. I would like to download .dat file as my input (which is digital representation of sinusoidal wave shown below) to test the real-time functionality 0 30273 23170 -12539 -32767 -12539 23170 30273 I'm not sure if the above data would show up in the correct format in the newsgroup, but each line represents a point on sine line (.dat file taken from sample files on Xilinx website - sine_9_375mhz.dat). Now, I would like to download the project into FPGA and test (using .dat file) it. Is there a way to download .dat file into FPGA block memory? The connectors I have: 1) Parallel IV cable 2) CF card The software I have (all full educational versions): 1) Xilinx ISE 2) Chipscope Pro 3) FPGA Advantage I do not currently have A/D converters on FPGA board. I received a suggestion that I can use counter to represent the sine wave; however, I would need to perform further operations on the data (which would be different than constant frequency sinusoidal wave), so using counters to create those signals would not be the optimal solution for me. PS. Sorry if this will be double posted. Thanks, Vitaliy Ryerson UniversityArticle: 113227
davidc@ad-holdings.co.uk wrote: >>Let's consider a 16 bit input. You can have from 0 to 16 leading 0's >>(16 leading zeros is a special case, it is 15 where the data is also 0). >> In this case we shift left 0 to 15 places, left shifting if all the >>leading bits for that shift are '0'. This is done with 4 layers of 2:1 >>muxes shifting by 8,4,2 and then 1 bits. Each layer's shift select is >>the logical OR of the left N bits (N=8,4,2 and 1) so that a shift only >>occurs if all those left bits are 0. > > > > > OK, so the "top" layer has 8 x 2-1 muxes for a 16 bit input (A0-A15), > the select line for each are connected together > by a logical OR function, the inputs of which are the left N bits - so > in this case would the inputs to the OR gate be A15-A8 or is it > "A1, A3, A5, A7, A9, A11, A13, and A15" which are all OR'd together and > the output goes to each select line SEL for > that particular layer? > > select for first layer (lyr8 below) is the logical or of bits 15:8 of the input. If all those bits are zero, then it left shifts the input 8 bit positions, shifting '0's into the 8 lsbs. The next layer uses the output of the first layer. If the 4 leftmost bits are zero then it shifts the previous (lyr8) result 4 bits to the left, filling the rightmost bits with zero. and so on. Basically, the decision at each layer is based on whether there are any significant (i.e. non-zero) bits in the field that will get shifted off the left end if a shift is performed. If so, then the data is passed through unshifted, if not then it is left shifted by the amount for that layer. > >>lyr8 <= din(7 downto 0) & X"00" when din(15 downto 8)=X"00" else din; >>sout(3) <= '1' when din(15 downto 8)=X"00" else '0'; >>lyr4 <= lyr8(11 downto 0) & X"0" when lyr8(15 downto 12)=X"0" else lyr8; >>sout(2) <= '1' when lyr8(15 downto 12)=X"0" else '0'; >>lyr2 <= lyr4(13 downto 0) &"00" when lyr4(15 downto 14)="00" else lyr4; >>sout(1) <= '1' when lyr4(15 downto 14)="00" else '0'; >>dout <= lyr2(14 downto 0) & '0' when lyr2(15)='0' else lyr2; >>sout(0) <= '1' when lyr2(15)='0' else '0'; >> >>This works if din is unsigned because you only have leading '0's. If >>din is 2's complement data, then you have leading sign bits instead of >>leading '0', so the detection at each stage is made more difficult; in >>that case it has to see if all the bits that will get shifted out match >>the leftmost retained bit instead of just being zero so the detect >>function has an additional term: when din(15 downto 7)="000000000" or >>din(15 downto 7)="111111111"; This precludes some shortcuts like using >>the carry chain to perform the detect. It is often easier to convert >>from 2's complement notation to sign-magnitude notation, which is an >>unsigned magnitude plus an independent sign bit. The conversion is done >>by performing the 2's complement if the 2's complement input is negative >>to get an unsigned magnitude, and then retaining the sign bit. (this >>description is to answer a question posed by email). > > > I understand what you mean as negative numbers have a "1" at the most > significant bit which will give a 0 for the CLZ. I think i'll leave the > 2's compliment for now ;D 2's complement numbers repeat the sign until you get to the first significant bit. For example consider -5 represented as a 2's complement 8 bit number: -5 => 11111011. for sign magnitude, we represent it instead as +5 with a sign bit: -5 => 10000101 where the leftmost bit is the sign, and the remaining bits are the unsigned absolute value of the number to be represented. In that case we leave the sign bit out of the shifter and then shift the unsigned portion left to eliminate leading '0's. > > Thanks >Article: 113228
page 21 schematic shows "CLK" driving the FPGAs, but note 5 say "CLKOUT" is used to drive the FPGA's CLK input, any clue which is correct?Article: 113229
Hello, I am using FFT v.3.2 core from Xilinx to implement FFT algorithm on FPGA. I would like to download .dat file as my input (which is digital representation of sinusoidal wave shown below) to test the real-time functionality 0 30273 23170 -12539 -32767 -12539 23170 30273 I'm not sure if the above data would show up in the correct format in the newsgroup, but each line represents a point on sine line (.dat file taken from sample files on Xilinx website - sine_9_375mhz.dat). Now, I would like to download the project into FPGA and test (using .dat file) it. Is there a way to download .dat file into FPGA block memory? The connectors I have: 1) Parallel IV cable 2) CF card The software I have (all full educational versions): 1) Xilinx ISE 2) Chipscope Pro 3) FPGA Advantage I do not currently have A/D converters on FPGA board. I received a suggestion that I can use counter to represent the sine wave; however, I would need to perform further operations on the data (which would be different than constant frequency sinusoidal wave), so using counters to create those signals would not be the optimal solution for me. Thanks, Vitaliy Ryerson UniversityArticle: 113230
At the fourth line of the report, there is mention about CPU time and Elapsed time. Similarly at the end of the report, just before the message total memory usage, there is again mention about another CPU time and Elapsed time. I would like to know precisely what do these two times mean and what can be interpreted from them for a particular HDL program. Do they carry significance ? --Starting of the report -- Release 8.2i - xst I.31 Copyright (c) 1995-2006 Xilinx, Inc. All rights reserved. --> Parameter TMPDIR set to ./xst/projnav.tmp CPU : 0.00 / 5.14 s | Elapsed : 0.00 / 5.00 s --> Parameter xsthdpdir set to ./xst CPU : 0.00 / 5.14 s | Elapsed : 0.00 / 5.00 s --> Reading design: fsopform.prj --End of Report -- ========================================================================= CPU : 15.02 / 20.44 s | Elapsed : 15.00 / 21.00 s --> Total memory usage is 241916 kilobytesArticle: 113231
fpga_toys@yahoo.com wrote: > page 21 schematic shows "CLK" driving the FPGAs, but note 5 say > "CLKOUT" is used to drive the FPGA's CLK input, any clue which is > correct? Note 5 says there are two ways to drive CCLK. The schematic shows an external oscillator (using dotted lines) to show one way. The other method is not shown in the schematic. The CLK pin of the XCFxxS is an input. CLKOUT is only available on the larger parts (8 Mbits up).Article: 113232
Hi. I'm trying to implement a fast 128-bit barrel shifter in a Virtex4 device. The obvious way is a 7-level cascade, each level shifting by another power of 2. The result is rather slow. Adding one pipeline stop I can achieve just above 125 MHz, but the result is available after 2 clocks instead of 1. For my application I'd prefer to get the full result within a single clock period. I saw that it's possible to use the DSP48 slices as 18-bit barrel shifters, but I couldn't figure out how to combine them to form a 128-bit shifter - and less so in a single clock cycle (the DSP48 output is registered). Is there anything I can do to speed up the 7-level approach? Regards, MarcArticle: 113233
Vitaliy wrote: > Hello, > > I am using FFT v.3.2 core from Xilinx to implement FFT algorithm on > FPGA. I would like to download .dat file as my input (which is digital > representation of sinusoidal wave shown below) to test the real-time > functionality > > 0 > 30273 > 23170 > -12539 > -32767 > -12539 > 23170 > 30273 > > I'm not sure if the above data would show up in the correct format in > the newsgroup, but each line represents a point on sine line (.dat file > taken from sample files on Xilinx website - sine_9_375mhz.dat). > > Now, I would like to download the project into FPGA and test (using > .dat file) it. Is there a way to download .dat file into FPGA block > memory? > > The connectors I have: > 1) Parallel IV cable > 2) CF card > > The software I have (all full educational versions): > 1) Xilinx ISE > 2) Chipscope Pro > 3) FPGA Advantage > > I do not currently have A/D converters on FPGA board. I received a > suggestion that I can use counter to represent the sine wave; however, > I would need to perform further operations on the data (which would be > different than constant frequency sinusoidal wave), so using counters > to create those signals would not be the optimal solution for me. > > > Thanks, > > Vitaliy > Ryerson University The easiest way to get data into block memory, assuming it doesn't have to change during operation, is to generate a ROM using COREgen. You can use a .coe format file to initialize the ROM, which is then built into your project so the data is in the blockRAM when the bitstream is loaded. The .coe file is described in the core datasheet. It's a comma delimited list with a selectable radix. HTH, GaborArticle: 113234
Hello, The elapsed time is what you experience and can measure on your watch (namely, how long you had to wait, in seconds, for completion). The CPU time is a measure of how long the CPU was actually executing instructions related to completing the task. In a multitasking environment, your application is not the only application that is "running". You can see this in the Windows task manager, or by using a command like "top" on a unix machine. The difference between the elapsed time and the CPU time is time the CPU spent executing other applications, and I believe it also includes overhead from application context switching. I'm not sure how the time spent waiting on I/O (e.g. disk or network access) is accounted for. These values, along with the "Total memory usage is ..." statistic, are not directly relevant to digital logic design, and not generally useful to me except when trying to figure out: 1. Why I had to wait longer than expected (was it the task, or the CPU load?) Obviously, this never happens! ;) 2. If my computer is in need of a memory upgrade. Eric "kartheic anantha" <karthik.anantha@gmail.com> wrote in message news:1165606360.895392.303820@l12g2000cwl.googlegroups.com... > At the fourth line of the report, there is mention about CPU time and > Elapsed time. Similarly at the end of the report, just before the > message total memory usage, there is again mention about another CPU > time and Elapsed time. I would like to know precisely what do these two > times mean and what can be interpreted from them for a particular HDL > program. Do they carry significance ? > > --Starting of the report -- > > Release 8.2i - xst I.31 > Copyright (c) 1995-2006 Xilinx, Inc. All rights reserved. > --> Parameter TMPDIR set to ./xst/projnav.tmp > CPU : 0.00 / 5.14 s | Elapsed : 0.00 / 5.00 s > --> Parameter xsthdpdir set to ./xst > CPU : 0.00 / 5.14 s | Elapsed : 0.00 / 5.00 s > --> Reading design: fsopform.prj > > > --End of Report -- > > ========================================================================= > CPU : 15.02 / 20.44 s | Elapsed : 15.00 / 21.00 s > --> > Total memory usage is 241916 kilobytes >Article: 113235
Hello, I'm in the middle of a project which involves digitizing and decoding baseband NTSC composite video. Right off the top, I'll let everybody know that this is part of an educational project (part of it for a university project, though it's largely a hobbyist type project). I realize that the project will be useless in a couple years, and that there are pre-made devices out there, but I still want to do it. That being said, I think the hardest part of the whole project (for me) is just getting the data into the FPGA (cleanly)! I know very little about clock management, and I'm worried that I'm pushing the limits of my setup. Let me briefly describe what I'm doing. The traditional way to sample NTSC video, as I understand it, is to use dedicated chips to derive a "pixel clock" off of the hsync. This clock then feeds the ADC, and perhaps the FPGA. I am not doing this. I am using a fixed, free-running crystal oscillator clock (50 MHz Epson SG-8002JF). For the record, that clock came on my Digilent Spartan 3 starter board, which I'm using for the project. I plan on sampling at the full 50 MSPS, even though the video signal is band-limited to about 4.2 MHz. Now -- I'm posting in this group for help on getting the ADC data into the FPGA. If you don't know anything about video, you can ignore this next paragraph. But for those who are interested, I then use an algorithm I've developed to look for the hsync pulses. The time between hsync pulses is not exactly constant in the real world. However, since I have many more samples than I intend on keeping, I use an adaptive algorithm to keep a fixed number of pixels per line. I'm still working on the gritty details, but it'll probably involve some type of polyphase resampling. I then use a DPLL to lock onto the chroma subcarrier burst. The DPLL's use an efficient sinusoid table, which are made of a block RAM and an interpolater. I think I've seen this referred to as DDS (direct digital synthesis). Basically, you keep an index which contains more bits than are necessary to index the table. Then you use the extra low bits for interpolation. The DPLL's have two outputs, one of which is 90 degrees out of phase. In practice, I use two DPLL's, which each lock onto every other line... Since the chroma subcarrier phase is reversed every other line, I think this helps the DPLL's to track. I use the DPLL's to coherently demodulate the chroma signal into I and Q. This involves a digital multiplier and a FIR windowed-sinc filter. I might change this to a CIC filter, due to a helpful suggestion from another newgroup poster. I'll won't go into details of anything past that on this newsgroup, unless anyone is interested. There are some things I left out, like a 2d adaptive comb filter, VGA generator, etc. OK, now onto the issue at hand ! My Digilent starter board has some headers conveniently soldered onto the PCB. These connect to available digital I/O ports on the Spartan 3. I was previously going to naively output my clock onto any old pin on one of these headers, and feed it into the ADC. The ADC will be on a seperate breadboard. I would also attach a header on that breadboard, and would use a ribbon cable to connect the clock and (parallel) data pins. I knew (know) very little about how jittery the clock output would be. So... I would love to get some help from this group. I did a google seach for "fpga adc jitter", and found some Usenet comments. I posted them at the very end of this post. Sorry if it's considered rude to include such long clips, I'm not sure what the netiquitte is for that. Some of them were helpful, but I still feel shakey about the subject. I now plan to connect my crystal oscillator *directly* to the ADC (by soldering on a wire directly from the PCB, without going through the FPGA at all), will jitter be a problem? In one of my threads from a different newsgroup, a poster said that I might want to use a buffer register (or a FIFO) to seperate the "clean" clock domain from the "dirty" clock domain. That way, the data will be delayed a tiny amount, but it will always be ready when the FPGA tries to read it (with its jittered clock). However, when I did a search for "adc fifo", I found that lots of people are using an FPGA *as* the FIFO. So is an external buffer needed? Could I perhaps the Xilinx's DCM to just phase-shift my FPGA clock by 90 or 180 degrees, so that the ADC data is sure to be ready and waiting when I read it? One of the posts (which I clipped to this post) says that some high-speed ADC's have their own clock *OUTPUT*, which I can feed *TO* the FPGA. Can someone suggest an example of a 50 MSPS video ADC (ie, by "video ADC", I mean: with built-in clamping, sample-and-hold, and AGC)? I hadn't even thought of doing it this way, but would it be easier? Finally, another one of the clippings below says that commercial FPGA + ADC boards often feed the ADC clock directly from the FPGA (as I had intended to do). So, the obvious question is, how bad is it in reality? I only need 8 bits of precision (10 might be nice) - some loss of color detail is acceptable for this educational project. Can I get that by driving the ADC from the FPGA's clock? Remember that my signal is band-limited to 4.2 MHz, so it isn't very fast-changing relative to what the ADC can handle. Is there a way (in Xilinx) that I can be *sure* that the clock passes directly from the FPGA input pin to the output pin *without* going through a DPLL? Any completely alternative ideas? Suggestions to web sites or books with explanations? Thanks for the help, and for reading this long post !! Regards, Sean ------------------------------------ 1) The issue is not whether or not it works, rather it is an issue of noise added to you sampled signal due to sampling jitter. A better set-up is to run the clock directly from your oscillator to the ADC and to the FPGA, then use the DLL in the FPGA to solve the I/O timing issues at the ADC. Frequently, the ADC data is brought through a discrete registers such as an 'LS374 before going into the FPGA to improve the timing relationship at the expense of an additional cycle of clock latency. Amazingly, several of the commercial boards out there that have an FPGA and a decent speed ADC are set up with the ADC clock supplied through the FPGA, an arrangement that doesn't make sense for real DSP applications. 2) I'm not sure what you mean by drive the ADC with the FPGA. The signal flow is the other way around: the ADC will drive the FPGA. You should not drive your ADC clocks from the FPGA. The jitter introduced by the FPGA will absolutely kill the noise performance of the ADC at 800MHz. At 100 MHz it will reduce the SNR to considerably less than the 10 bits. Use a clean external clock to clock the ADC. Most high speed ADCs have a clock output that can be fed to the FPGA to get a clean transfer of the ADC data into the FPGA. 3) BTW, the jitter tolerance for the ADC is based on your input frequencies rather than on the ADC clock itself. The problem comes about by the sampling time uncertainty. The faster your signal changes, the less jitter you can handle at a given noise level. It is not trivial to design an ADC circuit that meets the part specs even at 40 MHz, jitter can make the effective size of the converter quite a bit smaller if you are not careful. There are a number of commercial boards out with FPGAs and ADCs on them. I can't think of even one that isn't driving the ADC clock from the FPGA. That doesn't mean it is the right way to do it, just that the designer either didn't know better or didn't want to give up the 'flexibility'. 4) The major caution to using PLL generated clocks is to watch the clock jitter, which can be significant at 200MHz. This can be accounted for in the FPGA design by subtracting the max jitter from the period constraint. It is a bit more problematic if it is used to clock an ADC or DAC, as then you introduce aperature jitter which in turn translates to a degradation of the SNR. --- The above were all posted by Ray Andraka, I believe. Hopefully he's still around on these newsgroups, he seems to know the subject very well!Article: 113236
jetmarc@hotmail.com wrote: > Hi. > > I'm trying to implement a fast 128-bit barrel shifter in a Virtex4 > device. > > The obvious way is a 7-level cascade, each level shifting by another > power of 2. The result is rather slow. Adding one pipeline stop I can > achieve just above 125 MHz, but the result is available after 2 clocks > instead of 1. For my application I'd prefer to get the full result > within a single clock period. > > I saw that it's possible to use the DSP48 slices as 18-bit barrel > shifters, but I couldn't figure out how to combine them to form a > 128-bit shifter - and less so in a single clock cycle (the DSP48 output > is registered). > > Is there anything I can do to speed up the 7-level approach? > > Regards, > Marc > There's not a lot you can do if you need it in a single clock cycle. The DSP48's can be used with some pipelining for more than 17 bits shift (17 bits is what you get with one because the multipliers are signed) by recognizing a shift is a multiply by a power of two and then cascading the DSP48s as though you were building a multi-precision multiplier. You can get clever with the DSP48's to reduce the number needed as well.Article: 113237
I wouldn't put to much faith in that plan as I have tried something similar to that and putting any serious amount of data into a .coe file crashes corgen. ---Matthew Hicks "Gabor" <gabor@alacron.com> wrote in message news:1165609647.067578.96990@80g2000cwy.googlegroups.com... > > Vitaliy wrote: >> Hello, >> >> I am using FFT v.3.2 core from Xilinx to implement FFT algorithm on >> FPGA. I would like to download .dat file as my input (which is digital >> representation of sinusoidal wave shown below) to test the real-time >> functionality >> >> 0 >> 30273 >> 23170 >> -12539 >> -32767 >> -12539 >> 23170 >> 30273 >> >> I'm not sure if the above data would show up in the correct format in >> the newsgroup, but each line represents a point on sine line (.dat file >> taken from sample files on Xilinx website - sine_9_375mhz.dat). >> >> Now, I would like to download the project into FPGA and test (using >> .dat file) it. Is there a way to download .dat file into FPGA block >> memory? >> >> The connectors I have: >> 1) Parallel IV cable >> 2) CF card >> >> The software I have (all full educational versions): >> 1) Xilinx ISE >> 2) Chipscope Pro >> 3) FPGA Advantage >> >> I do not currently have A/D converters on FPGA board. I received a >> suggestion that I can use counter to represent the sine wave; however, >> I would need to perform further operations on the data (which would be >> different than constant frequency sinusoidal wave), so using counters >> to create those signals would not be the optimal solution for me. >> >> >> Thanks, >> >> Vitaliy >> Ryerson University > > The easiest way to get data into block memory, assuming it > doesn't have to change during operation, is to generate a ROM > using COREgen. You can use a .coe format file to initialize > the ROM, which is then built into your project so the data > is in the blockRAM when the bitstream is loaded. The .coe > file is described in the core datasheet. It's a comma delimited > list with a selectable radix. > > HTH, > Gabor >Article: 113238
Hi Perry,
Partial Configuration through ICAP can be used to dynamically
reconfigure any functional block.
You may find this link helpful:
http://www.xilinx.com/publications/xcellonline/xcell_55/xc_prmethod55.htm
Basically the Xilinx PlanAhead tool has been enhanced to better support
partial reconfiguration flows.
For added convenience we have included a DRP on the System Monitor (V5),
and CMT/MGT (V4 and V5) blocks as Austin mentioned. The DRP allows
faster access to a limitted set of bits at normal fabric clock speeds -
ICAP allows R/W access to all bits - but is slower (configuration clock
frequencies).
Which one you use depends on your application.
- Vic
Austin Lesea wrote:
> Perry,
>
> Only those blocks that have a dynamic reconfiguration port (DRP) interface.
>
> We standardized on the DRP so that any block that wanted to provide the
> feature should follow the same interface (a bit like creating an
> internal bus architecture for blocks that need reconfiguration).
>
> At this time, the DCM, the MGT, and the System Monitor all have DRP.
> There may be more, but you may go to the user's guide, and look at each
> block (PPC, EMAC, PCIe, etc.) to see if they use DRP, or if they have a
> set of registers that are part of the fabric access (or both).
>
> Austin
>
>
> Perry wrote:
>
>>Hi all,
>>It seems that run-time reconfigurations are only available in DCM and
>>RocketIO blocks.
>>Concerning about partial reconfiguration, can every functional block be
>>partially reconfiged?
>>thanks
>>
Article: 113239Which is what I presumed when I did the layout, and it means that the schematic is wrong, IE should have CLKOUT for PROM 0, since the schematic implies that is an output, and the note should say that it's wired to CLK for the optional configuration with an external clock. Gabor wrote: > fpga_toys@yahoo.com wrote: > > page 21 schematic shows "CLK" driving the FPGAs, but note 5 say > > "CLKOUT" is used to drive the FPGA's CLK input, any clue which is > > correct? > > Note 5 says there are two ways to drive CCLK. The schematic shows > an external oscillator (using dotted lines) to show one way. The other > method is not shown in the schematic. The CLK pin of the XCFxxS > is an input. CLKOUT is only available on the larger parts (8 Mbits up).Article: 113240
hi all,
i am using spartan 3e fpaga xc3s100e -4 speed grade
i have a problem while i am doing PAR after that post PAR static
timing analysis i am getting -ve slack as my design needs 155mhz clock
internal i am using DCM and i am generating that clock and that
CLK2X_BUF of DCM is volating and as a result i am getting -ve slack
about 1ns i have tried optins like
place and route effort level medium....
palce and route mode -> multipass route...
and other optins that are there in timing closure report............
but still i am getting -ve slack so i tried option of changing speed
grade -5 that time slack is meetig but i have spartan 3e fpga which is
xc3s100e -4 grade ........
so i tried false path option ........ but in my design timing is
critical so i need to meet timing as false path will ignor that path i
am not sure whether i will get actul timing slack (0 or +ve) in
realtime on board...........
so anybody can plz help me in finding the solution for this and i have
a doubt whether spartan 3e xc3s100e will support freq of 155mhz
............
regards
srik
Article: 113241sp_mclaugh@yahoo.com wrote: > Hello, > > I'm in the middle of a project which involves digitizing and decoding > baseband NTSC composite video. Right off the top, I'll let everybody > know that this is part of an educational project (part of it for a > university project, though it's largely a hobbyist type project). I > realize that the project will be useless in a couple years, and that > there are pre-made devices out there, but I still want to do it. > > That being said, I think the hardest part of the whole project (for me) > is just getting the data into the FPGA (cleanly)! I know very little > about clock management, and I'm worried that I'm pushing the limits of > my setup. Let me briefly describe what I'm doing. > > The traditional way to sample NTSC video, as I understand it, is to use > dedicated chips to derive a "pixel clock" off of the hsync. This clock > then feeds the ADC, and perhaps the FPGA. I am not doing this. I am > using a fixed, free-running crystal oscillator clock (50 MHz Epson > SG-8002JF). For the record, that clock came on my Digilent Spartan 3 > starter board, which I'm using for the project. I plan on sampling at > the full 50 MSPS, even though the video signal is band-limited to about > 4.2 MHz. > Quick calculation: using 4.2 MHz full scale (of the ADC input range) sine wave 4.2MHz is about 26 Mradians/s ADC input range corresponds to -1 to +1 of normalized sine 1 LSB of 8-bit ADC is therefore 1/128 (normalized). 1 / (26M * 128) is about 0.3 nS So for a 1 LSB sampling error, you could live with 300 pSec of sampling jitter. My guess is that the threads you looked at were concerned about significantly smaller acceptable jitter, as would be the case in most networking applications where the sampling rate and bandwidth are closer to the same frequency. I would guess that your clock oscillator should have much less than 300 pS jitter unless it is poorly bypassed (power supply decoupling). You can run this through the FPGA without a DCM. Additional jitter would then only come from threshold jitter and ground bounce at the FPGA input, which can be minimized by not using the adjacent IOB's or driving the adjacent IOB's to ground. I would worry more about accounting for off-board routing and ground returns. Using a differential clock from the FPGA to the ADC board would help. If you don't have an ADC that directly takes a differential clock you'll need to add a receiver of some sort. By this time you'll have a significant delay built up on the data clock, so running the clock back to the FPGA along with the data will help you to properly sample the ADC data. HTH, GaborArticle: 113242
o You wonder about the jitter on the clock. I liked Gabor's calculations that showed you wouldn't have much of a problem in data accuracy for your situation. The differential clock approach would make things cleaner overall. o You were worried about bypassing the DCM. Your FPGA won't use a DCM unless you explicitly include it. o You're concerned about getting the right sampling point for the data. The clock-to-out times should be well specified for the ADC you choose. At 50 MHz, you'll probably have no issues but if your timing adds up to be tight, you might run a DCM from the same clock feeding the ADC or improve your timing budget through other means. If you can use a global clock I/O pair on the S3 part on your headers (I don't think I/O is available for S3E global clocks, just input) you could even use the clock as it appears on the FPGA pad/ball feeding the ADC as the input to your global clock buffer with a little care. Put together a timing budget that shows what your times are from the clock edge until data is ready at the FPGA pins and compare that with what the FPGA needs in setup time relative to the 20 ns clock period. It's the amount of slack in the budget that tells you if your implementation is a breeze. o Polyphase filtering is only part of what you can do. Since the noise you'll see from the clock jitter will be spread across the full 25 MHz bandwidth of your 50 MS/s data stream, you could either subsample your signal (aliasing all the noise into your slower rate baseband) or you can actively filter the signal before decimating with an FIR or other filter without taking up excessive resources. Good execution on this aspect of a video design is superb experience for digital design. ____ You seem on target with knowing much of what to look for in the design. I hope it's fun. - John_HArticle: 113243
I was thinking of implementing some computer vision or neuro-morphic VHDL designs and then posting them on open cores, maybe build a library of useful vision components for the embedded computer vision community (embedded CV was the topic of my MS thesis). I wonder if any one would be interested in cooperating in some effort to make this happen. We could even publish some papers if there was interest in the library. Let me know if you are interested and we can look at starting small and maybe work up to something bigger. I am interested in all sorts of embedded CV projects (classifiers, feature extraction/detection, image processing, systolic arrays for image enhancement, GA's, etc). Regards, Geoffrey WallArticle: 113244
Alan, first of all, if you want to ask questions, please respect the newsgroup "netiquette". there are already way too many "plz help!!! design doesnt work!!!" posts on this NG. that being said, lets take a look at your problem. i am not an expert, hopefully i can do some helping anyway :) > The board is A3PE-A3P-EVAL-BRD1 REV3 which is manufactured by Actel Co. > This board has expantion port for I/O, some LEDs, 1 LCD and regulators, > just simple design. A very simple board, rock solid FPGA. Ive never had any problems with that one. but as far as i know, they come with a A3P250, not a A3P-1000... > The tested VHDL source has function of serial communication(UART). but there are no UART connectors on this board? > And always, LED blink correctly in VHDL source > But serial communication function operates unregular > Sometimes Reciever operates well, But Transmitter is not. > Sometimes Transmitter operates well, But Reciever is not. Either your board or FPGA is borken, or its your VHDL design. I would bet on the latter. > X-tal is 11.0592MHz and operates correctly. the default board clock is 40. are you using a PLL? some of the PLLs are not powered on some actel boards, and sometimes Designer chooses to use one of them. check your boards documentation! > Supply voltage is 3.3V for I/O which supplied by Application board from > Actel > As I know, TTL level can adapt CMOS 3.3V > Power ground was one point. > And I use RS232 to USB converter, but they operate well. Self test > passed. that doesnt prove anything. find a scope and check the TX signal manually. and I wouldnt add extra sources of failure when things arent working, connect the UART directly to your PC! > I don't know well about timing constraints which is default option. > But palce&router of Actel said satisfying the timing constraint. do you actually _have_ any? in any case, i dont think something as simple as an UART could have timing problems. > I can't understand about this situation.... > I use same source(VHDL), same program tool(Libero), same > device(A3P1000) and same programmer(FlashPro3)....But the device > operation is not regular.... > I test some functions using StartKit from Actel Co. > Many times, parts of function are un-operation.... > The un-operated functions are not fixed !!! Malfunctions are > irregular..................... I usually get this kind of behavior when i forget to synchronize external signals before reading them. google for "Peter Alfke" and "Metastability" for more info. > Also, the source of VHDL had been verified in Altera device > (EPF10K100ARC240) > In Altera, all functions are operated correctly........... I dont think it has anything to do with the FPGA vendor. I have had the same quick'n-dirty UART design running on actel, xilinx, altera and lattice boards without any problems. your problem could of course have something to do with the different clocks on each board, maybe in some cases the _derived_ uart clock differs a few percent too much against the ideal UART clock?? > Always, Actel's programmer said "Verifying Passed"....Is that true???? that means that flash pro writes your program to FPGA, then reads it back to make sure there were to communication errors. note that some actel FPGAs cant do readback, so the flash pro tool sometimes says Verifying Passed" without really checking. > Plz, help me.... I lost self control using Actel's device.... Help me, > Help me > > Are U want any informations? Plz, let me know.. I'm beginner of FPGA.. > :-) > Are there some options or parameters to consider for palce&route ? no, the default options are usually ok. one last thing, the Libero tool comes with a _superb_ beginner tutorial (there are also videos on their web site), which explains everything from creating a project to post-layout simulation. have a good look at those document, then do a post-synthesis simulation to find those nasty bugs. burnsArticle: 113245
there are two 2C35 boards that I know of: Altera NIOS II kit and Terasic DE2. by the way Mike, there are *hint* IRDA *hint* components on the DE2 board. you will find many projects on the Terasic website, ranging from LEDs flashers to a fully working TV decoder and a music synthesizer. There are also few universities that use this board in courses, and they usually have some very exciting projects online. burns Mike Harrison wrote: > I'm looking for a complete project containing a minimal VHDL design for the Cyclone II, preferably > 2C35 or similar to have a play around with with prior to getting hold of a real board for an > upcoming proiject - the sort of thing that usually comes with a low-end devboard to flash a few > LEDs etc. > Can't find anything at Altera for this family. > If <5MB, please email to mike@whitewing.co.uk, thanks.Article: 113246
Comments below. Gabor wrote: > Quick calculation: > using 4.2 MHz full scale (of the ADC input range) sine wave > 4.2MHz is about 26 Mradians/s > ADC input range corresponds to -1 to +1 of normalized sine > 1 LSB of 8-bit ADC is therefore 1/128 (normalized). > 1 / (26M * 128) is about 0.3 nS > > So for a 1 LSB sampling error, you could live with 300 pSec of > sampling jitter. My guess is that the threads you looked at > were concerned about significantly smaller acceptable jitter, > as would be the case in most networking applications where > the sampling rate and bandwidth are closer to the same > frequency. Thanks, it's nice to have a concrete figure like that. I hadn't thought to work backwards and calculate what jitter I can live with (not yet knowing how much jitter I have). > I would guess that your clock oscillator should have much > less than 300 pS jitter unless it is poorly bypassed (power > supply decoupling). You can run this through the FPGA > without a DCM. Additional jitter would then only come from > threshold jitter and ground bounce at the FPGA input, which > can be minimized by not using the adjacent IOB's or driving > the adjacent IOB's to ground. OK, after spending *far* too long on Epson's web site (the eea.epson.com site is poorly organized, though epsontoyocom.co.jp is better), I found some jitter figures. It says that for a 15pF load and a 3.3V power source, I should expect 200 ps maximum cycle-to-cycle jitter, or 250 ps maximum peak-to-peak jitter. As you said, that is assuming a clean (isolated) power source. I'll describe the power source in a second. But first, let me paste two lines from Epson's data sheet that sound a bit ominous: "Because we use a PLL technology, there are a few cases that the jitter value will increase when SG-8002 is connected to another PLL-oscillator. In our experience, we are unable to recommend these products for applications such as telecom carrier use or analog video clock use. Please be careful checking in advance for these applications (jitter specification is max 250 ps / CL = 5 pF." Perhaps they recommend against it because most commercial applications would need more than 8 bits of resolution (10 is usually used, I think, maybe 12 for professional video equipment). After reading that, do you still think that my application will be OK? And even if I run the clock through the FPGA? I don't mind spending $20 or whatever on getting a better clock, if it sounds like the best solution. I want this system for perform reasonably well, and I'm willing to pay for it. The starter board even has an optional 8-pin clock socket, so it would be exceptionally easy to do. After reading the specs on that Epson clock, I know *why* they included that socket! :-) Anyway, I'll now quickly describe the power supply (and decoupling of clock power input) on the Digilent starter board: - All power first comes from a 5V AC-DC wall plug - All power then goes through a LM1086CS-ADJ 3.3V regulator - For the FPGA, 2.5V and 1.2V are generated from the 3.3V - The 3.3V is used directly (shared) by a number of on-board components, including the crystal oscillator clock - There appear to be 35 parallel 47nF capacitors between 3.3V and ground - The only other isolation provided to the oscillator's power pin is another locally placed 47nF capacitor between power and ground Does it sound like the clock power input is adequately isolated (clean)? I don't have a "gut feeling" one way or the other. > I would worry more about accounting for off-board routing > and ground returns. What do you think about the previous plan I mentioned. I'd use about 6" of standard ribbon cable (about the same grade as ATA cabling) to connect from a header on the Digilent starter board to the ADC breadboard. > Using a differential clock from the > FPGA to the ADC board would help. If you don't have > an ADC that directly takes a differential clock you'll need > to add a receiver of some sort. I've never used a differential clock before. I wonder if my Spartan can do that... Some initial searching did turn up some mention of differential output pins (being used mostly for DDR memory clocks). If I can't do it on-chip though, there's no point, because I have to get to the breadboard to mount any discrete chips. There's no extra space on the starter board. And I don't intend to build a custom PCB (with the FPGA) to replace the starter board. > By this time you'll have > a significant delay built up on the data clock, so running > the clock back to the FPGA along with the data will help > you to properly sample the ADC data. I understand why there would be delay, but can you explain the part about running the clock back to the FPGA? Since it's a fixed delay, couldn't I just use the DCM to delay the Spartan's clock by a fixed amount? > HTH, > Gabor Very much !! Thanks.Article: 113247
Folks, I have an EDK(*1) based project that utilizes the Microblaze, along with several peripherals connected via OPB (on-chip peripheral bus) for use with a Spartan3(*2). The project is set to use VHDL. I would like to develop a custom data encoder(*3) Verilog module that can be accessed via C, and I am trying to determine if developing the module as device that attaches to the OPB would be a good choice of implementation. Probably I am missing some important technical considerations about the verilog module's interfaces, etc. However, it appears that if I try to develop the lzw_opb in this fashion, it will require that I write a device driver similar to the other OPB components. Also since the project is set for VHDL, I am not certain how to develop the Verilog project along side. Wondering if anyone else has had a similar issue and can perhaps shed some light on how to approach this kind of problem? The basic design I have in mind is as follows: Data Input => UART => C code running on uBlaze => updates state of lzw_opb => UART => Data out Thanks, BEA *1 Using Xilinx EDK 6.3 Build EDK_Gmm.12.3+1 *2 Spartan3 xc3s400 *3 LZW compression algoArticle: 113248
I got this working today using the following configuration : 16 bit interface to DRAM (yes, I am using the ML403 right now, but I plan on migrating to a mini-module in the near future). One PLB interface (I will split this out to ISPLB and DSPLB later...I had issues, but that is probably due to lack of experience with EDK). One NPI interface. I created an NPI "wrapper" and connected this to the NPI port on the MPMC2. Just curious, I noticed that "transparent" busses are being depreciated according to some documentation I read...what is the replacement bus type going to be? Everything looks good so far in terms of running in hardware. With this base configuration up and running, I'll have plenty of time/flexibility to experiment. The first thing I want to do is use the ISPLB/DSPLB interfaces for the performance increases. For now, I am simply running a memory test over the weekend. Just curious, did anyone get this up and running using SRL16s as opposed to BRAM for the interface FIFOs? I cannot wait for the version of the core where you can trade off LUTs for BRAM since the ideal situation is a mix of memories....still, this is more than adequate for now :)! Xilinx support has been very helpful as well as this group. Thanks! I hope to return the favor someday :)! I've been lurking way too long... Ed ed_h wrote: > Hi all, > > Has anyone ever had success routing an NPI port of the MPMC2 > controller to an External Port of a PPC based system component in EDK > (i.e. I would like to route an NPI port to some custom logic...I use > the flow where I use EDK simply to generate a component & I > subsequently instantiate this in the top level of my VHDL design)? I > am having a lot of problems doing this. Xilinx doesn't have a > reference design available for this partuicular case; however, the > documentation for MPMC2 implies that one can do this. Please keep in > mind that I am an EDK newbie....I have been using Xilinx > Alliance/ISE/etc. for many years though :)! > > What I seem to be seeing is that MPMC2 declares the NPI interface to > be a "transparent bus". Now, does this imply that I have to make some > kind of "bus to pins" converter and subsequently declare this component > in an MPD file, or is this completely useless? What I tried doing was > modify the MPMC2 MPD generated by the GUI...I simply removed the > "transparent bus" declaration from the MPD as well as all the labels on > the ports that were part of this bus, but that did not seem to help. > It almost seems like EDK is automatically recognizing the NPI bus as > some sort of "bus" and is getting confused no matter what I comment out > of the MPD. > > I understand that my above description sounds rather stupid. > However, I am just throwing this out there for discussion to see if > anyone was successful doing this. Basically, my MPMC has 5 ports : > > ISPLB > DSPLB > PLB (seems I need this so that I can add PLB slaves....if not added in > the MPMC2, I recall seeing errors...all reference designs seem to have > this as well). > OPB (again, seems like I need this in the MPMC2 or else I get errors > when adding OPB slaves to my EDK design...all reference designs seem to > have this as well) > NPI > > All I really thought I would need would be the ISPLB and DSPLB so that > the PowerPC would have fast access to the DDR DRAM. The NPI is > basically intended as port for storing data that is streaming into the > FPGA. I hope to use custom hardware to pop data from DRAM after the > PowerPC does some processing on it. > > If anyone has any tips, tricks, pointers, etc., it would be appreciated > greatly! I filed a webcase on this, but I would have to imagine that > someone out there has run into this situation before! > > Thanks! > > Ed > > PS After re-reading this before posting, I realized that some of the > errors or warnings I get are related to the block diagram generator > getting confused about multiple busses and probably not able to place > and route the block diagram...this might simply be a red herring & an > actual physical implementation might be OK....I will post again if that > is the case, but I am having problems with the PLB masters and slaves > now not having matching bit widths...ugh...Article: 113249
Wow! This newsgroup is like having a whole team of consultants or professors. Barely took an hour to get two really helpful replies! John_H wrote: > o You wonder about the jitter on the clock. > > I liked Gabor's calculations that showed you wouldn't have much of a > problem in data accuracy for your situation. The differential clock > approach would make things cleaner overall. As did I ! I'm looking into the differential clock approach now, though I fear that it won't be do-able. I *think* the Spartan 3 can do differential output, using special features of the IOB's, but it seems that some external setup/calibration components (resistors) are required. It would be up to Digilent (producer of my starter board) to have properly implemented these. There appear to be quite a few "special" output modes (ie, LVPECL, etc) and I would be lucky for them to have implemented exactly the one I need. Building my own PCB for the Spartan is out of the question at this time (it would take me a year or more to learn all the necessary skills). I could be mistaken - maybe there is an easy way. That's just my current best-guess after a few hours of research. > o You were worried about bypassing the DCM. > > Your FPGA won't use a DCM unless you explicitly include it. That's good to know. I wonder if I should still worry about routing the clock through the FPGA's output header to drive the ADC. Perhaps there would be added jitter due to other reasons, such as active switching flip-flops near the driving IOB... ? I'm basically repeating this from another post I've read, I don't know what order of noise we're talking about here, and whether it's negligible compared to my poor oscillator. > o You're concerned about getting the right sampling point for the data. > > The clock-to-out times should be well specified for the ADC you choose. > At 50 MHz, you'll probably have no issues but if your timing adds up > to be tight, you might run a DCM from the same clock feeding the ADC or > improve your timing budget through other means. I think you're talking about the same thing I say a bit further down (offsetting the FPGA clock by the clock-to-out time), but correct me if I'm wrong. > If you can use a > global clock I/O pair on the S3 part on your headers (I don't think I/O > is available for S3E global clocks, just input) you could even use the > clock as it appears on the FPGA pad/ball feeding the ADC as the input > to your global clock buffer with a little care. As of even yesterday, anything about the internal clock distribution in the FPGA would have flown right over my head. However, earlier this afternoon, I was reading a bit about the global clock buffers, etc. It'll take me awhile to digest all the literature I've read from Xilinx, plus what you wrote. So I'll get back to you on that one. Though if you're in the spoon-feeding type of mood, my mouth is open. > Put together a timing budget that shows what your times are from the > clock edge until data is ready at the FPGA pins and compare that with > what the FPGA needs in setup time relative to the 20 ns clock period. > It's the amount of slack in the budget that tells you if your > implementation is a breeze. Ah yes, a timing budget is something I will be doing. Of course, the rest of my design isn't finished yet, so I don't yet know what type of max setup times I'll need. I guess if I use input buffers (using IOB's), the setup time to get the data into the FPGA will be independent of the rest of my design, right? I've never touched any IOB features before, but it seems easy (just set a single attribute, I think...?). On the other hand, couldn't I avoid the issue altogether by using a DCM to adjust my FPGA clock by the clock-to-out time of the ADC? That way, the data is ready right on the rising edge of my FPGA clock. It seems that I can make adjustments in increments of 1/256 of my clock frequency. > o Polyphase filtering is only part of what you can do. > > Since the noise you'll see from the clock jitter will be spread across > the full 25 MHz bandwidth of your 50 MS/s data stream, you could either > subsample your signal (aliasing all the noise into your slower rate > baseband) or you can actively filter the signal before decimating with > an FIR or other filter without taking up excessive resources. Good > execution on this aspect of a video design is superb experience for > digital design. Good point! On my first reading, I got caught up on the "subsample" part for awhile, and kept thinking thoughts about running an ADC below the center frequency of a narrow band-pass signal. Then I realized that you were referring to the method I use to choose which samples to keep (ie, decimation, etc), and the "aliasing noise into..." part became clear. Now, it turns out that I *was* going to include a low-pass block in my polyphase resampler, but I must confess, I wasn't thinking of cutting out noise due to clock jitter in my ADC. I knew that I had to band-limit my signal before decimation, but I figured that the only high-frequency information would be noise coming directly from the video source. Cutting out a large chunk of the noise caused by jitter in my sampling clock is a very welcome bonus! So in essence, by sampling at 50 MSPS rather than the minimum of 8.4 MSPS, and then applying a low pass with cutoff around 4.2 MHz, I'm getting rid of about (25-4.2)/25 * 100% = 83% of the noise to to jitter on the ADC clock (assuming the noise content is uniformly distributed from 0 to 25 MHz)... Does that calculation sound right (assumes ideal filters, etc)? If so, what a pleasant surprise! ____ > > You seem on target with knowing much of what to look for in the design. > I hope it's fun. I appreciate the kind words, though I think I'm right on the borderline capability-wise. Let's hope I'm not right below that line - close enough to waste a lot of time, but just too far to ever get it working! But yes, it should be a fun project. The info you gave was very helpful, thanks! Regards, Sean
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