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
> onehot_to_binary: process (onehot) is
> variable OH: std_logic_vector (one_hot'length-1 downto 0);
> variable result: unsigned(address'range);
> begin
> -- Paranoia: Normalize the onehot vector
> -- so that you don't care how the original
> -- was defined. Leftmost bit is number N-1,
> -- rightmost bit is number 0.
> OH := onehot;
> -- start the OR-tree
> result := (others => '0');
> -- build the OR-tree
> for i in OH'range loop
> if OH(i) = '1' then
> result := result OR to_unsigned(i, result'length);
> end if;
> end loop;
> -- copy result to your output signal
> address <= result;
> end process;
>
> Tada! optimally small hardware.
I'd like to dispute that point.
(** convert one hot vector to binary. "Or" based
implementation. Two versions are possible,
with the or's composed linearly, or as a tree. *)
let one_hot_to_binary_a arity onehot =
let owidth = width onehot in
let bwidth = clog2 (owidth-1) in
if arity <= 1 then
fst (fold_left
(fun (r, i) x -> r ||| onehot.[i].mux2(consti bwidth i, 0), i
+1)
(zero bwidth, 1) [ 1 .. owidth-1 ])
else
tree arity
(fun x -> reduce_1 (|||) x)
[ for i in 0 .. owidth-1 -> onehot.[i].mux2(consti bwidth i,
0) ]
(* The or-tree version with an arity of 4 produces the smallest
circuit,
so that's the default. Just or'ing everything together without a
tree
structure (arity <= 1), however, produces the fastest circuit. *)
let one_hot_to_binary = one_hot_to_binary_a 4
Using XST 9.1 (similar results with Synplify) for a 128 bit one hot to
binary encoder targetted to V4;
vhdl for loop - luts(103) slices(54) Fmax(354.7 Mhz)
hdfs (arity=1) - luts(112) slices(56) Fmax(450.8 Mhz)
hdfs (arity=4) - luts(89) slices(49) Fmax(431.4 Mhz)
> No, I don't like it either. I like it better than
> obscure code-generator scripts, though :-)
Obscure, maybe, but not necessarily without value ;-)
Cheers,
Andy.
Article: 125301On Fri, 19 Oct 2007, Philip Herzog wrote: |-----------------------------------------------------------------------| |"Jonathan Bromley wrote: | |> 1) Break the bad habit of using nasty obsolete flaky | |> arithmetic packages, and switch to NUMERIC_STD. | | | |Jonathan, thanks for tips like that - I'm still looking for a good | |_current_ reference guide on VHDL (I own the "Designers guide to VHDL | |2nd edition", but although it's often recommended, I'm not quite | |satisfied with it) where you would find stuff like that. | | | |[..]" | |-----------------------------------------------------------------------| The standard packages are documented in recent versions of P1076 (the VHDL Language Reference Manual). Read it, really. Many people who specialize in VHDL but do not care about VHDL seem to have not bothered to read the standard.Article: 125302
On Oct 19, 4:46 am, scouselad <allanlewi...@googlemail.com> wrote: > Hi, > > I'm a student using Altera Quartus II v6.1 to program a Cyclone II on > a DE2 development board. I'm starting to build a library of Verilog > modules to re-use in future projects (mostly simple things like > adders, flip-flops, etc. - I don't want to use MegaFunctions too much > to avoid getting locked into Altera products) and I was wondering the > best way to do this. I notice that, when I compile a project with a > library folder (containing another project for, say, an adder), I get > a warning that the compiler is using abc.v (or whatever the verilog > file is called) as a design file although it is not included in the > current project - which is what I want it to do. However, this implies > that it is "compiling in" abc.v into the current project, which seems > a waste. > > So... is there an equivalent of "object code" in C++ that I can > include in my projects? So, for example, I could compile my full adder > module, copy some file (not the verilog code, but a compiled/partially > compiled binary file) into my library folder, and then use it in > future projects without making Quartus recompile it. > > Based on file size, I'd say the *.sof file is the best bet, but I > haven't found any information as to what this file is for. In any > case, I'd like to know what all the other files are for (apart from > the *.rpt files, which I know are the reports from the compiler, > simulator, etc.). Can someone point me in the right direction? > > Thanks in advance, > Allan Lewis. In addition to Mike's comments: The reason you get that warning is that some module instantiates (calls, for you 'C' people) a component you didn't specify in the project (link list ...). Specifically, some module instantiated abc, but i was not in you project files list. Quartus found a file 'abc.v' (in your project's search path) with a module 'abc' in it, and guessed that this is what you wanted. There is an equivalent of 'object code', that would be the netlist. But it's not useable as seamlessly as a collection of .o files, and it certainly does not behave like a .a file. The only other parallel I can think of is a 'synthesizeable VHDL package' but that isn't much use for the Verilog crowd. The good news is that you don't have to worry about the 'unreachable code' equivalent. All (modern) synthesizers have the ability to rip up unused logic. And I wouldn't worry too much about the amount of time it takes to compile your code. 90% of the tool-time is (probably) place & route, and pre-compilation doesn't change this. (It might make it worse, as it does take time to trim out unused logic.) And as Mike so accurately pointed out, most of your time will be spent testing & debugging. (Personally, I use the place&route time for a well deserved coffee break.) Gary. PS: If you haven't found out what the .sof file is for, you have quite a bit of the basics left to cover before leaping to advanced topics. "Patience, grasshopper :)"Article: 125303
Bryan <bryan.fletcher@avnet.com> writes: > A MAC+PHY costs more then a PHY, Although one would logically expect that to be the case, in my experience it isn't always true. I suspect it has to do with the high volume in which PCI Ethernet MAC/PHY chips are used in PCs. For instance, at one time a Realtek 10/100 MAC/PHY was quoted at a lower price than the Realtek 10/100 standalone PHY, in the same quantity. I don't know if that's still the case.Article: 125304
On Oct 18, 12:39 pm, sendt...@gmail.com wrote: > I'm trying to make a SDRAM controller with SOPC builder, but when I > change the data width to 8bits I get the following error.. > > Warning: Signal "az_be_n" of type "byteenable_n" and width 1 must have > width of 2, 4, 8, 16, 32, 64, 128. > > I'm trying to make the system for a 64Mb SDR SDRAM, Micron > MT48LC8M8A2P-75. > > Even when I select the Alliance AS4LC2M8S0-10 chip it does the same > thing. So I'm guessing it has to do with a width of 8 bits. > > Thank you, > Eric If this is your own component that you're trying to make up in SOPC Builder, then I think the problem has to do with that the 'byteenable_n' SOPC input is supposed to be a vector. When you have an 8 bit datapath, there will only be one byte enable input which I'm guessing you have defined as a std_logic and not a std_logic_vector. Wrong: az_be_n: std_logic -- Maps to SOPC's byteenable_n Correct: az_be_n: std_logic_vector(0 downto 0); -- Maps to SOPC's byteenable_n I'm not totally sure, I haven't used SOPC Builder in a while but I seem to recall an issue like this. KJArticle: 125305
hi groups xilinx docs is rather thin (ug454) ... is there somewhere an ucf file, and some public reference design (microblaze) thanks, raphArticle: 125306
austin <austin@xilinx.com> wrote: > The shunt, > Is only required if the Vcco is not drawing enough current, and is > sourced from all IO's when they are high. Best at a slow speed is to Did you look at pbft's circuit proposal. Without a pull-down, the high-low transistion is not defined. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 125307
Thanks to both of you for replying so quickly! I definitely have a lot to learn - thanks again for both replies.Article: 125308
Uwe, Do we care at 6 MHz? If the Cin of the pin is ~10 pf, and the R is 100 ohms, then .7RC = 1E-11 * 1E2 = 1E-9 seconds, or 1 nsec... Of course, added to R=100 ohms is his driver's output pull down resistance. Austin Uwe Bonnes wrote: > austin <austin@xilinx.com> wrote: >> The shunt, > >> Is only required if the Vcco is not drawing enough current, and is >> sourced from all IO's when they are high. Best at a slow speed is to > > Did you look at pbft's circuit proposal. Without a pull-down, the high-low > transistion is not defined.Article: 125309
Miscommunication: Austin says: without the diode, there is no speed problem at 6 MHz Uwe says: with the diode the falling edge is undefined. Both are right, of course... Peter Alfke On Oct 19, 3:45 pm, austin <aus...@xilinx.com> wrote: > Uwe, > > Do we care at 6 MHz? > > If the Cin of the pin is ~10 pf, and the R is 100 ohms, then .7RC = > > 1E-11 * 1E2 = 1E-9 seconds, or 1 nsec... > > Of course, added to R=100 ohms is his driver's output pull down resistance. > > Austin > > Uwe Bonnes wrote: > > austin <aus...@xilinx.com> wrote: > >> The shunt, > > >> Is only required if the Vcco is not drawing enough current, and is > >> sourced from all IO's when they are high. Best at a slow speed is to > > > Did you look at pbft's circuit proposal. Without a pull-down, the high-low > > transistion is not defined.Article: 125310
On 10 19 , 11 26 , Neil Steiner <neil.stei...@vt.edu> wrote: > > I downloaded many many ieee (and other) papers on the subject. But you > > know that papers are good for some purposes and books for others! > > Reading a paper is good to get answer some precise question ... not > > for getting state of the art. > > Agreed. > > > Papers are for researchers. But I'm searching for some books for > > students and newcomers even to FPGA but who would like to get answers > > concerning reconfigurable computing. > > One book that may be worth taking a peek at is "Reconfigurable > Computing: Accelerating Computation with Field-Programmable Gate Arrays" > by Maya Gokhale and Paul Graham, ISBN-10: 0387261052, ISBN-13: > 978-0387261058, Springer 2005. There are three books: System.Level.Design.of.Reconfigurable.Systems.on.Chip.Y2005.Springer.pdf Dynamic Reconfiguration Architectures And Algorithms Feb 2004.Kluwer.pdf Reconfigurable Computing Accelerating Computation with Field- Programmable Gate Arrays.Y2005.pdfArticle: 125311
Now I have ported a design from virtex-2 to virtex-4,because the xilinx announced virtex-4 have a lower dynamic power,but actually when I finished my design,running the same design with virtex-4,the metal face of the package is hot and this phenomenon is not existed in virtex-2.Why?Do anybody have the same phenomenon?Article: 125312
Hello, excuse me for my not perfect English. I must begin a project for the realization of the DVB-T/H modulator. I am documented a lot, using also the specific ETSI, but I have some question without answer. Someone can help me ? 1) The DVB-T/H modulator can be realized with single logical blocks (ex. Adder, Mult, Bram, Logic, Shift, IFFT ecc.) without to use CPU MicroBlaze or PowerPC on a FPGA ? 2) From where it is convenient to leave for the realization. From the end of modulator (DAC, Guard, IFFT, ecc) or from Init of the modulator (ASI in, FIFO, Energy Dispersal ecc.) ? 3) Which type of tool used and in order which part of the project (ISE, System Generator, EDK for Xilinx Project) ? 4) I Am much perplexed one on like all the modulator I can be synchronized, some blocks add given to the flow, like stopping the income ? 5) Some link that it can be of aid ? 6) Someone that reads this Newgroup is successful to realize DVB-T/H ? Thanks for the patience of who have read. By Kappa.Article: 125313
sunry, First, some easy questions: 1. Did you simulate the design? 2. Did you use XPE to estimate the power from your simulation? 3. Are you running the V4 at its proper voltages? 4. Have you used the power estimator on the web to estimate the power required by the IO? (IO power will not scale -- it will not change as this is something that is identical in your application often) Now, some more difficult questions: 5. What was the current on Vccint for the previous part, and what is it now? 6. Same question as 5 for Vccaux 7. Same question as 5 for each Vcco And finally, which size parts did you use, and are using now? "Hot" to the touch is not a very precise measure, and this may just be leakage current (static power), as with no airflow, and no heat sink, even the static power may make a part "warm" to the touch. Part to part process variation may have your previous parts with practically no static power, and the V4 may be at the fast corner of the process, and have much more leakage (comparatively). AustinArticle: 125314
On 19 Okt., 07:17, Thomas Stanka <usenet_nospam_va...@stanka-web.de> wrote: > On 18 Okt., 09:49, Antti <Antti.Luk...@googlemail.com> wrote: > > > the failing desing was made with S 8.8A1 and was not tested with other > > version of synthesis tools > > > after my quiz1 issue, that looked like tool error or faulty FPGA, I > > was not to belive that another problem so close the first one is > > related to tools making a mess, so I was very hard trying to find > > problem in my design. > > > I have made backup of the "known failing with 8.8" design, when i have > > time, i will retest it with 8.6.2 > > Which technology are you using? > Do you read the Actel customer notifications? > "FSM Bug - Synplify=AE 8.6.2H in Libero=AE IDE 7.3, 7.3 SP1, and 7.3 SP2" > This notification states also that you need to use 8.8A2 instead of > 8.8A1 for Axcelerator design due to another bug. > > bye Thomas PA3 it really looks like was caused by "fabric internal clock skew" i use Xilinx AR and errata and well guess no also need read Actel PCNs etc. so 8.8A1 vs 8.9 didnt make a difference only manuall inserting CLK_INT did. I did no (too late but still) run post-layour simulations, and so far did not see the problem in those simulations. did not do yet enough sims to say for sure it will not ever show in simulation, just the few P&R runs did not show it. this single desing that caused the quiz1,2,3 issues is now finally passed all the issues and soon to be verified in full function. and I have some more hard lessons ;) AnttiArticle: 125315
I try to stay with the xilinx eval boards because the documentation and support is quite good. There is a Spartan-3AN board that is only $225 and includes the USB download cable logic on the board so there is nothing else to buy. I believe it has ddr2 as well as serial and ethernet ports for messing with soft processors. http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-SPAR3AN-SK-UNI-G-PROMO&sGlobalNavPick=PRODUCTS&sSecondaryNavPick=BOARDS dan.walmsley@gmail.com wrote: > i have downloaded the xilinx webpack and gone through a few tutorials > on the software can anyone recommend a good starter board, that would > cope with trying a small softcore microcontroller. > > If anyone has any good tutorials or educational material on FPGAs > please could you email me. > > Any advice would be greatly appreciated. > > Dan Walmsley >Article: 125316
http://www.electronicspecifier.com/Active-Components/Ultra-Low-Jitter-S-PDIF-Receiver-from-Texas-Instruments.asp On Oct 18, 9:03 am, aravind <aramos...@gmail.com> wrote: > Hi, > I'm building a S/PDIF Receiver for implementation on spartan 3 > fpga. I don't have an expensive DSO to analyze the spdif signals : > ( So i decided to build a sampler and run it fast enough, say 10-20 > times the spdif signal frequency and the display the signal on some > audio editing software.(remember i'm sampling only digital signals so > there's no ADC involved) > > So here's my setup, I'm taking the input signal and passing it through > a 2 flop synchroniser, then i'm packing 8 samples to a byte and > writing it to a 16K block ram fifo on fpga. The sampled data is sent > to the PC through FTDI's UM245R module. At reset the sampler samples > 16K X 8 samples , writes to fifo and stops. the system is running at > 50Mhz (also sampling input signal at 50msps), the sampling packing and > writing to fifo is done on the fly. Then the usb module writes the > data to the usb port in its own time. > > The problem: > When i sample signals from the same clock domain (i.e, a divided > clock from 50Mhz sys clk) > the are no problems. I see perfect clock signal with nearly 50% duty > cycle and no glitches in sight. but once i feed an external signal > signal such as the spdif or a clock from a different oscillator, the > signal seems to closely match the frequency of the input but I see a > lot of glitches. Most of the glitches are one sample wide and very > close to the rising/falling edges of the input signal. but there are > also quite a few glitches in stable 1's /0's regions of the input > signal. > > So what could be the possible cause of these glitches? I can > understand glitches near the edges which could be due to metastability > but in the middle of stable 1's and 0's there could be no issue of > metastability. I have used 2 flop synchroniser like the ones used in > asynchronous fifo's. What else can i do the eliminate the glitches?Article: 125317
I would like to prevent GLOBAL_LOGIC0 and GLOBAL_LOGIC1 nets from stealing unused slices in a particular region. I don't mind if those or other nets pass through the region, but the logic within the region must remain untouched. Does anybody know how this might be accomplished? This is under ISE/EDK 8.1. I'm not presently using the PR flow, and would rather not use it if there is any alternate way of protecting the slices. (I did try defining an AREA_GROUP with attributes PLACE=CLOSED and MODE=RECONFIG, but that made no difference, either because the tools think these nets are exempt, or because I'm not using the PR flow.)Article: 125318
Hi, I've been looking at available VHDL/Verilog implementations of huffman coders. It appears that all currently available implementations use a fixed codebook (e.g. the one specified in the MPEG standard) for coding and decoding, and thus are quite trivial (they just look up symbols in that fixed codebook). I'm more interested in building a huffman codebook from the input data. It appears that this can become quite difficult due to the use of changing tree structures, which seem quite complicated to do in hardware. Can anyone point me towards readily available (read: free) implementations for such an encoder? Thanks in advance EnnoArticle: 125319
On 2007-10-19, Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> wrote:
> Use level-Shifters, like 74LVC8T245 or "translating bus switches" like
> SN74CB3T1.
If you just need one bit you can get small packages like SN74CBT1G125,
one fet switch in a SOT-23 package.
One thing to beware of is that "first generation" (?) but switches like
QS3384 (and the part I mentioned above) dropped about 1V from their
supply, so 5.0->3.3 used a QS3384 with 4.3V (via a single diode from the
5V). When I had to replace one of those on a proto board, I found most
new ones have no or negligible drop ("rail to rail") and you power them
from the lower rail directly, eg SN74CBTLV3384.
--
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/
Article: 125320>I did develop a RISC a few weeks ago, mainly for fun and to see how it's >done. The problem I am now facing is that there is absolutely *no* tool >that supports it, and I am unable to write a compiler. Do you need a compiler? How about a simple assembler? How much code are you expecting to write? Note that if you are writing timing critical code, it might be simpler to write it in raw assembler where you see every cycle rather than wondering what code the compiler will actually generate. If things are slow enough, you can hide all the delays behind magic constants and just recalibrate when you get a new compiler. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 125321
Il 21/10/2007 0.44, no_reply ha scritto: > Hi, > > I've been looking at available VHDL/Verilog implementations of huffman > coders. It appears that all currently available implementations use a > fixed codebook (e.g. the one specified in the MPEG standard) for > coding and decoding, and thus are quite trivial (they just look up > symbols in that fixed codebook). I'm more interested in building a > huffman codebook from the input data. It appears that this can become > quite difficult due to the use of changing tree structures, which seem > quite complicated to do in hardware. Can anyone point me towards > readily available (read: free) implementations for such an encoder? > > Thanks in advance > Enno > Check "FPGA Implementation of the Dynamic Huffman Encoder", Ernest Jamro, Maciej Wielgosz, Kazimierz Wiatr AGH University of Science and Technology al. Mickiewicz 30, 30-051, Poland Academic Computer Center CYFRONET ul. Nawojki 11, Kraków 30-950, Poland email: jamro / wiatr@agh.edu.pl They "augment" a standard, lookup table huffman encoder with an histogram unit, then use a microblaze to update the table on the fly. To easily implement Huffman in hardware you need a length limited code, so you can use a fixed width ram table to compress. So you may be interested in this, also: http://en.wikipedia.org/wiki/Package-merge_algorithm The links at the bottom are a very good place to start. I didn't find any free core, so far. Please share your results!Article: 125322
We have recently been using a Xilinx ML506 board with good effect as a logic verification platform. In many cases we need to have a software interface to our designs in order to really debug them. The ML50X boards have a PCI Express 1x edge connector that allows you to plug the board into a pcie slot in a cheap PC. The Virtex 5 T parts have the tranceivers and PCIe endpoint that really make it easy to get an interface up and running quickly. A skilled linux programmer put together a driver in an afternoon and now we are writing test programs against production firmware. This is more work to get going than a vhdl testbench but it runs at full speed once you get it going. In our case, we are verifying DSP logic that requires hundreds of millions of clock cycles to really say it is working. With real hardware in the loop we can quickly write C test programs that loop over the entire parameter space of the design. V5 PCIe really works! Pete yeah wrote: > Hi friends > > I am working in a pvt concern.We are decided to purchase FPGA trainer > kit. > But we are confused with Xilinx-Virtex-5 and Altera-stratix-3. > Which one will be the better in configuration? > Feauture-wise which one will be better? > And which altera device has the feature of ML505 in Virtex-5? > > Plz give up some ideas regarding thiz... > > thanks >Article: 125323
On Oct 21, 6:04 pm, "pdudl...@comcast.net" <pdudl...@comcast.net> wrote: > We have recently been using a Xilinx ML506 board with good effect as a > logic verification platform. > > In many cases we need to have a software interface to our designs in > order to really debug them. The ML50X boards have a PCI Express 1x edge > connector that allows you to plug the board into a pcie slot in a cheap PC. > > The Virtex 5 T parts have the tranceivers and PCIe endpoint that really > make it easy to get an interface up and running quickly. A skilled linux > programmer put together a driver in an afternoon and now we are writing > test programs against production firmware. > > This is more work to get going than a vhdl testbench but it runs at full > speed once you get it going. In our case, we are verifying DSP logic > that requires hundreds of millions of clock cycles to really say it is > working. With real hardware in the loop we can quickly write C test > programs that loop over the entire parameter space of the design. > > V5 PCIe really works! > > Pete > > yeah wrote: > > Hi friends > > > I am working in a pvt concern.We are decided to purchase FPGA trainer > > kit. > > But we are confused with Xilinx-Virtex-5 and Altera-stratix-3. > > Which one will be the better in configuration? > > Feauture-wise which one will be better? > > And which altera device has the feature of ML505 in Virtex-5? > > > Plz give up some ideas regarding thiz... > > > thanks I have been quite satisfied with the Virtex-4 ML403 development board.Read my blog to find out more. http://www.fpgafromscratch.com SvenArticle: 125324
Hi, Just wondering what could go wrong when synthesizing memories (i- cache, d-cache, and write buffer) of microprocessors on fpga Xilinx Virtex 5? Thanks! Wei
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