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
I far as I am aware you cant change the bitstream size. I dont really see why you would want to do that. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 151001
Un bel giorno Alex digiṭ: > I've got Spartan-3E Evaluation Kit and I need to realize a programmable > generator of pulses of nanosecond duration. The problem is as follows: I've > got a trigger pulse and I need to generate a TTL pulse of nanosecond > duration with programmable width (with step about 200-500 ps, range 2 ns - > 100 ns (for example)) and programmable delay (with 200-500 ps step). The > maximum delay from in to out must not be more than 10 ns. > Actually I need to realize a wide-range pulse generator, but as I > understand there is no problem generate wide pulses (more than 100 ns) with > larger step (10 ns) working in synchroneous regime and using clock. But for > narrow pulses I think I should work in asynchroneous regime. I could use > elements with known delay and link them into a chain. You could try to feed a DCM with a clock, generate another clock with a very small phase difference with the first one (you have resolutions down to tens of ps) and then try to XOR them with some combinatorial logic (or by using an output buffer with enable). -- emboliaschizoide.splinder.comArticle: 151002
"Dom Bannon" <nospam@nospam.com> wrote in message news:24ifm616e4fahpphnppdh33lf8e7n3og4n@4ax.com... > On Fri, 25 Feb 2011 16:00:34 +0100, "Morten Leikvoll" > <mleikvol@yahoo.nospam> wrote: > >>"Dom Bannon" <nospam@nospam.com> wrote in message >>news:la1fm6pel35182jhpkd5b19cvus3h28te7@4ax.com... > >>> BTW, if you do integer conversion first, as you suggest in another >>> post, it won't 'work' either. If you use 'TO_01', you'll get a warning >>> if you try to convert an 'X'. You can convert '0' to integer 0 if you >>> want to, but that wont affect any of the numeric_std multiplies. >> >>A warning I can live with. But I wonder what the invalid result will be.. >>Since integers cant go 'x' the result may end up with what I need. I >>prefer >>that to conditional simulation code. > > Integers can't be X, but you've got an X in your circuit somewhere. > You could convert your X's to 0 with the numeric_std to_01 > (to_01(my_int, '0')). The default is to set X's to '0' if you leave > out the second parameter. > > This is not a smart thing to do, though. You need to get rid of your > X's instead of persuading the simulator to treat them 'correctly' > according to your application. Ive seen some good arguments here why 'X'*zero is not always zero, but they are all only valid in "theoretical space". When it comes down to the real implementation there is nothing that can be multiplied with 0 and become <>0, since my input can not be NaN (at least not in my unsigned fixed point world), or even infinity in real life. I guess in the negative zero case, it should go negative zero unless you multiply it with a negative zero? So I guess I have to work with the model not being a "real life" model. Maybe the std_logic just doesn't do, and make my own datatype and operators for it. (or just live with bad conditional code)Article: 151003
On 02/28/2011 06:36 AM, Eugen_pcad_ru wrote: > Hello all! > I need pll which can: > 1) 40 MHz -> 320 MHz (0 deg), > 320 MHz (15 deg), > 320 MHz (30 deg), > 320 MHz (45 deg), > 320 MHz (60 deg) > 320 MHz (75 deg), > 320 MHz (90 deg), > 320 MHz (105 deg), > 320 MHz (120 deg), > 320 MHz (135 deg), > 320 MHz (150 deg), > 320 MHz (165 deg), > 320 MHz (180 deg). > They can be together or not. > And I have two fpgas: Cyclone III (Altera), Spartan-3AN. > What fpga is better for me? Why? Or its no difference? I don't know about the Altera part, but Xilinx is too cool to use phase-locked loops -- they use delay-locked loops instead (see the data sheet). This means that they can maybe generate the clock you need, but they'll do it by delaying the 40MHz clock, and they'll demand that your clock edges have no more than 150ps of jitter. In other words, you need to feed it a 40MHz clock that jitters no worse than a good 320MHz clock. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 151004
>It would be better if the simulator would be able to work with 'X' >signals, and return sensible results. > >For instance, if you turn a computer on, the RAM memory will be >initialized to a random state, and it will still work correctly every >time it boots up. In the case of RAM, it works because the system stores something useful into RAM before it reads it. >It would be nice if you could represent that unknown state by filling >the memory with 'X' during a simulation, and see if the model will still >run correctly. This requires that the simulator knows that X & 0 = 0, >and X | 1 = 1, and as a consequence, that X * 0 = 0. I'd prefer the simulator to give an error/warning if it reads an X from a RAM. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 151005
Richi <richardmolgner2@gmail.com> wrote: > I have a very simple VHDL module, consisting of a few lines of code. > The thing is, when I generate the bitstream, I end > up with a huge bitstream. The reason for this is, I guess, that XST > adds lots of extra information so that the bitstream > can run standalone on a FPGA. > However, for my purpose it would be interesting to see the size of the > bitstream of the module alone without any extra bits and pieces, just > the vaniall module alone. Is there an option in Xilinx ISE 12.1 that > allows me to do that? If you just want to see how much 'information' is in the file (in terms of information theory) try compressing it with a program such as gzip. There will likely be many empty CLBs with the same bit pattern for each one. A good compress program should find that pattern and compress it out. That should be pretty close to what you are asking for. You could, of course, decompress it in software or hardware on board, just before loading it into the FPGA. It is more usual to use a large enough ROM, but there is no rule requiring that. -- glenArticle: 151006
On Monday, February 28, 2011 9:32:26 AM UTC-5, Richi wrote: > Hi all, > > I have a very simple VHDL module, consisting of a few lines of code. > The thing is, when I generate the bitstream, I end > up with a huge bitstream. The reason for this is, I guess, that XST > adds lots of extra information so that the bitstream > can run standalone on a FPGA. > > However, for my purpose it would be interesting to see the size of the > bitstream of the module alone without any extra bits and pieces, just > the vaniall module alone. Is there an option in Xilinx ISE 12.1 that > allows me to do that? > > Many thanks, > Richi You didn't specify the device family, but most Xilinx parts support bitstream compression. Their algorithm is much simpler than you get from gzip or winzip, but for a mostly empty part the compression should be significant. You can enable compression in the BitGen options. -- GaborArticle: 151007
Alex <aivochkin@n_o_s_p_a_m.gmail.com> wrote: > I've got Spartan-3E Evaluation Kit and I need to realize a programmable > generator of pulses of nanosecond duration. The problem is as follows: I've > got a trigger pulse and I need to generate a TTL pulse of nanosecond > duration with programmable width (with step about 200-500 ps, range 2 ns - > 100 ns (for example)) and programmable delay (with 200-500 ps step). The > maximum delay from in to out must not be more than 10 ns. Can you give some hint as to why you need pulses like that? That might have some influence on the type of design that can generate them. Also, if it is a homework problem, you will get appropriate answers for that case. > Actually I need to realize a wide-range pulse generator, but as I > understand there is no problem generate wide pulses (more than 100 ns) with > larger step (10 ns) working in synchroneous regime and using clock. But for > narrow pulses I think I should work in asynchroneous regime. I could use > elements with known delay and link them into a chain. There are some designs like that. It isn't easy, but sometimes it is possible. There are also some mixed analog/digital solutions to problems like this. You can, for example, charge a capacitor with a current determined by the FPGA, and, through a comparitor on the output, generate the pulse. > If it possible to realize such project using Spartan-3E FPGA chip, > or maybe I need something from Virtex family. I believe that Virtex is often faster, and so may allow for clock rates fast enough to do this as synchronous logic. -- glenArticle: 151008
You are interpreting std_logic 'X' as "I don't care, but it is stable." This is not the definition of 'X'. It means undefined, and could be anything, including transitioning between states continuously. Depending upon the implementation, multiple inputs changing continuously at the same time can result in non-obvious results. Thus propagating X * ? to X makes some sense. You are also using an unofficial package placed in the ieee library by synopsys, and other vendors followed suit to provide compatibility with synopsys. Use ieee.numeric_std instead (or, if your tool supports vhdl 2008, then use numeric_std_unsigned, which is the functional equivalent of std_logic_unsigned). Both of these are ieee controlled, reviewed and balloted packages which guarantee compatibility between vendors that support them (not the case with std_logic_unsigned). However, as stated earlier, numeric_std (and I presume numeric_std_unsigned) both set the results to X if either input contains one or more bits of 'X'. If this is important to you, the vhdl200x standard is in early development and is taking suggestions for improvements. This is an excellent reason for using official IEEE sactioned packages instead of synopsys ones: You have a mechanism for changing the IEEE packages. Because synopsys does not control other vendors' versions of std_logic_unsigned, the package cannot be changed as effectively as can official IEEE standards. You can wrap the operation with additional simulated logic that checks either operand for all bits=0 and forces the output to 0. AndyArticle: 151009
On Monday, February 28, 2011 9:36:44 AM UTC-5, Alex wrote: > Hello, I'm a novice in FPGA, so please forgive me if I'm asking simple > questions. > > I've got Spartan-3E Evaluation Kit and I need to realize a programmable > generator of pulses of nanosecond duration. The problem is as follows: I've > got a trigger pulse and I need to generate a TTL pulse of nanosecond > duration with programmable width (with step about 200-500 ps, range 2 ns - > 100 ns (for example)) and programmable delay (with 200-500 ps step). The > maximum delay from in to out must not be more than 10 ns. > Actually I need to realize a wide-range pulse generator, but as I > understand there is no problem generate wide pulses (more than 100 ns) with > larger step (10 ns) working in synchroneous regime and using clock. But for > narrow pulses I think I should work in asynchroneous regime. I could use > elements with known delay and link them into a chain. > If it possible to realize such project using Spartan-3E FPGA chip, or maybe > I need something from Virtex family. > > Thank you in advance. > Alex. > > > > > > --------------------------------------- > Posted through http://www.FPGARelated.com What you're trying to do will be very difficult in any FPGA unless the input is periodic (like a clock). Any kind of asynchronous delay derived from internal prop delays (delay through LUT's) will have very wide variations over process, temperature and voltage. Spartan 3E does not contain output delay elements in the IOB's. Virtex 4 or Virtex 5 have calibrated output delay elements, but again you'll have issues with the small total delay through the chip. If your input signal is periodic and running at a frequency that can lock a DCM, then you have more options. For example running the input to more than one DCM, and using programmable phase shifting. You could also possible use a DDR output flop with a clock tied to each DCM, however you'd still have problems when the two clock phases become very close to eachother. -- GaborArticle: 151010
Hi, enter the menu "tool", and then press on "edit preference". in the right window, titled "window list", choose "source window". then in the left part, under the title "fonts", you can choose the font and its size. !!!important!!! you may need to widen the window, to see all the options (like the font size).Article: 151011
Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote: (snip, someone wrote) >>For instance, if you turn a computer on, the RAM memory will be >>initialized to a random state, and it will still work correctly every >>time it boots up. > In the case of RAM, it works because the system stores something > useful into RAM before it reads it. It is not always so easy. For ECC, it is necessary to write using appropriate sized words aligned properly. Otherwise, ECC requires the memory subsystem to do a read-modify-write cycle that will fail if the memory isn't in the right state. It is, however, an interesting question as to the state of memory on power-up. We assume it is random, but is that likely? For SRAM, the power-up state might depend on imperfections in the memory cell, such that one side is slightly stronger or faster than the other. Many years ago I worked with a display device using SRAM, and wondered if the power-up state was always the same. Even more interesting, for DRAM it might depend on effects that could be influenced by keeping the same data in for a long time. That has some information security considerations. -- glenArticle: 151012
I am implementing a design using Virtex-6 Device:XC6VLX550T Package:FF1759 = and Speed:-2. My top module instantiates 16 units, where each unit instantiates 18x8 mult= iplier 49 times. This means that my design is using 784 multipliers. The nu= mber of DSP48 modules available on the Virtex-6 device is 864 which means t= hat less than 100% of resources are used.=20 However, when I synthesize my design, I see this information:=20 Primitive and Black Box Usage: ------------------------------ # IO Buffers : 26946 # IBUF : 6562 # OBUF : 20384 # Others : 784 # xcorr_mult_18x8 : 784 Device utilization summary: --------------------------- Selected Device : 6vlx550tff1759-2=20 Slice Logic Utilization:=20 Slice Logic Distribution:=20 Number of LUT Flip Flop pairs used: 0 Number with an unused Flip Flop: 0 out of 0 =20 Number with an unused LUT: 0 out of 0 =20 Number of fully used LUT-FF pairs: 0 out of 0 =20 Number of unique control sets: 0 IO Utilization:=20 Number of IOs: 26946 Number of bonded IOBs: 26946 out of 840 3207% (*)=20 The Mapping report shows: Interim Summary --------------- Slice Logic Utilization: Number of Slice Registers: 0 out of 687,360 0% Number of Slice LUTs: 0 out of 343,680 0% Slice Logic Distribution: Number of LUT Flip Flop pairs used: 0 IO Utilization: Number of bonded IOBs: 26,946 out of 840 3207% (OV= ERMAPPED) Specific Feature Utilization: Number of RAMB36E1/FIFO36E1s: 0 out of 632 0% Number of RAMB18E1/FIFO18E1s: 0 out of 1,264 0% Number of BUFG/BUFGCTRLs: 0 out of 32 0% Number of ILOGICE1/ISERDESE1s: 0 out of 1,440 0% Number of OLOGICE1/OSERDESE1s: 0 out of 1,440 0% Number of BSCANs: 0 out of 4 0% Number of BUFHCEs: 0 out of 216 0% Number of BUFOs: 0 out of 72 0% Number of BUFIODQSs: 0 out of 144 0% Number of BUFRs: 0 out of 72 0% Number of CAPTUREs: 0 out of 1 0% Number of DSP48E1s: 784 out of 864 90% Number of EFUSE_USRs: 0 out of 1 0% Number of FRAME_ECCs: 0 out of 1 0% Number of GTXE1s: 0 out of 36 0% Number of IBUFDS_GTXE1s: 0 out of 18 0% Number of ICAPs: 0 out of 2 0% Number of IDELAYCTRLs: 0 out of 36 0% Number of IODELAYE1s: 0 out of 1,440 0% Number of MMCM_ADVs: 0 out of 18 0% Number of PCIE_2_0s: 0 out of 2 0% Number of STARTUPs: 1 out of 1 100% Number of SYSMONs: 0 out of 1 0% Number of TEMAC_SINGLEs: 0 out of 4 0% Mapping completed. See MAP report file "xcorr_pixel_channel_map.mrp" for details. Problem encountered during the packing phase. Design Summary -------------- Number of errors : 2 Number of warnings : 0 Section 1 - Errors ------------------ ERROR:Pack:2309 - Too many bonded comps of type "IOB" found to fit this dev= ice. ERROR:Map:237 - The design is too large to fit the device. Please check the= Design Summary section to see which resource requirement for your design e= xceeds the resources available in the device. Note that the number of slice= s reported may not be reflected accurately as their packing might not have = been completed. NOTE: An NCD file will still be generated to allow you to examine the mappe= d design. This file is intended for evaluation use only, and will not proce= ss successfully through PAR. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D How can I reduce the number of Bonded IOBs? Note: I have not specified an User Constraint File (.ucf) yet, as I am dete= rmining whether the design will fit or not on the selected FPGA. Thanks in advance.Article: 151013
In article <c7672a44-b425-4842-81cb-808300f85b7b@glegroupsg2000goo.googlegroups.com>, Vivek Menon <comp.arch.fpga@googlegroups.com> wrote: >I am implementing a design using Virtex-6 Device:XC6VLX550T Package:FF1759 = >and Speed:-2. > >My top module instantiates 16 units, where each unit instantiates 18x8 mult= >iplier 49 times. This means that my design is using 784 multipliers. The nu= >mber of DSP48 modules available on the Virtex-6 device is 864 which means t= >hat less than 100% of resources are used.=20 I suspect you're instantiating a unit whose multipliers have the output and one input marked as connected to the outside world; you seem to have about eight inputs and 18+8 outputs per multiplier. Obviously the FPGA doesn't have the thirty thousand pins that would imply! TomArticle: 151014
My port definition is as follows: --Inputs clk : in std_logic; ce : in std_logic; pixel_in : in std_logic_vector(17 downto 0); refim_in : in std_logic_vector(391 downto 0); -- 49 inputs of 8 bits each -- Outputs xcorr_prod_out : out std_logic_vector(1273 downto 0); --49 outputs of 26 bits each component mult_18x8 port ( clk : in std_logic; a : in std_logic_vector(17 downto 0); b : in std_logic_vector(7 downto 0); ce : in std_logic; p : out std_logic_vector(25 downto 0)); end component; --------------------------------- I thought it would be easier for naming and connection by building a single signal of 1274 bits rather than having 49 signals of 26 bits.Article: 151015
In article <240bfd78-c71f-497b-a093-ba23f37c8e40@glegroupsg2000goo.googlegroups.com>, Vivek Menon <comp.arch.fpga@googlegroups.com> wrote: >My port definition is as follows: >--Inputs >clk : in std_logic; >ce : in std_logic; >pixel_in : in std_logic_vector(17 downto 0); >refim_in : in std_logic_vector(391 downto 0); -- 49 inputs of 8 bits each > >-- Outputs >xcorr_prod_out : out std_logic_vector(1273 downto 0); --49 outputs of 26 bits each Yes, so if you're instantiating those without connecting them together, all those ins and outs are mapped to pins, and unsurprisingly you're using thirty times as many pins as the chip has. Add another component which has a single input and feeds that into a shift register which drives the pixel_in and refim_in of all the machines, takes out the xcorr_prod_out of all the machines and (eg) xors its bits together. Connect the out of that to some LED-driving pin, and you have a large and complicated device which has only two pins. Then you can discover whether the routing fits on the FPGA. TomArticle: 151016
On 02/28/2011 01:55 PM, Thomas Womack wrote: > In article<240bfd78-c71f-497b-a093-ba23f37c8e40@glegroupsg2000goo.googlegroups.com>, > Vivek Menon<comp.arch.fpga@googlegroups.com> wrote: >> My port definition is as follows: >> --Inputs >> clk : in std_logic; >> ce : in std_logic; >> pixel_in : in std_logic_vector(17 downto 0); >> refim_in : in std_logic_vector(391 downto 0); -- 49 inputs of 8 bits each >> >> -- Outputs >> xcorr_prod_out : out std_logic_vector(1273 downto 0); --49 outputs of 26 bits each > > Yes, so if you're instantiating those without connecting them > together, all those ins and outs are mapped to pins, and > unsurprisingly you're using thirty times as many pins as the chip has. > > Add another component which has a single input and feeds that into a > shift register which drives the pixel_in and refim_in of all the > machines, takes out the xcorr_prod_out of all the machines and (eg) > xors its bits together. Connect the out of that to some LED-driving > pin, and you have a large and complicated device which has only two > pins. Then you can discover whether the routing fits on the FPGA. > > Tom I was going to suggest that you connect them all to a device that ignores them -- but then they'll get optimized out of existence, wouldn't they? Wouldn't XOR-ing all the outputs together use up tons-o-real estate? It seems like it'd take less real estate to load up shift registers with those outputs, and shift the result out a single pin. Either way, I suppose you'll be able to see in the device map output how much of the chip is going away to your "glue". -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 151017
On Feb 28, 12:15=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > I believe that Virtex is often faster, and so may allow for clock > rates fast enough to do this as synchronous logic. > > -- glen Unless my math is wrong, 200pS increments require a 5GHz clock. Perhaps the Virtex-12 will be that fast, but the -7 isn't. There may be a way to do what the OP wants with IODELAY elements, but would involve real research. RKArticle: 151018
THanks for the tip. I am currently only setting the LSB as the output pin. Started the Synthesis procedure and waiting to see the Synthesis report if the 26946 IOB utilization disappears. I am using a transceiver to receive the input data, so that has minimum pin usage.Article: 151019
On Monday, February 28, 2011 5:32:40 PM UTC-5, NeedCleverHandle wrote: > > Unless my math is wrong, 200pS increments require a 5GHz clock. > > Perhaps the Virtex-12 will be that fast, but the -7 isn't. > > There may be a way to do what the OP wants with IODELAY elements, but > would involve real research. > > RK I think he was looking for a delay-based solution, but the problem is that Spartan 3E does not have IODELAY, only IDELAY, and those are not as flexible as even the IDELAY of Spartan 3A. Also to get a calibrated delay element you need to go to a V4 or V5 part. -- GaborArticle: 151020
my project is implementing of blowfish algorithm in FPGA and sending the data from PC through FPGA and encrypt the data.for this which protocols i can use.please tell me some links related to it.Article: 151021
On 28 Feb., 15:32, Richi <richardmolgn...@gmail.com> wrote: > I have a very simple VHDL module, consisting of a few lines of code. > The thing is, when I generate the bitstream, I end > up with a huge bitstream. The reason for this is, I guess, that XST > adds lots of extra information so that the bitstream > can run standalone on a FPGA. Complexity of a design is NOT measured in size of the bitstream. In first glance each design for same device has similar bitstream size. If you like to learn something about complexity of a module, you stop after synthesis or layout and start counting CLBs (or registers,...)Article: 151022
> You didn't specify the device family, but most Xilinx > parts support bitstream compression. Their algorithm > is much simpler than you get from gzip or winzip, but > for a mostly empty part the compression should be > significant. You can enable compression in the BitGen > options. Thanks for all the answers of you guys, very helpful. It is a Xilinx Virtex 5 board. I will try it with the compression option. Essentially, I have a couple of designs that I wanna use for partial reconfiguration (so they are part of a bigger bitstream), and I would like to know their sizes in kB to see how much memory I have to allocate on SRAM where I can hold then these bitstreams. Of course I could do the partial bitstream generation but this is a rather long process so I would prefer to get an estimation of the size of the bitstream in a faster way. So when using the compression algorithm this comes pretty close to the actual size of the partial bitstream? Thanks in advance, R. From prenom.nom@gmail.com Tue Mar 01 03:44:06 2011 Path: unlimited.newshosting.com!s03-b02.iad!npeersf01.iad.highwinds-media.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!cleanfeed2-a.proxad.net!nnrp11-2.free.fr!not-for-mail Date: Tue, 1 Mar 2011 12:44:06 +0100 From: Matthieu Michon <prenom.nom@gmail.com> Newsgroups: comp.arch.fpga Subject: Re: Question regarding bitstream generation Message-Id: <20110301124406.f01a819a.prenom.nom@gmail.com> References: <de8666eb-e854-45cd-b695-eb7faad9e519@a5g2000vbs.googlegroups.com> X-Newsreader: Sylpheed 3.0.2 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Lines: 25 Organization: Guest of ProXad - France NNTP-Posting-Date: 01 Mar 2011 12:44:07 MET NNTP-Posting-Host: 213.215.9.6 X-Trace: 1298979847 news-1.free.fr 14855 213.215.9.6:61106 X-Complaints-To: abuse@proxad.net Xref: unlimited.newshosting.com comp.arch.fpga:108991 X-Received-Date: Tue, 01 Mar 2011 11:45:08 UTC (s03-b02.iad) On Mon, 28 Feb 2011 06:32:26 -0800 (PST) Richi <richardmolgner2@gmail.com> wrote: > I have a very simple VHDL module, consisting of a few lines of code. > The thing is, when I generate the bitstream, I end > up with a huge bitstream. The reason for this is, I guess, that XST > adds lots of extra information so that the bitstream > can run standalone on a FPGA. AFAIK, with the default settings, "bitgen" generates bitstreams which are identical in size for a given target device, regardless of the design contents. You can make the analogy with a bitmap image file : when using the BMP file format, the file size is identical regardless of it contents (high-def very shrap image; plain all white; ...). Using a compressed file type (jpeg, png, ...) will yield different results. > However, for my purpose it would be interesting to see the size of the > bitstream of the module alone without any extra bits and pieces, just > the vaniall module alone. Is there an option in Xilinx ISE 12.1 that > allows me to do that? Yes. Look for a option called bitstream compression in the bitgen options. -- Matthieu Michon <prenom.nom@gmail.com>Article: 151023
Dear all,
I have come up with 2 solutions in VHDL, how to count number of bits
in input data.
The thing I don't understand is why the 2 solutions produce different
results, at least with Xilinx ISE and its XST.
There is quite a substantial difference in required number of slices/
LUTs.
1. solution with unrolled loop: 41 slices, 73 LUTs
2. solution with loop: 54 slices, 100 LUTs
The entity of both architectures is the same:
entity one_count is
Port ( din : in STD_LOGIC_vector(31 downto 0);
dout : out STD_LOGIC_vector(5 downto 0)
);
end one_count;
The architecture with an unrolled loop is the following:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
entity one_count is
Port ( din : in STD_LOGIC_vector(31 downto 0);
dout : out STD_LOGIC_vector(5 downto 0)
);
end one_count;
architecture one_count_unrolled_arch of one_count is
signal cnt : integer range 0 to 32;
begin
cnt <= to_integer(unsigned(din( 0 downto 0))) +
to_integer(unsigned(din( 1 downto 1))) +
to_integer(unsigned(din( 2 downto 2))) +
to_integer(unsigned(din( 3 downto 3))) +
to_integer(unsigned(din( 4 downto 4))) +
to_integer(unsigned(din( 5 downto 5))) +
to_integer(unsigned(din( 6 downto 6))) +
to_integer(unsigned(din( 7 downto 7))) +
to_integer(unsigned(din( 8 downto 8))) +
to_integer(unsigned(din( 9 downto 9))) +
to_integer(unsigned(din(10 downto 10))) +
to_integer(unsigned(din(11 downto 11))) +
to_integer(unsigned(din(12 downto 12))) +
to_integer(unsigned(din(13 downto 13))) +
to_integer(unsigned(din(14 downto 14))) +
to_integer(unsigned(din(15 downto 15))) +
to_integer(unsigned(din(16 downto 16))) +
to_integer(unsigned(din(17 downto 17))) +
to_integer(unsigned(din(18 downto 18))) +
to_integer(unsigned(din(19 downto 19))) +
to_integer(unsigned(din(20 downto 20))) +
to_integer(unsigned(din(21 downto 21))) +
to_integer(unsigned(din(22 downto 22))) +
to_integer(unsigned(din(23 downto 23))) +
to_integer(unsigned(din(24 downto 24))) +
to_integer(unsigned(din(25 downto 25))) +
to_integer(unsigned(din(26 downto 26))) +
to_integer(unsigned(din(27 downto 27))) +
to_integer(unsigned(din(28 downto 28))) +
to_integer(unsigned(din(29 downto 29))) +
to_integer(unsigned(din(30 downto 30))) +
to_integer(unsigned(din(31 downto 31)));
dout <= std_logic_vector(to_unsigned(cnt,6));
end one_count_unrolled_arch ;
And the architecture with a loop is the following:
architecture one_count_loop_arch of one_count_loop is
signal cnt : integer range 0 to 32;
begin
process(din) is
variable tmp : integer range 0 to 32;
begin
tmp := to_integer(unsigned(din(0 downto 0)));
for i in 1 to 31 loop
tmp := tmp + to_integer(unsigned(din(i downto i)));
end loop;
cnt <= tmp;
end process;
dout <= std_logic_vector(to_unsigned(cnt,6));
end one_count_loop_arch ;
I would be really grateful if somebody could point out what I did
wrong with the 2. solution with loop.
It certainly must be my mistake, but I can not find it...
Additionally, I know that this "brute-force" one counting might not be
the optimal approach,
but this is just my first attempt to get the job done. If somebody has
a better solution, I would
appreciate it if you could share it.
Regards,
Peter
Article: 151024>my project is implementing of blowfish algorithm in FPGA and sending >the data from PC through FPGA and encrypt the data.for this which >protocols i can use.please tell me some links related to it. > What is the data rate you need to send from PC to FPGA? Is it streaming? Are you sending any data back from FPGA to PC? --------------------------------------- Posted through http://www.FPGARelated.com
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