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
So I've implemented a NIOS II board using the SOPC builder. I ran out
of on-chip memory so I went off-chip to the DE2's SRAM. Suddenly my
programs stopped working and the for loops has an unusual behavior.
It'll go outside of the for loop..
for instance:
-----------------
//assume variables defined
For (i = 0; i < 3999999; i++)
{
IOWR_8DIRECT(memory_base, i, 0xff); //Writes all 1's to SDRAM
}
printf("Finished...\n");
... more code...
------------------
What ends up happening is that the loop will run with the
printf("Finished...") statement and repeat for the duration of the
loop.
Output:
Finished...
Finished...
Finished...
.
.
You get the idea... I didn't let it loop 4 million times you see what
happened.
This ONLY happens when I use the SRAM. If I use the SDRAM or the on-
chip memory it works fine.
Any one run into this problem?
Thanks,
el
Article: 125651On 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 AnttiArticle: 125652
Hi, I would like to debug a vhdl design over Jtag. Is it possible?. As XMD for EDK but for vhdl code. My best regards PabloArticle: 125653
On 31 Okt., 12:19, Pablo <pbantu...@gmail.com> wrote: > Hi, > > I would like to debug a vhdl design over Jtag. Is it possible?. As > XMD for EDK but for vhdl code. > > My best regards > Pablo yesArticle: 125654
On 31 Okt., 12:19, Pablo <pbantu...@gmail.com> wrote: > Hi, > > I would like to debug a vhdl design over Jtag. Is it possible?. As > XMD for EDK but for vhdl code. > > My best regards > Pablo check out "ChipScope Pro"Article: 125655
Hi, I want to make a simulation. However, I get an error like below. I dont know how to solve this problem. does anybody have an idea about this problem? THE ERROR: Running Fuse ... Compiling vhdl file "C:/work/prj/main.vhd" in Library work. Entity <main> compiled. Entity <main> (Architecture <behavioral>) compiled. Compiling vhdl file "C:/work/prj/tb1.vhw" in Library work. Entity <tb1> compiled. Entity <tb1> (Architecture <testbench_arch>) compiled. Parsing "tb1_beh.prj": 0.19 Codegen work/main: 0.02 ERROR:Simulator:222 - Generated C++ compilation was unsuccessful Codegen work/main/Behavioral: 0.05 Codegen work/tb1: 0.00 ERROR:Simulator:222 - Generated C++ compilation was unsuccessful Codegen work/tb1/testbench_arch: 0.05Article: 125656
On Oct 31, 7:27 am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote: > On 31 Okt., 12:19, Pablo <pbantu...@gmail.com> wrote: > > > Hi, > > > I would like to debug a vhdl design over Jtag. Is it possible?. As > > XMD for EDK but for vhdl code. > > > My best regards > > Pablo > > check out "ChipScope Pro" ChipScope is an awesome way to get "eyes" into the operation of the internals of your circuitry. It does not provide the capability to "debug" like software where you can tweak registers, memory, PC, etc on the fly. It has been a savior many times when trying to figure out why something that should have happened, but didn't. Tricks of the trade with using CS include: 1) Make sure you have MORE than what you want brought out in the triggers. Rebuilding larger systems can take a long time. 2) Make sure you have MORE than what you initially think you need in the data collection. Same reason as above. 3) Basic w/ Edges is a god-send and should be the default setting for data. 4) There is a hard limit on the amount of data/trigger signal you can have per ILA (256, maybe 512). If you need more, you can more ILA's, but its best to try to limit the signals you need to fit into an ILA. If what you need to see won't fit, then maybe you need to re-think exactly what you need. 5) ChipScope can be used together w/ XMD. This can allow you the ability to inject certain conditions without having to run large software programs to probe hardware.Article: 125657
On Oct 31, 7:29 am, morphiend <morphi...@gmail.com> wrote: > On Oct 31, 7:27 am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote: > > > On 31 Okt., 12:19, Pablo <pbantu...@gmail.com> wrote: > > > > Hi, > > > > I would like to debug a vhdl design over Jtag. Is it possible?. As > > > XMD for EDK but for vhdl code. > > > > My best regards > > > Pablo > > > check out "ChipScope Pro" > > ChipScope is an awesome way to get "eyes" into the operation of the > internals of your circuitry. It does not provide the capability to > "debug" like software where you can tweak registers, memory, PC, etc > on the fly. It has been a savior many times when trying to figure out > why something that should have happened, but didn't. > > Tricks of the trade with using CS include: > 1) Make sure you have MORE than what you want brought out in the > triggers. Rebuilding larger systems can take a long time. > 2) Make sure you have MORE than what you initially think you need in > the data collection. Same reason as above. > 3) Basic w/ Edges is a god-send and should be the default setting for > data. > 4) There is a hard limit on the amount of data/trigger signal you can > have per ILA (256, maybe 512). If you need more, you can more ILA's, > but its best to try to limit the signals you need to fit into an ILA. > If what you need to see won't fit, then maybe you need to re-think > exactly what you need. > 5) ChipScope can be used together w/ XMD. This can allow you the > ability to inject certain conditions without having to run large > software programs to probe hardware. Synplicty's Verify product merges the capabilities of Xilinx chipscope with a "source level debugger" operating with your vhdl/verilog. "source level debugger" is a generous title, but it is the closest to the real thing available. AndyArticle: 125658
Wei, I have worked with an ARM926 soft core. This deliverable provided an implementation guide as well as a simulation environment to verify the RAM integration. I would have thought the ARM11 would have a similar thing. Whether it is FPGA or ASIC the RAM integration follows the same process. The RTL simulation environment will ensure you have correctly connected the memories. MikeArticle: 125659
Thank you Brian for your reply. Unfortunately, I'm far from being a specialist and I'm not sure I quite understood everything > If it's meeting timings (as you say it is) and there is no advantage to > you in running it faster (say, 100MHz) you don't need to do anything. 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. 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?). Then I cut the formula into pieces until I had both report agreeing on the maximum frequency and the problem was solved, with added complexity. > 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? > The multipliers in newer technologies (V4 and V5) seem to have a huge > appetite for pipeline registers, and there are sometimes large delays > between these registers and the CLB fabric, so it is sometimes worth > adding a pipe stage devoted to getting signals from CLB registers into > multiplier registers (and back out) if you need higher performance. > > If you follow the HDL ADVISOR advice, 100MHz (10ns) should be relatively > easy even in Spartan-3e; but if you don't need that speed, what you have > done is fine. I don't for now but might want it to run faster in another setup. By the way, the limit with this setup is linked to the serial interface of the ADC/DAC, preventing me from getting above frequecies around 20kHz. 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 Thanks in advance for your reply! laurentArticle: 125660
Thank you for the last three responses from John, Andrew and Ray (and everyone else who responded). You pretty much convinced me of the need to have different size kernels to be able to handle a larger range of points possibility. Unfortunately that means that I won't be able to use Xilinx Coregen FFT. I guess we'll stick with zero-padding for the time being but at least now I know my options if I really wanna go that route. I'm still intriged by the chirp z-transform (Bluestein's FFT algorithm) however, because it seems to use power of 2 FFTs (at least the Matlab implementation of czt does). I don't quite yet grasp the algorithm though. I see that it is discussed in chapter 9.5 of the book Ray Andraka suggested. I'll try to get a copy. Thanks, PatrickArticle: 125661
On Tue, 30 Oct 2007 23:10:39 -0700, Thomas Stanka <usenet_nospam_valid@stanka-web.de> wrote: >On 31 Okt., 05:15, mk <kal*@dspia.*comdelete> wrote: >> On Tue, 30 Oct 2007 14:50:44 -0700, Thomas Stanka >> >> >> >> <usenet_nospam_va...@stanka-web.de> wrote: >> >On 27 Okt., 17:08, mk <kal*@dspia.*comdelete> wrote: >> >> On Sat, 27 Oct 2007 00:39:05 -0700, Thomas Stanka >> >> >> <usenet_nospam_va...@stanka-web.de> wrote: >> >> >when it comed to adders because nearly every actual fpga provides fast >> >> >carry logic which I haven't seen in ASIC so far. >> >> >> Almost all ASIC libraires I've used has a full adder in it which is >> >> basically what a fast carry logic is in an FPGA where they have >> >> hardwired full adders which don't need to be made from luts and don't >> >> need the programmable interconnect. I'ts very easy to accomplish the >> >> same in an ASIC. >> >> >Is it only a fulladder gate, or a full adder (for given bitsize)? >> >The adders I've seen in ASIC libs provide no fast carry compared to >> >normal cell delay. But that has nothing to say, as I'm not that >> >experienced in comparing ASIC technologies. >> >> Xilinx fast carry logic path for v5 is described in this documenthttp://direct.xilinx.com/bvdocs/userguides/ug190.pdfpage 193. As you >> can see it is not a multi-bit carry lookahead or anything similarly >> complicated. It's a hardwired implementation of a ripple carry logic >> which can be duplicated using standard cell full adders relatively >> easily. > > >Thankyou, I have no need to learn the details of the virtex5 carry >logic at the moment. Then I'm not sure what we're discussing here but I'll try one more time. >The point I'm on is that in the fpga technologies I know the carry >chain path has a much faster gate delay compared to the normal gate >delay. That's because "normal gate delay" is so slow because of the programmable gates and routing. Normally when one is designing custom adders, a carry ripple adder is the slowest and smallest adder against which other more sophisticated carry select, carry skip, carry lookahead etc. are judged. One can buy more speed by paying with area and/or power by using one of these architectures. The fact that in an FPGA a dedicated carry ripple adder is the fastest just shows the inefficiency of the fabric. But one gets programmability with that inefficiency so the compromise usually works out. 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.Article: 125662
hello,
Has anybody experience with xilinx bitfile merging using a bmm file?
I've a small processor core running in a spartan 3A using romcode which I
install into a generated vhdl file.
like
entity ROM is
port(
Clk : in std_logic;
A : in std_logic_vector(12 downto 0);
D : out std_logic_vector(7 downto 0)
);
end ROM;
architecture rtl of ROM is
signal A_r : std_logic_vector(12 downto 0);
type rom_type is array(0 to 1951) of std_logic_vector(7 downto 0);
signal ROM:rom_type := (
X"02",
X"00",
X"08",
etc.
This works fine (programming running), but I would like to replace this with
a generic rom file without any initialization or just zero's and merge the
romhexfile into the bitfile using a bmm. For the situation above the
following bmm file doesn't give any errors:
ADDRESS_MAP TV51MAP PPC405 0
ADDRESS_BLOCK CPU_INST_ROM RAMB16 [0X0000:0X7ff]
BUS_BLOCK
cpu_inst/rom/Mrom_D1 [15:0];
END_BUS_BLOCK;
END_ADDRESS_BLOCK;
END_ADDRESS_MAP;
It's possible to force a location etc. and a _bd.bmm is generated like the
documentation describes.
I call ngdbuild with:
if ngdbuild -bm cpu_rom.bmm -intstyle ise -dd _ngo -uc $(CONSTRAINTFILE) -p
$(DEVICE) $(DESIGN).ngc $(DESIGN).ngd
and bitgen with
bitgen -bd src/test.mem -w -g UnusedPin:PullNone $< $@ $(DESIGN).pcf
(so only the -bm and -bd arguments are added into the Makefile.)
The mem file looks like:
@00 02
@01 00
@02 08
@03 12
@04 00
@05 95
@06 80
The new bitfile is generated, but no luck. Program not running.
Anybody an idea how to tackle this?
Taco walstra
Article: 125663Hi, 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: 125664
On Oct 31, 12:52 am, Mike Treseler <mike_trese...@comcast.net> wrote: > Nicolas Matringe wrote: > > What are the books you wouldn't work without ? > > I could work without books, > but not without a simulator. > > -- Mike Treseler Probably not without the Internet, either. These days most information that has found its way to print is too old to use. However it's still handy to have a few reference books around like the Doulos Golden reference guide to Verilog. Really your bookshelf reflects the type of designs you're most likely to do. My "wouldn't work without" books may be of no value to someone else.Article: 125665
On 31 Okt., 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 > > -- > MMJ 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 AnttiArticle: 125666
On Wed, 31 Oct 2007 04:05:57 -0700, Jim Thompson <To-Email-Use-The-Envelope-Icon@My-Web-Site.com> wrote: >On Tue, 30 Oct 2007 21:12:11 -0700, "Mike" <mike@nospam.com> wrote: > >>Finally, proof positive! The PFD fails to detect phase! I'm sure you will be >>happy to know this important information. >> >>http://rfdesign.com/vlf_to_uhf/time_and_frequency/arrival-time-detection-pll-jitter-0207/index.html >> >>To begin, the author does acknowledge that the PFD detects frequency (at >>least you didn't get everything wrong): >> >>"When the frequency difference is small, one of the currrent sources will be >>turned on more often than the other. Therefore, the PFD does function as a >>frequency detector." >> >>So far, so good. At least you didn't mess everything up. But then, he >>delivers the shocker! The PFD does NOT actually detect phase! It's true! >> >>"To test whether the PFD is a true phase detector, a fixed-frequency signal >>can be supplied simultaneously to Fvco and to a variable-delay circuit whose >>output feeds Fref. This will produce a variable phase delay. With the output >>of the PFD connected to the LPF as before, the measured result shows that >>the PFD is not a true linear phase detector, because the output of the LPF >>can only stay at either the saturated high or low state, depending upon >>which signal has a phase lead over the other." >> >>As if that's not devastating enough, he delivers his final conclusion about >>the PFD: >> >>"The PFD is thus seen to be an arrival-time detector, instead of a >>phase-frequency detector, because it provides a steady-state output that >>provides both polarity and magnitude of the measured time difference." >> >>Wow! Can you believe it? I know I can. >> >>I've been using PFDs for many years, and thought I knew something about >>them, but the author of this article has far more experience than I do, and >>has even started a company to commercialize his discovery. He simply can't >>be argued with! >> >>I'm sorry Jim, but after umpteen years, the jig is up. Forget the design >>wins, and all the successful implementations. It didn't really work after >>all. >> >>Better luck next time. >> >>-- Mike -- >> >Sno-o-o-ort! > >Just goes to show you to what crap the USPTO will award a patent. > >I'll read it carefully upon return from hospital. > > ...Jim Thompson 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. JohnArticle: 125667
>Hello all >I am looking for references of books about digital design (ASIC & >FPGA, high speed, processor, signal processing ... ) >What are the books you wouldn't work without ? >Thanks in advance >Nicolas > > If you are going to write RTL in VHDL, I recommend Peter Ashenden's "The Designer's Guide to VHDL", 2nd editiion, ISBN 1-55860-674-2.Article: 125668
Hello, I 'm trying to use the Spartan-3E display developpement kit. I can program the FPGA with JTAG ( file.bit in direct), and the PROM (XCF 08P) with JTAG (file.mcs). But after an On/OFF, the FPGA is not programmed (no programmation between PROM -> SPARTAN). Could you help me to have the good config switch (M2,M1,M0 etc...) on the board, and the config of IMPACT software (master or slave, internal or external clock, etc...). I 'm using ISE 9.1.03i for IMPACT. Thanks in advance. Regards, Bhb.Article: 125669
eh the bmm approuch works. after some months-years ;) is your memory 8 or 16 bits? if 8 then make the bram block 8 not 16 as in your bmm connect chipscope to the ram add and data and let it run and look Antti On 31 Okt., 15:58, taco <trala...@joepie.nl> wrote: > hello, > Has anybody experience with xilinx bitfile merging using a bmm file? > I've a small processor core running in a spartan 3A using romcode which I > install into a generated vhdl file. > like > entity ROM is > port( > Clk : in std_logic; > A : in std_logic_vector(12 downto 0); > D : out std_logic_vector(7 downto 0) > ); > end ROM; > > architecture rtl of ROM is > signal A_r : std_logic_vector(12 downto 0); > type rom_type is array(0 to 1951) of std_logic_vector(7 downto 0); > signal ROM:rom_type := ( > X"02", > X"00", > X"08", > etc. > This works fine (programming running), but I would like to replace this with > a generic rom file without any initialization or just zero's and merge the > romhexfile into the bitfile using a bmm. For the situation above the > following bmm file doesn't give any errors: > ADDRESS_MAP TV51MAP PPC405 0 > ADDRESS_BLOCK CPU_INST_ROM RAMB16 [0X0000:0X7ff] > BUS_BLOCK > cpu_inst/rom/Mrom_D1 [15:0]; > END_BUS_BLOCK; > END_ADDRESS_BLOCK; > END_ADDRESS_MAP; > It's possible to force a location etc. and a _bd.bmm is generated like the > documentation describes. > I call ngdbuild with: > if ngdbuild -bm cpu_rom.bmm -intstyle ise -dd _ngo -uc $(CONSTRAINTFILE) -p > $(DEVICE) $(DESIGN).ngc $(DESIGN).ngd > and bitgen with > bitgen -bd src/test.mem -w -g UnusedPin:PullNone $< $@ $(DESIGN).pcf > (so only the -bm and -bd arguments are added into the Makefile.) > The mem file looks like: > @00 02 > @01 00 > @02 08 > @03 12 > @04 00 > @05 95 > @06 80 > The new bitfile is generated, but no luck. Program not running. > Anybody an idea how to tackle this? > Taco walstraArticle: 125670
"Pablo" <pbantunez@gmail.com> wrote in message news:1193829589.942040.77610@19g2000hsx.googlegroups.com... > Hi, > > I would like to debug a vhdl design over Jtag. Is it possible?. As > XMD for EDK but for vhdl code. > 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. /MikhailArticle: 125671
> 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.Article: 125672
"MMJ" <Spam@aldrig.com> wrote in message news:472899a3$0$2112$edfadb0f@dtext02.news.tele.dk... > 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 > > -- > MMJ You can go into the families that have the PPC 405 style core embedded as a hard core. I typically work in the lower cost families that don't include the PPC core (designed for cost, not for sheer performance) and I've never dreamed of using something more than $40 in production. Your cost will depend greatly on volume. DDR2 memory interfaces are available and are implemented as separate logic, not built-in, but cores are available. Please check the FPGA vendor website for supported speed. If you want to go the PPC hard core route, look at www.xilinx.com for the memory interfaces they have characterized. If you just need general 32-bit soft cores with good tool support, the mico-32 at www.latticesemi.com can get you into the ECP2M parts with exceedingly good memory to logic ratios or the NIOS-2 from www.altera.com can provide a nice controller as well. Xilinx has the MicroBlaze soft core if you want to stay in the lower-cost Spartan-3/3A/3E/3DSP series of parts. The speeds are around 100 MHz in the soft cores (from what I understand, not from experience) for these lower cost devices. You can get several hundered total I/O in some devices. Video coders are typically a mix of hardware and software depending on your performance needs. If you have to have full-speed H.264 encoding, you'll have much more logic dedicated to acceleration. Again, check the FPGA vendor sites for cores available from 3rd party IP developers that support video decoding for ideas on size and performance offerings already out there. The logic and routing is almost infinitely variable from design to design. If you want to dynamically swich signals, it's a simple matter of using multiplexers that you design in. If you're looking instead for plug&play style designs, FPGAs might not be for you. Check out the FPOA from www.mathstar.com (a device I haven't considered for my own uses) to understand what their ALU/MAC/RegisterFile arrays can do for applications that may be closer to your needs. FPOAs are not necessarily good for general logic, but if your goal is to have massively parallel video decoders, this could far outstrip an FPGA. Feel free to follow up with more specific questions after looking over the sites. - John_HArticle: 125673
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: 125674
On Wed, 31 Oct 2007 09:38:41 -0700, ray@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. John
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