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
Petter Gustad wrote: > Is there an easy way to convert a plain ascii file of hex numbers etc. > into a SOF format or similar in order to program the UFM of the MAX > II? > > Petter > I think plain hex-ascii to MIF format is so obvious that you don't need anything more that a few seconds of your text editor... See this example : ------------------------------- DEPTH = 16; WIDTH = 16; CONTENT BEGIN 0: 3BAA 95AD 3BAA C8AC 6A53 0000 0000 0000 3AC3 9E62 3AC3 CA79 619E 0000 0000 0000 ; END; -------------------------------- Put this in a file (without the dashes), call it "something.mif" and open it with Quartus. Voilà ! Hope this helps, Bet CuzeauArticle: 83251
Just use an "asynchronous" FIFO design which is ideally suited for this application. It uses a dual-ported RAM to separate the two clock domains (write and read). And it can also handle the special cases of EMPTY and FULL. That's where the two clock domains meet and where any FIFO design gets tricky, We tested our Virtex-4 hard FIFO design (in every BlockRAM) at 200 MHz write and ~500 MHz read clocking for many hundred hours without any problems. Peter Alfke, XilinxArticle: 83252
Simon Peacock wrote: > But you mentioned the two magic words ... Good and Compiler. :-) > But I don't know for a fact if its faster or slower.. just initial comments > ... the main difference seems to be clock speed.. and the 32 bit CPU's are > currently faster ... Well, there are already many good compilers for AMD64 compatible architectures like AMDs K8 and Intels Prescott/Nocona: - PGI Compiler Suite - Pathscale EKO Suite - GCC 3.x and 4.x (yes, they are even used for SPEC submissions) - Intel ICC 8.1 - MS VCC and some more or less exotic compilers (but they are not the bright lights performance-wise). Some of them include fortran compilers. Look at the SPEC submissions: http://www.spec.org/cpu2000/results/res2005q1/ In this quarter there are several submitted 64bit results using some of these compilers (look for Opteron SPECint results from HP and Sun or SPECfp from FSC, HP and Sun). Especially the SPECfp results are quite a bit higher than AMDs single submission (using ICC on Windows). The AMD K8 CPUs (Opteron, Athlon 64 etc.) are also 32 bit CPUs, which have a 64 bit mode. That's the difference to other 64 bit CPUs (MIPS, Alpha, HP PA, Itanium), which are designed as 64 bit CPUs from ground up with some backward compatibility (if they had 32 bit predecessors). But why does an Opteron with slow registered RAM and only 2.6 GHz and 1 MB L2 cache achieve higher SPECfp results than the fastest Xeon (3.6 GHz) or Pentium 4 (3.8 GHz) and also higher SPECint results (using the ICC compiler)? Because they are different architectures. The K8 has a shorter pipeline (code with many branches doesn't hurt that much) and higher execution bandwidth per clock and the Prescott/Nocona has a longer pipeline with less execution bandwidth per clock, but higher clockspeeds. So clock speed can't be used to compare them. It's like (since we are in a FPGA group) having 2 FPGAs able to run at 200 MHz but one of them has twice as many gates. I hope, writing all this gave at least a nice and comfortable update about current technology at least on the x86 MPU market :) MatthiasArticle: 83253
just another guy that come from software... "Dan Nilsen" <dan.nilsen@gmail.com> a écrit dans le message de news: 50a67599.0504260257.6c83de8e@posting.google.com... > Hi all! > > I have a problem that someone here might have the answer to. I have a > divider that takes inputs of 13 and 12 bits, and produces an output of > 12 bits. I have a component to strip away the redundant bits from the > divider, if the result of the division is, say an int value of 6, I > don't want to use all 12 bits. This circuit is a part of an MPEG-4 > device, a quantizer, so I want to compress as much as possible. My > question is then, how do I declare the ports on the component that > strips away the bits to output an std_logic_vector that is not fixed > in size, but dynamic? This must be synthesizable. Guess there are many > ways of doing this, and I hope someone has got an answer to me. > > Thanks, > > Dan NilsenArticle: 83254
But the old AMD processors aren't sold anymore. Since 1999 the Athlon had higher FP performance than Pentium III and although the Netburst architecture managed to get the crown back over time in a lot of applications, the situation changed again. Now the Opteron/Athlon 64 achieves higher performance for most scientific calculations, 3D calculations for games and similar stuff. For video encoders, some audio encoders and some renderers the situation is favouring Netburst architectures in case of single core CPUs. Regarding the help of big caches the same holds true, which I wrote to Simon Peacock: But why does an Opteron with slow registered RAM and only 2.6 GHz and 1 MB L2 cache achieve higher SPECfp results than the fastest Xeon (3.6 GHz) or Pentium 4 (3.8 GHz) and also higher SPECint results (using the ICC compiler)? Because they are different architectures. The K8 has a shorter pipeline (code with many branches doesn't hurt that much) and higher execution bandwidth per clock and the Prescott/Nocona has a longer pipeline with less execution bandwidth per clock, but higher clockspeeds. Here is a nice article comparing the Pentium 4 with 1 MB L2 to the new one with 2 MB L2: http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2353&p=2 MatthiasArticle: 83255
Hi Info, difficult is a relativ word (my age in the FPGA world is only 3 weeks). But the code looks nice :) thanks, Benjamin > Tick generation doesn't seem difficult : > > > -- ---------------------------- > -- 1 us, 4us & 10 us Tickers > -- ---------------------------- > > process (Clk, Rst) > begin > if Rst='1' then > Div1 <= 0; > Div4 <= 0; > Div10 <= 0; > Tick1us <= '0'; > Tick4us <= '0'; > Tick10us <= '0'; > Cnt05s <= (others=>'0'); > elsif rising_edge (Clk) then > Tick1us <= '0'; > Tick4us <= '0'; > Tick10us <= '0'; > > if Div1 = Div1us_c-1 then > Div1 <= 0; > Tick1us <= '1'; > else > Div1 <= Div1+1; > end if; > > if Tick1us='1' then > if Div10 = 9 then > Div10 <= 0; > Tick10us <= '1'; > else > Div10 <= Div10+1; > end if; > end if; > > if Tick1us='1' and Div4 = 3 then > Div4 <= 0; > Tick4us <= '1'; > elsif Tick1us='1' then > Div4 <= Div4+1; > end if; > > if Tick10us='1' then > Cnt05s <= Cnt05s + 1; > end if; > > end if; > end process;Article: 83256
mansoor.naseer@gmail.com wrote: > 2. The second question indirectly relates to the PCI, however, before > that, can someone please tell me exactly how plug and play works? When > the computer boots what steps are taken and how the system determine > how many legal devices are connected to the pci. During the configuration phase of the PCI, the kernel probes the PCI bus for any PCI devices using the PCI configuration commands. If a device is found, the following steps are taken: 1. Find out how much address space the device needs for each base address. 2. Allocate the address space within the kernel, usually by updating some address table. 3. Tell the PCI device to use address xxxx for base address y During the configuration phase, obviously you can't address the PCI device with the I/O space or memory space address. You use the device number, bus number, function number, and register number to address. The PCI host chip then asserts corresponding the IDSEL pin of the PCI device to notify that it is being configured. hth, jzArticle: 83257
Thanks a lot Austin.... Still hoping someone has experience with Hitech Global. Regards, Simon Austin Lesea wrote: > Simon, > > The FX12 is shipping. > > The FX60 very soon now...... > > If you need the FX60, contact your FAE for ES material. > > We have either met, or exceeded every date that we agreed to for the > roll out of the Virtex 4 family. > > Austin > > Simon Heinzle wrote: > >> Hi Austin, >> >> what about the FX series? When are FX60 - FX140 going to ship? >> >> Regards, >> Simon >> >> >> Austin Lesea wrote: >> >>> Simon, >>> >>> >>> The Virtex-4 LX25, LX60, LX100, LX200, SX25, SX35, SX55, and FX12 >>> FPGAs are shipping today. Xilinx now has a total of 20 FPGAs shipping >>> at 90nm -- three times as many 90nm FPGAs as its nearest competitor. >>> >>> All there, all ready for you, >>> >>> AustinArticle: 83258
Austin Lesea wrote: > Jason, > > The 'worst case'? For a FPGA the 'worst case' is probably something you > don't even want to consider. > > For example, if you put in all 100% of the CLB FF's toggling at 300 MHz, > you are likely to see that the power required is so large that you can > not heatsink the device (would melt the solder and fall off the pcb). WOW. Now I really want to try doing, and make the FPGA fall off the PCB. That would be really cool. In building my board, I have used 1A voltage regulators to be on the safe side. I have designed my board to be flexible with various designs. I guess a question which Austin or other members could help answer would be, what should be the best closest worst case when a relevant design is implemented on the FPGA. Since right now, I cant think of any design which could require all the CLBs toggling at such a high frequency. So maybe a design with Microblaze and very intensive DSP tasks implemented on the FPGA. What could be the power consumption for that or some other more intensive design on an FPGA The online tool does not really help if you are planning on getting the best perfomance yeild off the FPGA, and need to know the power constraints before hand. -Yaju > The power estimators need your case, not the 'worst case'. > > Austin > > jason.stubbs wrote: > > > Austin, > > > > The online tool also requires details of the design that I dont have. > > Can you guide me in what I have to enter to estimate the worse case? > > > > Thanks > > > > Jason > >Article: 83259
Duane Clark ha scritto: > TheMightyShaman wrote: > >> >> Hi Duane, again me here, I started working on the diff file, but I >> think it lacks of the dimm_controller.vhd implementation (that I think >> it's your revision of the ddr_controller.vhd, right? ). Or I am doing >> something wrong? Anyhow I'm checking if I can modify it myself. >> Can you confirm this? Any chance to check that file to? >> > > Oops, yep missed that one. It is there now. Have fun. Great!!! Thanks, now remains only the test on the board :) Back with the results soon!!!Article: 83260
Hi Petter, I hit the send button a bit too early. Here is the corrected post. The command should be: jtagconfig --add ByteBlaster /dev/parport0 The "ByteBlaster" is case SENSITIVE. If this does not work send me your email and I will have the person who tested this out, help you. Hope this helps, Subroto Datta Altera Corp.Article: 83261
Paolo wrote: > Hi, > This board: > http://www.altera.com/corporate/cust_successes/customer_showcase/csh-seventech_lp.html > has similar characteristics, besides is available a Software Dev Kit to > immediately develop your program in C++. > My company, buy this board to develop gambling machine. Our company doesn't > have an inside structure to develop hardware, but only software. Before we > developed our software on PC platform. But the PC platform it's not good > for an embedded use. Now with this board we succeed in realizing excellent > products. > On the web page of Seventech, you can also see a sample C++ code to realize > a graphic animation with this board. > With this board it is possible to realize graphic animations with very good > performance and the cost, also for the companies, it is <300$, for an only > piece. > > Paolo > > > > That does look interesting, too bad the FPGA doesnt have the dual PowerPC cores included.. What sort of free tools are available for the altera chips and are they any good?Article: 83262
gallen wrote:
> I'm getting an error during the translate portion of the implement
> design section and I have no clue what it is about:
>
> ERROR:NgdBuild:455 - logical net 'blt_blitter_o_memAddr<0>_cyo' has
> multiple
> drivers. The possible drivers causing this are:
> pin G on block XST_GND with type GND,
> pin PAD on block blt_blitter_o_memAddr<0>_cyo with type PAD
> ERROR:NgdBuild:462 - input pad net 'blt_blitter_o_memAddr<0>_cyo'
> drives
> multiple buffers. Possible pins causing this are: :
> pin I on block dll_rstpad with type IBUF,
> pin I on block w_extCe_OBUF with type OBUF,
> pin I on block w_fbce0_OBUF with type OBUF,
> pin I on block w_fbce1_OBUF with type OBUF
> ERROR:NgdBuild:466 - input pad net 'blt_blitter_o_memAddr<0>_cyo' has
> illegal
> connection. Possible pins causing this are:
> pin G on block XST_GND with type GND,
> pin DI on block blt_blitter_o_xAddr<5>cy with type MUXCY,
> pin DI on block blt_blitter_o_xAddr<6>cy with type MUXCY,
> pin DI on block tv_tvs_hcount_LPM_COUNTER_2__n0000<10>cy with
type
> MUXCY,
> pin CI on block blt_blitter_o_memAddr<6>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<9>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<10>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<11>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<12>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<13>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<14>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<15>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<16>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<17>cy with type MUXCY,
> pin CI on block blt_blitter__n0000<0>cy with type MUXCY,
> pin DI on block blt_blitter__n0000<1>cy with type MUXCY,
> pin DI on block blt_blitter__n0000<2>cy with type MUXCY,
> pin DI on block blt_blitter__n0000<3>cy with type MUXCY,
> pin DI on block blt_blitter__n0000<4>cy with type MUXCY,
> pin DI on block blt_blitter__n0000<5>cy with type MUXCY
> ERROR:NgdBuild:466 - input pad net 'blt_blitter_o_memAddr<0>_cyo' has
> illegal
> connection. Possible pins causing this are:
> pin G on block XST_GND with type GND,
> pin DI on block blt_blitter_o_xAddr<5>cy with type MUXCY,
> pin DI on block blt_blitter_o_xAddr<6>cy with type MUXCY,
> pin DI on block tv_tvs_hcount_LPM_COUNTER_2__n0000<10>cy with
type
> MUXCY,
> pin CI on block blt_blitter_o_memAddr<6>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<9>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<10>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<11>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<12>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<13>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<14>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<15>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<16>cy with type MUXCY,
> pin DI on block blt_blitter_o_memAddr<17>cy with type MUXCY,
> pin CI on block blt_blitter__n0000<0>cy with type MUXCY,
> pin DI on block blt_blitter__n0000<1>cy with type MUXCY,
> pin DI on block blt_blitter__n0000<2>cy with type MUXCY,
> pin DI on block blt_blitter__n0000<3>cy with type MUXCY,
> pin DI on block blt_blitter__n0000<4>cy with type MUXCY,
> pin DI on block blt_blitter__n0000<5>cy with type MUXCY
>
> I've looked at the xilinx web reference, but I don't have multiple
> drivers on this signal. The system passes simulation without any
> warnings, so what might cause this?
>
> I was getting this on other signals, but I changed how they were
worded
> at it went away. For example I had something like this
>
> wire [7:0] gfxinput;
> wire [3:0] xout;
> wire [3:0] yout;
>
> gfxmod gfx(
> .input(gfxinput)
> );
>
> gfxgen gfxg(
> .xout(xout),
> .yout(yout)
> );
>
> assign gfxinput = {xout,yout};
>
> and that would fail with gfxinput being the error node (gfxgen was
> driving xout and yout and gfxmod takes them concatenated as input).
>
> I got the error to go away (go to another net anyway) by changing the
> code to this:
> wire [3:0] xout;
> wire [3:0] yout;
>
> gfxmod gfx(
> .input({xout,yout})
> );
>
> gfxgen gfxg(
> .xout(xout),
> .yout(yout)
> );
>
> Does this make sense to anybody? Has this happened to anybody else
> before?
>
> Thanks for the help,
> Arlen
This looks suspiciously like you have a module that was built with
IO pads when it was intended to be internal. If for example you infer
an IFD (D flip-flop with an IBUF at its D input and IOB=TRUE) instead
of an FD (basic CLB D flip-flop), the IBUF forces the place-and-route
to instantiate a pad which will also drive the IBUF input in addition
to the net you attached to the IFD's D.
If you build a module as a black-box and include it in a top-level
design,
you need to synthesize with "Add I/O Buffers" unchecked in the
Synthesis properties.
Article: 83263Alex Gibson wrote: > Has any one tried running 7.1 for linux on OS X or darwin or freebsd ? > > Even just commandline tools ? > > Trying to avoid having yet another computer(or dual boot) > > Alex > > Not sure how it could work if the linux they support is ix86.. OSX is PPC remember...Article: 83264
It's like asking what is the price of a car or a house or a meal or a shirt or a book. There is always a more than 10-to-1 range. I think 1A is very stingy when you want to do fast DSP, where many nodes wiggle very fast. Try it out, and keep your options open. A 1.5 or 1.2-V AA battery is a convenient voltage source for trying it out. They give you >1A for an hour, enough time for some experiments. Peter Alfke, XilinxArticle: 83265
Hi Austin, > Since we power the pass gates from Vccaux through a band gap referenced > supply for the entire interconnect, many simple minded formulas that you > may come up with will not apply. Excuse my simple-mindedness, but I am having trouble understanding. You have no circuitry powered off the actual VccInt rail? Your routing buffers, LUTs, DSPs, RAMs and other hard-IP blocks do not use VccInt but rather run off the regulated VccAux-driven supply? Yes, I will concur that simple rules-of-thumb are never quite true in practice, and depend on exact circuits used. But are you suggesting that your supply current doesn't change with voltage? At all? Paul Leventis Altera Corp.Article: 83266
Antony wrote: > Duane Clark ha scritto: > >>TheMightyShaman wrote: >> >> >>>Hi Duane, again me here, I started working on the diff file, but I >>>think it lacks of the dimm_controller.vhd implementation (that I think >>>it's your revision of the ddr_controller.vhd, right? ). Or I am doing >>>something wrong? Anyhow I'm checking if I can modify it myself. >>>Can you confirm this? Any chance to check that file to? >>> >> >>Oops, yep missed that one. It is there now. Have fun. > > > Great!!! Thanks, now remains only the test on the board :) > > Back with the results soon!!! By the way, I should mention one more subtle gotcha. The addresses to the DIMM need to be reversed, because this determines the DDR/DIMM commands. # These need to be reversed from the schematic labeling, # because Xilinx made all their VHDL models (0 to n) NET "DDR_Addr<12>" LOC = "V25"; NET "DDR_Addr<11>" LOC = "U26"; NET "DDR_Addr<10>" LOC = "T28"; NET "DDR_Addr<9>" LOC = "T25"; NET "DDR_Addr<8>" LOC = "U27"; NET "DDR_Addr<7>" LOC = "T26"; NET "DDR_Addr<6>" LOC = "R27"; NET "DDR_Addr<5>" LOC = "R25"; NET "DDR_Addr<4>" LOC = "R28"; NET "DDR_Addr<3>" LOC = "P26"; NET "DDR_Addr<2>" LOC = "V26"; NET "DDR_Addr<1>" LOC = "M30"; NET "DDR_Addr<0>" LOC = "P27";Article: 83267
While the idea of using core made by the FPGA companies like Xilinx Altera etc and while those core if done properly will give not only good performance but also minimum use of resources I believe in this case it is a fast solution which will work but a bad one. Base on the way the question was put I believe the person want to have asynchronous FIFO however have no knowledge how to do it. In such case, to use something which was done by other, without the understanding as how exactly the implementation is done and as such what the pro and con, mean maybe solving the problem but without getting the knowledge and understanding. This is something like telling a new Math student who need to solve 1+1 or 5x7 not how to solve those equations but rather to buy a calculator ... It might be a better solution if Xilinx have an App note as how to do it and provide it and only after this Eng learn and understand the App note and know how to make Async FIFO by himself, than he should use Xilinx Core or Altera or anyone else for that matter. Have fun.Article: 83268
"Acceed See" <invalicd@hotmail.com> writes:
> I gather some file from this machine, but I was only able to save it in
> binary format. What I need is in plain text so that I can correlate with
> my simulator. Anyone can give a pointer?
Assuming that it supports the same Ethernet capabilities as the
older 16500B w/ 16500H, you can FTP the data out of it in text form,
one file per signal. I do that, then run the files through la2vcd
to get VCD file format which I use with waveform viewers:
http://www.brouhaha.com/~eric/software/la2vcd/
Eric
Article: 83269Andre, You should be able to constraint the Tco for the DQ and DQS in the input_setup/clock_to_output preference window. Check the example at $ispLEVER/ispcpld/examples/latticeEC/preferences_attributes/ddr/vhdl/ddr.syn and let me know. rgds, cristian ALuPin wrote: > "cas7406@yahoo.com" <cas7406@yahoo.com> wrote in message news:<1114271914.892049.115680@z14g2000cwz.googlegroups.com>... > > Andre, > > > > I think what you are missing are the constraints. Have set your Tco, > > fmax, Setup and Pin Assignment constraints? Use either the preference > > file (.prf) or the Pre-Map Preference Editor to set your constraints. > > Also TN1050 can help you out. > > > > rgds, > > > > cristian > > Hi Cristian, > > yes I have set the constraints for all the other signals which do not > come out the DATAPATH template. In the Timing Analysis these signals > (for example the address bus for DDR) do have the same tCO. > > I have constrained DQ and DQS in the PREFERENCE EDITOR under "In/Out Clock" > whereas the other signals are constrained under "Cell Attributes". > But the constraints for DQ and DQS do have no effect on the tCO. >=20 > Rgds > Andr=E9Article: 83270
On Tue, 26 Apr 2005 17:12:18 +0200, Marco wrote: > Ok, I will buy an Athlon 64. > > What model has the best price/performace ratio now? > > Thanks > Marco > > > <Alpharomeo2k@gmx.de> wrote in message > news:1114538838.484589.181300@z14g2000cwz.googlegroups.com... >> But the old AMD processors aren't sold anymore. Since 1999 the Athlon >> had higher FP performance than Pentium III and although the Netburst >> architecture managed to get the crown back over time in a lot of >> applications, the situation changed again. Now the Opteron/Athlon 64 >> achieves higher performance for most scientific calculations, 3D >> calculations for games and similar stuff. For video encoders, some >> audio encoders and some renderers the situation is favouring Netburst >> architectures in case of single core CPUs. >> >> Regarding the help of big caches the same holds true, which I wrote to >> Simon Peacock: >> But why does an Opteron with slow registered RAM and only 2.6 GHz and 1 >> MB L2 cache achieve higher SPECfp results than the fastest Xeon (3.6 >> GHz) or Pentium 4 (3.8 GHz) and also higher SPECint results (using the >> ICC compiler)? Because they are different architectures. The K8 has a >> shorter pipeline (code with many branches doesn't hurt that much) and >> higher execution bandwidth per clock and the Prescott/Nocona has a >> longer pipeline with less execution bandwidth per clock, but higher >> clockspeeds. >> >> Here is a nice article comparing the Pentium 4 with 1 MB L2 to the new >> one with 2 MB L2: >> http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2353&p=2 >> >> >> Matthias >> The best price/performance ratio is the 3400+ or the 3700+ which are 754 pin processors. The downside of those processors is that you can only put 3 DIMMs on them so get 1G DIMMs (you want 2G minimum on a machine for FPGA development). AMD underprices the 754s compared to the 939s because they only have one memory bus. But as you can see from benchmarks the 3400+ runs rings around the 3800+ (939 with 1/2M cache) on NCVerilog. The only places that my 3800+ does better than my 3400+ is where there is a lot of I/O. This is a disk issue not a processor issue. My 3400+ is a laptop and has a slow 4400RPM drive. My 3800+ is a desktop that has a fast 7200RPM SATA drive. A 3400+ with a 7200RPM drive will scream. The 939s are available with a 1M cache also but they are very expensive. However come June there will be dual core 939s available. Dual cores are very useful for a workstation. The Xilinx tools can run multithreaded on Linux machines and even if you aren't running them that way you will likely want to be able to simulate and place and route at the same time.Article: 83271
Hi Subroto, Petter, > jtagconfig --add ByteBlaster /dev/parport0 > > The "ByteBlaster" is case SENSITIVE. If this does not work send me > your email and I will have the person who tested this out, help you. As a little addendum, if you happen not to have a /dev/parportX entry, do the following: somehow go root type: modprobe ppdev chmod 666 /dev/parport? and your parport devices should be there with the proper permissions. It may be a good idea to have your admin add these lines to your /etc/init.d/rc.local file. Best regards, BenArticle: 83272
If the biggest answer available is 12-bits that's the resource you need to reserve in the FPGA. I don't think you can dynamically change the output port size without reconfiguring the FPGA. It wouldn't make sense if you could, you need to hardwire the max ouptut size. You could make the output port variable by using a reconfigurable computing algorithm and an external processor, but your process time is going to increase considerably. Are you size constrained? Is that why you are trying to optimize the VHDL code? EricArticle: 83273
Paul, It does change (with V), as is shown by the predictor. And yes, we do use Vccint. We also use Vccaux. Nothing is ever as simple as it first seems. The devil is in the details, and telling you how it works would just allow you to copy it, and improve your own estimator. Austin Paul Leventis wrote: > Hi Austin, > > >>Since we power the pass gates from Vccaux through a band gap > > referenced > >>supply for the entire interconnect, many simple minded formulas that > > you > >>may come up with will not apply. > > > Excuse my simple-mindedness, but I am having trouble understanding. > You have no circuitry powered off the actual VccInt rail? Your routing > buffers, LUTs, DSPs, RAMs and other hard-IP blocks do not use VccInt > but rather run off the regulated VccAux-driven supply? > > Yes, I will concur that simple rules-of-thumb are never quite true in > practice, and depend on exact circuits used. But are you suggesting > that your supply current doesn't change with voltage? At all? > > Paul Leventis > Altera Corp. >Article: 83274
Berty, I disagree. While it is good for every young engineer to learn the basic skills, designing an asynchronous FIFO is far from "basic". Using a dual-ported RAM makes most of the design trivial, but the EMPTY and FULL detection and arbitration at high asynchronous clock rates is far from simple. I have a few patents and several magazine articles, and Clifford Cummings has published extensively. It is still considered wizardry, and grown men can get into deep arguments, since this involves Gray counter decoding and metastability. It is much safer to use a proven circuit designed by experts. It may sometimes be overkill, but it works, and lets you spend your energy on the really important and unique parts of your design. Peter Alfke, Xilinx Applications
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