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
abgoyal@gmail.com wrote: > Thanks, Marc and Mike, for your responses. > > Marc, practially all of those links you listed (some i had not found on > my own, thanks again), talk about RAM, and write coherency etc. As i > only need a ROM, these are non-issues for me. Howdy Abhishek, I was only attempting to find examples of inferred memories with two read ports. Just drop the write portion of the code, find a way to INIT_ the BRAM, and you *might* have an inferred dual-port ROM. Unless your syn tools decides you really wanted two single port ROM's ;-). > Mike, your option "2" is what I am doing right now, and I do have BRAMs > to spare so this is sufficient for now, as i am using the larger FPGA > for prototyping, but the rest of my design is so small that just cause > of the BRAM problem I will have to keep using this much more expensive > FPGA. If i can use a dual proted BRAM, then i can use the smaller > cheaper one. > > I guess I can just go ahead and instantiate the BRAM blocks manually to > solve that problem. > > From both of your responses, I guess the consensus that can be derived > is there is no portable way to infer a dual ported ROM. Is this true > for VHDL as well? Depends on how you define portable, but in most senses of the word, probably not. > I was hoping that some newsgroup members who work at one of the > synthesis tool-vendors would have some suggestions? Indeed. Hopefully Ken McElvain will see this and add his Synplify take on it. MarcArticle: 88851
Hello everybody,
What are the main advantages of Fine Grain versus Coarse Grain
Architecures and vice-versa.
Thanks.
Article: 88852If you are using new debug interface you must use jp2 instead of jp1 Javier Castillo www.opensocdesign.com On 29 Aug 2005 20:22:22 -0700, "jeff murphy" <jeff.murphy@gmail.com> wrote: >i've worked thru all of the openrisc HW and SW steps. everything went >well, or at leas seemed to. however, when i >startup the jp1 utility, it connects to my board (xupv2) but >the "Read" and "Expected" numbers to do match at all. the HW doc says >if this happens to "check the onchip-ram module", but doesnt give any >more details. i'm looking for some hints... > >thanks > >jeff > ># ./jp1 xpc3 9999 >Connected to parallel port at 378 >Dropping root privileges. >Read npc = 00000100 ppc = 00000104 r1 = 00000000 >Expected npc = 4000000c ppc = 40000024 r1 = 00000005 >Read npc = 00000100 ppc = 00000104 r1 = 00000000 >Expected npc = 4000000c ppc = 40000024 r1 = 00000008 >Read npc = 00000100 ppc = 00000104 r1 = 00000000 >Expected npc = 40000024 ppc = 40000020 r1 = 0000000b >Read npc = 00000100 ppc = 00000104 r1 = 00000000 >Expected npc = 40000020 ppc = 4000001c r1 = 00000018 >Read npc = 00000100 ppc = 00000104 r1 = 00000000 >Expected npc = 4000001c ppc = 40000018 r1 = 00000031 >Read npc = 00000100 ppc = 00000104 r1 = 00000000 >Expected npc = 40000020 ppc = 4000001c r1 = 00000032 >Read npc = 00000100 ppc = 00000104 r1 = 00000000 >Expected npc = 40000010 ppc = 4000000c r1 = 00000063 >Read npc = 00000100 ppc = 00000104 r1 = 00000000 >Expected npc = 40000024 ppc = 40000020 r1 = 00000065 >Read npc = 00000100 ppc = 00000104 r1 = 00000000 >Expected npc = 4000000c ppc = 40000024 r1 = 000000c9 >result = 5eadeccd >Dropping root privileges. >JTAG Proxy server started on port 9999 >Press CTRL+c to exit.Article: 88853
See Figure 10 of Patent US000006246258B1. Check with Austin for a license. Kolja Sulimma Hw schrieb: > Hi. > > I need to digitize an array of signals (24) with minimum 8-bit > resolution, with < 2ms conversion time. Signals are single-ended 0 to > 5V. I am trying to keep costs low, therefore I am trying to avoid > multiple A/Ds and/or complex multiplexing situations. > > I know of the "slope" A/D technique of charging a capacitor or the > sigma-delta technique of using a PWM DAC and a comparator to form an > A/D. > > Would it be possible to get the speed I want using either of those > techniques with an FPGA? > > Thank you. > H. > > > >Article: 88854
Kolja, When Xilinx patents an application on our FPGAs (ie a use patent), one can use it with OUR FPGAs, without restriction. However, we are not likely to license it for free for use with a competitor's product. If you need a letter to that effect, please contact our legal dept. Austin Kolja Sulimma wrote: > See Figure 10 of Patent US000006246258B1. > Check with Austin for a license. > > Kolja Sulimma > > Hw schrieb: > >>Hi. >> >>I need to digitize an array of signals (24) with minimum 8-bit >>resolution, with < 2ms conversion time. Signals are single-ended 0 to >>5V. I am trying to keep costs low, therefore I am trying to avoid >>multiple A/Ds and/or complex multiplexing situations. >> >>I know of the "slope" A/D technique of charging a capacitor or the >>sigma-delta technique of using a PWM DAC and a comparator to form an >>A/D. >> >>Would it be possible to get the speed I want using either of those >>techniques with an FPGA? >> >>Thank you. >>H. >> >> >> >>Article: 88855
"Mike" <mike@nospam.com> wrote in message news:MlQQe.1853$mH.1380@fed1read07... > "Andrew Holme" <andrew@nospam.com> wrote in message > news:desmbt$i07$1$8302bc10@news.demon.co.uk... >> The dividers and the phase detector of my experimental frequency >> synthesizer >> are implemented in a 15ns Altera MAX7000S CPLD. I've tried different >> multiplication factors (kN) to see how the close-in phase noise varies. >> At >> a 1 KHz offset, I get: >> >> -82 dBc/Hz for N=198 (VCO=19.8 MHz, comparison freq = 100 KHz) >> -95 dBc/Hz for N=39 (VCO=19.5 MHz, comparison freq = 500 KHz) >> >> Calculating the equivalent phase noise at the PFD: >> >> -82-20*log10(198) = -128 dBc/Hz >> -95-20*log10(39) = -127 dBc/Hz >> >> Given the 5:1 ratio of comparison frequencies, at a guess, I'd expect >> these >> to differ by 13 dB if the noise was mainly due to a fixed amount of time >> jitter at the PFD. >> >> I'm using a 10 MHz canned crystal oscillator, which I'm dividing down >> (inside the CPLD) to obtain the reference frequencies. I've read these >> are >> good for at least -130 dBc/Hz (before dividing down) so I'm a bit >> dissappointed with my noise levels. Maybe it got a bit too hot when I >> soldered it to the ground plane! I must try another.... >> >> Googling for "altera cpld jitter" doesn't turn-up much, and they don't >> mention jitter in the datasheet. Does anyone know what sort of >> performance >> can be expected from a CPLD in this regard? I don't know if the CPLD, or >> my >> circuit lash-up is the root cause. >> >> A full write-up of the project can be found at >> http://www.holmea.demon.co.uk/Frac2/Main.htm It has a fractional-N >> capability, but noise-levels are the same in integer-N mode with the >> external RAM disabled. > > I'm not sure why you think you should be seeing a 13dB difference at the > input. If I can make some gross assumptions here, I'm going to assume that > your system is second order, highly overdamped (the poles are widely > separated), and that the bandwidth, even at the 100kHz update rate, is > much greater than 1kHz. Then, if your dominant noise source is at the > reference input, the gain from input to output close to the carrier is N. > If your dominant noise source is at the VCO input, the gain close to the > carrier is N/(Kd*R). In both cases, you have a gain of N. Looking at your > data, I see that if the noise at 1KHz offset is constant, whether it's at > the reference input or the VCO input, the noise should change by about > 14dB. > > You're measuring 13dB instead of 14dB... so, what's the problem? I think we can take things one step further. Mini Circuits thoughtfully provides us with the typical phase noise of their VCO (-86dBc @1kHz offset), and the VCO gain (1-4MHz/V, which we will take to be 2.5MHz/V). If we insert this noise at the VCO output in a simple PLL, and again assuming that you're overdamped with a loop bandwidth wider than 1kHz, the loop gain at 1kHz offset is approximately wN/(KoKdR). So, based on your measured values, -95 = -86 + 20log(wM/(KoKdR)) where w = 2pi*1kHz Ko = 2pi*2.5MHz M = 39 Solving for KdR, KdR = wM/(Ko*10^(-9/20)) = 0.044 You haven't published your loop filter design, but most of the PLLs I've designed in the past few years have had Kd*R somewhere in the range of 0.01 to 0.05, so the value I've obtained above looks like it might be about right. The point of all this is that your noise is probably not coming from your crystal reference oscillator. I think it's more likely that it's coming from your VCO, and (if my assumptions about Kd*R are roughly correct) is approximately what you'd expect to see. -- Mike --Article: 88856
"=2E..Altera continues to sell Excalibur devices, this product family is not recommended for new designs. Designs requiring embedded processors should consider Altera's Nios=AE II processor. Excalibur devices integrate a 200-MHz processor with the APEX=99 20KE FPGA architecture, balancing the price, performance, and system integration requirements of system-on-a-programmable-chip (SOPC) designs." Not sure if this is just research or product development, but you could still get Excalibur devices. EricArticle: 88857
Simon Peacock wrote: > More likely the programmers have to learn how to think parallel.. then write > a compiler that thinks parallel.. then learn to write games parallel.... > stuff hardware guys have done for years.. but not your normal programmers > vision > > But the possibilities are good.. and the processor is cheap... :-) I think > it will catch on.. to a point where PC games will suffer... but it will > start to infect PC's soon enough > > Simon > snipping Its is very funny that HW guys are so parallel with out even thinking about it but not in the same way that software guys try it. Now go into a NG such as comp.arch or any proper SW or par group and say that and get the cold shoulder, complete waste of time. The general discussion about parallel in the software world is stuck in the 1960s model of locks, and semaphores. Message passing is considered odd in some way, most talk of parallel steers away from it. Message passing is the natural way to distribute computing even if it means copying data between processes. In hardware we do this all the time with wires. Every seasoned ASIC and FPGA EE knows that wires and communications are half the problem and solution, without them the modules can't communicate. Somehow the SW folks are trying to avoid what is percieved to be a redundant copy operation by having processes share memory directly which is in the end a horrible scheme to implement after only a few processors. Only small amounts of visiblity is needed between processes but still they ask for complete memory sharing across the entire compute space. They often don't understand that memory operations are hugely expensive and are comparable anyway with using direct message passing. Now in the Transputer and occam, we have message passing only, no shared memory, messages pass through channels or software wires or even real links and real wires. Processes model hardware. A collection or hierarchy of occam processes looks exactly like a hardware hierarchy. This is the only natural model of concurrency that works and is scaleable across a vast sea of processors. Even the brain appears to work a bit like this (no shared memory, cache coherence etc). When you have 100s or more processors running 1000s of persistant processes, you get a new problem for software types, we call it floor planning place & route, they call it process mapping and don't know anything about hardware "process" mapping. Now almost all the best Transputer programming was done by hardware types who saw the pattern, and grokked it with no trouble (except for the horrible syntax). Most Transputer apps became DSP and FPGA apps. I like to say that FPGAs and Transputers are 2 sides of the same coin, 1 runs processes as hardware and the other as software, put 1 in the other (or vice versa) and processes can be run as either as the designer sees fit. johnjakson at usa .. transputer2 at yahoo ...Article: 88858
blah wrote: > Does anyone know of another FPGA (other than Virtex series from Xilinx) that > has an embedded processor comparable to the PowerPC 405 as well as 3Gbps > Serdes? > > No there isn't anything else on the market or announced. The only FPGAs with hard embedded processors and high speed serial transceivers are from Xilinx. Virtex-II Pro - PowerPC405 (up to 400 MHz) & Transceivers (up to 3.125 Gbps) Virtex-II ProX - PowerPC405 (up to 400 MHz) & Transceivers (up to 6.250 Gbps) Virtex-4 FX - PowerPC405 (up to 450 MHz) & Transceivers (up to 10.3125 Gbps) EdArticle: 88859
Brian C. Van Essen wrote: > I am attempting to simulate a very basic system built with Xilinx EDK > 7.1.02i, using VHDL. After generating the ModelSim specific compiler > scripts, I can execute a do system.do, which works okay, but when I > execute the vsim system command I get the following results. I have > had similar problems when trying to do a Verilog/VHDL mixed simulation > system. Looking around on the Xilinx web site, I see that someone else > has had a similar problem > (http://toolbox.xilinx.com/cgi-bin/forum?50@233.ec6BaE6ihO8.4@.ee8f9bc), > but I did not see any responses or suggestions. > > Any help would be appreciated. > > Thanks, > Brian > > ------------- > > ModelSim> vsim system_conf system > # vsim system_conf system > ... > Loading c:\Modeltech_6.1a\win32/../ieee.vital_primitives(body) > # Loading Z:/simlib/EDK7.1.2_mti_se_nt/ISE_Lib/unisim/.vpkg(body) > # ** Warning: (vsim-3479) Time unit 'ps' is less than the simulator > resolution (1ns). > # Time: 0 ns Iteration: 0 Region: > /system/microblaze_0/microblaze_0/decode_i/prefetch_buffer_i/using_fpga/prefetch_buffers__0/srl16e_i > # Have you tried running with the simulation resolution set to 'ps'? That would normally be done in the modelsim.ini file or the project.mpf file, by changing the "Resolution" line. > > > ** Fatal: INTERNAL ERROR in reset_trigger_process(). > # Time: 0 ns Iteration: 0 Process: > /system/mb_opb/mb_opb/opb_arbiter_i/opb_arbiter_core_i/multi_master_gen/park_lock_i/grant_gen__1/reggrnt_gen/reggrnt_process > File: > C:/EDK/hw/XilinxProcessorIPLib/pcores/opb_arbiter_v1_02_e/hdl/vhdl/park_lock_logic.vhd > # > > FATAL ERROR while loading design > # Error loading design These kinds of problems can be difficult to debug in Modelsim. I try to narrow down the problem by trying to load individual pieces of the project. That is, when you get the "Load Design" dialog, pick an entity for just a portion of the design. You are not going to simulate the pieces of the design, because all you care about for this testing is whether they will simply load. For example, pick the entity that is in park_lock_logic.vhd. If that loads, then the problem is elsewhere. If not, the problem is either that entity or one of the entities contained within it. It is a bit of a trial and error method, but I have always been able to find the problem file with this method.Article: 88860
CMOS wrote: > hi, > im wondering whether there is a point in using 8087 Math Co-Processor > in this FPGA Age? > CMOS Thats sounds so funny, but it might not be such a bad idea, only look for a much faster unit that is comparable in functionality. One might suggest a Pentium4 or Athlon but that would be tooo fast to interface to. I don't know what the equiv of a ready made 8087 would be today at comparable FPGA interface speeds. Perhaps one of the FP DSPs, or just do it in FPGA with a cpu + FP core and some hardwork. It really depends on exactly what you want to do in FP. johnjakson at usa ..Article: 88861
Bubba wrote:
>Multiplier
>
>
>
>Is there a good algorithm (small) to multiply two 36 bit “signed” numbers to
>get a 72 bit result.
>
>
>
>
The mult18x18s are signed multipliers, there is no option to make them
unsigned. You can use them as unsigned 17x17 by forcing the MSB to '0'.
In order to build a larger multiplier out of smaller ones, you must
treat only the most significant 'digit' (where the input to each smaller
multiplier represents a digit) as signed, all the lower order digits
must be unsigned. Hence, with the Xilinx multipliers, splitting your
input into two words will get you up to a 35x35 multiplier. If you
attempt 36x36, you will need a third multiplier in each dimension, which
means 9 multipliers. You can create 1x35, 35x1 and 1x1 unsigned
multipliers in the fabric to complete your multiplication to avoid using
up multiplier blocks.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 88862There is also Tensilica, Stretch and a raft of other mixed hardware-software computing companies (startups) out there that try to combine some FPGA fabric with a processor, but they don't make as much noise as the 2 bigger players. They probably don't have Serdes either. I don't get the impression the Excalibur/Arm is being further developed, a 1 shot offering for Arm users. johnjakson at usa ...Article: 88863
Alissobn Brito wrote: > Hello everybody, > What are the main advantages of Fine Grain versus Coarse Grain > Architecures and vice-versa. > Thanks. Now that sounds like homework assignment right?Article: 88864
Hi All, I am having some problems using UDP LwIP calls in EDK7.1. Let me give some details. I am trying to create an Ethernet bridge using the Memec V4LX60MB board. The board has a 10/100 Ethernet PHY connected to a Virtex-4 LX60 FPGA. I have the EDK project from Xilinx appnote XAPP663 as a starting point. After changing the pinouts and SRAM to match the Memec board, I can get this project to work (a simple Telnet echo server). Now, I want to change out the TCP calls with (simpler) UDP calls so that I can unicast streaming video to the board and have it in turn stream this out to a different IP address. I am using the RawAPI LwIP calls (no OS running on the Microblaze). When I attempt to compile the appication in the EDK I the following errors: mb-gcc -O2 code/udp_echo_main.c -o udp_echo/executable.elf \ -Wl,-defsym -Wl,_TEXT_START_ADDR=0x86000000 -mno-xl-soft-mul -mxl-barrel-shift -mno-xl-soft-div -Wl,-T -Wl,udp_echo_linker_script -I./microblaze_0/include/ -L./microblaze_0/lib/ \ -xl-mode-executable \ -llwip4 /cygdrive/c/DOCUME~1/westra/LOCALS~1/Temp/1/ccsNdu71.o: In function `main_main': /cygdrive/c/DOCUME~1/westra/LOCALS~1/Temp/1/ccsNdu71.o(.text+0x880): undefined reference to `udp_new' /cygdrive/c/DOCUME~1/westra/LOCALS~1/Temp/1/ccsNdu71.o(.text+0x89c): undefined reference to `udp_recv' /cygdrive/c/DOCUME~1/westra/LOCALS~1/Temp/1/ccsNdu71.o(.text+0x8b4): undefined reference to `udp_bind' ./microblaze_0/lib//libxil.a( microblaze_interrupts_g.o)(.data+0x0):/cygdrive/d/OSD27/Firmware/JW_EMAC/microblaze_0/libsrc/standalone_v1_00_a/src/microblaze_interrupts_g.c: undefined reference to `mytimer_int_handler' collect2: ld returned 1 exit status make: *** [udp_echo/executable.elf] Error 1 Upon inspection of the library file (liblwip4.a), there seems to be no sign of the rawapi UDP functions (though the TCP functions seem to be there). Is anyone familiar with using LwIP with Microblaze? Are the RawAPI UDP calls not supported? Is there a work-around to this problem? Any help would be appreciated. Thanks. JeffArticle: 88865
Hello Robert, > Yes Joerg, or a cheap ADC (or a small microcontroller with ADC) and an > external 32 channels mux (available from Analog Device, ADG731, for $4,5 / > 1k, probably far less than an FPGA... That would be an option. However, I was thinking about a mux that is around 10dB lower in cost. Three CD4051 should do which run about $0.15 to $0.18 a pop in >1k quantities. The HC versions must somehow have fallen from grace because they are sometimes unavailable and when you find them they are expensive. Guess the market didn't accept them much. Regards, Joerg http://www.analogconsultants.comArticle: 88866
the clock tree in FPGA is already there, but the tool automatically places and routes the resources while taking into account the clock tree skew. Vladislav <yijun_lily@yahoo.com> wrote in message news:1125182762.242631.203300@z14g2000cwz.googlegroups.com... > Dear all, > > In ASIC design, clock skew can be solved by using Clock tree > generation. How does FPGA solve it?Use the clock tree too?How? > > Thanks, > > Ethan >Article: 88867
Hello, Could you paste your code? This would help us to determine the problem (which, according to your description is the code) Vladislav <yijun_lily@yahoo.com> wrote in message news:1125177858.566707.241190@g47g2000cwa.googlegroups.com... > Dear All, > > After I take a look at the schematic view of post-map RTL code, it > seems "reset" signal is connected to the "clk" of FF and "clk" signal > is connected to the "reset" of FF. What is wrong there?How can I fix > this problem?Thanks, >Article: 88868
On Tue, 30 Aug 2005 01:00:51 GMT, Joerg <notthisjoergsch@removethispacbell.net> wrote: >> I need to digitize an array of signals (24) with minimum 8-bit >> resolution, with < 2ms conversion time. Signals are single-ended 0 to >> 5V. I am trying to keep costs low, therefore I am trying to avoid >> multiple A/Ds and/or complex multiplexing situations. >> >> I know of the "slope" A/D technique of charging a capacitor or the >> sigma-delta technique of using a PWM DAC and a comparator to form an >> A/D. >> >> Would it be possible to get the speed I want using either of those >> techniques with an FPGA? > >FPGA usually do not contain comparator inputs which you need for a slope >conversion. How about using a cheap ADC plus a few low cost 8:1 muxes >(74HC or CD series)? > The Xilinx lvds differential inputs are actually pretty good comparators but I doubt you could get a solid 8 bits from them. Besides, single-slope adc's are tacky. I bet you could do a good delta-sigma adc in an fpga, with a few external parts. But the op needs a cheap 8-bit adc and a mux. There's nothing very complex about multiplexing. JohnArticle: 88869
Does anyone actually believe that KCPSM stands for Constant(k) Coded Programmable State Machine, as opposed to Ken Chapman's Programmable State Machine? I find the whole thing rather fishy. The real question: When using verilog, is it "better" to use the kcpsm3.ngc file in the package, or the .v source files? This is with ISE7. Specifically, are the source files as up to date as the .ngc file and will the synthesis result in as compact a result as the provided .ngc file? Thanks. Paul.Article: 88870
Brian C. Van Essen wrote:
> I am attempting to simulate a very basic system built with Xilinx EDK
> ModelSim> vsim system_conf system
> ** Fatal: INTERNAL ERROR in reset_trigger_process().
> # Time: 0 ns Iteration: 0 Process:
> /system/mb_opb/mb_opb/opb_arbiter_i/opb_arbiter_core_i/multi_master_gen/park_lock_i/grant_gen__1/reggrnt_gen/reggrnt_process
> File:
> C:/EDK/hw/XilinxProcessorIPLib/pcores/opb_arbiter_v1_02_e/hdl/vhdl/park_lock_logic.vhd
> #
> FATAL ERROR while loading design
> # Error loading design
Bring up park_lock_logic.vhd
and find reset_trigger_process
Check the declarations of all
array indexes used there.
I fixed a similar problem by changing
an array index type from integer to natural.
-- Mike Treseler
Article: 88871
CMOS wrote:
> im wondering whether there is a point in using 8087 Math Co-Processor
> in this FPGA Age?
No. Throw it away.
You would need an 8086 style interface just to talk to it.
-- Mike Treseler
Article: 88872Alissobn Brito wrote: > Hello everybody, > What are the main advantages of Fine Grain versus Coarse Grain > Architecures and vice-versa. > Thanks. Depends on whether you work for a company that provides devices with a coarse- or fine-grain architecture. -aArticle: 88873
I changed the version of LwIP that I was using from 1.00 to 2.00 and that seems to have fixed the problem.Article: 88874
Hello, I want to implemented a gated clock signal that is active for only a certain period. What is the best way? I did it like this (I know that is bad) wire clock_coding; assign clock_coding = (counter > 5 && counter < 120)?clock:1'b0; Thanks,
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