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
Hi, John I suppose you know about the old Xilinx app note: http://direct.xilinx.com/bvdocs/appnotes/xapp028.pdf which would benefit from your diode trick. Cheers Peter Alfke, Xilinx Applications On Oct 31, 10:32 am, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Wed, 31 Oct 2007 09:38:41 -0700, r...@desinformation.de wrote: > >> I "invented" this last week. FPGAs aren't very good at implementing > >> the classic charge pump. > > >>http://s2.supload.com/free/PFD.jpg/view/ > > >> The outputs here are just hard (not tri-state) logic outputs, driven > >> directly by the up/down flipflops in the pfd circuit. It's nicely > >> symmetric. > > >> John- Zitierten Text ausblenden - > > >> - Zitierten Text anzeigen - > > >But the Inventor mentioned the additional jitter due to uncorrelated > >noise of the 2 PFD outputs and their summation in your example, and > >the evil glitches due to unmatched symmetry and parasitic coupling of > >the digital to the analog ! > >This must be worth a patent. > > >Having read > > >http://www.keystonesemiconductor.com/press_releases.html > > >i now fear the evil glitch and deadtime jitter to corrupt my computer > >before global warming blasts icebergs and blazes glaciers. > > Oh, the guy is clearly a lunatic, and an amateur lunatic to boot. His > writing is hilarious. > > But the dual-diode thing solves a couple of problems using an FPGA as > a phase-frequency detector. > > JohnArticle: 125676
MM wrote:
> For the purpose of this discussion VHDL is a language describing hardware.
> Every change in code requires new hardware to be synthesized. For this
> simple reason software style debugging is not really possible with real
> hardware. However, you can debug all you want (before going to hardware)
> with VHDL simulators such as, for example, Modelsim, or Active HDL.
Good point.
Some prefer working out the logical problems
in a tight loop at the code level on a simulator.
This avoids waiting for a special place and route
on each try.
-- Mike Treseler
Article: 125677Thank you, Ray, for pointing this out. We know that the carry delay is important, and we have used a few tricks to make it short, while maintaining the appearance of a "ripple delay". Peter Alfke On Oct 31, 10:26 am, Ray Andraka <r...@andraka.com> wrote: > mk wrote: > > Actually what the FPGAs has should be named "dedicated/hard-wired > > carry ripple logic & routing" as there is not much "fast" about it. > > What would've been fast is if they added some carry look ahead logic. > > Within a CLB, there certainly is carry look-ahead. It is abstracted out > in the user's guides as an implementation detail that is not visible to > the user. Be assured however, that there is a carry look-ahead going on > in the physical hardware.Article: 125678
Peter Alfke wrote: > Hi, John > I suppose you know about the old Xilinx app note: > http://direct.xilinx.com/bvdocs/appnotes/xapp028.pdf > which would benefit from your diode trick. > Cheers > Peter Alfke, Xilinx Applications The tristate drive is seen in many PFD's. Tristate works well, but does float the FPGA pin at the Opmap Bias point, and is also a noise-injection point. Also either the Diode, or Tristate directly couple the FPGA Vcc and GND noise into the integrator (when ON) So the "purists PFD", would use a TinyLogic analog Switch, [example of 2 in one package : 74LVC2G66 ] and keep the Hi-Z integrator node tiny, and shielded from digital charge injection, and power supply noise. Also, some designs have deliberate overlap in the PFD impulses, as that avoids a dead-band, which can give higher spurious noise spurs. -jgArticle: 125679
MMJ wrote: > Hi, > > For a future project we are considering the use of FPGA technology and IP > cores instead of using an ASSP solution. > As a software guy...only doing some initial invistigations I have absolutely > no specific idea of how much functionality you can expect to implement into > a FPGA device in the pricerange of maximum 100$. > > Some of the basic functionality we need is: > > - Control CPU (e.g. ARM9). > - Memory Interface for control CPU and video decoder. > - x number of I/O interfaces (High speed parrallel). > - n Video decoders (MPEG2, MPEG4, H.264) > - Interal switch matrix of some sort. > > How much of this should we (hypothetical speaking) be able to implement in a > single device in the mentioned pricerange? Offcourse I don't expect an exact > answer to this question since everything depends on how each function is > realized. But a "This might be possible" or "Not in this world" answer with > some pointers would be very nice. Hope this is not to stupid a question. You should also look at the CODE and DATA size requirements, and the DATA bandwidths needed. Also realise that the 'single chip' is rather a myth, you will need the FPGA plus NV config and code storage plus run-time code storage. Generally, if you can buy merchant silicon, that will always be cheaper (both in use and R&D costs) than a FPGA solution - it also usually means you step to a smaller/cheaper FPGA. For example, if your code/data will fit into a single chip microcontroller, you can eliminate many EMC issues. -jgArticle: 125680
On Wed, 31 Oct 2007 11:22:20 -0700, Peter Alfke <peter@xilinx.com> wrote: >Hi, John >I suppose you know about the old Xilinx app note: >http://direct.xilinx.com/bvdocs/appnotes/xapp028.pdf >which would benefit from your diode trick. >Cheers >Peter Alfke, Xilinx Applications The diode thing allows true overlap (ie, zero deadband operation) without worrying about relative pfet/nfet drive strengths or tristate enable times. It also eliminates a more subtle problem related to pin capacitances, which would add yet another nonlinearity to the already nonlinear xapp circuit. Skyworks makes some 0.22 pF, SC79 schottkies that would be ideal here. Loop gain doubles in the overlap region, but that's easy to deal with. It's sure better than a flat spot. The opamp situation can be interesting. JohnArticle: 125681
John Larkin wrote: > On Wed, 31 Oct 2007 11:22:20 -0700, Peter Alfke <peter@xilinx.com> > wrote: > > >>Hi, John >>I suppose you know about the old Xilinx app note: >>http://direct.xilinx.com/bvdocs/appnotes/xapp028.pdf >>which would benefit from your diode trick. >>Cheers >>Peter Alfke, Xilinx Applications > > > The diode thing allows true overlap (ie, zero deadband operation) > without worrying about relative pfet/nfet drive strengths or tristate > enable times. It also eliminates a more subtle problem related to pin > capacitances, which would add yet another nonlinearity to the already > nonlinear xapp circuit. > > Skyworks makes some 0.22 pF, SC79 schottkies that would be ideal here. > > Loop gain doubles in the overlap region, but that's easy to deal with. > It's sure better than a flat spot. Yes, better systems take effort to avoid any dead-band > > The opamp situation can be interesting. With the single-resistor drawn in the Xilinx app note, it gets worse - there is buffer contention during that (short) time = more unknowns -jgArticle: 125682
>THE ERROR: >ERROR:Simulator:222 - Generated C++ compilation was unsuccessful I've run into something like this fairly often. Usually because the [C++] compiler was unable to write the executable, because Windows thought it was busy. There's a message about "unable to delete...", but it's usually lost in the shuffle. If this is the case, kill any runaway simulation process. If the file remains busy, rename it. If that fails, pay your respects to Windows and reboot. -- mac the naïfArticle: 125683
Using the Digilent XUP V2P Board, I have to use additional memory (256 Mb DDR SDRAM). The only memory drivers I can find run with the embedded processor kit. I do not wish to use the PowerPC or Microblaze processor nor the EDK. Does any one have access to some code to access the add on memory module directly. tdbArticle: 125684
"Peter Alfke" <peter@xilinx.com> wrote in message
news:1193854940.231665.110490@z24g2000prh.googlegroups.com...
> Hi, John
> I suppose you know about the old Xilinx app note:
> http://direct.xilinx.com/bvdocs/appnotes/xapp028.pdf
> which would benefit from your diode trick.
> Cheers
> Peter Alfke, Xilinx Applications
>
Guys,
Beware of XAPP028...
From
http://groups.google.com/groups/search?q=xapp028+symon+MAXSKEW+group%3Acomp.arch.fpga
Quote:-
A small note of caution when using Peter's XAPP028 in Virtex II. As
well as constraining the logic to the CLBs shown in the app note, make
sure you specify a MAXSKEW attribute on the reference signal and
feedback signal to the circuit. I use 100ps. Without this the circuit
can occasionally malfunction depending on the place and route. (These
are the signals called 'from VCO divided by N' and 'from reference
frequency'.)
There was no problem when this circuit was used on older FPGAs
where the routing to the F and G lookup tables in a single CLB was
guaranteed to have low skew. In Virtex II this is no longer the case
and a single signal that goes to both the F and G inputs of a CLB can
have significant skew if not constrained. This can cause the circuit
of XAPP28 to misbehave.
HTH., Syms.
Article: 125685> > Some of the basic functionality we need is: > > - Control CPU (e.g. ARM9). > - Memory Interface for control CPU and video decoder. > - x number of I/O interfaces (High speed parrallel). > - n Video decoders (MPEG2, MPEG4, H.264) > - Interal switch matrix of some sort. Can you share what sort of level of video decoding performance you would need? Would you need to support multiple video standards at the same time? What sort of I/O interfaces are needed - is it for the video and if so what formats? Is the CPU just required to control the video decoder, or are there other tasks needed? What you ask is not totally unfeasible depending on your precise requirements. Thanks, Andy.Article: 125686
On Wed, 31 Oct 2007 13:11:54 -0700, Peter Alfke <peter@xilinx.com> wrote: >Thank you, Ray, for pointing this out. >We know that the carry delay is important, and we have used a few >tricks to make it short, while maintaining the appearance of a "ripple >delay". >Peter Alfke > >On Oct 31, 10:26 am, Ray Andraka <r...@andraka.com> wrote: >> mk wrote: >> > Actually what the FPGAs has should be named "dedicated/hard-wired >> > carry ripple logic & routing" as there is not much "fast" about it. >> > What would've been fast is if they added some carry look ahead logic. >> >> Within a CLB, there certainly is carry look-ahead. It is abstracted out >> in the user's guides as an implementation detail that is not visible to >> the user. Be assured however, that there is a carry look-ahead going on >> in the physical hardware. > Peter, If I remembering correctly there is a TTL IC which has a 4 bit CLA in it. It would fit into the CLB nicely :-)Article: 125687
On Oct 31, 3:47 pm, "Symon" <symon_bre...@hotmail.com> wrote: > "Peter Alfke" <pe...@xilinx.com> wrote in message > > news:1193854940.231665.110490@z24g2000prh.googlegroups.com...> Hi, John > > I suppose you know about the old Xilinx app note: > >http://direct.xilinx.com/bvdocs/appnotes/xapp028.pdf > > which would benefit from your diode trick. > > Cheers > > Peter Alfke, Xilinx Applications > > Guys, > Beware of XAPP028... > > Fromhttp://groups.google.com/groups/search?q=xapp028+symon+MAXSKEW+group%... > > Quote:- > A small note of caution when using Peter's XAPP028 in Virtex II. As > well as constraining the logic to the CLBs shown in the app note, make Thanks, Syms, for pointing this out. I published this in 1990, in the XC3000 era, and I was proud of packing it so nicely. Your comment makes me retire the circuit, but it will unfortunately survive on the internat... Peter > sure you specify a MAXSKEW attribute on the reference signal and > feedback signal to the circuit. I use 100ps. Without this the circuit > can occasionally malfunction depending on the place and route. (These > are the signals called 'from VCO divided by N' and 'from reference > frequency'.) > There was no problem when this circuit was used on older FPGAs > where the routing to the F and G lookup tables in a single CLB was > guaranteed to have low skew. In Virtex II this is no longer the case > and a single signal that goes to both the F and G inputs of a CLB can > have significant skew if not constrained. This can cause the circuit > of XAPP28 to misbehave. > > HTH., Syms.Article: 125688
On Oct 31, 6:50 pm, mk <kal*@dspia.*comdelete> wrote: > > Peter, > If I remembering correctly there is a TTL IC which has a 4 bit CLA in > it. It would fit into the CLB nicely :-) Do you think of the 74181 (=9341 in Fairchild parlance)? Nostalgia from 1970... It's a 4-bit ALU, but that means 22 signal pins in a 24-pin package: 4+4 operand inputs and 4 result outputs,5 mode controls (one of them to change between logic and arithmetic), carry in, carry out, carry generate, and carry propagate, plus an A=B output thrown in for free. Hard to put into a CLB, unless you define the mode by configuration. PeterArticle: 125689
mk wrote: > > Peter, > If I remembering correctly there is a TTL IC which has a 4 bit CLA in > it. It would fit into the CLB nicely :-) That reminds me of the time I was in one of two row boats racing to shore. I thought I could "help" the race by jumping out and pushing the boat with my swimming. Boy did we suddenly slow down! A 4-bit CLA in a CLB (wait - is there a CLK? no, no...) is marginally helpful in only the most extreme cases. Very long adders would still need a "generate" signal from each segment in a multi-segment adder (even the 74181 is a 4-bit ALU) when the individual sum is all-1s to go along with the carry from the carry chain. If you wait for the result to decode the generate, you need to get on and off the carry chain and through two levels of logic to detect a 16-bit "generate" or double your counters with A+B and A+B+1 results to come up with a C and G at the same time. What's this gaining? The carry from your 4-bit CLA needs 2 levels of logic to generate the "lookahead" from the 4 segments. A 64 bit counter would need 4 levels of logic plus routing *or* twice the number of adders with 2 levels of logic on top of routing. This is a quick way to make things go very slow. If you want to accelerate small adders in FPGAs, you can't do it with FPGA logic. The carry chains are already very low propagation though there might be an opportunity to get on and off the carry chains more quickly with focused silicon development, perhaps compromising other performance aspects of the chip to achieve that improved on/off adder delay. If you want to accelerate very large adders, there are methods that can provide better results than a CLA. You know about carry select, carry skip, etc, you should know that for small adders there's no help in the FPGA. Don't believe me? Take a splash. Watch the boat slow down. Synthesis is cheap! Or was the smiley face showing an attempt at humor that I just can't grasp? If you're suggesting that adding dedicated CLA functionality to the FPGA fabric, think of what it takes to produce the generate with the carry and aggregate the signals into the CLA structure. Do you think it could possibly be worth it for 99% of the adders in user designs? - John_HArticle: 125690
On Wed, 31 Oct 2007 21:19:13 -0700, Peter Alfke <alfke@sbcglobal.net> wrote: >On Oct 31, 6:50 pm, mk <kal*@dspia.*comdelete> wrote: >> >> Peter, >> If I remembering correctly there is a TTL IC which has a 4 bit CLA in >> it. It would fit into the CLB nicely :-) > >Do you think of the 74181 (=9341 in Fairchild parlance)? Nostalgia >from 1970... >It's a 4-bit ALU, but that means 22 signal pins in a 24-pin package: >4+4 operand inputs and 4 result outputs,5 mode controls (one of them >to change between logic and arithmetic), carry in, carry out, carry >generate, and carry propagate, plus an A=B output thrown in for free. >Hard to put into a CLB, unless you define the mode by configuration. >Peter > Actually I was thinking of 74182. The resemblance between it and page 193 is quite interesting, no? 4 pairs of inputs in addition to carry from previous block. The outputs need changing a little though.Article: 125691
On Oct 31, 11:42 am, Antti <Antti.Luk...@googlemail.com> wrote: > On 31 Okt., 07:57, Franck <franck.jull...@gmail.com> wrote: > > > Thanks, > > > I have seen this product but this is not flexible enough for me. This > > king of chip is too specific, that why I wanted to do this with a > > fpga. I don't know exactly how flash memory works so I'm not able to > > know which throughput I could reach with an IDE interface and a flash > > memory controller in a fpga.... > > > I thought someone else could have done this before, then I would gain > > some time... > > > Anyway, I'll have to shearch by myself :) > > you are asking for "commercial grade" IP core. > I have done evalution/search for similar case, the closest you get > are partial IP solutions for around 20.000 USD or so for the ATAPI > device IP core. > > I bet you will find it not free what you are looking for > > Antti Thanks Antti, I think I'm going to have to study ATA standard and flash memory mechanism :) Regards, Franck.Article: 125692
My FPGA master clock is at 100MHz. I have assigned a counter to count from 0 to 99 to achieve a period of 1usec. As the counter is counting from 0 to 99, i will take 1 sample at each count and therefore i have a total of 100 samples. Now my task requires me to increase my sample size to 200. However, i can't increase the counter count to 0 - 200 as this will increase the period to 2usec. My task requires me to double the sample size while maintaing the period at 1usec. I tried to implement this by adding another clock to the system but i am not able to synthesis the code as one clock is only allowed same for dual edge behavior of the clock pulse. I am running out of ideas how to accomplish this task as i am not very strong in VHDL coding and my deadline is nearing. Would appreciate if someone can help me. Thanks!!Article: 125693
raullim7@hotmail.com wrote: > My FPGA master clock is at 100MHz. I have assigned a counter to count > from 0 to 99 to achieve a period of 1usec. As the counter is counting > from 0 to 99, i will take 1 sample at each count and therefore i have > a total of 100 samples. Now my task requires me to increase my sample > size to 200. However, i can't increase the counter count to 0 - 200 as > this will increase the period to 2usec. My task requires me to double > the sample size while maintaing the period at 1usec. Use a PLL to double the clock frequency, if your FPGA has one. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 125694
> Has anybody experience with xilinx bitfile merging using a bmm file? [...] > The new bitfile is generated, but no luck. Program not running. > Anybody an idea how to tackle this? I once summarized my experience with bmm files in http://home.mnet-online.de/al/BRAM_Bitstreams.html Maybe you find some answers there. Cheers ArnimArticle: 125695
Frank Buss wrote: > raullim7@hotmail.com wrote: > >> My FPGA master clock is at 100MHz. I have assigned a counter to count >> from 0 to 99 to achieve a period of 1usec. As the counter is counting >> from 0 to 99, i will take 1 sample at each count and therefore i have >> a total of 100 samples. Now my task requires me to increase my sample >> size to 200. However, i can't increase the counter count to 0 - 200 as >> this will increase the period to 2usec. My task requires me to double >> the sample size while maintaing the period at 1usec. > > Use a PLL to double the clock frequency, if your FPGA has one. > Or a DDR input cell (assuming your FPGA has them), or even two flipflops, one positive-edge triggered and one negative. Of course, this assumes your 100MHz clock is of good enough quality, ie closely symmetric.Article: 125696
> attempt to use ARM9 soft ip in FPGA below 100$ is bad idea, depending > on your yearly volume maybe it could be possible to fit the CPU itself > but not much more, and performance would be very bad anyway. > if you dream adding ARM9 + something else + n>0 video decoders into > sub 100$ FPGA hm you need wait a few years... or some more years for > 35nm FPGA's > so you need really re-thing what parts of the system you want into the > FPGA and what not Thank you for replying! Ok.....what if I change the softcore ARM9 to something else...like MicroBlaze and maybe limit the video decoders to 4 ? -- MMJArticle: 125697
Hi, why don't you have a look at actel's Igloo family? http://www.actel.com/products/IGLOO/ Recently they added support for the ARM cortex core, with plently of other interesting capabilities. csb On 31 oct, 16:03, "MMJ" <S...@aldrig.com> wrote: > Hi, > > For a future project we are considering the use of FPGA technology and IP > cores instead of using an ASSP solution. > As a software guy...only doing some initial invistigations I have absolutely > no specific idea of how much functionality you can expect to implement into > a FPGA device in the pricerange of maximum 100$. > > Some of the basic functionality we need is: > > - Control CPU (e.g. ARM9). > - Memory Interface for control CPU and video decoder. > - x number of I/O interfaces (High speed parrallel). > - n Video decoders (MPEG2, MPEG4, H.264) > - Interal switch matrix of some sort. > > How much of this should we (hypothetical speaking) be able to implement in a > single device in the mentioned pricerange? Offcourse I don't expect an exact > answer to this question since everything depends on how each function is > realized. But a "This might be possible" or "Not in this world" answer with > some pointers would be very nice. Hope this is not to stupid a question. > > Best Regards > > -- > MMJArticle: 125698
"Patrick Dubois" <prdubois@gmail.com> schrieb im Newsbeitrag news:1193673009.082475.114600@k35g2000prh.googlegroups.com... > > The two proms can be considered as one big prom twice as large. No > prom is exclusively dedicated to one FPGA in particular. For example, > the bit file for FPGA #1 might take 2/3 of the first prom and the bit > file for FPGA #2 might be half in prom #1 and half in prom #2. This is > handled for you when you create your mcs files for the proms. > Okay, thank you very much. But one more question: What about the DO pins from the PROMs to the FPGA? In the Platform Flash In-System Programmable Configuration PROMs data sheet ds123.pdf (page 18) it is recommended to tie the DO outputs of both PROMs together and connect the FPGAs in series. I don't see any reason to do it this way. What I would have done normally (without having read the user guide) is having the DO of one PROM connected to one FPGA (DIN) and the other DO of the second PROM to the the other DIN of the remaining FPGA. What is the reason not to do so, i.e. is there any reason? Any help is highly appreciated! Regards ToniArticle: 125699
On Wed, 31 Oct 2007 14:24:38 -0000, llombard@gmail.com wrote: >Indeed, for now it's ok, but I had to cut the formula into pieces with >a counter to be able to meet timing requirement. The price to pay is >that the formula is no more computed into 1 clock cycle but into 2 or >more cycles with an added counter. This sounds like adding pipeline stages. >The reason why I forst wondered about this problem is because at first >the loop worked sometimes and would have weird behaviour when changing >almost insignificant parts of the code. For example, some integer >comparisions were wrong. I then realized that even if the ISE "place >and rout report" said that the 50MHz timing constraint "TS_clk = >PERIOD TIMEGRP "clk" 20 ns HIGH 50%" was always met, the ISE >"Synthesis report" would say "maximum frequecy: 20MHz" but without >issuing any error (do they check different things?). The ISE synthesis report gives an estimate of the maximum frequency, a prediction of what PAR might do, but not an accurate figure. I have often found it 10% or more out. But never as far off as 20MHz instead of 50 MHz... If it's that far off you were correct that you had to fix your code. The PAR report contains the accurate figure, and the .twr trace report contains more detail about which paths were too slow. >> If you want to run it faster, add more pipeline registers around the >> multiplier and re-simulate to verify that your control loop stability is >> satisfactory. (Adding delays around a feedback loop makes me nervous :-) > >What does "add more pipeline registers" mean? does it mean cutting >even more into pieces? Then I still have the "number of cycles price" >to pay? It does increase the number of cycles latency, but you can start a new computation each cycle, so throughput is high. Of course, for a control loop, latency is probably important; that's why you need to simulate to check stability if you add latency. >Do you know another cheap kit with several ADC/DAC with >"parralel access" or do I have to take a standard dev. kit and add a >custom AD/DA daughter card http://www.enterpoint.co.uk/moelbryn/raggedstone1.html and http://www.enterpoint.co.uk/moelbryn/modules/adc_ad9727.html may be of interest - Brian
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